
SaaS CTO Security Checklist - vinnyglennon
https://www.sqreen.com/checklists/saas-cto-security-checklist
======
jupp0r
> Enforce a password policy

> (links to [https://www.digicert.com/blog/creating-password-policy-
> best-...](https://www.digicert.com/blog/creating-password-policy-best-
> practices/)) where they give the usual (at least 2 special characters, but
> not " or \\) advice

This is counterproductive and is actually discouraged by the latest NIST
guidelines, that prefer passwords that are easy to remember, but still hard to
guess [1].

[1] [https://auth0.com/blog/dont-pass-on-the-new-nist-password-
gu...](https://auth0.com/blog/dont-pass-on-the-new-nist-password-guidelines/)

~~~
orev
Starting to feel like this is one of those things that people just blindly
parrot all over the Internet without understanding the full context of the
NIST guidelines, and as a result are actually causing many security problems.

You can’t take one recommendation that you like out of a whole body of work
and start running around telling everyone to do this one thing. If you’re
going to follow NIST, you need to do all of it. MFA is a big part of why
complexity is reduced in the NIST guide, and you MUST have it if you’re going
to remove complexity requirements. If you can’t have MFA for some reason (and
yes, there are legitimate reasons for this), then you still need to use
complexity, expiration, etc.

~~~
technion
If for some reason you're stuck without MFA (and I appreciate why it happens),
I can't agree short expiration adds value.

I've done brute force exercises. Some people always pick bad passwords. Tell
an organisation to change every 60 days and a lot more people give up and land
on May2019!.

~~~
privateSFacct
This 100%.

I have a complicated google password - I use it no where else. I have a
security key. In 12 years I've NEVER had to change my google account password
AND I have not been hacked. This works well. Because google is resistant to
brute force I don't even bother adding tons of weird special characters.

I worked at a govt related agency. They had to change passwords every 30 days
and there was a dual password requirement (one to login to the VPN, the next
for the app). Result?

    
    
      - Many folks used a shared account with a public password emailed out every 30 days so everyone else did not have to deal with all the hassles of the password expiration dance. It was also super hard to onboard anyone new (ie, 3-4 months for staff with 12 month projects) This account ended up posted next to every computer. 
    

The idea that making security so user unfriendly will makes folks like and use
security is a ridiculous approach.

\- Rate limit attempts \- Block after 4 tries for an hour, after 8 tries till
a reset \- Screen against password lists \- Screen out other obviously bad
(ie, too short etc). \- Allow hardware 2fa BUT allow staff to validate
computer.

This alone gets you a ton of mileage

~~~
bigiain
So much this.

If you make your security policies into a problem for your people trying to do
their work, they'll find ways to work around it.

That either means 1) your policies are misplaced and you need to relax then,
or 2) you need to fire everybody who creatively works around them.

If your adversary is Mossad, the option 2 is the right one. If your adversary
is not-Mossad, you can almost certainly have a security policy that people
won't feel the need to work around.

There are, of course, shades of grey below "Mossad adversaries", but in my
opinion at the upper end of that you have policies that include providing
every employee with a good password manager, TOTP apps/devices, and/or USB 2FA
keys - and choosing services which integrate properly with them.

"Change your password every X days" is an admission that you're going to leak
passwords somehow, and that you only care about your data/systems enough to
close the attack window down to X days. Which means you're screwed before you
start, and may as well just turn everything off now.

------
tptacek
Discussed previously:

[https://news.ycombinator.com/item?id=16615593](https://news.ycombinator.com/item?id=16615593)

In the year this has percolated with me, I've grown to actively dislike it. I
have three major problems with it:

1\. This cutesey "seed, A, B" triage scheme is misleading. In reality, you can
break everything down into just two categories: "do it before product/market
fit" and "do it after product/market fit" (or "now" and "later", or whatever
you'd like to call them).

2\. Most of what this list defers to later phases shouldn't be deferred --- or
at least, if you're going to do it at all, there's benefit to doing it early.
Monitoring computers? Much harder to start at "series B". SDLC? Same. Share
accounts until "series A"? I like how their product category, "RASP", is
assigned "seed" stage, though.

3\. It's not internally consistent, or, at least, to make it internally
consistent you would have to make silly decisions. For instance: use 2FA where
possible early, and _later_ centralize authentication?

I feel like this list is unserious, and serves essentially the sole purpose of
putting "RASP" on the "do now" agenda.

~~~
yaleman
2FA on SaaS applications is free and easy, while centralising authentication
is much harder - you need to manage an authentication platform instead of just
using the application's own authentication.

Taken by itself the suggestion is odd, but in concert with the next entry "use
password management software" it makes for a low-cost, zero management, higher
security stance than not suggesting 2FA by itself. Noone should _ever_ ignore
the option to turn on 2FA.

------
tompic823
This list seems incredible helpful. As a security-conscientious CTO, one of
the challenges I faced was determining how much we should be doing now (during
YC and while raising our seed round) versus pushing down the line. For
example, we obviously should be monitoring outdated and insecure dependencies
from the outset, but when is the right time to switch our servers and external
tools to centralized account management, or to pay for an external pen test.

Now, I would probably move the external pen test up to seed if the company is
well-funded (e.g. post demo day) and holding PHI. But that’s personal
preference and my security paranoia talking. Overall I think this list really
gets it right.

I also liked seeing a recommendation against sharing your WiFi network in the
seed stage. Network segmentation to separate your computers and IoT devices,
printers, etc. should probably appear somewhere in series A/B.

~~~
tptacek
The best indication that you need an external penetration test is that you
have client prospects demanding to see the output of those tests. A less
important indication would be that you (1) have product/market fit, (2) have
implemented your core product, (3) can predict what development on that
product will look like for the next 12 months, and (4) have revenue sufficient
to eat the $20-30k cost of a penetration test.

I would not generally recommend that seed-stage companies contract out
penetration tests simply because they've raised enough money to do so. You
should be on a relatively stable, predictable path with regard to product
engineering before you start asking contract pentesters to beat you up.

I feel like this is a pretty good illustration of how _not_ useful lists like
these are. It's simplified down to this "seed", "series A", "series B" thing
in order to suit the format and make it punchy; the real, serious advice isn't
as slick, and doesn't showcase their product, so it's nowhere to be found.

------
andrewstuart
I really like this idea - alot.

But aimed perhaps at everyone, not just the CTO.

In fact the CTO probably needs one thing on their checklist.

Checklist item 1: Hire an outside security auditing firm to report on the
state of this checklist quarterly".

And if the company has the financial resources:

Checklist item 2: Hire a second, independent outside security auditing firm to
report on the state of this checklist quarterly".

I don't see any value in relating anything to the financial stage of the
company because it's irrelevant.

Security also needs a time and priority aspect to it. For example if your
company hasn't done anything on the checklist yet then what should come first,
what is most important? Also it would be good to know what are the biggest
typical weaknesses - a security chedclist can have so much stuff on it that it
becomes hard to know where to focus.

~~~
laurentl
> Checklist item 1: Hire an outside security auditing firm to report on the
> state of this checklist quarterly

Security auditing firms cost a lot of money. Money you don’t have when you’re
a small startup. Besides, an auditor _audits_ and the hard part about this
list is implementing it. Until you can afford to hire someone to take care of
security, it’s usually the CTO’s job to make sure security is not an
afterthought.

> I don't see any value in relating anything to the financial stage of the
> company because it's irrelevant.

It is extremely relevant, for at least two reasons. The first one is that the
company’s financial resources dictate what you can or cannot do (e.g. hire a
dedicated security resource, pay for pen testing). The second is that some
recommendations just don’t make sense before a certain size (e.g. there’s no
sense in setting up an AD and GPOs when there’s just 3 of you in the company).

~~~
jammygit
How lucrative is security work? It’s a direction I’ve been considering moving
towards but the salary info I’ve seen is not great. Am I looking up the wrong
terms/titles?

~~~
tptacek
As an employee, application and infrastructure security work pays somewhat
better than normal product engineering work (there are good jobs and bad jobs,
of course).

There are lots of security jobs that don't pay especially well and are career
dead-ends --- enteprise IT security isn't a good place to end up, nor is sales
engineering ("security engineer") for security product companies, nor is
malware analysis.

My feeling is that software/application security consulting is a reasonable
route to go, if you want to work for a consultancy, but I'd be wary of any
other kind of security consulting.

~~~
jammygit
Thanks for the insight!

------
Eldt
"At Sqreen, for example, if someone catches another person’s laptop unlocked
while they’re AFK, they can type “Cookies!” in that person’s Slack. That
person will then have to bring in cookies for the office!"

This sounds like a fun idea, but has anyone ever refused to bring in cookies?

~~~
SmokeGS
I'd be more inclined to do a "drinks" option.

~~~
loco5niner
Except for those that obstain. Of course, not all people can eat cookies
either, I suppose.

~~~
saagarjha
Psst…I think you meant "abstain".

~~~
loco5niner
whoops

------
mediocrejoker
The slider of funding rounds is a neat idea but it's kind of hard to read in
chronological order without mentally keeping track of which items appeared
each time I slid it forward.

Would love to see a plain, non-javascript version of this content.

------
NullPrefix
Don't know if the post author is the one who submitted it here, if so, it
would be way nicer to read the list if items within each category (employees,
code, ..) would be sorted by timeline (seed, series a, series b+).

~~~
paulb81
Thanks for the feedback! That makes complete sense. We are going to update
that

~~~
Macha
While you're at it, "Monitor your user's computers" appears twice. The first
time under your users appears to be correct, but the second occurence has a
description about how lets encrypt is a free, easy to use option. I'm guessing
the second heading should be "Use encryption on all your web sites and APIs"
or similar?

~~~
paulb81
Thanks! Deploying the fix and stealing your heading suggestion :)

------
paulddraper
> Connections to your infrastructure and non-public properties (hosted CIs,
> admin interfaces, databases etc.) should only be accessible through a bounce
> host (in a VPC, behind a bastion host or VPN, etc.).

How valuable is this?

I see articles for [1] and against [2] this practice.

And not a lot of interest in the subject from security SE. [3]

[1] [https://cloudacademy.com/blog/aws-bastion-host-nat-
instances...](https://cloudacademy.com/blog/aws-bastion-host-nat-instances-
vpc-peering-security/)

[2] [https://medium.com/@henriksylvesterpedersen/you-dont-need-
th...](https://medium.com/@henriksylvesterpedersen/you-dont-need-that-bastion-
host-cd1b1717a9e7)

[3]
[https://security.stackexchange.com/questions/194024/should-i...](https://security.stackexchange.com/questions/194024/should-
i-have-an-ssh-bastion)

------
dgrove
Lots of talk about passwords, but fewer about password managers. The password
managers listed in this do not protect against backdoors. Lastpass, for
example keeps all your passwords in plain text once you've unlocked it.
Passwords stored in Apples Keychain can be synced across devices and a remote
attacker can do something like a sim port, gain access to your iCloud account
and then sync to their computer leaving you vulnerable.

Password managers should be bound to hardware tokens and each password should
be individually encrypted, as well and individually decrypted that also force
physical tap.

Password Store is a perfect example of this. Physical password managers are
also on the rise, see: Ledger and Mooltipass

~~~
saagarjha
I think you need to provide approval from one of your other devices, or enter
your iCloud security code before the sync can occur.

~~~
dgrove
iCloud security code can come over SMS if your account is configured as such,
therefore the above example of a SIM port applies

~~~
tptacek
No, the iCloud second factor can come over SMS. That's not the same thing as
your iCloud password.

------
paulddraper
They also have a good free site security eval:

[https://www.sqreen.com/scan](https://www.sqreen.com/scan)

It was after that I found out the only way to have HSTS for Cloudfront/S3 is
creating your own Lambda@Edge function [1] :/

[1] [https://aws.amazon.com/blogs/networking-and-content-
delivery...](https://aws.amazon.com/blogs/networking-and-content-
delivery/adding-http-security-headers-using-lambdaedge-and-amazon-cloudfront/)

~~~
s_gourichon
The correct entry URL appears to be
[https://www.sqreen.com/scanner](https://www.sqreen.com/scanner) .

~~~
sk5t
This is... not a useful general-purpose scan tool for web APIs. A warning
because port 443 is open, no kidding? And a lot of carping about HTTP headers
relevant to frontend apps.

------
amanzi
While it's easy to pick holes in specific areas of this, overall I really like
the layout and presentation of the advice.

------
reallydude
[The SaaS] CTO Security Checklist

Just a small correction.

~~~
dandandan
The majority of these items are applicable to any startup.

------
scurvy
It kinda reminds me of TwistLock (which just got bought for a boatload of
money).

------
notlukesky
SAASPASS can do most of the items covered. 2FA Computer Protection with 2FA
Enterprise Password Manager Single Sign On Directory Services

~~~
eropple
It's not exactly sporting to plug the product you work on without disclaiming
that you do[0].

It also seems half-baked, to be frank, and really doesn't seem like it does
"most of the items covered". The badly-written marketing all over your website
immediately makes me think you're borderline scammers, too--I've got my beefs
with Okta but they aren't trying to scare me about "man-in-the-mobile" attacks
just because they use push notifications rather than SMS.

If you're serious about putting forward your product as a serious option in
this space, can you tell us why we should trust you and how you're
demonstrating that you deserve it?

[0] -
[https://news.ycombinator.com/item?id=19714999](https://news.ycombinator.com/item?id=19714999)

