Risk management

This stage first stage of modelling and analysis is about developing a model of the technology system or service we are building, to a sufficient level of detail, that allows us to apply some security analysis effectively. Models can be in the form of data flow diagrams (DFDs), use case models or architecture diagrams, and whilst there are software tools that can be used to help you model and analyse your system or service semi-automatically, you can always use your preferred drawing tool.

When modelling your system or service it is important to remember that your model will never be perfect, but it must be good enough to enable some effective analysis to be carried out. To this end, the model of your new system or service should, as a minimum, include all components (including users) of the system or service, all data flows, or interactions between those components any interconnectivity to other systems and services, and any trust boundaries across which data and information flows. Trust boundaries are those areas of the system or service where we (as owners of the system or service) can exert some sort of security control over the data or information that flows across by using - for example - security policies and security controls.

In this second stage we focus on a particular part of the system for analysis. For example we might choose to analyse the interaction between a client and server. The aim here is to consider how that part of the system might be attacked or otherwise go wrong. It can be tempting here to simply come up with a list of all the ways you think the system or service might be attacked. This approach can be problematic as there is a real risk of you missing something significant. To avoid this we would recommend that you use a structured approach to analysing the security of the system. For example Microsoft’s threat modelling approach uses the mnemonic STRIDE to systematically consider the types of attack that could be relevant to the focus of your analysis. The STRIDE mnemonic considers the following types of threat/attack:

• spoofing
• tampering
• repudiation
• information disclosure
• denial of service
• elevation of privilege

Other structured approaches to describing attacks could be used here to analyse the system or service you are building. For example the 14 attacker technique groupings from the MITRE ATT&CK framework or the Cyber Kill Chain as described by Lockheed Martin. The MITRE ATT&CK framework can also prove very useful in helping to understand how attacks against certain technology types and platforms are carried out by threat actors in the real world.

An alternative approach to understanding what could go wrong with the system or service you are building is to build an attack tree. Building attack trees is a well-known way of analysing the steps and attacker might take to achieve their aims. We provide further information on building and analysing attack trees in this guidance.

This stage is about taking the analysis carried out in the previous stage and proposing security measures or controls that can help manage the threats, attacks and risks that have been identified. Again the MITRE ATT&CK can prove useful here as it suggests mitigations to identified attack techniques. This phase will also need expert input to ensure that the controls proposed are effective and properly prioritised.

The cyber security control and mitigation recommendation outputs from a threat modelling exercise can be used to inform a secure by design activity, a secure design and development process or a CI/CD process.

When threat modelling is carried out as part of an overall risk assessment and analysis exercise, then the outputs can be used to inform identified risks and the prioritisation of controls and mitigations recommended by threat model outputs. It is important that the cyber security control and mitigation output recommendations from any threat modelling exercise are considered in the context of an organisation's approach to risk management, and their risk appetite and therefore included in risk management artefacts such as risk treatment and assurance plans. For more information, refer to the section on gaining and maintaining assurance in cyber security controls.

This final stage of the 4-stage process is simply about continually improving out threat modelling processes, by looking back at what we have done and thinking about whether we have modelled the whole system or service, and asking questions like:

Did we miss anything?

Are there areas we would improve and do differently next time?