The link between risk scenarios and detection use cases

Wednesday, 1 March, 2023

A macro photograph of a puzzle showing the missing piece

Earlier last year, I delivered a webinar on the importance of mapping risks and understanding threat coverage for a successful security monitoring strategy. A poll we ran at the start of this webinar revealed 4/10 of attendees had not yet clearly identified any risk scenarios relevant to their business. In this blog post I take a closer look at risk scenarios and how you can use them to check your detection coverage.

Most people working in security will be familiar with the risk register. In its most basic form, it is often an Excel spreadsheet with line after line of something someone in the business is worried about, along with some view on how likely it is to happen, and what the impact would be. If you’re lucky, it has some more columns with analysis of what controls are considered to mitigate the risk. Even the use of more advanced tooling to capture such risks barely moves this view forward.

Lots of management teams assume that their SOC is an all-seeing eye, and security operations teams may struggle to explain their coverage and how it relates to the organisation’s cyber risk.

Risk Scenarios

At Cydea, we’re big fans of starting with a more top-down approach that looks to capture a business-context narrative of the risks facing a business. Just by taking a more narrative approach, these top level risk scenarios can be immediately more useful in communicating with stakeholders about the risk, as they’ll feel like real-world stories they recognise from their own experience.

For many businesses, the majority if not all of their cyber risk can be summed up in around 5-10 risk scenario statements. If you end up with much more than this, you’re not only going to struggle to fit them on that single slide you’re allowed in the board briefing pack, but you’re probably also getting too low-level and technical!

An example risk scenario:

  • Personal Data Breach - Cyber criminals find a flaw in one of our online portals that enables them to access and download large amounts of sensitive personal information of our customers which they then attempt to sell on, leading to a public data breach.

While the description of the risk scenario under consideration can be tailored to use language appropriate to the organisation in scope, the underlying statement of the risk that scenario represents can, and should, be standardised in some way to allow easy further analysis. We like to use the Open Information Security Risk Universe to help provide some structure to how we make the underlying statement of the risk and its components:

Diagram for risk scenario - Sources is a key component, Events, their consequences and factors pertaining to them are supplementary considerations

By focusing on these core components for each risk scenario, we are able to map out further detail, using our understanding of exactly who will be targeting us, as well as the all important question of ‘what are we defending’. When we’ve done this work to understand the ‘who’ and the ‘what’, we can proceed to look more closely at ‘how’ the risk scenario could unfold in practice, and get down into specifics.

This is where we can start to look at mapping to use cases for security monitoring.

Mapping risk to detection use cases

Diagram depicting risk scenarios feed into use cases which then inform data sources of the potential compromised data

Lots of security monitoring tools describe the different ‘use cases’ that they can detect. Use cases look to link an action that an attacker will take to a set of one or more rules that will fire off alerts of the activity in certain data log sources.

More and more organisations are turning towards the MITRE ATT&CK framework to ensure use cases focus on realistic scenarios of how an attack could be conducted, and what to look for. It does an excellent job of mapping all the most likely tactics, techniques and procedures (TTPs) at each stage of a possible cyber intrusion.

The pitfall of using MITRE ATT&CK to check the scope of what your SOC can detect is that an organisation can start to focus too much on bottom up coverage across the entire framework, with a ‘gotta catch them all’ Pokemon approach! It also doesn’t give you insight into if those detections are being fed by data sources relevant to the risk you’re trying to prevent.

By linking an organisation’s risk scenarios to detection use cases (and their data sources) we can ensure we focus SOC coverage on what matters most for the organisation. We can answer the question “are we looking for the right things in the right places?

In conclusion, we’ve shown that by mapping out our high level business risk scenarios to use cases, monitoring rules, and then on to individual data sources, security professionals can demonstrate that monitoring efforts are aligned with an organisation’s overall security strategy.

Cydea’s cyber risk analysis and security operations advisory services can help you understand your cyber risk and set an appropriate SOC strategy.

Photo by Pierre Bamin from Unsplash