Does a CISO need to Be Technical?
One of the motivations for writing Cyber Risk Management was the opportunity to give my view on some of the pertinent debates in our industry. The subjects which are conference keynotes and panel topics the world over. A cathartic dossier of my opinions based on my engagements across the years. I wrote a tonne of content that didn’t make the book, subsequent conference talks, podcasts or blogs. In that category was the perennial ‘does the CISO need to be technical?’ debate. My two cents herein!
The word technical is as subjective as ‘secure’. For a CISO to understand the organisational risk posture, they need to appreciate the constituent components of the technology stack(s) which is being used to deliver business services. This is not to say that all CISOs must have come from a role as a system engineer but knowing how systems and applications process information is critically important if the CISO is to: a) identify appropriate controls to mitigate the impact or likelihood of a risk b) provide non-security stakeholders with a view of the organisational threat landscape.
Some will say that the CISO doesn’t need a technical grounding. The rationale being that the CISO function is increasingly a business leader who simply needs to translate technical jargon into meaningful layman’s language. I personally believe that this approach is fundamentally flawed for two reasons:
Firstly, a large percentage of cyber risks are grounded in technology and risk assessments invariably require the leaders of the IT function and the security function to make concessions in the best interests of the company. During the control assessment and mitigate phases of an assessment, the CIO/CTO and the CISO will often have to articulate the risk landscape along with mitigating factors. A good risk management framework will often only allow for a risk to be accepted for a finite period of time. These factors require the CISO and the CIO/CTO to speak with confidence and authority, I have personally found that this process can resemble an episode of Dragon’s Den. The CIO/CTO and CISO defending their position and fielding a myriad of complex questions, such as:
Why do we have to do this?
Isn’t there another technical alternative?
How long will this take to fix?
For the CTO, the responses are often immediately available or, they can speak with enough understanding of the subject matter to give some indicative estimates. The CISO who isn’t technical may have to say, ‘I don’t know’ or ‘let me check with my design team’. The non-technical CISO is able to present a (metaphorical) firewall should the conversation wade into technical territory “I don’t want to get into the weeds” being a staple response. There are situations where exploring the minutiae is a fruitless activity but surely the leaders of our function need to understand our function. I always think that cryptography is good barometer for CISO technical knowledge. Should your security leader be able to run through the substitution and replacement s-box construction of AES? Probably not, they will (skills shortage allowing) have domain experts in this field. They should, in my opinion, be able to understand and articulate when AES is a more robust encryption algorithm than, say, DES. The CISO cannot remain deep and should never be ‘in the weeds’, but they must take technical concepts from their teams, assimilate and pick out key points for a board or steering committee.
