Corporate Security

There Is No Such Thing As Information Security Risk

Measuring RiskHaving 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);

C-Level bod

“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”

Marketing bod

“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”

Developer bod

“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”

Security bod

“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”

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

6a00d834527c1469e200e54fa36ecc8833-800wiA 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.

3 replies »

  1. Security is always about supporting the business. This is why I ensure our security consultants understand business. When all you can talk about is technology and “security stuff”, it’s not that they won’t listen, it’s that they can’t listen. We as security professionals must talk business. We need to articulate security issues in ways the business understands. It;s very similar to insurance. No one want’s insurance but they are glad they have it when things go wrong. They understand that a car crash can cost anything from a few pounds to millions depending on the nature of the incident. As an insurance policy describes what it covers, what excess the “business/person” will have to pay we can articulate the costs of doing nothing (our excess) and the cost of our insurance (firewall) and the limit of protection it offers.

    Great article. Thanks for raising the issue.


Want to add to the discussion?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.