←back to thread

233 points gmays | 1 comments | | HN request time: 0.395s | source
Show context
quicklime ◴[] No.44362564[source]
From the article:

> SOC 2 is a security and compliance framework created by the AICPA

How is it that a group of accountants (the American Institute of Certified Public Accountants) was able to create a security framework for software, and position themselves as the sole gatekeeper who decides which auditors are allowed to certify SaaS vendors?

I’m surprised that companies would look to accountants, rather than people from the tech industry, to tell them whether a vendor has good IT security practices.

Yet the whole tech industry seems to be on board with this, even Google, Microsoft, etc. How did this come to be?

replies(3): >>44362616 #>>44362924 #>>44363678 #
tptacek ◴[] No.44362616[source]
It's an audit standard about security. It's not a security standard. It defines a small number of extremely broad goals, like "you do risk management" and "you have access control mechanisms", which might be IT tools or might be a tabletop RPG.

You're irritated that people keep describing it at a security standard, which is understandable, but it isn't. AICPA auditors run SOC2 audits because SOC2 is an audit; it's about reconciling paperwork and evidence, about digesting policies and then checking that you actually do anything in those policies.

If you want to know about a firm's actual security program, you'll need to ask deeper questions than SOC2 can answer.

replies(2): >>44362654 #>>44362786 #
alexjplant ◴[] No.44362654[source]
When I worked someplace undergoing a SOC2 audit I had to periodically jump into calls with our auditor and security architect to answer all sorts of highly-specific questions about how we deployed our software and the infrastructure that it ran on. At one point, for instance, the auditor told me that they needed me to demonstrate that our servers were all configured to synchronize their clocks to an NTP server. Kubernetes was a foreign concept to them and pointing to GKE docs wasn't sufficient - if memory serves I had to MacGyver some evidence together by hacking a worker node to be able to get a terminal on it and demonstrate that, yes, Google's managed VMs indeed run chronyd.

This seems to be the opposite of

> It's not a security standard. It defines a small number of extremely broad goals

Is this because of the specific auditors we were using? Are some more sympathetic than others to contemporary engineering practices?

replies(3): >>44362680 #>>44362720 #>>44362764 #
1. tptacek ◴[] No.44362680[source]
Yes, and yes. No matter how good your auditors are, unless you're accepting a shrink-wrapped set of controls from a tool provider like Vanta, you need to be pushing back on things they demand; you just have to have a clear idea of what the Common Criteria control they're looking for is (you'll see this clearly from the DRL they give you at the start of the engagement), and then when they ask for stuff that doesn't matter or isn't relevant for your org, you explain how what they're asking for has nothing to do with the actual control you're working on.

So far as I can tell there is almost nothing that is a firm requirement in a standard SOC2 Security TSC audit. We even got "background checks" rolled back.

Our audit firm is a SOC2 practice that informally spun of out of a Big 4 firm. When people get audits after using GRC tools like Drata, they often get matchmade to auditors who bid down the cost of the audit. It's possible that one of the things you get when you pay low-mid 5 figures for an audit instead of low-mid 4 figures for an audit is a lot more flexibility and back/forth with the auditors; I don't know. If that's the case: pay for the better auditors. These are rounding error expenses compared to doing extra engineering work just for SOC2.