Previous discussion: https://news.ycombinator.com/item?id=13797834

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.

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) 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.

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."

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.

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/

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

"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/

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.

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".

"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.

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.

I'm not saying to use AD for a SaaS product, I'm saying the advice on having an obscure domain is a bad one. The SaaS product is saas.com, the company domain is company.com, and the IPA or AD Domain is domain.company.com. I don't see any good reason to have a 3rd domain floating around for directory services. If anything it is another thing to manage and keep track of.

So what should be used for SaaS directory infrastructure?

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.