Live data from Hacker News

SaaS CTO Security Checklist

sqreen.com

61–70 of 114 posts

Re: SaaS CTO Security Checklist

#61
post #28

Earlier quoted context omitted.

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 o…

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!.

I totally agree.

Every time I start in a new organization, I spend some time to sit down and make a very strong password. The kind of password I would trust my retirement savings to. I'll sit down and dedicate a solid 30 minutes to transforming a bizarre but easy to remember phrase in 20-30 special characters with abbreviations instead of full words. Then I'll spend the time to commit it to muscle memory. I've done this probably 30 times over the past 20 years.

60 days later, maybe I make another new very strong password. 60 days after that, it's 8:15 and my computer is forcing me to update my password and I have an 8:30 meeting and now my password is asdfg;lkjh. 60 days later it's asdfg;lkjh1. And so on.

Password expiration dates are one of those things that just don't work with human beings. It's the "work harder, not smarter" approach to security. Somebody wrote it down once, and now everybody who came along later copied the same bad checklist and added more bad things to it. Instead of working to improve the practical security of their system, they work to adhere to their arbitrary checklist. It only makes sense from the most cynical Dilbert perspective.

Re: SaaS CTO Security Checklist

#62

Earlier quoted context omitted.

Cool idea! I like the self-assessment angle. We wrote this for CTOs since prior to hiring a dedicated security engineer, security responsibilities in a company often fall to the CTO. But really, any more technical person in a company with some ownership or interest in security can leverage this.

The "SAAS security dashboard". Grab that domain! Features: - Including an overall alert status red/yellow/green. - Critical issues rise to the top somehow for the team's attention. - Mechanisms and best practices for reporting security issues. - A knowledge base linking to relevant articles on each topic. - A button must be pressed to say that backups have been tested, failing to do so raises alert level. - Team memb…

A lot of these features are actually already inside our product Sqreen, but it "only" starts at $250/month.

We're also hiring if you want to help us build the missing items ;)

Re: SaaS CTO Security Checklist

#63
post #51
post #28

Earlier quoted context omitted.

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 o…

It depends on your definitions of easy to remember, hard to guess. 6 dictionary words with one random character is sufficiently complex to thwart planetary scale brute force attacks. It's much easier to remember than 20 random ascii characters.

I use the first three letters of each word in book titles/song lyrics and a number that means something to me like 186282 (speed of light in a vacuum in miles per second) for master passwords everything else is stored in Keepassxc.

aphiofsofdes68537513 is good enough and defeats a dictionary attack.

It requires discipline but I’m responsible for people’s PII at work and I treat that seriously.

For my personal stuff I keep a separate vault but with the same criteria.

Re: SaaS CTO Security Checklist

#64
> 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...

[2] https://medium.com/@henriksylvesterpedersen/you-dont-need-th...

[3] https://security.stackexchange.com/questions/194024/should-i...

Re: SaaS CTO Security Checklist

#65
post #62

Earlier quoted context omitted.

The "SAAS security dashboard". Grab that domain! Features: - Including an overall alert status red/yellow/green. - Critical issues rise to the top somehow for the team's attention. - Mechanisms and best practices for reporting security issues. - A knowledge base linking to relevant articles on each topic. - A button must be pressed to say that backups have been tested, failing to do so raises alert level. - Team memb…

A lot of these features are actually already inside our product Sqreen, but it "only" starts at $250/month. We're also hiring if you want to help us build the missing items ;)

[deleted]

Re: SaaS CTO Security Checklist

#68
Discussed previously:

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.

Re: SaaS CTO Security Checklist

#69
post #23

Earlier quoted context omitted.

Easy to remember high-entropy pass phrases still makes the most sense to me, with maybe a number or symbol thrown in somewhere for added extra oomph. correct horse 19 battery staple https://xkcd.com/936/

Just don't use that as the key to generate your BitCoin address. I saw a funny video, can't remember where, where a guy does that to prove a point. He sends a small amount of BitCoin to the wallet address, and someone steals it within seconds.

There's an article floating around about Ethereum private keys, where people use "0x[...]0000" or "0x[...]0314" or what have you. You can check the corresponding public addresses on Etherscan and see funds being systematically siphoned out by the same few accounts.

Re: SaaS CTO Security Checklist

#70
post #18

> Enforce a password policy > (links to https://www.digicert.com/blog/creating-password-policy-best-... ) 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...

fourwordsalluppercase
Post reply on HN