Hacker News Reader

Comment by Sebb767 | Hacker News Reader

CISO - and IS overall - is actually much more people-focused than most realize. You'd think you're hacking away and/or find vulnerabilities all the time, but in reality - at least in my experience -, you spend most of your times fixing the easy stuff and selling the measures to both management and your users. Quite a few people I know (including me) tried to get into IS with a good technical skillset, but it turned out that what we really needed was patience and people knowledge.

Of course there are pentesting companies that provide a far more hacker-like job, but even then, it's still a lot of report writing and explaining.

View on HN

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.

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.

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).

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.

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.

>CISO - and IS overall - is actually much more people-focused than most realize. You'd think you're hacking away and/or find vulnerabilities all the time

Finding vulnerabilities is just a specialized type of software QA that sometimes looks and acts more like an internal auditor.

I think "the security community" is too caught up thinking that hacking is the end-all-be-all. It prevents them from realizing they're just another category of business analyst who's job is to complain to the development (or ops) team that their requirements should be prioritized over every other stakeholder's requirements.

Can confirm.

I've been interested in security since I was a teenager on the wild west internet in the 90s. I went into Computer Science and subsequently gained work as a software engineer, but stayed interested in security. I did my masters in Cybersecurity and interviewed for a number of security focused jobs (including pen test jobs), but I ended up taking none of them because the majority of them were not writing code. Usually we were either running existing tools (nobody wants to invest in developing their own tools, but that's another story), or doing code reviews of horrendously nasty code. I ended up staying in software engineering and the security work usually finds me.

> You'd think you're hacking away and/or find vulnerabilities all the time, but in reality - at least in my experience -, you spend most of your times fixing the easy stuff and selling the measures to both management and your users.

As I see it, whatever technical measures are put in place people in the org will always need access to data at some level. With that in mind, it's about educating users so they know what's risky, what best practices are etc. Easier said than done of course!

Pentesting involves report writing 'cause you've got to tell people what you did somehow :)

A better model (IMO) is for the pentester to get onboarded into the bug/defect tracking system and put things there. Pretty much every pentester I know would prefer this to writing long reports :P

Those reports tend to be 90% boilerplate.

Depends hugely on the testing team and scope :) I've been a customer and tester over the years and I've seen everything from obvious scanner output, through to actually good bespoke content.

There is going to be some boilerplate though, especially on lower price testing, that's one of the reason why testers would prefer just to file bugs.

Fair enough, there are exceptions.

It always depends on what your client knows. For most clients you could probably cut 30-70% of boilerplate, it's just that you don't know what. I've seen people who could exploit an unpatched Linux box in minutes but would have a hard time exploiting CRSF vulnerabilities and also the other way around.

Of course, some people sell you a lot of paper for a lot of money, but even the good companies include a lot of you-know-if-you-can-skip-it boilerplate so that the client understands the report. At least that's my experience.

Reply on news.ycombinator.com