Live data from Hacker News

SaaS CTO Security Checklist

sqreen.com

101–110 of 114 posts

Re: SaaS CTO Security Checklist

#101

Earlier quoted context omitted.

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

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

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.

Re: SaaS CTO Security Checklist

#102
post #59

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…

I did - early beta. Based on my experience as CISO for SaaS a well as running security engineer team at a Fortune 5 company, performing Tier 1 PCI DSS, NESA, scans, etc https://joinsecurekit.com/

This sounds really good! I've just signed and I would definitely use this. I'd be happy to help with beta testing.

Would you be able to share some details about the pricing and business model?

EDIT: I get a "You are already signed in" error when I try to fill out the welcome form: https://www.dropbox.com/s/bfxfpm2tczbyn7d/Screen%20Shot%2020...

Re: SaaS CTO Security Checklist

#103

Earlier quoted context omitted.

I'm not sure I agree with that assumption, as the entire purpose of a passphrase of words rather than a password of random characters is that the passphrase should be easier to remember. If you're randomly picking words like 'gargarize-youster-noctivagant-axilla', it's not exactly accomplishing that purpose very well. It's also a huge PITA to type in, which based on my experience in the IAM space, is an immediate dea…

I’d rather pick from obscure words I know than at random. In my case the words might lean tech/business/news/sports, but I’m sure I could come up with a good list. It might be interesting to try and generate passwords from a corpus of email and/or browsing history... assuming you blacklist sensitive subjects.

If i used that model i am pretty sure there would be some kind of proper noun or fantasy novel reference, meaning the Dictionary would need to be pretty extensive.

Re: SaaS CTO Security Checklist

#104

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

Having someone on the team who understands security (can be a security engineer who also writes software, or a software engineer who also has some serious clue about security) should happen as early as possible.

You will almost certainly need some form of authentication system in a couple places, and it doesn't take a lot to keep you from making the worst mistakes.

Once you've build your entire (internal or external) auth system in a broken way, fixing it afterward is much more expensive, and you can expect to have weekly breaches while you do it.

This doesn't need to be back-breaking (compare: WhatsApp), but it is avoidable.

Re: SaaS CTO Security Checklist

#105
post #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 l…

RASP under "seed" did massively stand out as a "whhaaat?" moment

Re: SaaS CTO Security Checklist

#106
post #24
post #22

Earlier quoted context omitted.

What does NIST have to say about passwords like CorrectHorseBatteryStaple [0] that can be easily cracked by brute-forcing concatenations of dictionary words? [0] https://xkcd.com/936/

Even if you knew the pattern, four random lowercase dictionary words (assuming a dictionary size of 50,000 words) would take longer to crack than a randomly generated 10 digit password with letters, numbers, and special characters. 50,000^4 > (26+26+10+10)^10

What I find interesting about the XKCD is that the entropy analysis is basically spot-on, even very generous towards the opposition. It shows that a) the typical "strong password" that people pick is not truly random (i.e. not 26+26+10+10, but worse), and b) that under these conditions even a 4-length pass phrase picked from a measly dictionary of 2048 words is better. (This is probably an even more interesting / compelling argument.)

Yet somehow, each time the XKCD is posted, someone will "point out" that pass phrases can be dictionary attacked, which is kind of like me saying "I know which letters are on your keyboard, and can therefore brute force your password!", but not having done the math beyond that.

Re: SaaS CTO Security Checklist

#108
post #99

Earlier quoted context omitted.

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

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

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

Re: SaaS CTO Security Checklist

#109
post #73

Earlier quoted context omitted.

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?

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

Thanks for the insight!

Re: SaaS CTO Security Checklist

#110
post #46

Earlier quoted context omitted.

the assumption is you do not come up with your own words, and pick words at random from the whole dictionary.

I'm not sure I agree with that assumption, as the entire purpose of a passphrase of words rather than a password of random characters is that the passphrase should be easier to remember. If you're randomly picking words like 'gargarize-youster-noctivagant-axilla', it's not exactly accomplishing that purpose very well. It's also a huge PITA to type in, which based on my experience in the IAM space, is an immediate dea…

    $ egrep '^[a-z]{4,10}$' /usr/share/dict/words | wc
      50768   50768  433477
    $ for i in `seq 5`; do egrep '^[a-z]{4,10}$' /usr/share/dict/words | shuf -n 4 | xargs; done
    droned engraves developer manoeuvre
    lifeforms lurked pursuing subjugated
    hooligans underplay sudden command
    quartettes soapbox blacklist pigtails
    roughening chefs mortals earthy
In my experience, things like that are both easier to remember and to type than things like fa#klwgjl5235 - I type sequences of English words far more often than I type anything else.
Post reply on HN