Summary

Industry best practice frameworks and standards emphasise the need for a risk-based approach in selecting and designing controls that will suit an organisation, but neglects to provide practitioners with the process to implement this. We provide a threat scenario modelling approach to the selection and design of security controls to ensure that they are pragmatic and aligned to the risks that your organisation prioritises.

The Symptoms of a Bigger Problem

One of the big problems we have seen in the industry right now is the lack of a risk-informed approach to security. This can often be identified when any variation of the following statements or questions are presented in relation to implementing security:

• “What controls can I implement to increase my maturity?”
• “I want to, need to, must be NIST-aligned.”
• “We did our ISO 27001 certification, but I don’t think it actually made an impact on our security.”

There is a big reliance on using best practice security frameworks without a consideration to ask more risk-based questions of why and what are we trying to protect?

As a result, when we do ignore these questions, it leads to a mis-prioritisation of security spending and attention to the right controls that will mitigate risk.

So what is the solution?

Frameworks are like a dictionary – they provide the words, but you still need to write your own story…

Industry best practice frameworks and standards are a great starting point for understanding what security controls should be considered for your organisation. It is important to note that all these frameworks and standards emphasise the need of using a risk-based approach in selecting and designing the controls that suit the organisation it is being applied to. Despite this, there is often very little guidance on how this can be practically done, leaving organisations to adopt a blanket approach, trying to implement every single control.

Using business risks to inform cyber risk scenarios

In this top-down approach, we use risk scenarios as a basis for prioritising control selection for the key systems of interest for the organisation.
To effectively define cyber risk scenarios, we should be looking closely at our business risks – What assets does the business define as critical? How does someone materialise a scenario to compromise these assets?
Instead, we often see organisations fall into the trap of defining very technical / low-level cyber risks that are centered around a control (or lack thereof).

For example, consider these two statements:

When we define control-centric risk statements or scenarios, it is often hard to measure its impact or likelihood. As we know, taking a defence in depth approach relies on multiple layers of controls to be working together to reduce the likelihood or impact of an attack. As a result, it makes it difficult to find the right mix of controls to achieve pragmatic risk reduction.

By design, the language used in control-centric risk statements is quite technical. Given that most business leaders are not technical, it does not resonate well with them and unlikely to get you the budget you are asking for.

When we break away from the control-centric approach and move to business-centric impact approach, we can much more easily see this correlation between controls and the risk they mitigate. It also helps us select the most relevant controls to reduce the risk at hand, thereby increasing efficiency of security spend.

Going back to the basics

Before we start formulating our cyber risk scenarios, let’s revisit the foundations of risk. If we take it back to the basics, we know that cyber risk is made up of the following components:

To simplify, we have a threat actor that exploits a vulnerability which causes an impact to the business. Ultimately, the controls you implement should influence one of these levers above, i.e., ultimately reducing the likelihood or impact of a risk. In summary, we want to reduce the number of weaknesses in the organisation and increase the effort it takes to exploit known / necessary gaps that we have. On the impact side, our controls should be designed to limit the impact as much as possible to the organisation.

As an example, for an Internet facing system, we can invest in reducing the likelihood of it being compromised through a WAF, hardening and vulnerability management. At the same time, we can reduce the impact from such compromise by reducing sensitive data available in the system and employing various controls to prevent further spread towards other assets.

Formulating a cyber risk scenario

To formulate our risk scenarios, we need to understand the impact and the threat actors that are motivated to cause them.

Analysing the impact

The goal of this step is to identify the most important adverse impacts that can be achieved through cyber means.

To achieve this, we want to:

1. Understand what a significant business impact is by consulting enterprise risk register / frameworks and engaging with key business stakeholders.
2. Identify and map the key business processes and related systems / assets if compromised can materialise the impact.
3. Assess if impact can be achieved through cyber means and identify the systems that would need to be exploited to do so.

To apply these steps, this is what an example output can look like.

Let’s say when we first consulted with the business and risk stakeholders, we found that a significant adverse business impact is a fraud event that results in the loss of more than $250K.

Next, we would identify which business processes could result in the identified adverse business impact. We found 2 of interest: that is, the payment of employee salaries and payment of suppliers – where payments made to employees or suppliers were greater than $250K per payroll run or for certain suppliers.

Next let’s identify if this fraud event can be materialised using cyber means. We mapped the systems of interest as follows:

• Employee salaries are paid through a central HR/Finance
• Supplier invoices are sent through email to a dedicated inbox and paid manually

Lastly, we assess how a threat actor could achieve this impact through cyber means. For the employee salaries, a threat actor could potentially manipulate the finance system by either stealing the credentials of an authorised/privileged user or by manipulating the underlying database directly. For the manipulation of supplier invoices, a threat actor could perform social engineering by impersonating suppliers, requesting a change to payment details to redirect funds.

Forming the threat profile

When capability meets motivation a risk is formed, and therefore our goal in this step is to identify which threat actors have both in relation to a specific scenario. To achieve this, we want to:

1. Map relevant threat actor(s) per scenario (insider, hacktivist, cyber crime, organised cyber crime, nation state).
2. Understand each threat actor(s) capabilities, tactics and techniques and motivation.

The following is an example of what this could look like:

Carrying over from the previous example, we start off by identifying that opportunistic cyber criminals are a likely motivated threat actor that would want to materialise this for financial gain.

We can also extrapolate that we know that opportunistic cyber criminals often employ low-medium sophisticated techniques, where common tactics they use is social engineering and/or credential stealing.

Often because they are opportunistic actors, they don’t want to expend too much effort into achieving their objective.

Note: For the purposes of this example, this is quite a simplified version of what can be done when we develop the threat profile for a scenario.

However, in the practical application of this approach, this is the perfect chance to leverage knowledge and expertise from defensive and offensive security teams to flesh out the threat profile. We can leverage threat intelligence or the in-field experiences of red-teamers and penetration testers to help us establish this threat profile.

Identifying the relevant weaknesses and vectors for a scenario

The goal of this step is to identify the relevant weaknesses that could be exploited in an attack.

This is a crucial step as often an attack path is made possible via other systems, essentially bypassing the per-system controls. As an example, an attacker may have gained control of our entire domain in the form of high privileges, without having to interact with a HR system containing sensitive data.

However, by having that level of access, bypassing application level controls is trivial by way of the hosting infrastructure.

The following should be taken into consideration when performing this step:

• Consider attack paths from the perspective of the relevant threat actor. Are they coming in externally or already in a position of privilege in the network?
• Consider what systems they will need to traverse through. This does not often align with CIA ratings.
  • For example, can an attacker move laterally from the development network to production? Is there shared infrastructure between development and production that could allow this? Can this be facilitated through IT management / orchestration systems?
• Consider validating attack paths through technical assessments or testing

Selecting and designing controls that mitigate risk

Once we have the following information, we now have the relevant information to select and design controls that 1. Will address the risk and 2. are commensurate with the relevant threat actor capability/intent and the risk tolerance of the organisation.

Putting this all together

Consider the following scenario that we created before where we identified the business impact and the relevant threat actor:

We next identify the weaknesses and vectors that this threat actor can exploit:

To exploit the supplier payment business process, a threat actor would need to target emails of finance staff.

From our understanding of opportunistic threat actors, they often try to impersonate suppliers through email spoofing.

From this assessment, we understand that we need to apply system based controls, process-based controls as well as people-based controls for our finance staff.

Finally, we look at control selection:

Firstly, we might want to consider reducing the likelihood of a threat actor impersonating a supplier by implementing DMARC, DKIM and SPF to prevent email spoofing.

Next, we may look to implement security awareness training for our finance staff, specifically around phishing emails and common fraud / scam scenarios that finance staff face.

Additionally, we might even want to look at the process itself to include a step to validate the legitimacy of changes in payment details from our suppliers.

When we look at the total effort to circumvent these controls, we find that the effort to compromise is likely to be very high. However, our opportunistic cyber criminal may only want to expend less effort than this. Through this process we can be assured that the controls we put in place would push the attacker beyond the point of economic viability.

This is a very simplified example of how we can use this approach to ensure our controls are mitigating actual risk for our organisation.

It is important to note here that not all of these controls were technical controls e.g. the process control around verifying payment detail changes. This goes to highlight how the select and design phase is important and may require collaboration outside of the security organisation or purely technical controls.

Benefits of this approach

Through this approach, we ensure that we focus on the risks and mitigating controls that matter.

By using this approach, we:

• Optimise cyber risk mitigation aligned with the business and the value that we are trying to protect.
• Create a common risk language between the business and security by using business impact language that is familiar to business leaders.
• Prioritise control implementation on high-risk and high-value systems

This approach can be used with any security framework or standard to help organisations select the right controls for their risks.

What is described here is primarily a top-down approach and can (and should be) used to complement other approaches for completeness, such as the CIA and asset-based approach to control selection.