Threat modeling: on guard of the infrastructure security

As developers strive to roll out new features faster and meet production deadlines, security issues are given less priority when developing applications and products. Time and again, security is sacrificed for the sake of functional needs and becomes an afterthought.

Needless to say, that when identified too late, potential threats become concrete security issues. Not only will they cost you more to remediate but also expose your business to higher risks. Doing threat modeling in the early stages of your project development helps to strengthen application security posture and avoid extra expenses in the future.

In this blogpost we shall review the basics of threat modeling and risk assessment process, give its definition, outline the main steps and the most common techniques to use.

Definition

Threat modeling is a risk management approach that lies in identifying potential threat actors, the ways in which they could affect an application, and how to prevent or lessen their negative effect. In other words, threat modeling is about locating system vulnerabilities and developing countermeasures to either prevent or mitigate the effects of cyber attacks against a system.

To help build secure applications, the Open Web Application Security Project (OWASP) has developed a set of security by design principles. Early threat modeling helps to integrate these principles into the application architecture, thereby reducing chances of compromising your systems.

Knowing your enemy

Before investigating the security properties of a given system, it is worthwhile to reckon who your potential attackers can be and characterize them in terms of their resources, access and risk tolerance. There are different types of adversaries with their own motives and objectives.

The method of attacker personas uses the known attacker types to help you build the adversary models that are applicable to your system. Same as you do in marketing to represent all of the major types of users of your product, you create evil personas to help you explore the potential groups of malicious users.

The process includes several steps. Finally, you end up with a persona card of a potential attacker who is likely to act in the given context. The card consists of personal information, motives, specified skills, resources and modus operandi of the supposed criminal. The attacker personas are based on various sources of data regarding the types of people who have been known to attack systems. For example, the potential adversaries in the field of digital banking may include the gang leader, the cyber thief, the insider informant, etc.

In line with the attacker personas is the method of evil user stories. It helps to foresee the system usage from an abuser perspective, and then brainstorming the ways to prevent it.

Same as you write normal user stories in Agile, you create evil user stories to describe what an abuser would do in your system. As pointed out in this blogpost, the simplest way to create an evil user story is to use the regular user story format from an evil point of view, for example: “As a hacker, I want to break into another user’s account, so I can steal their credit card number.”

Knowing the abuser’s intentions helps you to assume what steps they might take to accomplish their goals. And as such, think through the ways to defend against it.

Technical steps

Threat modeling is a well-defined process that includes a series of concrete steps. Following these steps helps a security team to fully understand the environment they’re trying to secure, identify system flaws and map them to potential threats. The steps center around a simple, question-based scheme suggested by a leading threat modeling expert Adam Shostack.

What are we building? To estimate a scope of threat model, it is essential to have a shared technical understanding of the software or infrastructure you are dealing with, and the ways it interacts with external entities. The best way to present it is to draw a technical diagram that explores software designs.

Remember, adversaries use the same pathways to navigate your system as the legitimate users do. The only difference is that they misuse them or use in ways that nobody would supposed to check. So to help see where real threats could happen, your diagram should feature:

• the entry points to interact with the application;
• visualization of data flow through the application;
• trust boundaries where data could be potentially altered;
• business value assets that the attacker would be interested in (for example, authentication credential store).

What can go wrong? The goal of this phase is to determine potential dangers by brainstorming threats to your system. Usually it takes form of a collaborative session with the participation of security architect, the operations/infrastructure team and lead developers together. The output of such session is a living document that includes comments and viewpoints from the whole team.

This phase implies using threat modeling methods (see below) to help you think through the potential threats and evaluate attack vectors.

What are we going to do about it? The goal of this phase is to develop countermeasures and mitigations for the threats that have been identified in the phase 2:

• Prioritize the threats by risk and filter the riskiest ones.
• Work out what fixes you actually need to reduce risk.
• Add security fixes to your backlog.

Did we do a good enough job? This is the final phase that includes retrospective of your threat modeling efforts, i.e. what went well and what could be improved.

Thinking through these questions in the initial project phase is essential to build an effective defense strategy. Normally the picture does not change quickly unless you redesign your application or introduce some large features. As your product evolves, it is wholesome to use the scheme over time to see how the answers change. This will help you asses the security of your new features.

Threat modeling methods

There is a variety of different techniques, with some having a specific emphasis (risk, security, privacy), while others being abstract or people-centric. You can find a detailed guide introducing you to 12 methodologies in an article by the Carnegie Mellon University Software Engineering Institute. Up to date, the following methods remain the most commonly used.

STRIDE

A framework of threats developed at Microsoft, is the most mature and widely used model. The word is an acronym derived from the following six threat categories:

PASTA

The Process for Attack Simulation and Threat Analysis (PASTA) is a risk-centric framework that brings together business objectives and application functionality, and allows to analyze the application vulnerabilities in light of potential threats. PASTA is a fundamental 7-step method, with each step having its own substeps:

• Define the objectives – includes description of the essential business objectives in their relation to the pieces of application functionality, identifying business critical components, services and data-assets;

• Define the technical scope – includes capturing the application architecture at high level and identifying the application dependencies; characterizing the architectural elements of the application in terms of their exposure to attacks, security impact and countermeasures;

• Decomposing the application – the objective is to dissect the application into parts in order to identify potential threat targets; includes creating data flow diagrams with outlined trust boundaries;

• Analyze the threats – the objective is to identify the threats that affect the application and map these threats to the most probable attack scenarios; includes analyzing security reports and application logs;

• Vulnerabilities and weaknesses analysis – includes mapping threats to vulnerabilities using existing application vulnerability assessments;

• Model the attacks – identifying the application’s attack surface, i.e. the points that can be exploited for the attack; representing attack scenarios with attack trees;

• Risk and impact analysis – the goal of this stage is to quantify and qualify business impacts, identify gaps in security controls, calculate residual risk and identify risk mitigation strategies.

Attack Trees

Attack trees as the method of threat modeling emerged in the 1990s. It has been developed and widely used by Bruce Schneier, one of the founders of cyber security. The method uses tree-structured diagrams to depict attacks against a system, where the root node is a goal and leaf nodes represent different ways to achieve that goal.

The method of attack trees allows to investigate possible attack scenarios in terms of their feasibility. Setting value to each leaf node (Boolean: doable, not doable or continuous: cost, risk) can help security engineers evaluate a specific type of attack and assess the related risks.

RRA

An alternative to complete threat models is Mozilla Rapid Risk Assessment (RRA), an open source methodology designed for applications and services under active development. The RRA process centers around a threat modeling template aimed to help security teams make risk assessments. It involves a quick (up to 60 minutes) session, having completing which you receive a concise, informative summary of the risks associated with your data and the list of security recommendations.

RRA is applicable to services only. Its main objective is to understand the value and impact of a service to the reputation, finances, and productivity of the project or business.

Conclusion

Threat modeling and risk assessment is the key practice for building secure applications. It can be run throughout all stages of product development, however, is the most effective during the design and architecture phase. To help you start, OWASP has developed guidelines on deriving threat models for applications. There is also a very useful article by Jim Gumbley from ThoughtWorks that contains a detailed guide for developers on how to start threat modeling.

At SHALB, we offer threat modeling and risk assessment as part of our services. Our security experts will be happy to guide you through the process to help you explore unwanted scenarios and secure your application from potential vulnerabilities.