A pretty useful, logical and sensible list. I'd be actually surprised if most SaaS startups were NOT doing this. As a one man show (recently doubled in size to TWO!), I've ticked off nearly everything on here.<p>One question though - is on the multiple domains bit. Not sure how several separate domains is better than one domain utilising subdomains for API etc.? Intrigued about the 'secret' internal domain thing, and I guess it would apply to larger organisations.<p>I'd be interested to hear how many startup founders here have a separate internal domain name for back office stuff related to their web offerings.
Might not contribute much to the discussion, but I found this pretty sad:<p>- Mac users can encrypt their drive with 1 click.<p>- Windows users would need the Pro version and prefer laptop hardware that supports TPM.<p>- Linux users would require disk reformatting
Good advice but this is a little dubious "For other internal communication use Slack". Use slack because it is beautiful and free, not because of security
A few remarks/questions<p>> Stop using disk-on-keys<p>never heard that phrase<p>> Buy at least 2 or 3 domain names<p>I don't really understand the whole paragraph - or fundamentally disagree with your reasoning. Of course there are some upsides (regarding security) of splitting stuff over a few domains but there's a lot of reason why you wouldn't do that. I think this is written too harshly as "Do as I say" without <i>proper</i> explanations and nuances of the details.<p>> Monitor your endpoint's public certificate expiration date, to detect prevent certificate expiration.<p>typo? missing "and"? remove "detect"?<p>> By default AWS users choose Oregon (us-west-2).<p>Highly misleading. Or is your advice only relevant for US companies? I'd also say this is false for many people who have an international market leaning towards Europe, not Asia - then us-east is often better.<p>> Using git would allow you to add outsource/freelance developers for a limited time, by giving and then revoking commit permissions.<p>Non-sequitur unless you insert "easily". Maybe. I don't disagree that git is the way to go, but your reasoning is nonsensical here. We did exactly that with CVS and SVN 15 years ago.<p>> Every service you use requires a 2nd authentication factor (2FA).<p>This is under "your first customer". Was this meant to be "should require"? Are you talking about the XaaS you (the company) are using? Are you advocating that your users use 2FA with your product?<p>> Antivirus<p>No, don't.<p>All in all some good points, but could use some clean up. You're lumping things together from varying degrees of technical expertise - also some paragraphs are highly detailed (and thus, sometimes miss to convey the bigger point) and others are pretty sparse.<p>Sorry if this sounded like complaining, there were (very) few points where I strongly disagree, but overall a good overview. I probably would've split it in at least 2 parts - e.g. for a CEO (overviews, less details, but more fields) and CTO level (technical stuff, with details).
SPF and DKIM can be applied just fine to subdomains, I don't understand the suggestions made for email, yet there are good reasons to have a few extra domains, none which are actually mentioned: accidental cookie leakage and redundancy being obvious ones. The implication made for the API domain was that it should not be protected by SPF and DKIM<p>I stopped reading there
I would advise against Google Drive for document sharing. Recently I tried to share a trial build of an application (an exe I built) with a client. I zipped everything up and created a share link. Google auto-flagged it as a terms of service violation and blocked the file. No way of getting round it, and no way Google will bother to remedy the situation in time.<p>There's also OneDrive for business which seems to work well for sharing, though syncing options are totally broken. There's no way to selectively sync a share folder, so either you have your entire filesystem downloaded or you go online to get files. That sucks when your backup is terabytes of data.<p>I ended up sending a Dropbox link instead. So far it seems to be more or less foolproof.
> automation (for example a Jenkins task)<p>I think there's value in this, but I want to point out that often time Jenkins becomes a collector of tech/security debt itself. It has very high privileges, and often time accesses/changes are not properly auth & audited.
If any developer says code review is too "corporate", I would suggest that they need to try a different profession.<p>Code review is an industry practice these days, and that is a good thing. I would say even for POC / MVP development, CR is a must.
> Open an email group and name it seurity@mycompany.com and add a page on your website to report security incidents to this email<p>You know a company takes security seriously when they have a typo in the word "security".