Risk management

In cyber security, risk is most commonly described in terms of the component parts of a system such as hardware (computers, servers, etc) or software. We call such approaches bottom-up or component driven risk techniques. In this view, risk is assessed as being some combination of the value of a given system component, and the likelihood that it will be compromised in some way. More specifically, this requires an assessment of the threat that these components face, their vulnerabilities and the business impact that a compromise would cause.

This type of approach allows analysts to identify specific risks faced by specific components within the system. It then allows these risks to be prioritised according to the severity of the risk's impact (or the ease with which the vulnerability could be exploited by a threat). The purpose of prioritising risks in this way is to mitigate the worst risks first, where possible.

A complementary approach focuses primarily on the goals or purposes of the system (rather than components). We call such approaches top-down or system driven risk techniques, because they focus primarily on the whole system, rather than individual components. Top-down techniques consider the interactions between all aspects of the system, including people, business processes and technology.

These approaches require risk analysts to start by stating a system’s high-level purpose. From there, you iteratively add more detail to that statement, as a way of designing how the high-level purpose may be achieved. There is a focus on understanding how parts of the system interact with each other. Approaches like this will be very familiar to systems engineers, and others involved in iterative design techniques, where these ideas are commonplace.

Where does risk come into this? As well as thinking about the purposes that a system should serve, a top-down risk management technique would also consider the high-level purposes that the system should not serve. We talk about these in terms of 'losses' which could occur in the course of a system's operation. For example, if you are designing a system which controls an automated security door, the system’s purpose is probably to let people in and out. A loss that you might identify, would be letting through unauthorised people, or injuring people by trapping them in the door’s mechanism.

This concept of losses might seem obvious. However, our experience shows that these high-level descriptions of what the system must not do are very rarely considered at the beginning of a project life cycle (unlike purpose, which is considered). Losses are usually only considered when a system’s design is reasonably mature (so you already have an understanding of what the system might logically look like). This is part of the reason for the common complaint that security 'is bolted on, not baked in'.

To help examine how bottom-up and top-down techniques relate to each other, we can draw on Jens Rasmussen’s Abstraction Hierarchy, which is illustrated below.

This model introduces the idea that you can look at systems at different levels of abstraction. Considering just the top three layers of the illustration allows us to think about the system in conceptual terms. That is, we're focusing our analysis on what should be achieved by the system (rather than how it should work). Bottom-up or component driven approaches are about analysing what could go wrong at the bottom two layers of this hierarchy. Here, you are concerned with things that physically exist, or their representations, such as detailed architecture diagrams detailing specific technology decisions.

Separately, top-down or system driven approaches consider the system's high-level purpose and losses. The aim is to identify ways in which losses could be realised, as a consequence of the conceptual design of your system. At this level of abstraction, concepts such as threat and vulnerability, as they are used in component driven methods, don't make sense. Here, you are looking for ways in which the system could realise any losses.

The reason for introducing this framework is to demonstrate that component driven and system driven risk management techniques analyse risk in fundamentally different ways, but that they both support each other. They are both valuable risk management tools, when applied to the right kind of problem.

These techniques can be used alongside each other to provide a complementary perspective on risk. For example, you might use a top-down approach to identify your most critical systems, interactions or vulnerabilities, and then switch to bottom-up analysis to explore those critical areas in detail.

They add value in different ways; neither is 'better' than the other. However, each technique is better suited to certain kinds of risk management problem:

• Component driven approaches are useful for exploring your exposure to known technical vulnerabilities. For example, there might be a single computer in your organisation that you are unable to patch or upgrade for operational reasons. This is common with some types of operational technology. A component driven risk analysis can be used to explore how the vulnerabilities in that unpatched machine could impact on your organisation. This kind of analysis can identify safeguards that can be put in place around this unavoidably vulnerable computer.
• Systemic approaches are useful when analysing large and complex systems. In particular, they can help you to explore interaction failures. For example, the correct and secure operation of your system may be dependent on interactions between a number of the components or sub-systems that comprise it.These occur when individual components within the system are working precisely as they should, but that there is some flaw in the way in which these components interact with one another which makes it possible for a security breach to occur. A good example of this might be the risk of fraud against an online payment system, where component driven perspectives might miss the importance of customer systems to the security of the system as a whole.

The strengths of each technique is summarised in the following table:

Component driven and system risk management techniques can be used alongside each other. For example, you might use a system driven approach to ensure that security risks are conceptually identified before any specific technology decisions are made, and then switch to component driven analysis once you are committed to adopting a particular solution.

If you're keen to get stuck into practicalities, we have produced separate guidance which lists some common frameworks which apply the principles of component driven and systemic analyses.