Whiteboard Hacking

Threat Modeling

What is threat modeling, who is involved and why use it at all? Threat modeling is a methodology that helps you discover and prevent security risks in your application or system. This is beneficial in the long run: the damage that an attack might cause could have a serious negative impact on your business. Threat modeling does not only involves IT staff but also business stakeholders.

What is threat modeling?

Cyber security is an important factor to take in mind when you want to build out a web application or any other type of software. Threat modeling – also called Architectural Risk Analysis – is a 4-step security methodology for tackling cyber security threats. Following best practices, we usually start implementing threat modeling in your project before a single line of code is being written. During the process we make use of an internationally recognized framework OWASP SAMM. We help you integrate all the aspects of threat methodology efficiently as part of your software development.

Now how exactly do you have to perform a threat modeling project? We normally have 4 different steps that can help you out.

In the first step of the threat modeling process we draw up data flow diagrams so we can get a solid understanding of the mechanics of the upcoming project. We add trust boundaries to the diagram in locations where potential attackers might interfere with the software.

Secondly, we use this initial diagram so that for each trust boundary we review potential threats to the software that could occur .To identify those possible risks, we use the STRIDE approach, one of the many threat modeling methods that were developed or introduced by Adam Shostack, while working at Microsoft. For more complex threat analysis we might introduce so-called ‘attack tree’ diagrams.

In a third step of threat modeling, after the risk assessment, we review those areas which are prone to possible cyber-attacks and determine the best possible solutions.

To conclude we validate the threat models that we have drawn up. Will each of the identified risks be mitigated? And are those areas where no full proof protection is guaranteed clearly tied up with the business risks of the company that will be using the app? To conclude you decide how to follow up the whole process.

 

Why use threat modeling?

The main reason to use threat risk modeling is mitigating the potential security flaws of your software, before an attack actually happens and causes damage to your company. During the assessment of the possible threats you can also look at the techniques (and the required costs for implementing these) that can help mitigate the attack. Also, you can rank the different threats based on risk weighting, meaning: how important each of these threats is and how likely it is that the threat will occur. All of this might be helpful in order for you to choose which threats should be prioritized when development starts. Here you also might have to make choices about which threats you don’t see as necessary to address and thus you don’t (for the time being) want to mitigate.

Who is involved in threat modeling?

Threat modeling is a cost-efficient technique to reduce security risks. One of its strengths is that it brings together all the different stakeholders involved in the security of the application and ensures that they all share a common understanding of the business value and security posture of the system or project. Also, it helps those people to share a view on the main threats and what mitigations can be used to address them.

But who are those stakeholders? Involve too few, and the threat modeling exercise loses its main benefit because not everyone shares the same understanding of the business value and threats. Involve too many, and the exercise can result into a costly set of meetings. In our experience, threat modeling is best performed within a core team of limited size. Ideally, at least the following roles are represented:

Role Motivation
Business stakeholder Ensure that business value and potential business impact is clear.
Architect Provide a high-level overview of the application ecosystem and the underlying rationale.
Developer Provide details on used libraries, frameworks, and coding guidelines.
Security and/or infrastructure engineer Provide details on existing security and/or network configuration.
Project manager Validate proposed mitigations in terms of timing and budget
Threat model specialist Ensure proper execution of the threat model process.

This team composition can be very powerful, as it contains stakeholders with complementary views. First, it contains people with in-depth technical know-how, such as developers, security and infrastructure engineers. Second, it contains people that have a broader view, either technical such as architects, or non-technical such as business stakeholders and project managers. This is a proven recipe for constructive discussions, as one might imagine. If managed well, this protects the threat modeling exercise from not representing reality, underestimating certain technical risks, or missing the goal of the exercise by failing to appropriately frame the uncovered risks with respect to their business impact.

Whiteboard Hacking - Grotehondstraat 44 1/1 - 2018 Antwerpen - jelle@diggle.be