Threat modeling hasn't always gotten the recognition that it deserves but the recent Recommended Minimum Standard for Vendor or Developer Verification of Code by the National Institute of Standards and Technology (NIST) is taking a big step in this direction.
While there are some other aspects to this standard that do make it unique and quite effective, the fact that it is highlighting threat modeling is what is sets it apart.
We can also see that threat modeling is something that is also being promoted by the Food and Drug Administration (FDA) in their premarket cybersecurity guidance. This is a big step as the NIST framework is something that is eventually going to be adopted by all organizations that indirectly or directly work with the government.
While the standard does improve things and the US government is trying to bring this concept to the masses, in the near future it can have some far-fetched implications. Specifically, this is going to have an impact on the wider software market. As firms working with the government start to incorporate this style of analysis other developers and industry experts will naturally become interested in this in order to keep themselves relevant. However, it might not be as straightforward as what we think.
According to the Threat Modeling Manifesto, the process of threat modeling aims to understand a system specifically in terms of its capacity and ability when it comes to the security and privacy of stakeholders. Essentially, this gives organizations the ability to understand the associated risks with a certain kind of software before the software is actually put into code. This is great for threat analysis but it is even better for the actual design and construction of an app, service, or software. Ideally, a good threat modeling approach focuses on clarifying what the goal of the job is, what the possible problems can be, what can be done about these problems, and how the final goal can be achieved most efficiently.
Starting with this approach is also known as "starting from the left" and is something that has been around in software security for quite a while.
The most significant advantage of this approach is that threat areas can be identified right from the get-go and countermeasures can be made. When this is the starting point for any program it directly influences all the security practices that follow and makes it much easier to create an outline for the rest of the work to follow.
Moreover, the deliverable asset also becomes predictable as the job of penetration testers has already been taken care of and you are creating something that can go directly into testing and you can start teaching other teams on how to secure it.
Also for the developer, this is a useful tool as it allows them to create a system that is to the best of their abilities and a product that holds up their reputation. While this is not a technical advantage of the product itself it is something that enhances the work of the development team.
For businesses, this is the best way to create momentum in the right direction and achieve quick success, even though the initial part if time-consuming.