[kasey_junk]

I have direct experience telling a soc2 auditor that the approval control for installing applications on “endpoints” was a message to a slack channel that was assumed approved.

To satisfy the audit they looked at an app that was installed on a laptop that was not part of our base image from the previous 6 months and a screenshot of the message where the user “asked” to install it.

You can literally get a soc auditor to write up whatever you want as a control and if they don’t explain that and encourage it you should find a new auditor.

[jasonlotito]

Yep, I see I was wrong.

I can see that my experience was in putting actual effort into things.

[kasey_junk]

The problem with these audit regimes is that done poorly they cause you to put effort into the wrong thing.

We could have codified some more complicated approval process for apps on laptops. That could involve tickets and strenuous review and making everyone spend tremendous resources trying to keep an endpoint secured that way.

But we didn’t believe that was the right way to do it. Instead we assumed no matter what we did laptops were going to get owned up. So we focused on blast radius, detection, forensics and time to remediation. We’d need all those things even if we believed in a pre approval process.

But we didn’t document most of those things in audit scoped controls, because that would have ossified them. If we wanted to improve our detection regime we didn’t want audit ceremony to get in the way.

I’m comfortable with those decisions and would make them again. We worked very hard to make sure our endpoint security was as good as we could make it.

A specialist accountant certainly would not have improved the process.

So no, I don’t think the solution we came up with was not putting effort into the problem, it was thinking very hard about it and not letting a checkbox audit cause us to make bad decisions.