Having worked in IT and Information Security for 13 years, I’ve come to the conclusion that there is no such thing as information security risk. There are just business risks that have one or more security or IT related causes.
There is a fundamental and persistent disconnect between risk conversations in technical and non-technical business communities and few are building the bridges needed to close that gap. Taking the world of IT change as an example (I reckon you’ll have no problem recognizing most of these actors on the project stage);
“The late delivery of this IT project is impacting our ability to realize our digital marketing and sales strategy, main pillars of our growth plan for the next two years”
Operational business bod
“If we don’t get this solution in place, we are at risk of not meeting annual performance objectives”
“Every second we delay getting this to market risks loss of planned competitive advantage”
Project Management bod
“The late delivery of this IT project is risking an overrun in the allocated budget and disappearance of my hoped for bonus”
“Squeezing time and resource to fully pin down requirements, understand system interactions and robustly test means we could have significant functional issues with the implemented solution”
“Not allowing time to assess security of planned changes, pentest web elements and fix problems found, risks serious vulnerabilities ending up in the live service which could lead to financial fraud, data disclosure or data theft”
What really matters? The bottom line. Why is security so often deprioritized in this context? Because all of the other impacts are easier to understand and feel more immediate. Without a means to compare these risks side by side, security will continue to be the poor relation.
Something technical security folk don’t always seem to get;
If there’s a new threat, newly identified vulnerability or a procedural control is broken, it doesn’t matter…
…UNLESS it is likely to lead to an exploit that can impact the balance sheet and/or reputation of the business and…
…IF that impact makes it cost effective to delay implementation and get it fixed.
I’m not ignoring the fact that it’s still an industry-wide challenge to realistically assess security gaps and monetize potential impact. Especially estimating the likelihood of vulnerability exploitation and turning all risk inputs into useful cost benefit analyses. This article from John Pescatore prompted me to start a discussion on LinkedIn about risk calculation. It drew in comments from a broad range of contributors (including Jack Jones creator of the FAIR risk framework) and highlighted many of the challenges facing IT and security teams today.
Sorting out an organically grown risk function is not quick or easy, but until we get better at putting our security news into a business context and build credibility for the function, security will never be everyone’s responsibility. No matter what lip service is paid, IT risk will be seen as IT’s job to fix and security risk will be a job (to reflect the view of many senior managers) “for the people who understand security”. How painfully ironic.
A good place to start? A rock solid security RACI. This Tech Target article (scroll down to read without registering) looks at using RACIs in the context of risk assessment and here I take a look at proper allocation of risk ownership in security assurance for change, but to nail this, I suggest going a step further. Use security incident management scenarios to thrash out who contributes what to the security picture and who has what to lose. It jointly focuses minds on the “so what”.
Who’s neck is on the block when the Information Commissioner or financial regulator comes calling? Who owns the services that will be operationally impacted by an outage? Who answers to the markets if a breach slices 30% off the share price? Along the way security awareness will be dramatically improved.
At the same time, to keep that respect and awareness bandwagon rolling, have a long hard look at the MI generated by your security team – does it headline with tangible current or potential fallout from security related issues? If it doesn’t, do you have the inputs and communication skills to ensure the next report does?
So, that’s why I argue that there’s no such thing as Information Security or (based on the same premise), IT risk. You might aggressively disagree, but it’s not a bad way to start your next risk conversation with the board.