Application Security

Threat Modeling – What is it and why developers should learn about it

Within the process of building a software, understanding its functionality, and identifying possible security requirements is a key function. That can be a huge difference between your software becoming secure or not. This article aims to introduce development teams to the concept of Threat Modeling.

You can also listen to this article:

To perform Threat Modeling is to seek to identify scenarios that may allow an attacker to compromise or even cause some damage to our application. If we have this vision of scenarios, it is possible that we can identify security requirements that can mitigate or even eliminate these scenarios.

But, why does this article bring in the title the idea that this is for developers? Well, of course it is, after all, who else knows the application? Who will work on the solution? Who will implement the requirements? The security team? Sorry, but no! It will be the developers who will act directly, so there is no one better than them, with the help of experienced professionals, to develop a Threat Modeling strategy.

So, developer, get used to it, you will work with it eventually!

What Threat Modeling is and where it begins

I believe that the first step is to explain to those who have not yet had contact with the topic what it is and what it is not Threat Modeling.

First I want to start with what Threat Modeling is not.

Searching for attack scenarios will not hand over vulnerabilities to analysts – that’s not the point of Threat Modeling. So, even though it is common to have some professionals with this outtake, modeling a system is not looking for vulnerabilities.

If we look for the initial concept, Threat Modeling happens in the Design stage of an application. Consequently, we wouldn’t have the application itself yet, so how could we possibly have the vulnerabilities, right?

It would not be necessary at this point, but it is important to point out that there is nothing to discuss when and at what moment the Modeling takes place. 

This is clear within the methodology, and it happens in the Design phase. This is important because we also have this understanding across multiple teams – “Can we choose when to do Threat Modeling?” – no they can’t, the SDLC process is very clear and defined, just follow it, don’t invent the wheel.

Well, now that we understand what Threat Modeling is not, let’s try to understand what it actually is.

Threat Modeling according to Owasp

At Conviso, we use OWASP as a very important source. And even though we can find numerous other methodologies that handle the topic, we will use the one described in OWASP as a basis.

Looking at the definition provided by OWASP, we can say that:

“Threat modeling works to identify, communicate, and understand threats and mitigations within the context of protecting something of value.

A threat model is a structured representation of all the information that affects the security of an application.”

But, if we understand that Threat Modeling is a structured methodology that has the purpose of helping us to identify scenarios, and from them create our security requirements, everything becomes simpler.

But how can this happen?

What to do with complex problems

When we look at the construction of an application, it is common that the problems it solves are broken down into smaller problems – which makes it easier and helps when we create the application.

When we follow in the same direction, only now looking at application security problems, seeking to identify what the security requirements would be, it is not always so simple, and it can easily turn out to be a very complex problem.

Our goal as security professionals is to look at the application and try to mitigate or even eliminate possible threats that it may face. We have to be ahead and think about scenarios, and from these scenarios identify what would be the security requirements that we point out as needed.

The concept is the same, what we did was to look at it from a different angle!

Modeling is a collaborative process

Try to understand: in this case and many others, the group of participants’ experiences will be much better than the individual approach, so adopt a collaborative approach.

Working, identifying, and understanding attack scenarios is not an easy job. Accumulating experiences in the Threat Modeling process is important, and will help the team to develop a much better result, much more efficient from the point of view of security requirements.

How deep is the Modeling?

This is a very common question, and the answer is simple.

Start slow and then get better! What does that mean? In the OWASP documentation itself we can find this answer, take a look:

“Ideally, a high-level threat model should be defined early on in the concept or planning phase, and then refined throughout the lifecycle.”

Here it is worth remembering that whenever the development process returns to design, even in agile models this happens numerous times, Threat Modeling must be reviewed, revalidated and improved.

This is natural because now a new scenario has been created, new threats may have become more real to the current scenario and a lot may have changed. The message is simple – Modeling is a living, constant process!

So, what can we expect?

Well, I particularly hope that you, the developer, understand that it is important for you to study this topic, since you will work with it eventually.

I hope I at least have created a little curiosity about the topic, and if you understand I can try to help with your doubts.

And last but not least: study, understand, and realize that the Threat Modeling process can help you to develop better and more secure applications. It can even help you reduce your work, having to go back to correct a code that should have been created more securely.

You see, developing the wrong way, and developing the right way takes the same work, so why do it the hard way?

If you are interested, I can write another article showing in more detail how to perform a modeling. Let me know in the comments if you’d be interested!

Nova call to action
About author


Over 15 years of experience in Information Security and Applications, graduated in Data Processing worked as a Professor and participated actively as an instructor on trainings to more than 6000 developers and IT teams. Father of two daughters and trader on free time.
Related posts
Application Security

Finding classes for exploiting Unsafe Reflection / Unchecked Class Instantiation vulnerabilities in Java with Joern

During a pentest engagement we found a Java application vulnerable to unsafe reflection [1]. This…
Read more
Application Security

Mitigating Vulnerabilities: Elevating Security Proficiency in Software Development

In the ever-evolving digital landscape, the significance of software security cannot be overstated.
Read more
Application Security

The Importance of Supply Chain to Application Security

When we think about software development, we usually think about complex technical concepts…
Read more

Deixe um comentário