If you have not yet seen the Threat Modeling Manifesto, then you’re missing out. The manifesto project resulted from the gathering of 15 passionate threat modeling people, with whom I was honored to work, throwing all of their collective knowledge, wisdom, and experience into a blender. We then negotiated for six months to define the values, principles, patterns, and anti-patterns for threat modeling.
The result: A document that you can use to build your threat modeling program, taking the wisdom and battle-tested experience from the authors and applying it to your organization.
The Manifesto defines threat modeling as analyzing representations of a system to highlight security and privacy characteristics. Threat modeling is that, and much more. Threat modeling educates developers and testers about security from a different perspective than the OWASP Top 10 or an attacker-centric view.
Threat modeling is about securing design, finding security and privacy issues, and mitigating them before they can manifest themselves in production. Threat modeling provides a path to understand both the security and privacy challenges of a feature, application, or product, using a repeatable and valuable process for stakeholders.
We did not create this document to sit upon a shelf, garner academic praise, or win world awards. We made it to help practitioners build threat modeling programs. Here's how to put the Threat Modeling Manifesto into action on your dev or test team.
1. Study it yourself and absorb the wisdom
If you’re going to put the Threat Modeling Manifesto into action, you’ll need to understand and absorb the content found within. We wrote the document so that it has something for everyone, regardless of their knowledge level with threat modeling.
If you’re a threat modeling pro with years of experience, read and review the Manifesto. You’ll agree with some parts and disagree with others. As authors, we didn’t all agree on everything, and that’s okay. The Manifesto has something for everyone, even if you don’t agree with every line.
If you’re someone new to threat modeling, read through the Manifesto twice, then look at other sources to understand the different methods available to perform threat modeling. To launch your program, you’ll need the wisdom of the Manifesto and also a specific methodology. As the Manifesto says, “The Manifesto contains ideas, but is not a how-to, and is methodology-agnostic.” We wrote the document to be compatible with any method, but you’ll have to choose the methodology you’ll carry forward with your program.
Study STRIDE, LINDDUN, data flow diagrams, threat trees, and tools such as OWASP Threat Dragon, and read books such as Threat Modeling: A Practical Guide for Development Teams and Threat Modeling: Designing for Security. Consider all the different, practical ways to perform threat modeling, and decide which methodology you’ll use.
After you have a methodology, it’s back to the Manifesto to take the component pieces and mold them together into a threat modeling program.
2. Build a threat modeling program of your own from the Manifesto’s values and principles
Here is a rundown of the Threat Modeling Manifesto's values.
A culture of finding and fixing design issues over checkbox compliance
Culture is a crucial word in a threat modeling program. With threat modeling, the ultimate goal is to reach a point in the future where developers and testers perform threat modeling inherently with every new feature. In that future nirvana, the need for a threat modeling process dissipates. That only happens with a strong culture of finding and fixing design issues.
As with all the values in the Manifesto, the first thing is better than the second thing. Checkbox compliance works for some places, and it provides some weight, but our guidance is to focus on a program that impacts your overall development culture and puts threat modeling at the front and center.
Program building tip: Focus your program on finding and fixing design issues, and make that the key metric you use from day one.
People and collaboration over processes, methodologies, and tools
Process, methodology, and tools are essential, but for truly secure design improvement, the key is focusing on the people and the methods they use to collaborate. Even if you have the best process, the most robust methodology, and the best tools money can buy (or open source can provide), if you don’t have people with knowledge and need for threat modeling and a culture of collaborating to squash security and privacy issues, you have almost nothing.
Program building tip: Invest in teaching developers and testers about threat modeling and set up your program to value the people's knowledge and experience. Provide the collaboration best practices for successful threat modeling.
A journey of understanding over a security or privacy snapshot
Security is a journey, not a destination. The same holds for threat modeling. Developers and testers should think of threat modeling as a journey of learning more about their feature's or application's security and privacy properties each time they perform a threat model. Nobody, not even those of us that wrote the Manifesto, have all the threat modeling answers. Everyone that threat models is on this journey to expose new threats and mitigate them. We are all on this shared journey of understanding.
Program building tip: Embrace the journey. Expect threat models that have holes and encourage your threat modelers to get better with each iteration.
Doing threat modeling over talking about it
As with any topic, it is easy to spend more time talking about it than doing the activity. I have a rule when I teach threat modeling in workshops that I call the “30-minute rule.” I’m only allowed to talk about threat modeling for 30 minutes before students have to start doing threat modeling.
Threat modeling is something that is better caught than taught. Threat modeling expertise sprouts from experience. The more threat modeling you perform, the better you get at it.
Program building tip: Focus your developers and testers on performing threat modeling quickly. Follow the 30-minute threat modeling rule.
Continuous refinement over a single delivery
The threat modeling journey demands constant reinvestigation. Over even short periods, features change; applications gain new features; software is continuously evolving. Threat modeling is something that you must revisit at a constant time interval. Threat modeling is never complete; you always need to rinse and repeat.
Program building tip: Ensure the revision of threat models according to a defined time; do not allow threat models to die on the vine.
Teach it to your developers and testers
You’ve studied and decided upon a methodology. You’ve built a program on top of the Threat Modeling Manifesto’s values. Now it’s time to teach threat modeling and the goodness the Manifesto contains to all of your developers and testers.
You could choose to teach them using the workshop model, where you gather a group together for a two-hour session, with 30 minutes of instruction and 90 minutes of threat modeling exercises.
Whatever method you choose, take the message to those who need to threat model and encourage them to teach others. Threat modeling is a discipline that magnifies as more people buy in. Once you buy in, you’re inclined to introduce more people because of the value you see in the mitigations that come from the process.
Teach the developers and testers well
Study the Manifesto and take away the lessons that apply to your program. Review the methodologies and choose the best one for your organization. Build a program upon the Threat Modeling Manifesto’s values. Teach your developers and testers to threat model according to the plan you’ve laid out.
With every person you empower to threat model, a feature or product's security and privacy get a tiny bit better. Take threat modeling to as many people as you can, and you just might change the world, one small step at a time.
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
