What is threat modeling?

What is threat modeling?

Threat modeling is an exercise for finding security holes in an application and its environment. It involves creating a representation of an application with all its components, then identifying weak spots. Ideally, developers and security engineers use threat modeling throughout the software development process — before an application goes live, not just after. Threat modeling can help make an application much more secure than it would have been otherwise, but it should not be expected to make an application impregnable.

In heist movies, the lead characters often examine blueprints of the facility they plan to rob, figuring out weak points — where the building can be entered, the angles that security cameras cannot see, and so on. Similarly, threat modeling is like examining the given application's "blueprints." The difference is, threat modeling is done by persons who would like to keep the application secure, not the would-be robbers.

Threat modeling requires teams to create a complete view of the application. It then involves thinking like someone who might want to compromise the application. What would an attacker do? Would they perhaps take advantage of weak API security? Would they use a supply chain attack to infect an integrated system library? Although not all attacks can be anticipated, threat modeling helps stop some of them before they happen.

What are the steps of threat modeling?

There are a lot of possible approaches to threat modeling, and no one method can be applied to every situation. But typically these four main steps are involved:

1. Assessing and diagramming the application

Threat modelers attempt to identify and depict:

• The components of an application, including database servers, web servers, gateways, libraries, and the user interface
• The ways in which those components connect, such as the protocols used for exchanging data and any encryption protecting that data in transit

If Terry writes a simple application that displays pictures of balloons, his diagram of the application could look as follows:

Note that this is a vastly simplified example, and a real threat modeling application diagram might be much more complex.

2. Identifying security flaws in the application's construction

Seeing an application laid out in this way can make it easier to identify flaws. Terry, for instance, might notice that the communications between his database of balloon photos and his web server do not use Transport Layer Security (TLS). This means that neither server verifies the other's identity via digital signatures, making it possible for an attacker to impersonate the database server and send malicious content to the web server.

3. Making changes that fix those flaws

Since threat modeling takes place throughout the development process, mitigating flaws may mean either changing the plan for an application's architecture, or deploying a fix to an application build in progress.

To mitigate the threat he identified, Terry can reconfigure his database server and web server to use TLS for their connection — or better yet, to use mutual TLS (mTLS) and verify each other.

4. Verifying that those changes have been applied and correctly mitigate the threat

At this point, Terry might run the application in a test environment and check if 1) the servers use TLS as configured, and 2) if the web server will accept HTTP traffic from an unverified server instead of the database server. He would perform similar checks for any other mitigations he has applied.

What are the different threat modeling methodologies?

A threat modeling methodology is an approach for identifying threats. Methodologies provide structure to the threat modeling process, which could otherwise be overwhelming in a complex system. Organizations can choose from a wide range of threat modeling methodologies, or even develop their own. A few of the most common methodologies include:

• STRIDE: This methodology, developed by Microsoft, is a mnemonic device for identifying security threats. The letters of "STRIDE" stand for "Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege." ("Repudiation" here means the inability to verify data's origin and integrity.) The idea is to look for these six specific types of threats across an application's architecture.
• PASTA: This stands for "Process for Attack Simulation and Threat Analysis." PASTA is a seven-step process to identify, enumerate, and score threats.
• VAST: The Visual, Agile and Simple Threat (VAST) methodology is associated with ThreatModeler, an automated threat modeling software product.
• SQUARE: The Security Quality Requirements Engineering (SQUARE) methodology helps identify security concerns up front, early in the development process.

There are several other threat modeling methodologies as well. Some of them, such as "Trike" and the various hybrid methodologies, do not even have acronyms.

When does threat modeling take place?

Threat modeling is intended to take place before and during software development, throughout an application's lifecycle. If an application is released without any threat modeling or mitigation, security flaws may be discovered by users — or attackers — before they are discovered by security teams. This can result in a data breach and introduces a greater risk of zero-day threats.

However, because threat modeling does not discover all risks within a system, developers and organizations should continue with this process even after release. In addition to threat modeling, they can do so by:

• Threat hunting: This involves proactively searching for threats against a system. Threat hunting can be a manual investigation process carried out by a security analyst, an automated process done by a security tool, or a combination of both.
• Penetration testing: Penetration testing, or pen testing, is a security exercise in which an ethical hacker attempts to find and exploit vulnerabilities in a computer system. To be effective, penetration tests should be performed by someone without prior knowledge of the system, and therefore have to be carried out completely separately from the threat modeling process. Often those who built the application are too close to it to identify all the flaws, just as the architect of a secure facility may not anticipate the flaws that allow a team of robbers to break in during a heist movie.
• Other application security measures: Application security is a complex discipline. No system or application should ever be considered completely secure. A web application firewall (WAF) can go a long way towards securing web applications.

Cloudflare also offers a threat intelligence and operations service, Cloudforce One, to protect customers from the latest threats. Cloudforce One is led by a world-class threat research team that is highly experienced at disrupting global-scale attackers. Learn about Cloudforce One here.