On cocktail JDs in infosec and why they will keep coming...
How is having 5 years of experience as C++ developer relevant for a CISO role? This is the age of cocktail JDs. I think they will keep coming for some time. Read to know why.
I see lot of opinion and feedback on JDs that ask for hands-on experience for a leadership role in infosec or a cocktail of administration experience.
I don’t think they will stop anytime soon. I think they will keep coming for quite some time. Here's why.
- InfoSec is a cost centre for almost every company, except in a firm that provides it as a service.
- Due to the many dimensions that infosec has branched into myriad set of skills are required if a firm wants to keep themselves secure from all threats (penetration testing, soc, threat hunting, administration of security tools, etc.).
- Due to point 1, companies want to maximise their return on investment (employee salaries are a major opex item).
- The first hire in any new department/ function is always the leader. The leader is then expected to hire, train, and utilise the optimal resources (read - at as minimum a cost as possible, without hurting the company) to achieve desired outcome. Hence the rise of outsourcing of many security activities.
- Information security, as a career and industry, is still evolving. Employers are still trying to figure whether they need such a function in-house (cue - rise of MSSP and vCISO), whether the position of CISO really deserves a seat at the table, do they need a CISO (a strategic advisor) or Head of Infosec (more hands on administration and involvement), etc.
- Due to points 3, 4, and 5, the employers try to cram as many skills and experience requirements as they can, into a JD.
That, is the reason why you see so many mixed JDs (CISO requiring 5 years of C++ development experience, looking for significant IT experience for a junior role, etc.) in infosec.
However, is this situation bad enough to warrant a rant?
Let’s take a cocktail JD as example - administration experience as a requirement for a GRC role.
Not every company has use for a GRC professional full-time. Companies want (and need) governance and strategic infosec advice, but they also need people who can implement them. These are in a very short supply.
Our understanding of GRC is different from that of an employer. For many of those, it involves
- Documentation (processes, SoP, position papers, project plans, ToR, RFP),
- Coordination (interfacing with other departments; facilitating people who are 2-3 layers deep on infosec issues, why you want them to do the work, what is it that you exactly want them to do, facing audits, getting the findings closed, etc.),
- Project management, with activities that are 2-layers deep at each step.
We think 'strategy', they see 'documentation'.
We think 'security program management', they see 'someone who will do all jobs related to security, including driving a security program'.
Add to it the following facts,
- We are at odds with all other disciplines in a company (we are in our infancy, industry is still figuring out how to treat us and where to put us in the org chart),
- Most of GRC work is hard to prove (unless the process yields tangible benefits or stakeholder delight), and
- Most of the us as practitioners are not doing a good job of making employers aware of the nuances and challenges of their role, and the value they can bring except by way of a lament/ rant.
I have said before that you don't need administrative certifications when your aim is to understand how-something-works-so-that-you-can-break-it. However, some level of hands-on experience is an advantage that you don't want to miss on. Hands-on experience on technology is a boost to GRC activities.
My GRC skills improved drastically, once I spent time on tools.
- I could write better processes that aligned with the environment (rather than advising industry best practices), perform a security audit better, identify more risks in the environment than before, understand a regulatory advice and suggest a better way forward than ‘best practices’, etc.
- I could identify serious findings in a ticketing solution because I spent some time with the tool.
- I could suggest a patch management process that utilised the current tool and manpower better due to my familiarity with their tech stack, my understanding of the way patching works there.
So, I think we will continue to see the cocktail JDs in InfoSec for some more time.
What is invisible (individual needs, desires, and greed) will always drive what is visible (JDs, compensation, market preferences in infosec hiring and purchases, etc.).
At the intersection of pentest, auditing, risk management and career advice. Musings based on real experiences, not theory. All infosec, mashed up.
Follow the Risky Context channel on WhatsApp (if WhatsApp is your thing. Your number is not shared with others when you connect to my channel): https://whatsapp.com/channel/0029VaDqrFU8aKvQohD5nq0r