5 ms·

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

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.

deleted 5y ago
[deleted]
cheschire 5y ago
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.
- freedomben 5y ago
  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.
- pnutjam 5y ago
  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.
  - raesene9 5y ago
    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.
    - pnutjam 5y ago
      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.
      - raesene9 5y ago
        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.
  - rfoo 5y ago
    In a way this is a very nice explanation of something we called "offensive mind" :)
  - wjnc 5y ago
    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.
- munchbunny 5y ago
  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.
- spoonjim 5y ago
  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.
freedomben 5y ago
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.
remus 5y ago
> 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!
dogleash 5y ago
>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.
raesene9 5y ago
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
- jacquesm 5y ago
  Those reports tend to be 90% boilerplate.
  - raesene9 5y ago
    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.
    - jacquesm 5y ago
      Fair enough, there are exceptions.
  - Sebb767 5y ago
    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.

deleted 5y ago

[deleted]

cheschire 5y ago

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.

freedomben 5y ago
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.
pnutjam 5y ago
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.
- raesene9 5y ago
  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.
  - pnutjam 5y ago
    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.
    - raesene9 5y ago
      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.
- rfoo 5y ago
  In a way this is a very nice explanation of something we called "offensive mind" :)
- wjnc 5y ago
  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.
munchbunny 5y ago
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.
spoonjim 5y ago
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.

freedomben 5y ago

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.

remus 5y ago

> 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!

dogleash 5y ago

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

raesene9 5y ago

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

jacquesm 5y ago
Those reports tend to be 90% boilerplate.
- raesene9 5y ago
  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.
  - jacquesm 5y ago
    Fair enough, there are exceptions.
- Sebb767 5y ago
  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.