It’s clear that there’s value in doing Threat Modeling a new application at design time, but what about existing applications? If the application is already deployed and ready, would you apply threat modeling for a specific security task? Thank you in advance.
Userlevel 3
Yes, there is value even for deployed apps. One example is preparing for a pen test. Assuming you don’t have an unlimited budget, you’ll want to focus on the most risky areas, and building a threat model is very useful for identifying those. Whether you buy a blackbox pen test, or a code review, when you say “we have a threat model and will share it with you”, the price will go down.
Userlevel 3
Hi
most of the threat models I have seen were developed for existing apps irrespectively of whether further development activities were planned or not.
I believe having a TM in place also has a positive effect on transparency about the risks your application exposes. Penetration testing preparation as mentioned above is also a perfectly valid point. Even in cases where price is not influenced, you could benefit for more effective pentest.
Userlevel 2
IMO, I think a TM of an existing app is good as it provides insight into existing threats and potential risk. However, I like to spend time threat modeling things in which I can help reduce risk. I’m not overly interested in just identifying risk. I’m much more interested in things in which I can work with the team to reduce risk. For teams that have time-boxed constraints, I will typically chose to focus on things in which I can help identify and reduce risk to the business.
Userlevel 3
The value of threat modeling in the design stages (and early and often afterwards!) is tremendous and an immediate impact of the threat model can be realized, because the decisions happen in real-time. I see a lot of value in threat modeling something already in production for a few different reasons:
- Sharing knowledge of the system or application. Too many times there is tribal knowledge. Through threat modeling the team, stakeholders, and partner teams get a chance to get an in-depth look of an application that may have not before.
- Getting the data out of threat models. Getting the data out of the threat model is great to help train others, use to highlight new threats, or even help sell your program to management or other teams who are interested.
- Influencing decisions. This goes along with using the data out of threat models. If a threat and control registry was to be created with data from threat models, the teams responsible for controls may get more insight into how these controls are operating. If we see the same threats occuring in many threat models, maybe its time to bring this up (and possible solutions!) to management or engineering leads who can do something about the problem in from an enterprise-wide perspective.
- As threats change over time, its good to be able to re-review, assuming there are no new changes to the application, understanding if certain threats are more or less severe as they once were considered.
Userlevel 2
As a technique, Threat Modeling should be applied frequently before, and during the application development cycles. A known and working system is a good starting place for teams to learn Threat Modeling skills in a collaborative manner. When getting started with Threat Modeling, the abstract nature of thinking through the threats can be overwhelming when the system itself is theoretical. Practicing your Threat Modeling process on existing systems is a faster feedback loop for training and insight.
On the topic of feedback loops, the activity of a Threat Modeling exercise is a GREAT way to track your team feedback loops. If an overall system design and Threat Model is part of the shared and documented knowledge of the team, then new feature designs don’t have to re-write the wheel.
For example - if a Threat Model exercise for a system identifies a potential remediation to existing functionality that the team can execute, what happens then? Ideally, the remediation becomes a “feature request” in the very next sprint, prioritized against the delivery of all the other features. Because the Threat Model informed the documented work, the team reaps the benefit of a shared understanding of the deliverable, the acceptance criteria (able to mitigate the documented Threat), and is ideally able to demonstrate the change at the end of the deliverable time/sprint. The next time the Threat Model exercise is conducted, there’s a clear trail of Threat identification, remediation/mitigation, and demonstration of the functionality.
Benefits include: Any new members of the team or stakeholders can understand the process and the change, and existing stakeholders are able to have a measurable result.
>If the application is already deployed and ready, would you apply threat modeling for a specific security task?
Yes. First start with a High Level Threat model of the system, its external interactors, and trust boundaries. Then, once you’ve identified a shared visual understanding of a system, define component workflows. These workflows should use parts of the completed first Threat Model, but specifically be scoped to the most minimal components. When you say “specific security task”, I hear “All feature work”. All feature work is a security task, and should have some time (maybe not a full meeting, but just part of the workflow) of asking “What could go wrong?” or “How can this feature be misused?” This keeps smaller feedback loop cycles, and feeds information back into your larger threat modeling exercises.
Great question!
I believe that the industry has been and will continue to trend away from performing threat modeling only within the design phase or “greenfield” applications. The reason behind this is the same as why you would not restrict other security practices (SAST, DAST..) to only these parts of the SDLC. Even if the application does not change, the threat landscape (actors and attacks) change constantly. A threat modeling program that is designed to perform the practice at regular intervals will yield threats that may have otherwise been overlooked.
Userlevel 3
To add to what others have said, I think the pain in threat modeling existing apps comes when we reach the question “what are we going to do about it?”
Existing apps will often have threats that are hard to address without a re-write. There may be no change budget available to go address the problems.
When I work with clients who are getting started, I encourage them to threat model the apps that they’re working on, as they’re working on them, because it avoids the pain of finding a threat and having to then fight for budget for a fix, and it avoids threat modeling getting a “bad rap” as the thing that keeps opening cans of worms. (And the attendant question, “why do we keep opening these cans of worms?”)
Reply
Log in
Create your account
Not a member yet? Become a member to join forum discussions, participate in community events and apply to write articles.
Create an accountLog in with LinkedIn
or
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.