Contextualization
Why should we think on threat modeling? Well, during the software development process, some steps must be observed so the final result is truly a secure application and is able to reach all established requisites.
New policies and normatives are being created so data owners will have the guarantee that their information is secured.
Privacy has become an overrated therm when the topic is software security. In case of loss or compromise of these data, new laws appear to ensure owners to get the attention and the answers necessary to each event.
In this scenario we need to understand that these models of development – here we don’t want to limit this therm neither the agile models, nor on more traditional ones – need to be more observed, understood and followed on their better practices so the final result is a developed software more secure every time.
How to get to threat modeling
To ring a bell, a development model has basically five distinct levels – this is even when we talk about the more agile models, because on their basic concept we continue having five levels: Requirement, Design, Coding, Testing & Maintenance.
When followed, these five levels will guarantee that the final result is a structured and valid software on each of those levels. However, the idea is a little different, because the speed that other functionalities are required – or even new softwares – are forcing many development team to not follow a concept model. It was and still is a problem, that in a certain way was faced by Microsoft in 2002 to answer a directive called: Trustworthy Computing (TwC)
In answer to this directive Microsoft has created a series of study groups with the objective to develop methods to improve application security. Thus, one of the groups was created to study the concept of Secure by Design.
In this model, one of the levels to be developed is the creation of a threat modeling document, where basically creates a map of possible threats to the software then some mitigation solutions are designed based on the application construction concept.
What other things we should understand on models of development
However, this model is not the only one that can be used, many other patterns are available in the market, one that is becoming notorious is presented by ISO- International Organization for Standardization and by IEl C – International Electrotechnical Commission in its international pattern called, ISO/IEC 27034, normative that brings a series of controls that must be implemented in a secure development process.
Being one of the most used models, ISO/IEC 27034 is not the only one, other patterns can be found in the market, ad one that can be used is OWASP SAMM, normally called OWASP OpenSAMM since 2009, but recently it was updated to OWASP SAMM. We are not going to talk about it at this point, we will just show that the threat modeling is present in many other models and treat its use and importance to the safest application development.
However, it is up to us to recommend. The reading on the OWASP SAMM as well as of other OWASP materials is fundamental to maintain the developer’s knowledge on the best practices of secure development.
What is threat modeling?
After all, what threat modeling truly is?
Well, there are many definitions that can be found as the example used by microsoft on its SDLC study material.
“It’s an engineering technique you can use to help you identify threats, attacks, vulnerabilities, and countermeasures that could affect your application.”
Even though it is not a good definition, the one I appreciate the most is one by Adam Shostack on his book, “Threat Modeling: Designing for Security”, where he describes threat modeling as:
“Threat modeling is the use of abstractions to aid in thinking about risks.”
This definition although very simple, is the one that better represents what threat modeling really is, though in a more abstract way, because it is done in the application design phase, looking for possible threats that an application can be exposed to.
For many architects and developers this might be a very strange definition, because the aim is to make this validation on the initial phase, without a single coding line being developed. But it is like this, we’ve got to set our development model or put our way of thinking into practice to identify possible threats to the applications, being done on the given time will bring a significant gain of time, as well as on vulnerability reduction identified on the final phase of the development process, though reducing costs.
So, let’s look again to shostack definition, and if we read it with closer attention we will perceive that his definition is in fact the objective of our threat modeling which is identify and prioritize risks.
To conclude, what is threat modeling? Well, if we can summarize, and having as base Shostack definition, we can say that it is the search for possible risks to which our software is exposed, consequently resolving the cause of the problem.
Sources:
IBM: Security Intelligence
OWASP
