Excalidraw+ Is Now SoC 2 Certified

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?

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.

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?

In my experience, it's more likely it was the approach of the folks at your company that made your controls.

SOC2 (and a bunch of similar regimes) basically boil down to "have you documented enough of your company's approach to things that would be damaging to business continuity, and can you demonstrate with evidence to auditors with low-to-medium technical expertise that you are doing what you've said you'd do". Some compliance regimes and some auditors care to differing degrees about whether you can demonstrate that what you've said you'd do is actually a viable and complete way to accomplish the goal you're addressing.

So the good path is that the compliance regime has some baseline expectation like "Audit logs exist for privileged access", and whoever at your company is writing the controls writes "All the logs get sent to our SIEM, and the SIEM tracks what time it received the logs, and the SIEM is only administered by the SIEM administration team" and makes a nice diagram and once a year they show somebody that logs make it to the SIEM.

One of the bad paths is that whoever is writing the controls writes "We have a custom set of k8s helm charts which coordinate using Raft consensus to capture and replicate log data". This gets you to the bad path where now you've got to prove to several non-technical people how all that works.

Another bad path is that whoever writes the control says "well shit, I guess technically if Jimbo on the IT team went nuts, he could push a malicious update to the SIEM and then log in and delete all the data", and so they invent some Rube Goldberg machine to make that not possible, making the infrastructure insanely more complex when they could have just said "Only the SIEM admins can admin the SIEM" and leaned on the fact that auditors expect management to make risk assessments.

The other bad path is that whoever is writing the controls doesn't realize they have agency in the matter, and so they just ask the auditors what the controls should be, and the auditors hand them some boilerplate about how all the servers in the server farm should run NTP and they should uninstall telnet and make sure that their LAMP stack is patched and whatever else, because the auditors are not generally highly technical. And the control author just runs with that and you end up with a control that was just "whatever junk the auditors have amalgamated from past audits" instead of being driven by your company's stack or needs.