Threat modeling is now an increasingly popular tool for teams working on software development as they integrate security into their design lifecycle.
Threat modeling was developed to be a highly customizable tool. Teams can determine the methods that work best for them, while avoiding the other methods they consider to be unimportant.
STRIDE is one of the techniques that has become a standard element of threat modeling over time, was recently questioned by my colleagues. They were pondering whether STRIDE is still an effective method for threat modeling.
What is STRIDE?
For those who are not familiar with STRIDE as an acronym for threat classification model It is an acronym that stands for:
Spoofing – Tampering Information Disclosure – Deny of Service – Escalation Privilege
The classification model could be utilized as part of an exercise to model threats which assists participants in determining “What could go wrong with this feature or application that we’ve created?” Participants can then think of potential threats to the app or feature through the creation of situations of abuse that fall into the six threat categories of STRIDE.
Is this still beneficial for the team members who created this model of threat? My view is strongly stated, “Probably”.
Think about carefully the Six Classifications of Threats
I can see the value of the use of STRIDE threat modeling for those who are not experienced individuals in a modeling group. A lot of software engineers aren’t aware and uninformed about the kinds of frequently employed attacks that their software and features might be required to protect themselves against.
If these novice threat modelers are asked to create an inventory of threats, the STRIDE model could be an ideal place to begin to ensure that all six categories of threats are taken into consideration by the team.
Clear Application Vision using the Eyes of an Attacker
Unexperienced threat models may not realize that sharing details about the technical aspects of an application could be utilized by attackers to understand what vulnerabilities might be found in the app or feature. However, by asking these novice threat modelers to learn about STRIDE, they will start to view the application from the perspective of an attacker, which is a valuable technique when building better security-focused applications.
Reviewing the List of STRIDE Check-List
I am also a believer in the use of STRIDE for the more experienced members of the modeler team. However, in this scenario, STRIDE can be used as a check list after the team that is modeling threats has made a list of threats. For instance in the event that the list of threats has been developed however there aren’t any instances of threats to privilege escalation An experienced group using STRIDE to create a tool might find that a threat classification was not found and might think about whether there aren’t any privilege-escalation threats in the list or if they’ve missed something.
Threat modeling was designed to be able to be customized in order that teams can gain some advantage from this useful process, no matter the amount of time or resources could be assigned to it. If a threat modeling group is familiar with the process and is comfortable using STRIDE and they can focus on doing other processes for threat modeling that they feel are more effective, that’s fine. However, I believe STRIDE can still be a powerful tool to fully comprehend, “What threats could this application possibly face within our production environment”.
Menu