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 divisions between development, security, operations, and other relevant teams and 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 finding ways to mitigate 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 the attacker’s point of view. Threat modeling allows developers to identify risks specific to their application early and reduce the costs of remediating them. 

There are different types of threat modeling frameworks, including: 

• STRIDE: This focuses on six types of risks, 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 to be protected, such as core applications, confidential data, and necessary 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 the following activities and provide a targeted approach to prioritizing threats based on business goals and 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 will work with the operations processes and integrate 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 effective and practical security measures. 

Step 3: Identify and Prioritize Threats

DevSecOps teams can use various methods to identify threats. As with most elements of cybersecurity, using more than one method will provide more comprehensive coverage. Some options include: 

• Brainstorming to take advantage of creative thinking and 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 (DFD) illustrate how data flows through the system and the points where 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 validate and test them regularly. Ongoing testing will keep models up-to-date and secure applications against new threats as they develop. 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 have to monitor applications for threats and update their security posture continuously. 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 make your DevSecOps team work better and increase product quality. You just have to start thinking like an attacker.