8 ms·
Saas CTO Security Checklist
- Spooky23 9y agoOne modification to the backup bullet... “backup, backup and restore” I’ve seen more than one day ruined by a backup that wasn’t.
- kumarski 9y agoi love stuff like this: * Goodui.org * enterpriseready.io * ixdchecklist.com
- mkagenius 9y agoYou may then want to see this one too: https://git.io/security https://git.io/security
- ggregoire 9y agoThe first link has a great content but the UI could be so much better. Some suggestions: 1) adding a sidebar to give an overview of the tips and help to navigate to the ones I'm interested in 2) grouping the tips by category to make the list shorter and easier to read
- bdiu 9y agothis is fantastic. Bookmark this if you plan on starting a SaaS business, though...these seem broadly applicable for other models as well.
- gaurx003 9y agoGreat checklist. One recommendation - the checklist page has a lot of CORS policy violation and unsecure end points errors/warnings. Being that this list, and your company represent a security product, these errors undermine the credibility a little.
- ejcx 9y agoThose are CSP violations not CORS violations. There are different levels of maturity with your security headers, and Sqreen's cookies are scoped to a completely different subdomain my.sqreen.io versus www.sqreen.io. It looks to me like they are doing everything right. There is no shame in having your CSP header in Report Only. It's complicated to manage your assets, especially when using a tag manager where it's not obvious what the hell the URI/hosts are that will be loaded.
- tptacek 9y agoIt's not a bad list, though it is a bit of a marketing tool for "Sqreen" (though, I guess if we did one, it'd come off as a marketing tool for us). What I actively don't like is their use of "Seed", "Series A", "Post-Series-A". It's cutesy but, more importantly, their categories are mostly wrong. Here's their "Series A" list: * No shared accounts * Centralized account management * Centralized logs * Server list * DDoS protection * IP restrictions for internal services * Monitor metrics * Public security policy * Special security for non-tech staff * Real-time monitoring/protection * Customer 2FA * Monitor suspicious activities * Security-oriented test sessions Many of these are things you want to be doing ASAP. That doesn't mean they take priority over product/market fit, but it does mean you're not waiting for a milestone to build them. For instance: most competent teams have centralized logs. Every competent team restricts access to internal services (and IP restrictions aren't the way to do that). If you don't get this stuff started early, it's a nightmare to start later. Other things on the list are things that mature, profitable companies don't bother doing, because the ROI isn't high enough. Customer 2FA is an example --- if you need it, you probably know. Real-time security monitoring tools are another big one; chances are, if you're reading a checklist like this, your monitoring needs are too idiosyncratic to buy COTS. Post-Series-A is worse: * CloudFormation * Incident Response * Internal security policy * Asset inventory * Bug bounty program * Security audits * SDLC With the exception of bug bounties, which you might not bother ever doing at all, these are all ASAP items. You could also start a list of important things they're missing: * Security testing integrated into CI/CD pipeline * Automated routine network monitoring * Segmenting AWS accounts * Having a process to tag PRs for security review * Adding a security page to your website This list reads to me like it was originally shrink wrapped around a product, and then expanded with bullets with links to random websites to throw the scent off.
- mkagenius 9y ago> IP restrictions aren't the way to do that I think they might talking about something else — like restricting db access to only certain IP where apps are hosted. That’s the problem with checklists — they aren’t very clear at times.
- jbaviat 9y agoI’m the CTO at Sqreen and I do love Matasano (cryptopals... awesome crypto challenge https://cryptopals.com/ https://cryptopals.com/). Realistically, security audits or bug bounty are not doable in seed startups - where most of the time no one has any security knowledge, and no money :) Thanks for the missing things we will update! By the way this is open source, feel free to contribute: https://github.com/sqreen/CTOSecurityChecklist https://github.com/sqreen/CTOSecurityChecklist (not sure this is 100% today with the version on Sqreen.io, we’ll get there this week).
- ploggingdev 9y agoI wish frameworks included 2FA support in the default auth systems. While there are third party packages to add 2FA support, adding support at the framework level would help drive 2FA adoption in a major way. Question : How would you add 2FA to a django website? Ideally TOTP + yubikey + backup code, but TOTP + backup code is also fine. The website I plan to add 2FA support will be open source and is meant to be self hosted by users, so I want to avoid SaaS solutions. I came across a couple of packages : django-two-factor-auth [0] which is based on django-otp [1]. There's pyotp [2], which will require me to integrate it into the login flow (not a good idea to be writing login flows). If anyone's using the mentioned packages in production, would be interested to hear about your experience. [0] https://github.com/Bouke/django-two-factor-auth https://github.com/Bouke/django-two-factor-auth [1] https://django-otp-official.readthedocs.io/en/latest/ https://django-otp-official.readthedocs.io/en/latest/ [2] https://github.com/pyotp/pyotp https://github.com/pyotp/pyotp
- vivienm 9y agodjango-two-factor-auth seems to be a good choice (using django-otp alone might be considered too). I agree that pyotp is less suited, since it does not integrate easily with Django.
- technion 9y agoFeedback: The section on password policy recommends requiring special characters and mixed case, then as a reference links Troy Hunt's article specifically recommending against that. To be fair, I zeroed in on this because a mega corp did the same thing this morning.
- paulb81 9y agoThank you. You're right. We will change that
- doubleocherry 9y agoAs someone who has made a similar, internal checklist, I find this to be well-done. A good primer for someone who is starting their own Saas company, and is interested in understanding the scope of what it takes to implement best practices as a CTO.
- dsacco 9y agoMy honest opinion is that this is vacuous. I dislike being that critical but this is important. First, I don’t think it’s meaningful to segregate this list into divisions by funding milestones, and I don’t think it’s productive to have so many bullet points crowding one page for attention. Second, and more specifically, I think this list leaves a lot of the heavy lifting out of the problems to the detriment of solving them. For example: > Encrypt all employee laptops and phones You have two sub-problems here. Either you take endpoint security very seriously (which becomes its own much more important bullet point), or you trust employees to encrypt their devices on their own. This process should be entirely automated. My concrete criticism: mention this problem alongside endpoint security. Accustom your team to locking their computers This is another endpoint security problem. You should automate this enforcement across all employee computers. Even if people are fully on board with it conceptually, they will err because no one can have Constant Vigilance. Centralize and archive your logs Yes, but how? Provide examples. You linked to Elastic, but why not talk about tradeoffs between the Elastic stack and others? How about the tradeoff of paid infrastructure versus full open source? A build versus buy discussion is very useful here. Evaluate your website’s basic security There’s a messaging problem here. Your checklist doesn’t recommend bug bounties until post-Series A (!!!), partly because you have no qualified staff to review reports. Precisely how are your engineers reviewing “basic” security without basic qualifications? What defines “basic?” If they have the time and initiative to learn how to do this step, why can’t they do other steps you reserve for Series A or beyond? Frankly, most of this list could be meaningfully reduced to prioritizing automation, endpoint security, formal processes and finding the right people to tell you your unknown unknowns very early on.
- marcinzm 9y ago>You have two sub-problems here. Either you take endpoint security very seriously (which becomes its own much more important bullet point), or you trust employees to encrypt their devices on their own. This process should be entirely automated. My concrete criticism: mention this problem alongside endpoint security. Do you have any recommendations for endpoint security? I'm setting that up now and finding a good vendor has been annoying. >Precisely how are your engineers reviewing “basic” security without basic qualifications? There are standards and checklists for this (ie: OWASP Top Ten). Being able to read and follow a simple checklist, that someone recommends to you, doesn't mean you're even close to an expert in that area. That said, the OWASP Top 10 includes "Logging and Monitoring" on it while this checklist punts it to Series A, so it's confusing.
- maruhan2 9y ago"It will protect against both malicious activities and accidents (e.g. an employee’s child accidentally wiping a mailbox)." Can someone help me understand how a child accidentally wiping a mailbox is related to encryption? Isn't this just a matter of putting a password on your computer and not related to encryption?
- dkns 9y agoDon't just make backups and then backups. Test regularly if you can restore your system from said backups. The worst feeling in the world is having backups and then learning that you can't restore from them in case of emergency.
- pfalke 9y agoSlightly OT: Can someone elaborate on "Do not share Wifi"? What can be problematic when using a shared but encrypted (say, WPA2 with pre-shared key) Wifi? This is a common setup in public places like cafes. I've always wondered in what ways this can cause problems.
- finaliteration 9y agoI think they meant, “don’t have internal and guest WiFi connections use the same subnet”. If you’re giving non-employees passwords and access to a network that contains sensitive resources that’s a big security red flag. Many companies also use IP whitelisting for external services/systems, so if someone from outside the company joins an internal network they now have access to them as well. Edit: Actually, they point out those exact reasons if you expand that entry in the list.
- coin 9y agoThe stupid share links blocks the left of content. Crap web layout.