For many SaaS startups, security takes a backseat to other needs and functions in the early stages of the company. This approach often makes sense (you have to have working applications before you can protect them), but what that means in practice is that building a security team is something that is pushed down the road a ways. Without a security team, all security concerns fall to the CTO or another technical leader who may or may not have a strong background in security. Fortunately, there’s a lot that this leader can do to move their company’s security from 0 to 1, regardless of their personal security background.
Back in 2016, we talked to a lot of SaaS CTOs to put together our SaaS CTO Security Checklist. In the preceding three years, there have been some evolutions and new wrinkles in the security space that SaaS CTOs need to be aware. So we buckled down and put together a second edition of the checklist (now available!). The SaaS CTO Security Checklist, Second Edition covers the latest best practices for taking the first steps towards building a strong security foundation. From processes to culture to tooling, these best practices can help you get started on security, or help you take stock on where your current security practices stand today.
About The SaaS CTO Security Checklist
A few weeks ago, our CTO Jean-Baptiste outlined a framework for thinking about security as a SaaS CTO. This checklist expands upon each of these areas and more with actionable best practices and tips mapped to stages in a company’s early life. Each SaaS company is different in terms of their approach to growth and scaling, so you may want to take action on some of these tips earlier or later than we recommend, depending on your specifics. To give a general sense of order, we grouped things by funding round (Seed, Series A, Series B and onward). You can also think of these groupings as “just starting out,” “product-market fit,” and “starting to scale” if that approach makes more sense for you. The way to read the stage groupings is as a means of prioritization. Certain processes or practices won’t have as strong an impact or won’t be helpful if done too early. On the flip side, certain practices should be done as early as possible, but if you haven’t done them by the time you’ve hit a later stage, it just means that now is the time!
I wanted to share a couple examples of best practices from The SaaS CTO Security Checklist, Second Edition to give you a sense of what it contains.
Examples of best practices at each stage
Require 2FA wherever possible — Seed Stage
Your employees should all use 2-factor authentication. By adding 2FA, you add an extra layer of security. Should your employee’s password get stolen, the attacker would still be locked out unless they have access to the second factor (e.g. phone app or text) as well. As a CTO, your role is to make sure everyone complies with this rule. Phones are the most commonly used device for second factors, and thus have to be secured accordingly (e.g. with codes or biometry). Another option is to use purpose-built hardware-based 2FA, like Yubikeys.
Read more:
- https://en.wikipedia.org/wiki/Multi-factor_authentication
- https://support.google.com/a/answer/184711
- https://get.slack.help/hc/en-us/articles/212221668-Require-two-factor-authentication-for-your-team
- https://www.yubico.com/why-yubico/how-yubikey-works
Perform security-oriented test sessions — Series A
Once in a while, the entire technical team should sit together and spend time targeting all parts of the application, looking for vulnerabilities. This is a great time to test for account isolation, token unicity, unauthenticated paths, etc. You will heavily rely on your browser’s web console, curl, and 3rd party tools such as Zap.
The benefit of doing these test sessions yourselves is that your team has the best understanding of your application, and likely where the weak points are. Showing that they can be exploited (or not) is valuable feedback for the team.
These sessions complement external pentests quite well.
Read more:
Have a security incident response plan — Series B+
This will allow whoever is in charge at the time of a breach to communicate accordingly about an incident and will allow for the fastest response. Trying to make your plan up in the heat of the moment can make the impact of breaches much worse.
Read more:
- https://zeltser.com/security-incident-response-program-tips/
- https://github.com/meirwah/awesome-incident-response
- https://security.openstack.org/vmt-process.html
- https://medium.com/@magoo/incident-response-writing-a-playbook-773e7920f171
More SaaS security best practices
This checklist was written for SaaS startup CTOs and engineering leaders responsible for their company’s security and looking to get started on bringing security into their company, or for those interested in comparing their current processes and practices against a recommended list.
Download the full checklist here to see all 55+ best practices. If you have any feedback, please let us know at @SqreenIO. We’re always looking to make our resources as useful and relevant as possible!
