Threat modelling – don’t start anything without it – 2021 update
We recently posted a blog on the importance of security by design in relation to software development. We discussed the importance of implementing security analysis throughout the system development lifecycle (“SDLC”) in the broader sense. In this blog, we have focused specifically on the Threat Modelling Review.
Technically, you can carry out a threat modelling review at any stage throughout the SDLC, however, OWASP have a moto for this, which reads; “Threat modelling: the sooner the better, but never too late. Our advice would be ‘Threat modelling: don’t start anything without it”.
What is a Threat Model?
A threat model identifies all possible risks and threats that a piece of software could be vulnerable to. Once you have documented all known threats, you can examine each in turn, enabling you to identify potential consequences, the severity of those consequences and required remediation.
By developing a threat model from the very beginning of the software design process, you will benefit from both the design and development team working together at the earliest stage, enabling them to collaborate and jointly establish areas of concern and truly embed security by design into your software.
Below, we have outlined the key stages of the threat model review and noted what should happen at each stage.
1. Application Architecture
Essentially, this is a diagram of the application, it should show how the application will work, how data will flow through it and how users will interact with it. It should contain the types of assets that need to be protected such as personal data and where those assets will be stored. The diagram will highlight areas that require greater attention.
2. Identify any Threats (Attack Surface).
If the architecture is done to a high and detailed standard, identifying threats will be much simpler. The architecture will enable you to identify the attack surface which is essentially all the areas in which users can interact with the application and thus where potential users could act with malicious intent. Once you identify these areas, you can ascertain the sort of vulnerabilities the application could be exposed to and categorise them to establish what mitigating controls should be put in place.
Once threats are identified and documented, it is beneficial to rate them in a similar way as you would manage your general organisational risks. That is, select a methodology that will be repeatable and work through it, placing each threat in order of how the methodology works, this could be the higher the score the higher the risk.
3. Mitigation
Once you’ve got the threats rated, you will start with the highest-scoring threats and depending on the threat will determine the mitigation control put in place.
4. Review
This final step is to look back and ensure:
- the architecture is as accurate as possible,
- all known threats to the application have been identified,
- the threats have been mitigated (or planned to be)
- any threats that may not have any controls are communicated to key stakeholders for approval and identification of residual risk.
Carrying out the threat modelling process in the design stage sets the tone and security stance of the organisation. Ensuring data protection by design in software applications is good practice and provides confidence in the application. If security is incorporated from the beginning, it can be highlighted in the work required for the development stage and if resources are available, an internal or external party can then penetration test the application for the threats that were identified to see if the proposed mitigations are effective.
We can help
If you need help developing your Secure Development Life cycle or with creating a threat model, we can help. Please contact us.
