How to Implement Threat Modeling in Your DevSecOps Process

This blog on threat modeling was co-authored by Dr. Ratinder Paul Singh Ahuja, CTO for Security and Networking, and Rajan Yadav, Director of Engineering, CNBU (Portworx), Pure Storage. Dr. Ahuja is a renowned name in the field of security and networking. 

Building secure software is critical in today’s world, where cyberattacks are becoming increasingly common and sophisticated. Threat modeling is an essential tool for developers and security professionals to identify and mitigate potential security risks in software systems proactively. 

In a previous blog, we shared how a newly acquired startup, Portworx®, embarked on a journey to improve the security posture of its products by adopting the six-point DevSecOps methodology. In this blog, we’ll do a deep dive into the first of the six points: threat modeling. We’ll also discuss how to integrate threat modeling into the software development lifecycle (SDLC) and provide best practices for building a successful threat model.

What Is Threat Modeling?

Threat modeling is the process of identifying potential threats and vulnerabilities in a system and determining the likelihood and impact of each threat. The goal of threat modeling is to proactively identify potential security risks and address them before they can be exploited by attackers.

The Benefits of Threat Modeling

Threat modeling provides a number of benefits to software development teams, including:

• Identifying potential security risks early in the SDLC, reducing the cost and effort required to address them later
• Prioritizing security efforts based on the likelihood and impact of potential threats
• Improving communication between development and security teams by providing a shared understanding of security risks and mitigation strategies

Common Threat Modeling Methodologies

There are several methodologies used in threat modeling, including:

• STRIDE: Identifying threats based on the following categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege
• DREAD: Assessing threats based on the following criteria: Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability
• PASTA: Identifying potential attack scenarios and evaluating the risks associated with each scenario

How to Build a Threat Model Using the STRIDE Methodology

STRIDE is a widely used methodology for threat modeling that focuses on identifying threats based on the following categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. The STRIDE methodology provides a structured approach to threat modeling that can be easily integrated into the SDLC. The following are the elements of STRIDE and the assets they apply to:

• Spoofing: Spoofing refers to the ability of an attacker to impersonate a user or system component. This can be a serious threat to authentication systems and other security controls. Assets that are vulnerable to spoofing include usernames, passwords, and digital certificates.
• Tampering: Tampering refers to the ability of an attacker to modify data or software without detection. This can be a serious threat to data integrity and system availability. Assets that are vulnerable to tampering include software binaries, configuration files, and data in transit.
• Repudiation: Repudiation refers to the ability of an attacker to deny that a particular action was taken. This can be a serious threat to audit trails and other compliance controls. Assets that are vulnerable to repudiation include logs, audit trails, and digital signatures.
• Information Disclosure: Information disclosure refers to the ability of an attacker to gain unauthorized access to sensitive data. This can be a serious threat to confidentiality and privacy. Assets that are vulnerable to information disclosure include customer data, financial data, and intellectual property.
• Denial of Service: Denial of Service refers to the ability of an attacker to disrupt the normal operation of a system or network. This can be a serious threat to availability and can result in lost productivity and revenue. Assets that are vulnerable to denial of service include web servers, routers, and other network infrastructure.
• Elevation of Privilege: Elevation of privilege refers to the ability of an attacker to gain unauthorized access to system resources or functions. This can be a serious threat to data integrity and confidentiality. Assets that are vulnerable to elevation of privilege include administrative functions, privileged user accounts, and system-level processes.

By applying the STRIDE methodology to a threat model, development teams can identify potential threats and develop mitigation strategies that are tailored to the specific assets and vulnerabilities of the system. What follows are the detailed steps on how to apply STRIDE to a design. The next section will take you through some design patterns and how STRIDE was used to discover design weaknesses.

Design Review: Identifying Assets, Trust Boundaries, and Threats

Decompose a design based on the following concepts. Figure 1 shows some of these components and boundaries:

Figure 1

Here is how STRIDE is applied to boundaries and entities, a.k.a. “What applies where”:

Figure 2

Here are the common assets and corresponding STRIDE elements that apply to them:

By identifying the assets and the corresponding STRIDE element, development teams can prioritize the most critical assets and apply mitigation strategies that are tailored to the specific threats facing those assets. To apply some of the principles of threat modeling and STRIDE, we’ll consider a common cloud-based service architecture that we’ll take through a thread modeling exercise: 

Figure 3

Special Attention: Authentication and Authorization Bypass Attacks

Most services like the one depicted in Figure 3 above will have a web interface or API. Note that these external interfaces could be subject to authentication and authorization bypass attacks.

What Are Authentication Bypass Attacks?

Authentication bypass attacks occur when an attacker is able to gain access to a web service or API without providing valid credentials. This can happen due to flaws in the authentication mechanism, such as insecure storage of passwords, lack of rate limiting on login attempts, or vulnerabilities that allow an attacker to impersonate a legitimate user. The implications of these attacks can be severe. 

Unauthorized access to a web service or API can lead to data theft, data manipulation, execution of unauthorized actions, and potential compliance violations. In the case of APIs, which often act as gateways to a company’s most sensitive data and critical functions, an authentication bypass attack could have particularly serious consequences. It’s therefore crucial for both web services and APIs to implement robust authentication mechanisms and to regularly test and update these mechanisms to guard against potential attacks.

12 AuthN Bypass Attacks on Web Services

There are several ways in which authentication bypass can occur for a web service. Here are some common methods:

• Credential Stuffing: This is when attackers use stolen or leaked usernames and passwords from one site on another, banking on the fact that many people reuse passwords across multiple sites.
• Brute Force Attacks: Attackers use software to try many password combinations until they find one that works.
• Phishing: Attackers trick users into providing their login credentials, usually by mimicking a legitimate website or service.
• Session Hijacking: If an attacker can intercept a user’s session cookie (which keeps a user logged in), they can impersonate that user without needing their password.
• Man-in-the-Middle (MitM) Attacks: Attackers intercept and potentially alter communication between two parties without their knowledge.
• Exploiting Vulnerabilities: Software bugs or misconfigurations can sometimes allow attackers to bypass authentication. For example, a poorly implemented password reset feature might allow an attacker to reset someone else’s password.
• SQL Injection: If user input isn’t properly sanitized, an attacker might be able to execute arbitrary SQL commands on a website’s database, potentially allowing them to bypass authentication.
• Cross-Site Scripting (XSS): Similar to SQL injection, but with JavaScript. An attacker might be able to execute arbitrary JavaScript in a user’s browser, potentially allowing them to steal session cookies or perform actions on the user’s behalf.
• Using Default or Weak Credentials: Many systems come with default usernames and passwords that are easily guessable if they aren’t changed. Similarly, weak or easily guessable passwords (like “password” or “123456”) can be exploited.
• Social Engineering: This involves manipulating people into breaking normal security procedures, such as revealing their password or other sensitive information.
• Keylogger Attacks: Malware installed on a user’s device can record keystrokes and send them to an attacker, revealing usernames and passwords.
• Pass the Hash: In systems that use hashed credentials, an attacker who can steal the hash might be able to use it to authenticate without ever knowing the user’s actual password.

The following table summarizes these authentication bypass attacks, their STRIDE classification, and how to avoid introducing those vulnerabilities.

10 AuthN Bypass Attacks on APIs

Similarly, APIs are also subject to authentication bypass attacks. There are several ways in which authentication bypass can occur for an Application Programming Interface (API). Here are some common methods:

• Insecure Direct Object References (IDOR): This occurs when an API exposes a reference to an internal implementation object. By manipulating these references, an attacker could gain unauthorized access to data.
• Missing Authentication: If an API endpoint is not properly secured, it might be possible to bypass authentication entirely.
• Brute Force Attacks: Attackers use software to try many password or token combinations until they find one that works.
• Token Hijacking: If an attacker can intercept an API token (similar to a session cookie for a web service), they can impersonate that user.
• Exploiting Vulnerabilities: Software bugs or misconfigurations can sometimes allow attackers to bypass authentication. For example, a bug in the way the API handles token expiration might allow an attacker to use an expired token.
• Insecure Storage of API Keys/Tokens: If API keys or tokens are stored insecurely (e.g., in plain text or in a publicly accessible location), an attacker might be able to find and use them.
• Man-in-the-Middle (MitM) Attacks: Attackers intercept and potentially alter communication between two parties without their knowledge.
• Using Default or Weak API Keys: Many systems come with default API keys that are easily guessable if they aren’t changed. Similarly, weak or easily guessable keys can be exploited.
• Insufficient Rate Limiting: Without proper rate limiting, an attacker can make many attempts to guess a password or token in a short amount of time.
• Social Engineering: This involves manipulating people into breaking normal security procedures, such as revealing their API keys or other sensitive information.

The table below summarizes the authentication bypass attacks, their STRIDE classification, design hardening steps, and mitigating controls:

Authorization Bypass Attacks

8 AuthZ Attacks on Web Services

Authorization bypass attacks on a web service occur when an attacker gains access to functions or data that they are not authorized to access. This can happen due to flaws in the way the web service checks permissions or other vulnerabilities that the attacker can exploit.

Here are some common types of authorization bypass attacks and their implications:

• Insecure Direct Object References (IDOR): This occurs when an application provides direct access to objects based on user-supplied input. By manipulating these references, an attacker could gain unauthorized access to data. The implication is unauthorized data access, which could lead to data theft or manipulation.
• Missing Function Level Access Control: Sometimes, an application might check permissions for a function at the UI level but not at the server level. An attacker could bypass the UI restrictions and directly call these server-side functions. The implication is unauthorized function access, which could lead to unauthorized actions being performed.
• Forceful Browsing: This involves guessing the URL of restricted pages and accessing them directly. The implication is unauthorized page access, which could lead to unauthorized data access or actions.
• Elevation of Privilege: If an application has a flaw that allows a user to elevate their privileges, they could gain access to functions or data that they are not authorized to access. The implication is unauthorized access at a higher privilege level, which could lead to significant data theft or manipulation.
• Session Hijacking: If an attacker can steal a user’s session cookie, they might be able to impersonate that user and gain their authorizations. The implication is unauthorized access as a legitimate user, which could lead to significant data theft or manipulation.
• Cross-Site Request Forgery (CSRF): An attacker could trick a user into performing actions they are authorized to do but didn’t intend to do. The implication is unauthorized actions being performed on behalf of a legitimate user, which could lead to data theft or manipulation.
• Exploiting Vulnerabilities: Software bugs or misconfigurations can sometimes allow attackers to bypass authorization. For example, a bug in the way the application checks permissions could allow an attacker to bypass these checks. The implication is unauthorized access, which could lead to data theft or manipulation.
• Parameter Manipulation: If an application uses parameters in the URL or hidden form fields to control access, an attacker could manipulate these to gain unauthorized access. The implication is unauthorized data access, which could lead to data theft or manipulation.

The implications of these attacks can be severe, including data theft, data manipulation, unauthorized actions being performed, and potential compliance violations. It’s important for web services to implement robust authorization checks and other security measures to prevent these types of attacks.

7 AuthZ Attacks on APIs

There are several ways in which an authorization bypass can occur for an API. Here are some common methods and their implications:

• Insecure Direct Object References (IDOR): This occurs when an API exposes a reference to an internal implementation object. By manipulating these references, an attacker could gain unauthorized access to data. The implication is unauthorized data access, which could lead to data theft or manipulation.
• Missing Function Level Access Control: Sometimes, an API might check permissions for a function at the UI level but not at the server level. An attacker could bypass the UI restrictions and directly call these server-side functions. The implication is unauthorized function access, which could lead to unauthorized actions being performed.
• Forceful Browsing: This involves guessing the URL of restricted endpoints and accessing them directly. The implication is unauthorized endpoint access, which could lead to unauthorized data access or actions.
• Elevation of Privilege: If an API has a flaw that allows a user to elevate their privileges, they could gain access to functions or data that they are not authorized to access. The implication is unauthorized access at a higher privilege level, which could lead to significant data theft or manipulation.
• Token Hijacking: If an attacker can steal a user’s API token, they might be able to impersonate that user and gain their authorizations. The implication is unauthorized access as a legitimate user, which could lead to significant data theft or manipulation.
• Exploiting Vulnerabilities: Software bugs or misconfigurations can sometimes allow attackers to bypass authorization. For example, a bug in the way the API handles token expiration might allow an attacker to use an expired token. The implication is unauthorized access, which could lead to data theft or manipulation.
• Parameter Manipulation: If an API uses parameters in the URL or hidden form fields to control access, an attacker could manipulate these to gain unauthorized access. The implication is unauthorized data access, which could lead to data theft or manipulation.

Sample Threat Modeling Exercise

Referring back to the architecture in Figure 3, let’s take it through a threat modeling exercise. 

Identify Major Threat Boundaries

Map the STRIDE Methodology to the Threat Boundaries and Entities 

• For user access, the following STRIDE elements apply: 
  • Spoofing: Ensure user/browser/API are authenticated and authorized to access the service. It cannot be a malicious user with stolen credentials or a valid user going to a fake service. In essence, ensure both sides are who they say they are. Refer to AuthN sections described above to dive deeper into how to harden Spoofing attacks. 
  • Tampering: The network traffic and the payload cannot be tampered with. Refer to AuthZ sections described above to dive deeper into how to harden Tampering attacks.
  • Repudiation: The ingress controller should have an audit trail for all activity and must not be tampered with. 
  • Information Disclosure: Ensure no sensitive information such as customer/financial data can be stolen. 
  • Denial of Service: The service should have protections to prevent DDoS attacks. 
• For business logic, the following STRIDE elements apply: 
  • Spoofing: Ensure the containers hosting business logic are authentic and cannot be spoofed by a rogue container. Refer to AuthN sections described above to dive deeper into how to harden Spoofing attacks.
  • Tampering: Ensure data flows between business logic containers cannot be tampered with. Refer to AuthZ sections described above to dive deeper into how to harden Tampering attacks.

• • Repudiation: Logs and audit trail maintained by business logic cannot be tampered with.

• • Information Disclosure: Ensure the business logic services do not have any unencrypted exchange of information.

• • Denial of Service: Each business logic service must have guardrails to prevent DDoS.

• For storage systems, the following STRIDE elements apply: 

• • Spoofing: An unauthorized system must never have access to the storage systems. To avoid spoofing, we must have zero trust network ACLs and mTLS (mutual TLS) and logic to authenticate with the storage subsystem. A rogue system cannot access storage. 

• • Tampering: Authorization from business logic to storage subsystem. In essence, the various components that interact with the storage system must be allowed to access only the data that they are authorized to access. 

• • Repudiation: Storage subsystem logs and access logs from business logic to storage system must be retained and cannot be tampered with. 

• • Information Disclosure: All regulatory content must be encrypted at rest and in motion. 

• • Denial of Service: The storage system must have logic to avoid DoS through rate limiting and other mechanisms. 

Best Practices to Follow Even Before Starting Threat Modeling 

This is a lot and one must wonder if this is all automated or can one use available tools/platforms/storage systems that already take care of hardening the components one wants to use in their environment. 

• Use CIS-benchmarked components

• • Use CIS hardened containers, platforms (Kubernetes), AWS, databases/storage (Mongo, S3). For example, use a CIS hardened EKS for your Kubernetes platform if you’re running your services in AWS. The same applies to databases and storage platforms you plan to use in your design. 

• Use the following checklist to ensure cloud security controls are in place

• • FW (Botnet/DDoS): Network-specific firewall rules

• • IDPS: Intrusion detection prevention systems

• • Web application firewalls (WAF)

• • API security

• • Network (segmentation)

• • Logging to SPLUNK

• • Container and EC2 security

• • Kubernetes hardening as per CIS benchmark

• OWASP Top 10 for web apps/APIs

1. • Follow the best practices described in the OWASP Top 10 for ensuring apps and APIs are adhering to the guidelines set by the OWASP community. To summarize:
     1. Implement authentication controls to prevent impersonation of users.
     2. Restrict object and function access to prevent unauthorized data exposure.
     3. Validate all inputs and sanitize data to stop injection attacks.
     4. Use rate limiting and disable unnecessary methods to prevent DOS attacks.
     5. Deprecate outdated APIs to avoid shadow surfaces vulnerable to attack and maintain up-to-date API protections against evolving OWASP threats.
     6. Properly configure headers, error handling, and other settings to block misconfiguration risks.
     7. Monitor activity closely with detailed logging for early breach detection.
     8. Follow general secure coding practices like avoiding mass assignment of user inputs.
     9. Limit data exposure only to authorized users to prevent access abuse.
     10. Guard against object/ID manipulation that could enable data exploits.

Conclusion

Threat modeling has become essential for building secure software, yet many organizations still do not practice it regularly. This needs to change.

Threat modeling provides tangible benefits across the software development lifecycle. Architects can design more secure systems knowing the high-risk areas early. Developers can code defensively against potential threats. Security teams gain confidence that risks are proactively addressed. Organizations face lower costs from dealing with fewer incidents later on.

While various techniques exist, STRIDE provides a straightforward methodology to apply threat modeling in a structured way. Mapping threats to boundaries, assets, and components enables methodical risk analysis and mitigation planning. Integrating threat modeling sessions into existing design and code reviews institutionalizes it without requiring wholesale process changes.  

However, threat modeling is not a solo activity done in silos. Collaboration between security and development teams is key to building a robust threat model. Cross-functional engagement results in more insights, rapid feedback, and improved solutions. Integrate threat modeling into your SDLC by:

• Scheduling regular threat modeling working sessions 
• Making threat models and mitigation requirements visible 
• Providing threat modeling training and guidance
• Updating models continuously as designs evolve

With a collaborative culture of “security by design,” organizations can build more resilient software, gain visibility into risks, and prevent incidents proactively. The increasing threat landscape makes threat modeling too important to overlook any longer. The time to institutionalize it is now.