image
Threat modelling and stride
Start course
Difficulty
Beginner
Duration
1h 26m
Students
2132
Ratings
4.7/5
Description

Course Description 

This course takes a deeper look at the governance and risk elements of cybersecurity. It starts with a focus on cyber and legal frameworks, then moves into information assurance. After this, it moves into risk management and treatment, followed by service assurance and standards. Finally the course ends with software security assurance and threat modelling.

 

Learning Objectives 

The objectives of this course are to provide you with and understanding of: 

  • Legislation, chain of custody, reporting and assurance within the context of a legal framework. Inc. overview of Data Protection Act (DPA 2018) and the EU General Data Protection Regulation (GDPR) 
  • The drivers for UK Information Assurance, initiatives and programmes, risk assessment vs risk management, risk components 
  • Business context and risk management approach, risk management lifecycle, who delivers risk management - where in the lifecycle, understanding the context, legal and regulatory. Risk Treatment - Identify the ways of treating risks, methods of gaining assurance, understanding the nature of residual risk, collecting evidence that supports decisions, risk management decisions 
  • Assurance perspective – including CPA, CAPS, FIPS, CE, Common Criteria, SPF. Summary of common industry standards. (Inc. OWASP, ISO27001, PCI-DSS) 
  • Principles for software security, (securing the weakest link, defence in depth, failing securely, least privilege, separation of privilege), IA design principles 
  • What is threat modelling, threat modelling processes 
  • Risk mitigation options 

 

Intended Audience 

This course is ideal for members of cybersecurity management teams, IT managers, security and systems managers, information asset owners and employees with legal compliance responsibilities. It acts as a foundation for more advanced managerial or technical qualifications. 

  

Prerequisites  

There are no specific pre-requisites to study this course, however, a basic knowledge of IT, an understanding of the general principles of information technology security, and awareness of the issues involved with security control activity would be advantageous. 

 

Feedback 

We welcome all feedback and suggestions - please contact us at support@cloudacademy.com if you are unsure about where to start or if would like help getting started. 

Transcript

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. 

About the Author
Students
9218
Courses
5
Learning Paths
12

Paul began his career in digital forensics in 2001, joining the Kent Police Computer Crime Unit. In his time with the unit, he dealt with investigations covering the full range of criminality, from fraud to murder, preparing hundreds of expert witness reports and presenting his evidence at Magistrates, Family and Crown Courts. During his time with Kent, Paul gained an MSc in Forensic Computing and CyberCrime Investigation from University College Dublin.

On leaving Kent Police, Paul worked in the private sector, carrying on his digital forensics work but also expanding into eDiscovery work. He also worked for a company that developed forensic software, carrying out Research and Development work as well as training other forensic practitioners in web-browser forensics. Prior to joining QA, Paul worked at the Bank of England as a forensic investigator. Whilst with the Bank, Paul was trained in malware analysis, ethical hacking and incident response, and earned qualifications as a Certified Malware Investigator, Certified Security Testing Associate - Ethical Hacker and GIAC Certified Incident Handler. To assist with the teams malware analysis work, Paul learnt how to program in VB.Net and created a number of utilities to assist with the de-obfuscation and decoding of malware code.

Covered Topics