The SaaS CTO Security Checklist Redux

It&#x27;s a good list, but like most (all?) of these lists it doesn&#x27;t offer too much advice on organizational best practices.<p>IMO a security program which cannot justify its own worth to others in the organization is incomplete.<p>Most security professionals I&#x27;ve met (and I&#x27;ve been one of them, too) assume that security is or should be everyone&#x27;s top priority. They struggle to deal with people for whom security is just one of many competing concerns.

I think of myself as pretty security-conscious. But it&#x27;s striking to me just how _long_ this list is. Even as someone who is trying to constantly think about this stuff, if I were faced with a list of this magnitude, I&#x27;d be tempted to throw in the towel and admit defeat right off the bat. It&#x27;s no wonder so many SaaSes end up getting exposed. Even with a lot of best practices built in to so many cloud providers... how did we as an industry end up in a place where it&#x27;s this dang hard to keep systems secure?

This list is the &quot;brute force&quot; security algo. Eg &#x27;just make everything more secure&#x27;. This would have someone upgrading a door lock with a hole in an adjacent wall.<p>There are at least the following major factors:<p>* what might happen (event A,B, ...) ?<p>* how probable is eventi?<p>* what is the cost if eventi happens?<p>* how can one deal with eventi? (action 1, 2 ...) ?<p>* how much &#x2F; how long does actioni take?<p>* what actions should we perform with the skills&#x2F;resources&#x2F;time we have?<p>My algo:<p>1 enumerate possible security issues<p>2 assign approx probability and cost to business<p>3 re-order by prob*cost<p>4 imagine ways to address issues, assign cost to address<p>5 decide on courses to address issues<p>6 for next epoch, address issues<p>7 goto 1

I don’t see any mention of domain names. Domain names should be set up properly, like implementing dnssec, dmarc, dkim, spf, and using a secure registrar. So many overlook domain security.

While I&#x27;m generally a fan of the Sqreen checklist that this is built on, looking over it with fresh eyes I have quite a few quibbles:<p>&quot;Require 2FA wherever possible&quot; - Given the target audience, it would be nice if this was explicit about the reason to use hardware keys (including those builtin to TouchID + chromebooks).<p>&quot;Accustom your team to locking their computers&quot; - This is good advice, but I&#x27;d recommend configuring locking on inactivity a higher leverage effort<p>&quot;Hire your first security engineer&quot; - &quot;do we have a security roadmap? do we manage to deliver on it?&quot; is not a good heuristic for whether you need a security hire. I&#x27;d argue that most startups will lack a formal security roadmap when they don&#x27;t have dedicated security staff. For example, the linked First Round article [1] has a more actionable recommendation, with justification: &quot;Onboard your first, full-time security hire between 30-100 employees.&quot;<p>&quot;Set up a bug bounty program (NEXT)&quot; and &quot;Monitor your user’s suspicious activities (NEXT)&quot; being placed before &quot;Have a security incident response plan (LATER)&quot;<p>[1] <a href="https:&#x2F;&#x2F;review.firstround.com&#x2F;how-early-stage-startups-can-enlist-the-right-amount-of-security-as-they-grow" rel="nofollow">https:&#x2F;&#x2F;review.firstround.com&#x2F;how-early-stage-startups-can-e...</a>

Previously — <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16615593" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16615593</a><p>With Sqreen&#x27;s acquisition, the list&#x27;s previous home unfortunately redirects the their acquisition announcement. We&#x27;re grateful that they released the list under CCA and we look forward to keeping it updated and relevant to startups on beginning their infosec journeys.

2FA on itself is good, but should not be an excuse for corporate to own my cell phone.<p>They want to send messages with codes to my phone? I&#x27;ll live with it. But then they want me to buy a phone with more recent android version. Then they want to enforce biometrics and encryption on my phone. Then they want to remotely erase my phone?<p>No. If central IT wants that kind of access, they should buy me a phone.

This is the first I&#x27;d heard of RASP (runtime application self protection), so thanks for that, I think. Now I need to decide which RASP tool to use.

Company that want to become SOC2 or iso27001 can automate all of this and more with <a href="https:&#x2F;&#x2F;www.vanta.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.vanta.com&#x2F;</a>. This helps us a lot at <a href="https:&#x2F;&#x2F;mergify.io" rel="nofollow">https:&#x2F;&#x2F;mergify.io</a> for our SOC2 certification.

Whenever I&#x27;m forced to use 2fa the most probable outcome is that I will get locked out when I need to log in the most. Not to mention most implementation in the wild trivially reduces to 1 factor.<p>I could make a case for MFA if really pressed, but M=2 is such a bad choice too.

I didn&#x27;t see ransomware mentioned anywhere in there.<p>At best being ignorant of that risk is going to result in fiscal losses and dubious legalities wrt sanctions, at worst existential risk to the company.

I didn’t see ssh security mentioned maybe I missed it? I recommend, in addition to public key only authentication to also use an 2nd factor as well

I work within the Cyber Security domain, and I have to say this was a very solid list. Great work!