Hacker News Reader

Comment by cheschire | Hacker News Reader

My experience dealing with IS professionals is they're either spending all their time writing documentation, or they're checking boxes in automated scan tools, or they're uploading results into centralized systems.

It always seemed to me that a tiny fraction of a percent of the entire IS workforce is actually involved in defining strategy. Most of them just become experts at bureaucracy compliance.

IS has more in common with being an accountant than being an IT professional, in my unjustifiably harsh opinion.

View on HN

I work with red teams and auditors as a blue team dev, and I don't think the documentation is necessarily because of excessive bureaucracy. It's because modern infrastructure is complicated as hell and it's several full time jobs just to translate what the red team finds into a systemic view of current weaknesses, and then to translate that into a plan that the inevitably outstretched blue team can actually act on. Writing things down is a critical part of making the problem tractable.

In my experience, being able to think clearly end to end is the hardest part of the whole operation, and the lack of that capability is the reason it feels like paperwork and mindless checklists.

Infosec people are, by and large, auditors. Someone once told me you can understand auditors better if you assume they hate you for no reason.

This advise has served me well.

That's a pretty large generalization. There's a wide range of careers under the umbrella of what gets called Infosec.

Some that really don't fit the definition of "auditor"

- Vulnerability research - Pentesting - Incident Reponse - Threat Hunting

Even the type of Infosec work which can end up being closer to audit should have a different focus, if done well.

Yes, they "should", but they rarely do.

My comment was largely directed at the type of infosec person any other IT person is most likely to interact with.

I'm not sure I'd agree with "rarely". There is some cross-over with auditing, but the infosec people (in my experience) are generally more risk focused than auditors who are more "rules" focused.

Also I've worked with quite a few security people who have strong technology backgrounds and have worked in IT before moving to security, so definitely understand the frustrations of operational teams.

In a way this is a very nice explanation of something we called "offensive mind" :)

Auditors don’t hate you for no reason. They have the tricky job for being (formally) responsible for signing off on practices they know too little about, get shitty documentation for while not getting enough time to understand. To make matters worse they get paid a lot, but get paid by the people they audit whom fire them for withholding signatures. Looking at firms they they think “why do they always send me the wrong documents, at the wrong time while withholding the documents I need and only bringing them up when I’ve escalated the matter to the board”. It’s a crazy relationship from both sides.

Honestly, as a free market person with 15 years working with auditors I sometimes think that external audits need less market and more intervention. Then I remember most government oversight is even less effective. Every government agency (EU / NL) I know of is both awed by a big-4 rubber stamp and an avid consumer of big-4 hours. My humble conclusion is that oversight is a hard human problem.

> responsible for signing off on practices they know too little about...

Ok, well, there's the problem. Or at least most of it. No one should be even considered to audit a system unless they understand how it works.

Aand there's a problem :) So if you consider the size of most audit teams relative to the size of the IT departments they audit, how do the auditors become subject matter experts in all the different types of technology in use in the organization?

It's a tricky problem. One option is to audit against "known standards" but that's often a horrible hack as the standards themselves need maintained and with more cutting edge technologies (think the rise of cloud native) the standards may not even have been written yet (or are hard to maintain as the underlying tech evolves so quickly)

Another option is to rely on external companies (e.g. the Big-4) but they don't have any more ways of getting large pools of SMEs in all the different technologies either (despite what their sales people might tell you).

You're not wrong, but ironically this often depends on the CISO!

But yeah very few sec jobs are actually doing real hacking or dev. A much more common position is more like a PM mixed with a lawyer: Reading through mountains of compliance regulations, talking to engineering to find out if we comply, and documenting the compliance. If we don't comply, you'll often create high-level tickets and track engineering progress.

Then of course there's the tools you run and the boxes you check. Back in the day this often involved writing scripts if not full applications, but nowadays there's a SaaS for everything and everything is a REST API (or GraphQL) and very, very few CISOs will invest in custom tools. The only exception I saw was at a company where we were developing a layer 7 protocol on top of UDP. It was a lot easier to justify since by definition no tools existed for this protocol, but this is super rare.

Securing a system is like flying an airplane - if one thing goes wrong, the whole thing is fucked. At large scale, a good CISO will be more of a process fiend than a whitehat hacker, the same way that Jetpack Guy is probably not the guy you want piloting your vacation flight to Maui.

Reply on news.ycombinator.com