Threat Modelling

Threat modelling – don’t start anything without it – 2021 update

September 10th, 2019 Posted in Information Security

We recently posted blog on the importance of security by design in relation to software development. Wdiscussed 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 thiswhich 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 threatsyou can examine each in turnenabling you to identify potential consequencesthe 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 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 standardidentifying 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 intentOnce 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 applicationIf 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. 


Evalian Icon PNG

Written by Evalian®