Comment by kstrauser | Hacker News Reader

Comment by kstrauser | Hacker News Reader

Summary: "don't be bad at cybersecurity".

Cybersecurity is special in a real sense: it's one of the few groups typically charged with enforcing required compliance controls. I was a senior engineer for many years before moving full-time into security, and it's amazing how many of those annoying inconveniences are actually mandated from external customers or frameworks[0]. As an engineer, I don't really care if every PR has an associated Linear/Jira/whatever ticket; sometimes it's enough to say "I'm fixing this thing because it needs to be fixed". As a compliance person, SOC2 says that all change requests must have an associated ticket, and my personal feelings about that aren't part of the equation.[1] Think Security is a pain in the neck? Work in a regulated industry like healthcare or finance where you have lawyers instead of colleagues giving you a list of commandments.

Also, I've never slept so well as I did the month after I was allowed to hire my CISO replacement. It's like looking up and seeing the Milky Way instead of the Sword of Damocles.

[0] Having worked at shops where Security didn't take time to explain those things, I've vowed never to be that person. If I ask you to do a thing, I'll tell you why it's something we have to do. We should all collectively be better about that.

[1] Although there's an analogy between "compliance" and "unit testing". A side benefit of thorough test coverage is that you tend to write better structured, more loosely coupled, easily testable code. That's all good to have even if you never ran a single test. Same with compliance. The ability to audit all the things means you're more likely to design your systems so that they can be inspected, instrumented, and monitored. In the "where's the ticket?" audit case, know what's more annoying than having to match every PR to a specific ticket? Having to individually assess a couple hundred exceptions to very that each of them reflects a reasonable judgment to violate the guidelines.

> As a compliance person, SOC2 says that all change requests must have an associated ticket

Does soc2 actually say this? IIRC their spec docs are proprietary so chumps like myself can’t actually read them. But a (imo great) SOC2 auditor I worked with previously allowed us to treat GitHub PRs as their own sufficient justification. We still used Jira for most, but for minor fixes, quick upgrades, no Jira necessary. A former coworker said they did the same at a previous job. I think, in this particular case, it isn’t SOC2’s fault, it is the fault of auditors who are afraid to not just do what everyone else does.

Sigh. I don't have the docs in front of me, and even if I did, darned if I'm touching those diabolic tomes without a 10-foot pole and a paycheck. But they do say something along the lines that all change requests have to have some kind of a ticket. The good/bad part is that it doesn't specify exactly what that means. If you can find an enlightened auditor who accepts an explanation in the PR, awesome! There's no guarantee that the _next_ auditor will see it the same way. The whole audit process was a back-and-forth with explaining why we think our controls satisfy the request, and the end result was a clean report.

> it isn’t SOC2’s fault, it is the fault of auditors who are afraid to not just do what everyone else does.

There's some liability for them if they're too lax. Suppose a breach happens and a given control, as written in the spec, would have prevented it. It could come back on the auditor who signed off on a clever interpretation of that control.

I haven't worked on anything that had to adhere to that standard, but I also have yet to work somewhere where a "Change Request" was a very specific thing related to workflows that may or may not involve software, i.e. hardware. A pull request rarely had relation to a proper Change Request.

A control that results in a paper trail without making anything materially better, but must still be obeyed to the letter because a certification depends on it? Why, I've never heard of such a thing, I do declare!

It depends what’s in scope and the control being evaluated. For example, if your SDLC/release and infrastructure processes the environment(s) that are built from them are in scope of your SOC2 audit, then a change to the code deployed to the in-scope environment must meet a defined policy for change control. Auditors aren’t eager to accept “there is no SDLC,” or “our change control policy is to deploy to production whenever.”

A lot of SOC2 is hand waived as paperwork, but the point is that an organization (and their independent auditor) can show evidence that they have established certain processes and controls, and that they can demonstrate compliance with their word. (This belies the tension that some use to discredit independent auditors: that the client pays the auditor for their report. What’s less well understood is that the auditor has a much greater vested interest in being honest, and that they’re going to get questioned if a matter ever goes to court. No one client is worth losing the entire firm. There are, of course, bad auditors just as there are bad developers, admins, accountants, etc.)

I spent time working in compliance and led the inaugural SOC2 Type 2 audit at a household name. These days I spend my time primarily on infrastructure.

the SOC requirement is that any change can 1) be looked at before happening, and 2) there is an audit trail. A PR generally works because it's auditable and there may not be an impactful change.

"change request" is often a specific term in things Project Mgmt, SDLC, etc.

Reply on news.ycombinator.com