Beginner’s Corner: Using STRIDE After Threat Modeling 

Post Credit: Austin Miller

Although understanding the basic principles of threat modeling and how to use modeling tools is useful, threat modeling is nothing if there is no reaction! That’s why we’re going to look at the STRIDE Threat and Mitigation techniques. 

Although we have looked at STRIDE in the past, we still need to understand how to implement the threat list and implement useful practices to complement your investigations.  

What is STRIDE?

STRIDE gives us a way to identify threats and classify attacks that the adversary uses against us. Broadly speaking, all threats can be sorted into one of STRIDE’s six categories. In case you’ve forgotten, STRIDE stands for: 

  • Spoofing 
  • Tampering 
  • Repudiation 
  • Information Disclosure 
  • Denial of Service 
  • Elevation of Privilege 

Lateral movement is often included in the STRIDE threat model, rendering it STRIDE-LM. Because of that, the advice below also contains advice for dealing with opportunities for lateral movement in your applications. 

From this acronym, we can develop toolkits that help find and treat problems in our software. 

How do I implement STRIDE?

After you gain a full understanding of your application’s threat model and identify the risk present in your software, we need to find a way to address these issues. Thankfully, we can turn to the NIST Cybersecurity Framework (CSF) for advice. 

Using the STRIDE threat list, we can develop strategies to tackle the largest risks we face. Below you will find a list of best practices for making secure, safe applications. Each category from STRIDE has been broken down into example cases that could occur in your software to offer practical solutions. 


Desired outcome: authentication 

  • PR.AC-6: Identities are proofed and bound to credentials and asserted in interactions. Identifier management (IA-4) and authenticator management (IA-5) are particularly important at this stage. 
  • PR.PT-1: Audit/log records are determined, documented, implemented, and reviewed in accordance with policy. Deveping clear policies and procedures (AU-1), event logging practices (AU-2), and implementing audit record reduction and report generation (AU-7) is key at this stage. 


Desired outcome: integrity 

  • PR.DS-1: Data-at-rest is protected. Restricting media access (MP-2), media transport (MP-5), and media downgrading (MP-8) are top concerns in this tactic. 
  • PR.DS-2: Data-in-transit is protected. Although more difficult to implement than protecting data-at-rest, implementing transmission confidentiality and integrity (SC-8) and trusted path (SC-11) only protocols will protect your application’s data. 
  • PR.DS-6: Integrity checking mechanisms are used to verify software, firmware, and information integrity. Software, firmware, and information integrity (SI-7) and information input validation (SI-10) are key at this stage. 


Desired outcome: non-repudiation 

  • Similar advice is offered in both repudiation defenses and spoofing defenses. 

Information Disclosure

Desired outcome: availability 

  • PR.DS-5: Protections against data leaks are implemented. Best practices include information leakage defenses (PE-19), access agreements (PS-6), and boundary protection (SC-7). 
  • PR.IP-6: Data is destroyed according to policy. Obviously dependent on having a safe data destruction policy in place, media sanitization (MP-6) and component disposal (SR-12) are key to effective data practices.

Denial of Service

Desired outcome: availability 

  • PR.DS-4: Adequate capacity to ensure availability is maintained. Audit log capacity (AU-4), contingency planning (CP-2), and denial of service protection (SC-5) are all healthy practices that defend against denial of service attacks. 

Elevation of Privilege

Desired outcome: principle of least privilege 

  • PR.PT-3: The principle of least functionality is incorporated by configuring systems to provide only essential capabilities. Access enforcement (AC-3) and least functionality (CM-7) are the only effective preemptive ways to stop elevation. 
  • DE.CM-4: Malicious code is detected. Using detonation chambers (SC-44) to access and assess risking content shields the organization from phishing and injection attacks and system monitoring (SI-4) creates effective defenses beyond initial infection. 
  • DE.CM-7: Monitoring for unauthorized personnel, connections, devices, and software is performed. Continuous monitoring (CA-7) and configuration change control (CM-3) allow better defenses against adversarial access. 

Lateral Movement

Desired outcome: containment 

  • PR.AC-5: Network integrity is protected (e.g., network segregation, network segmentation). Information flow enforcement (AC-4) and concurrent session control (AC-10) is key to securing your perimeters and defending your organization. 
  • RS.MI-1: Incidents are contained. CSF offers IR-4: Incident Handling advice to help support this difficult aspect of app security. 

Using the CSF for Threat Modeling

As you can probably tell by now, the NIST CSF is a dense framework that is full of practical advice for securing applications and networks. By using the tactics, techniques, and procedures contained within the framework, you can build defenses to improve the integrity of your application and secure your network in the event of a vulnerability. 

Of course, threat modeling at this stage is a heavily time-consuming process. By identifying the biggest risks in your application and comparing them against your risk threshold, your insights into the vulnerabilities and the mindset of the adversary will help you address the biggest issue first and protect your organization. 

Stay up to date with the latest threats

Our newsletter is packed with analysis of trending threats and attacks, practical tutorials, hands-on labs, and actionable content. No spam. No jibber jabber.