Recently updated on March 18, 2024
What is Threat Modeling in Software Development?
How to Perform Threat Modeling?
When to Threat Model During Agile?
In the article “QA is the New Black,” we argued that the “new-age” Quality Assurance professionals should ensure the test-driven development throughout all stages of a product’s life-cycle, starting from the conceptual level. Threat modeling is a powerful methodology that complements the test-driven development and can elevate the security and quality of a product to a whole new level.
What is Threat Modeling in Software Development?
When you are walking down the dark deserted alley and your vivid imagination starts writing unpleasant scenarios of what could happen to you and how you can avoid them — you are threat modeling.
You are also threat modeling when thinking about how to mitigate the negative consequences of running late to that one important meeting, which of course had to be the first thing in the morning.
If you’ve ever tried to think like a criminal out of curiosity, boredom, or intent (hopefully not) to determine weak spots in a system that can be exploited — you’ve threat modeled as well.
In other words, threat modeling is an activity for the identification and management of risks.
Software developers, Testers, DevOps, Business Analysts, and other IT professionals threat model on a constant basis to determine how the system they are building can be screwed up so they can implement additional protection. Threat modeling is similar to playing abstract Jenga with software architecture: you pull out one block at a time to see whether the structure holds.
However, the process of threat modeling is not always a conscious and planned team effort but rather a spontaneous individual initiative of an employee.
Imagine a hypothetical situation:
Mary is a developer who currently works on a big FinTech project and is responsible for creating a key-encryption mechanism. She decides to use a default random number generator for encryption. After the work is done, Mary goes to have some coffee. While enjoying the hot beverage, she thinks about her algorithm and whether it is reliable enough. Mary starts thinking about the ways of abusing the encryption mechanism and remembers about random number generators attacks that can affect encryptions that use random generators that are not random enough so can be exploited. Therefore, she goes back and changes the default random generator for a more quality one that uses several sources of randomness with big levels of entropy. The resulting encryption mechanism is significantly more durable and their FinTech project will never be a part of the Random Number Generator Attack list.
Imagine how many more vulnerabilities, it would have been possible to identify and get rid of if a process of threat modeling was a directed and well-structured effort during the early stages of a product life-cycle. It also would have saved Mary time that she spent rewriting her code.
Thus, threat modeling cannot manifest its full potential if it is not a must-have approach during the early stages of software development. Such a powerful bug-preventing and vulnerability-identifying mechanism can be a powerful Quality Assurance tool in the software development industry.
How to Perform Threat Modeling?
The first thing to establish – threat modeling should be a team effort; it requires the cooperation of QAs, Developers, DevOps, Business Analysts, and everyone else in between. Otherwise, the results will not be complete.
Even though threat modeling is all about one’s creativity, experience, and criminal ingenuity, it still has a universal structure to it that helps to bring forth its full potential. In his book, “Threat Modeling Designing for Security,” Adam Shostack states that you start threat modeling by focusing on four questions:
1) What are you building? You can start answering this question by modeling the way data flows in your application.
2) What can go wrong? You can divide the answer to this question into three parts:
a. What valuable assets of the application should be secured?
b. What an attacker can do to the assets?
c. What system vulnerabilities can the attacker use?
3) What should you do about those things that can go wrong?
4) Did you do a decent job of analysis?
The achieved results will shed light on the previously hidden and not so obvious issues with the product and as a result, will significantly improve testing practices and make the code more fireproof.
There are different approaches and even a special game developed for Threat Modeling that can be found in the book mentioned above.
As you can see, threat modeling is a great opportunity for IT professionals to go full-scale Moriarty and exercise their creativity.
When to Threat Model During Agile?
Threat modeling does not have a fixed place within the agile software development approach. Use threat modeling when and where you find it the most appropriate.
We have two tiny recommendations though; conduct threat modeling
1) As soon as the architecture is ready.
2) Right after a change to the architecture was made
Also, you can treat threat modeling as a part of the test-driven development and develop test cases accordingly to the results. The only limit is your experience and imagination.
Remember, threat modeling is about elevating the quality of software products to a new level by determining the system’s weaknesses and vulnerabilities in the earliest stages of product development. Threat modeling is not mandatory for software development. However, it is an amazing tool for companies who want to create products of the highest quality possible.
You can also read our article “Developing Secure FinTech Application” for more cyber-security tips.