How to Implement Threat Modeling in DevSecOps

With cybersecurity incidents increasing at an alarming rate, modern development teams are transitioning to a DevSecOps framework to integrate security into the entire software development lifecycle (SDLC). This approach helps create more secure and resilient applications by breaking down silos between development, security, operations, and other relevant teams, and by incorporating automated security checks and continuous monitoring. 

Threat modeling is a DevSecOps tool for identifying and assessing system threats. By identifying potential threats early and mitigating them, developers can reduce risks before deployment. 

Understanding Threat Modeling

In threat modeling, DevSecOps teams ask, “How could hackers exploit my code for malicious purposes?” They analyze a system to understand it from an attacker’s perspective. Threat modeling enables developers to identify application-specific risks early and reduce the cost of remediation. 

There are different types of threat modeling frameworks, including: 

• STRIDE: This focuses on six types of risk, including spoofing, tampering, repudiation, information disclosure, denial-of-service, and elevation of privilege. 
• DREAD: This model evaluates threats based on damage potential, reproducibility, exploitability, affected users, and discoverability. 
• PASTA: This is a seven-step Process for Attack Simulation and Threat Analysis that considers business objectives and technical requirements in risk management.  

Integrating Threat Modeling Into DevSecOps

Application security is complicated and requires a comprehensive, multi-tiered approach. Many security measures take broad strokes designed to protect against a wide range of common threats. 

While this is valid and necessary, threat modeling takes a narrower approach. It lets DevSecOps prioritize its security efforts based on the likelihood of a threat occurring and its possible impact. This proactive approach aligns with the DevSecOps principle of embedding security throughout the SDLC. 

Step-by-Step Implementation Guide

DevOps teams can use the following guide to implement threat modeling effectively. 

Step 1: Define Objectives and Scope

The first step is to identify which system assets need protection, such as core applications, confidential data, and critical infrastructure. Once the team understands what needs to be protected and why, they can set clear, measurable objectives for threat modeling. 

Objectives should identify threats and their risks by understanding how they could impact the system. These objectives will set the stage for subsequent activities and provide a targeted approach to prioritizing threats based on business goals and available resources.  

Step 2: Assemble the Right Team

A threat modeling team should include members from all relevant areas, including: 

• Developers who can provide input into the team’s coding practices, the system’s architecture, and potential code vulnerabilities.
• Security experts with specialized knowledge in identifying and assessing risks and developing mitigation strategies.
• Operations team members who can ensure the threat modeling process aligns with operations processes and integrates them during deployment and monitoring.

A cross-functional team brings different perspectives to the threat modeling process, just as it does to the SDLC. Collaborative teams can communicate effectively, work together towards a common goal, and create practical, effective security measures. 

Step 3: Identify and Prioritize Threats

DevSecOps teams can use various methods to identify threats. As with most cybersecurity elements, using multiple methods provides more comprehensive coverage. Some options include: 

• Brainstorming to take advantage of creative thinking and the various perspectives of team members
• Examining threat libraries such as OWASP to find common vulnerabilities and attack vectors relevant to the system
• Utilizing automated tools that can scan code for known vulnerabilities and generate potential threat scenarios

After teams have identified likely threats, they should prioritize them based on factors such as: 

• How likely each threat is to occur based on the system architecture, historical data, and the current threat landscape
• How much damage each threat could cause if it led to data breaches, service disruptions, or financial losses
• The resources and effort that would be needed to mitigate each threat 

Step 4: Develop Threat Models

The threat model is a detailed representation of the system that identifies potential attacks and threat vectors using the following tools: 

• Data flow diagrams (DFDs) illustrate how data flows through the system and the points at which it’s processed, stored, and transmitted. DFDs make it easier to spot vulnerabilities by visually documenting where and how system components interact. 
• Architectural diagrams provide an overview of the system’s structure, including how components interact and depend on each other. These diagrams help the DevSecOps team understand the system’s overall security posture. 

After creating the diagrams, the team should document areas where unauthorized users could intercept, alter, or access data.

Step 5: Implement Security Controls

The next step is to map each threat to appropriate security controls. Best practices for this include: 

• Implementing multiple layers of protection against each attack vector.
• Using automated security tools within the continuous integration/continuous delivery (CI/CD) pipeline
• Regularly update security controls in response to emerging threats

Step 6: Validate and Test Models

Once threat models are in place, teams should regularly validate and test them. Ongoing testing will keep models up to date and secure applications against new threats as they emerge. DevSecOps teams should integrate continuous testing into the CI/CD pipeline through: 

• Automated scanning tools that examine the code base, such as Kiuwan’s Insights (SCA)
• Static application security testing (SAST) tools, such as Kiuwan’s Code Security to check the source code for vulnerabilities before it is deployed
• Dynamic application security testing (DAST) tools that scan an application for vulnerabilities at runtime
• Penetration tests that simulate real-world attacks and validate the effectiveness of the threat model

Step 7: Monitor and Update Models

There is no finish line in cybersecurity. Developers must monitor applications for threats and continuously update their security posture. Teams should update threat models based on new information and feedback to constantly improve and keep them relevant. 

Optimize Your Security Standing With Threat Modeling

Regardless of the approach you use, threat modeling can improve your DevSecOps team’s performance and increase product quality. You just have to start thinking like an attacker.