
Security 101 for SaaS startups - lumisota
https://github.com/forter/security-101-for-saas-startups/blob/master/readme.md
======
wink
Previous discussion:
[https://news.ycombinator.com/item?id=13797834](https://news.ycombinator.com/item?id=13797834)

------
graystevens
I'm not sure if it's the fact I work in the industry and therefore in a bit of
an echo chamber, but almost every other story has a security angle these days
- and that can only be a good thing, raising its awareness.

Whilst this list isn't perfect, it's certainly a good starting block. Oh, and
obviously these suggestions aren't just for start ups! It's nice seeing about
the risk of 'insider threats and data leakage' being brought up, seeing as I'm
working on a service in these areas.

------
nodesocket
Security is a huge concern for companies and largely executives who typically
aren't as technical. It keeps them up at night, mainly because they can't
control it and to a certain extent they don't understand a lot of the
technical details and attack surfaces.

In January I founded a DevOps and infrastructure consulting startup (shameless
plug [https://elasticbyte.net](https://elasticbyte.net)) and security audits
and best practices is one of the top "value" adds of my service. I don't claim
to be a crypto expert or DevSec guru, but most of the issues aren't deeply
technical problems like what CloudFlare experienced. Usually it just takes
rigor and following best practices, firewall rules, don't share keys and
passwords, two factor auth, use IAM, use jump hosts, if a server doesn't need
public access don't provision a public address. Isolate services and dev and
staging environments.

~~~
lykron
ElasticByte looks kinda cool. I'm curious to the market for it, as you seem to
fit between "We can use heroku" and "We can hire two people."

~~~
carterehsmith
You forgot DevOps. Enter credit card #, acquire +12 DevOps, +33 stamina, +7
Heroku.

There, you just gained an unfair edge against your competition. Amazing? Yes.

------
jbaviat
For a more checklist oriented approach you might also find this other list
helpful.

It is a reminder of all measures you could take, at a higher level, about
technical as well as cultural things you need to do about security.

[https://cto-security-checklist.sqreen.io/](https://cto-security-
checklist.sqreen.io/)

Full disclosure: I worked on it (feel free to send me feedback)

------
twakefield
"Once your sales starts selling to large customers, they would report back on
compliance requirements and certifications related to security."

And get ready for the questionnaires, each different enough to maximize the
time spent on them. The Vendor Security Alliance[0] is attempting to
standardize them. Although, I'm not sure how much uptake it's getting. At a
minimum, it's a good example of a typical questionnaire.

[0]
[https://www.vendorsecurityalliance.org/](https://www.vendorsecurityalliance.org/)

~~~
ryanmarsh
I don't see how any small company could provide a sufficient response that
questionnaire at a reasonable cost in a reasonable amount of time. I'm not
saying security isn't important. Just that looks like a lot of money down the
drains.

~~~
intrasight
First, with modern SaaS platforms, it's not that hard to do security right.
Seconds, it's not like you can say "no, I'm not going to fill out your
questionare".

------
lykron
"A third domain is needed for internal use and back office. This domain would
probably be registered anonymously, so it would be a little more difficult to
find."

Um, security through obscurity is not security. And I don't get this? Are we
talking Active Directory? It can be a subdomain off your root domain that is
only accessible internally.

~~~
inopinatus
No. Absolutely not I'd say - because the purpose of an infrastructure domain
isn't obscurity. That is simply a minor side-effect. The #1 reason is to
assist in separation of concerns for the control plane, especially given the
human factors in managing trust relationships between devices. The name should
a) be instantly and recognisably distinct, b) easy and quick to type, and c)
not creating risks of fuzzing a trust boundary due to misunderstood
hierarchical naming.

Also, no-one should be using AD for SaaS infrastructure. It is a pretty good
product for your enterprise internal services, but cannot handle the rather
different needs of a SaaS system directory.

~~~
programd
So what should be used for SaaS directory infrastructure?

~~~
inopinatus
That's a damn fine question. There's probably a book in it.

Briefly, though, keep it federated; layering integrity is super important for
systematic consistency and quality, so wherever possible, entities should
register using the tools provided by the PaaS/IaaS layers that the SaaS is
inevitably running on. This includes any home-grown PaaS/IaaS, which are
pretty common in SaaS at scale. I like to delegate a DNS subdomain to each
subsystem, which is then served either natively from that subsystem (e.g.
because its control plane used etcd) or using script-generated zones served by
nsd. The only central aspect I want is the meta-directory that contains,
ideally, nothing but delegations under the infrastructure domain name.

