Risk management

If you're talking about systems it is essential that you first state the function that you are trying to analyse. Otherwise, you might end up only analysing a single system component (such as the website server in the example above) and ignoring the rest. Examples of system functions might be:

• to enable customers to use the internet to buy your products
• to enable people to travel from London to Birmingham in under one hour
• to enable an organisation's staff to produce and share documents collaboratively

One of the defining features of systems driven approaches to risk management is that they require a clear statement of the system's function at an early stage of development. A common mistake at this stage is to confuse the system's function with a statement of the problem that the system contributes to solving.

For example, you might state that the function of a sales website is 'to improve your organisation's sales figures'. Strictly speaking, the website's function would be better described as 'to enable customers to identify and purchase your products online, and to enable your logistics division to dispatch them promptly'. This function will contribute to solving the problem of 'improving sales', but it will not completely solve it, and other solutions will also impact upon solving that problem.

A good statement of function needs to be achievable, and it must be possible to verify that you have achieved it. Getting this statement of function correct is an essential part of conducting a system driven risk analysis.

In the introduction to system and component driven techniques, we learnt how the high-level purposes that your system should not achieve (or contribute to achieving) are known as losses. In order to perform a system driven risk analysis, you need to enumerate the high-level outcomes that you don't want to occur in the operation of your system. In this context, we are just concerned with the actual outcome of a loss.

Here, we are talking about top-level losses that the organisation cares deeply about. This works most effectively if you identify a small number of highly significant losses, rather than a large number of relatively small ones.

Examples of losses include:

• injury or loss of life
• large-scale fraud against your organisation
• breaking the law
• key organisational processes being disrupted

An important part of any system driven risk analysis is clearly and precisely defining which losses you are concerned about in the context of the system you are operating or designing. Importantly, we're not talking about the way in which a loss could be realised, just the outcome itself. The result of this stage should be a list of losses which you have decided are relevant to your system.

In cyber security, system driven risk analysis techniques are nowhere near as established as component driven techniques. As such, there are fewer formalised techniques, and there is greater variation between them. This guidance introduces what the NCSC sees as the common features of these techniques, and explains what value they can add.

Any system driven risk analysis techniques should start with an articulation of function, and the losses you wish to avoid. You would usually expect to see an iterative process of adding complexity to that statement of function, by breaking it down into sub-systems, each of which have their own functions, and by demonstrating how these sub-systems control and communicate with each other. At each of these iterative stages, you would explore any possible exposures to losses, and in doing so, you would develop security requirements to avoid these exposures.

A significant barrier to talking about cyber security risks to technology systems is the temptation for organisations and analysts to quickly move on to component-level thinking before the system level has been properly analysed. This is why we recommend that organisations gain the best possible perspective on the cyber security risks they face by seeking to understand them at both system and component levels.

STPA (System Theoretic Process Analysis) is a part of the STAMP framework, which is a collection of techniques for modelling the causation of accidents. It has been developed by Professor Nancy Leveson and her colleagues at the Massachusetts Institute of Technology. Whilst STPA originally focused on safety, it has since been adapted into a number of other contexts, some of which accommodate cyber security requirements.

TOGAF (The Open Group Architectural Framework) is a commercially available architectural framework developed by The Open Group. Whilst it is not a risk management technique in itself, it draws from many of the same ideas as system driven risk analysis frameworks such as STPA. It is an Enterprise Architecture Standard designed to improve business efficiency and manage risk, for instance seeking to provide better return on investments, reducing overheads and improving procurement processes. The framework is based on an iterative process model that can be implemented at different levels across the organisation either on its own or integrated with other frameworks. TOGAF supports both the top down (system driven) and bottom up (component) approaches to risk management described in our guidance.

SABSA is a business-driven security architecture framework with a high-level focus on how organisations generate value for stakeholders. As noted with TOGAF, whilst SABSA is not primarily a risk analysis technique, it draws on many of the same systems concepts. Starting with the organisation’s unique configuration of their value chain, the SABSA framework assists analysts in decomposing the process down through a number of business architectural layers. The layers progress down through business capabilities, business processes, business services, and from there down into technology services. SABSA requires analysts to address risk at every layer so that requirements defined at the top of the ‘stack’ are inherited down through the layering and addressed at each layer. High-level, value-generating opportunities could be compromised at any of the lower layers, but this layer-by-layer analysis ensures that a range of different cyber risk perspectives are considered.