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!