Hacker News Reader

Comment by superq | Hacker News Reader

I've been through the process before and just went through it again, and the first thing listed (Single Sign-On) is not required at all. I'm not even sure it's mentioned directly in the AICPA criteria.

I'm also not sure what SSO really buys you, except for just moving the criteria target to another SOC-2 report. ;)

Also, MDM is not really critical at all, as long as you have a solid/documented way of managing accounts on web and mobile apps.

I do like the rest of the article except for the list itself, however. SOC-2 is all about documentation and processes. Justifying your security choices is less important than carefully and fully documenting them, and the processes that you have in place.

View on HN

SOC2 doesn't really "require" much of anything. The question we're answering is: "which security engineering projects can you undertake that will make a SOC2 audit go more smoothly". Because SSO directly addresses a lot of access control control points, and generates a lot of evidence for those control points, and because it's generally a very good practice to have anyways, it'd be the first bit of security engineering we'd recommend to ratchet up your maturity.

What I can tell you is that the IRLs I've seen, both from big 4 auditors and from SOC2 boutiques, have dozens of questions that are directly answered by a sane SSO configuration.

We've watched clients clear SOC2 audits without any coherent SSO. It's clearly doable.

This is all made more tricky by the fact that different SOC2 auditors have different requirements. They're in one sense or another all negotiable, in that you can always switch auditors if they're unreasonable, and we've definitely collected several horror stories about aborted SOC2 processes that were resumed with a different vendor. And, to layer more complexity on that, different bigCo customers will have opinions about who did your SOC2. It's all a mess.

Right, agreed 100%. In terms of security, the value of centralizing credentials is debatable.

The other bit of subtext in this post is that you often have multiple ways of addressing control points auditors bring up, and we'd like to steer startups towards the good ways of doing that. So if an SSO keeps you from having an insane password rotation policy, or an MDM (also not "required") keeps you from installing Mac AV software, it's super worth it to us.

That makes sense to me -- thanks for clarifying!

I feel like that's recognized in the article: we even point out that anti-malware is one of the few (technical) things the AICPA criteria do care about. The point is not that you need SSO, the point is that it is _much simpler_ to demonstrate you've got anything resembling an access control story if you do SSO. You are not doing it because it's the only way, you're doing it because it's the best way.

Agreed! I've run into the malware scanning audit issues at several clients in the past but things have gotten a bit better (or auditors have gotten smarter, since we certainly don't want to install commercial anti-virus software or even ClamAV on certain types of systems): recently, for Linux systems, we successfully used cron-job rootkit scanners/FIM (such as Tiger) to clear the malware scanning hurdles, while on Mac and Windows workstations, client security manuals require built-in anti-virus software (Mac XProtect, Windows Defender).

Maybe! Generally, I get the impression auditors haven't changed their tune much, and we've seen success with people ELI5ing controls and why they are good.

For malware in particular, on the server side, we've seen:

a) auditors not asking after seeing convincing endpoint answers

b) people be successful with scanning container images and then just arguing that containers aren't long-lived enough to matter (and having other infrastructure level controls to argue that if something does leave a container you'll see it somewhere).

That only works if you actually have short-lived containers though, of course :D

> You’re going to sign up for Okta or Google Cloud Identity, tie as many of your applications (first- and third-party) into it, and force 2FA.

Are these really the only options? I'm not terribly comfortable with an external entity owning my SSO--ESPECIALLY Google.

They do mention (but apparently do not recommend) that you can roll your own SSO.

This is really about having SSO, not about Octa or Google.

Reply on news.ycombinator.com