Using Threat Modeling to Boost Your Incident Response Strategy

Threat modeling is increasing in importance as a way to plan security in advance. Instead of merely reacting to threats and incidents, an organization can identify and evaluate its security posture, relevant threats, and gaps in defenses that may allow attacks to succeed.

Threat modeling has a two-way relationship with incident response:

• When an attack happens, incident responders can benefit tremendously from a threat model that shows them which attack vectors are likely to impact a system, what defenses are in place, and which steps are necessary to mitigate the attack.
• After an attack, lessons learned by incident responders can and should be used to update the threat model.

What Is Threat Modeling?

Threat modeling is the process of mapping out and investigating threats with the goal of creating better security strategies. As Cynthia Gonzalez discusses in her blog, there are several threat modeling frameworks, including:

• STRIDE – Microsoft’s threat model covering six types of threats: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service (DoS), and Privilege Escalation
• PASTA – A 7-step model designed to correlate business objectives with technical requirements
• CVSS – The standardized scoring system used globally to communicate information about known vulnerabilities
• Hybrid Threat Modeling Method (hTMM) – Focused on extracting security requirements and uncovering ways systems can be abused by attackers

Whichever framework you select, all have a common goal – to identify vulnerabilities, analyze the organization’s security posture, and define countermeasures to mitigate or prevent the threat.

Typically, the modeling process defines a threat as any potential or actual adverse event that might be malicious like a denial-of-service (DoS) or SQL injection attack. A threat can also be incidental, like storage failures that can compromise company assets.

Effective threat modeling determines where efforts should be applied in order to keep the organization and its systems secure. This can change as new threats develop or become known. Also contributing to change are applications or infrastructure that is added, upgraded, or removed. This is why threat modeling should be an iterative process.

A threat modeling process typically consists of the following stages:

1. Identifying what each application does
2. Defining enterprise assets
3. Profiling each application and specifying its security properties
4. Detecting potential threats
5. Prioritizing potential threats
6. Documenting adverse events and actions taken to mitigate them

How Does Threat Modeling Work?

Threat modeling works by identifying types of threat agents that can harm an application or computer system. To identify threats, the process requires adopting the perspective of malicious actors to assess how much damage they can inflict.

When performing threat modeling, organizations carry out a comprehensive analysis of their software architecture, business context, and artifacts like functional specifications and user documentation. This process helps gain a better understanding of the threat landscape and the existing security measures.

Threat modeling at the development stage

Organizations typically perform threat modeling during the design phase of a new application. This is common in a DevSecOps organizational model. This helps developers discover vulnerabilities and secure their design, code, and configurations.

Developers typically perform threat modeling in four steps. First, they create a chart showing the structure of the software under development. Second, they determine things that could potentially go wrong, including malicious attacks and incidental damage. Third, they determine what they can do to mitigate the threats. Finally, they validate that these mitigation steps were implemented correctly and effectively.

Threat modeling at the production stage

Threat modeling doesn’t end in the software development phase. As applications are released to production, they are exposed to real threats and attacks. This makes it possible to validate the threat model. Did we correctly anticipate threats facing the application? Are there vulnerabilities or threat vectors that were not taken into account?

This is where threat modeling connects to incident response. When an incident occurs and the organization responds and mitigates it, this is a golden opportunity to refresh the threat model. In the opposite direction, the threat model can inform incident response by giving responders the context they need to understand the threat and take the most appropriate action.

Using Threat Models for Incident Response

Security incidents affect all organizations, with causes ranging from infected hosts to social engineering and malicious insiders. Threat modeling can help security teams implement incident response by providing a clearer picture of attack vectors.

The following process can help application security teams identify threats and respond to them in an effective and timely manner.

1. Incident response planning

The incident response planning process provides structure for incident responders, usually based on the NIST or SANS incident response process (see these blog posts to better understand the NIST and SANS incident response frameworks). Ideally, threat modeling can be integrated into incident response at the planning stage. For example, when an incident response plan includes specific sections for dealing with specific types of threats, those sections should be informed by the organization’s threat model.

2. Identifying an incident

Identify the initial issue and the scope of an attack. This should be a quick, preliminary understanding rather than a full analysis with complete documentation. You can provide diagrams to help teams visualize the breach.

3. Identifying threats

Map the incident to a known threat in your threat model, use the context of the threat to understand how to respond, and identify other related incidents.

If it is not clear what is involved, use attack trees to model threats, prioritize or rule out various scenarios, and test them to verify the threat. Don’t ignore scenarios that you deem to be impossible. Test them to see if they might actually be made possible by software or environment changes, new vulnerabilities, and other safeguards.

4. Updating the threat model

Once the attack is over and attack vectors have been discovered, you can update your playbooks and maintain your threat model. Update your definition of threats in light of recent experience. You can also create automated tests and run them continuously to verify if the threat, as it is known today, can be exploited.

If there are root causes remaining even after the attack was mitigated, work with security and IT teams to fix them. Also, try to identify other related incidents and see if they were fully mitigated in light of threat data. This is a key part of threat modeling—understanding the broader context of the threat and ensuring it is eradicated beyond the specific incident.

Threat Modeling Best Practices

Follow these best practices to ensure threat modeling is more effective and able to positively impact incident response activities.

Build a Threat Catalog

A comprehensive list of pertinent threats affecting your organization, or specific systems, is critical to incident responders.

There is no standard list of threats because the most relevant threats depend on the type of application, the industry, region, and other factors unique to each organization.

Identifying threats often requires brainstorming. You can use frameworks or lists like STRIDE, the MITRE Matrix, or the OWASP Top 10.

You should use this process to create and provide an organization-specific threat catalog that can accelerate future brainstorming processes and help improve the consistency of threat modeling.

Use a Consistent Approach

Incident responders need to move fast. They don’t have time to read through documentation or figure out the terminology used by the security research team.

A consistent approach makes it possible to leverage effort by other team members instead of starting from scratch. For example, a team member can respond to an incident using a threat model previously developed by other members. Consistency also allows teams to gain more granular information about threats, which is difficult to develop at real time as the incident unfolds.

Additionally, this approach helps achieve scalability. If the specific workload function (which the team is modeling for threats) uses components with existing threat models, the team can reuse the existing threat model (or security controls) for those components. This approach enables teams to effectively rely on and build upon the component’s existing threat model and eliminate re-work.

Use Existing Workflow Tooling

Modern application development teams typically use a toolset that includes collaboration tools, notification and alerting tools, issue tracking, and version control. In a true DevSecOps organization, everyone should use the same toolset – developers, operations staff, threat modelers, and incident responders.

Existing workflow tools can provide feedback, assign tasks, and serve as a single place to view the overall status of threat modeling artifacts. Tests should be part of the workflow to reduce friction and ensure threat modeling is part of the development cycle. Ideally, your workflow tool should enable team members to work asynchronously as they create and review threat models.

Distribute Ownership

In the long run, it is impossible to have one person or department responsible for creating a threat model. The process can only scale when more people join the process. Also, centralized ownership of threat modeling means it is disconnected from those who actually design and implement applications.

Distributed ownership of threat modeling is easier to scale, with the teams designing and implementing each application function helping with threat modeling for that function. This gives application development teams control and enables them to continuously improve the security of the components they are developing. The threat modeling process also helps diverse teams acquire and implement security knowledge.

Conclusion

Threat modeling methodologies can impact and improve incident response in these important ways:

• Helping to identify incidents faster and understand their severity.
• Assisting incident responders to act faster and more effectively.
• Adding effectiveness when integrated with an incident response process because incident responders provide a feedback loop to continuously update threat models.

As you evolve and improve your organization’s incident response and security research processes, adding threat modeling can add speed and efficiency, making your efforts worth the time and investment.

About the Author: Gilad David Maayan is a technology writer who has worked with over 150 technology companies including SAP, Imperva, Samsung NEXT, NetApp, and Ixia, producing technical and thought leadership content that elucidates technical solutions for developers and IT leadership. Today, he heads Agile SEO, the leading marketing agency in the technology industry.

LinkedIn: https://www.linkedin.com/in/giladdavidmaayan/

Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.