How to translate security concepts into business risks

At RSA this year, we launched a new product capability, Business Risk Perspectives, that translate security concepts into business risk.With everything that’s happened over the last few weeks, it’s easy to forget that RSA 2020 took place just over a month ago. As anyone who’s attended knows, RSA is intense – our team had a seriously busy schedule. One of the many people that we caught up with in San Francisco was Varun Haran from ISMG. During the conversation, our CEO said something that got us thinking: 

‘No one in the business cares about a vulnerability on a Linux box. Everyone in the business cares about a vulnerability in our payment process. They’re the same thing, I just described them in different contexts.’ 

Business stakeholders understand that security is a risk that has to be taken seriously, but security reporting can leave them wading through a lot of information and jargon in order to find the insight that they need. Reframing IT or security concepts in business terms is a good way to help business stakeholders zero in on the things that matter most to them. However, it can be complex and time-consuming to filter out data that isn’t relevant, calculate thresholds or explain the potential cost of a vulnerability, especially when it’s not being automated. In this post, we’ll look at why security and the business sometimes struggle to see eye to eye and how translating security concepts into business risks can help. 

Why does security struggle to give the business the insight it needs? 

Security teams supply metrics to a range of business stakeholders, from the board to the C-Suite and the heads of the different departments or business lines. Each of these groups has different priorities and require different levels of detail. The board and C-Suite want reassurance that the company and the brand are protected from threat actors and that risk to the organisation is being sufficiently minimised. They also want proof that it can substantiate regulatory compliance when it needs to and that security investments are achieving reasonable ROI. The line of business heads, on the other hand, will want to understand internal policy adherence for the lines of business for which they are responsible. Specifically, they will want to know how issues, threats or vulnerabilities flagged by security might affect their operations. Or, if their line of business is under-performing, they will want to know why and may request additional support. Or, if they have a valid reason, they may request some kind of exception. Whether they’re looking after the organisation as a whole, or specific parts of it, both groups want to understand security as it relates to the business. Without additional context – whether that’s financial, organisational, geographic, regulatory or some other alignment – the data will be of limited use. And crucially, they need someone to filter out the bits that are relevant for them and communicate them in a way that’s meaningful. The filtering, segmentation or processing required to provide this context and filter out unnecessary data is often easier said than done. For instance, if the board wants to understand the posture of a specific part of the organisation, they won’t want to wade through pages of metrics. A simple ‘red, amber, green’ (RAG) status might be better, but providing that top-level view is harder than it sounds. The vast majority of data for security measurement originates from security or IT tooling, which are typically highly specialised point solutions. This data is very technical so wouldn’t be relevant to a head of business line. The challenge is threefold: 

1. Attaching relevant business context to assets to ascertain scope. 
2. Calculating and combining your measures and metrics across different security verticals. 
3. Summarising this data effectively, so that important security information from all business area across all relevant business processes can be consumed in a bitesize format. 

To illustrate an example, if you’re responsible for payments processes you will want to know the state of your security. First, you’ll need to identify the assets relating to this business process – the apps handling payments, the servers hosting them, the databases storing them, the accounts used to access the apps, and the people who own those accounts.  Next, you need to collect and combine data to calculate our security KPIs and KRIs across all these assets for all security areas of importance for your payments process. This could be anything from vulnerability scans to privileged access controls. You can’t just ‘add it all up’, though. The trick is to design an appropriate algorithm to combine all these different pieces in a meaningful way. A simple but effective approach can be to decide on what value of your metric can be considered a ‘pass’. Once you have established thresholds for key metrics, you can create a RAG system (i.e. red is a fail, amber is a close pass, green is strong pass). This helps normalise across disparate data, allowing you to combine similar outcomes (pass/fail or RAG) in different ways. This approach also really helps with the summarisation aspect, as the RAG system is easily digestible. This is much easier said than done, however. This process is a major data science undertaking. As a result, security teams can struggle to provide business stakeholders with the insights they need. Either, they’re not able to frame the data in a way that’s useful or because they can’t balance the time required to do so with their other work. This can lead to breakdowns in communication between security and the business, which over time can have an adverse effect on the security posture and regulatory compliance of the organisation. 

  

How to translate security concepts into business risks 

We’ve seen why business context is valuable and why it can be challenging. Now we need to think about various different ways of reframing security concepts, performance or data in business terms. Try to put yourself in the shoes of the business owner. These are the sorts of questions that will be on their mind, so think about whether the security insight you’re providing addresses these concerns:

• How will this affect our core business operations? 
• How might this affect our customers? 
• What’s the potential cost of this risk? 
• What financial, operational or reputational damage might this cause? 
• How would this improve our operational resilience? 

Admittedly, questions about attaching specific cost values can be difficult for security teams, so this might be left to risk modelers. In any case though, it is essential to think about key questions like these to sense-check reporting, ensuring you’re measuring what really matters to business stakeholders. Now, this may seem somewhat tangential, but my A-level History teacher once gave me a great bit of advice. Keep asking yourself: ‘So what?’ This is another way to move towards something that matters to the business. Let’s look at an example: You see you have a vulnerability on your VPN server. ‘So what?’ It’s critical and there’s a patch available. ‘So what?’ The longer we don’t apply it, the longer we risk someone finding a way to exploit it. ‘So what?’ VPN is really critical right now as it’s the only way our newly remote staff can connect to key business documents. Now you’ve got to a place where the business owner would raise their eyebrows, so you’re pretty much there. There will, however, be a lot of ‘so whats?' so we need to prioritise. The worst business outcomes and any areas that relate to audit points or regulatory requirements are top of the guest list. But equally, you need to give time to the things that are less impactful, but more likely. So the essential prioritisation is weighing up potential impact and likelihood. The list you present upwards should always be relatively short – if there are too many things to worry about, the impact of the message could be lost.

 

How can Business Risk Perspectives help with this? 

We recently caught up with Mike MacIntyre, our Head of Product, to explore how Business Risk Perspectives (BRP) helps security teams to identify, isolate and resolve the risks that matter most to the business. Check out the interviews below.[arve url="https://youtu.be/kYFpCLjQYuw" /][arve url="https://www.youtube.com/watch?v=RX5bHBoP_GE&feature=youtu.be" /]To learn more about Business Risk Perspectives, and how it can help organisations to translate security concepts into business risk, feel free to get in touch by email, Twitter or Linkedin - or book a demo with one of our team.