Welcome to this video on Threat Modelling. 

In it you’ll learn about threat modelling, why we would use it and look at the STRIDE methodology for threat modelling.  

We will focus on threat modelling, benefits for assurance, the threat modelling process, STRIDE and coding to a threat model. Threat modelling is essentially security analysis. It allows you to map out and understand the vulnerabilities that any system may have and evaluate exactly what the potential threats are in relation to those vulnerabilities. 

The threat modelling process has several aims: Firstly, it helps to identify the assets owned by the organization. In order to assess any asset, you need to find it first! It identifies vulnerabilities and threats. It allows for a governance mechanism to be put in place for security concerns. Ultimately, it is looking to help an organization reduce its security risks. Threat modelling is integral to producing security design specifications. 

Threat modelling can have some very tangible benefits for system development and assurance. Mapping out the potential threats to an application will help you better understand its functionality as well as helping to find issues within the code. 

A threat model document can be used to bring new team members up to speed, giving them detailed insight into the operations of an application.  

Needless to say, a threat model document should be regarded as containing sensitive information, as it contains information about the vulnerabilities of an application. Using a threat model will assist in devising a suitable testing regime for the security features of an application. 

This diagram shows the flow of activity through the threat modelling process. Assets are identified, and these are then placed into an overall plan of the layout of the system or application. The application is then deconstructed, and any threats to the individual components of the application can be identified. It is important that these threats are comprehensively documented, to enable them to be rated and prioritized for resolution. 

One methodology for threat modelling is STRIDE. The STRIDE methodology was created by Microsoft and is a mnemonic device to assist in remembering six particular areas of threat: 

Spoofing is the creation of fake data, or the theft and re-use of authentication credentials. 

Tampering involves changing data, whether in transit or at rest. 

Repudiation centers on carrying out a particular act, and then denying your actions. 

Information disclosure refers to the accidental or deliberate exposure of information to non-authorized parties. 

Denial of service refers to the act of rendering a system unable to service requests for information. Finally, elevation of privilege refers to the process of gaining access to a system by increasing the level of privilege that you have been granted within that system. Privileges can be escalated vertically by gaining higher level privileges, or horizontally by using another user account which has the same level of access as you originally had. Moving to another account in this fashion means that your activity is no longer associated with the initial system compromise. 

This diagram shows a practical application of the STRIDE methodology, with the threats being modelled in an attack tree. An initial threat is identified at the top, and two potential manifestations of that threat are given below it. The tree then develops downwards, with each threat having various methods in which it could be actioned. 

Once the attack tree is mapped out, it is then possible to rate each of the threats. 

It could be that the organization is only going to concern itself with threats that could manifest themselves rather than threats that require a whole host of conditions to be met in order to be actioned. A risk treatment plan can then be created, into which all of the threats can be placed and prioritized. 

Having identified threats using STRIDE, you can now consider which mitigation strategies might be best employed to deal with these threats. The first option is the easiest – don’t do anything. It may transpire that although you have identified a threat it is unlikely to happen or have such a low impact that the disruption and cost involved in mitigating it could in fact be worse than what would happen should the threat actually materialize. 

Secondly, the threat may be acknowledged as being potentially problematic, but a robust user education program could be sufficient to diminish the likelihood of it having an impact, to the point that you can safely do nothing further. 

Thirdly, the problem could be removed, or avoided. Simply stop using the application or procedure that is vulnerable. Move to a better, more secure way of achieving the same business goal. 

Fourthly, acknowledge that the threat is sufficiently serious, and that there is no way to educate around it or remove it, and get the vulnerability fixed.  

In many instances fixing the issue is likely to be the desired outcome, and it may be that threats which may not be particularly relevant to an organization will be fixed as part of a regular patching and maintenance cycle simply because vendors have identified the threat and issued a fix to all of their customers. 

This diagram details the methodology used when deciding on a mitigation strategy identified under STRIDE. Identify which category of threat is at hand; select a technique for mitigating the threat; apply an appropriate solution. The example given shows that Spoofing is the identified threat.  

The chosen mitigation technique is to employ authentication solutions. The chosen technologies to achieve this include account authentication mechanisms and encryption of communications. 

This diagram is a more detailed explanation of the mitigations that could be applied to threats identified under STRIDE. The white highlighted letters indicate exactly which elements of STRIDE have been related to each threat, and it is worth just reminding ourselves what these are: 

• Spoofing 
• Tampering 
• Repudiation 
• Information disclosure  
• Denial of service  
• Elevation of privilege 

We can see that the first area encountered at the top of the diagram has S, T, I and E identified – the mitigations for these particular threats could include encryption of communications. To mitigate Denial of Service, the mitigation is to deploy a firewall thus handling the types of attacks that could cause a denial of service. 

Employing a threat modelling process throughout any systems development life cycle allows the developers to focus their efforts on those areas of code which present the greatest threat. It can also assist in determining how data flows through an application, identifying decision points within the application. Having identified any vulnerable areas, a risk treatment plan can be devised to mitigate the threats. 

That brings us to the end of this video.