If you have not yet seen the Threat Modeling Manifesto, you’re missing out.
The manifesto project resulted from gathering 15 passionate threat modeling professionals, throwing their collective knowledge, wisdom, and experience into a blender. They 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 system representations 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 manifest themselves in production. Threat modeling provides a path to understanding the security and privacy challenges of a feature, application, or product using a repeatable and valuable process for stakeholders.
Read More: Unveiling the 3 Key Benefits of Threat Modeling
Here's how to implement the Threat Modeling Manifesto on your dev or test team.
If you’re going to put the Threat Modeling Manifesto into action, you’ll need to understand and absorb the content found within. The document has something for everyone, regardless of their threat modeling knowledge level.
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. 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.” The document is 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.
Access The Ultimate Beginner's Guide To Threat Modeling Here
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.
Here is a rundown of the Threat Modeling Manifesto's values.
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. 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. Checkbox compliance works for some places and 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.
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 people's knowledge and experience.
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 features or application's security and privacy properties each time they perform a threat model. Nobody, not even those who wrote the Manifesto, has all the threat modeling answers. Everyone that threat models are on this journey to expose and mitigate new threats. We are all on this shared journey of understanding.
Program building tip: Embrace the journey. You can expect threat models with holes and encourage your threat modelers to improve with each iteration.
As with any topic, it is easier to discuss it than do the activity. Consider implementing a rule called the “30-minute rule.” The facilitator is only allowed to talk about threat modeling for 30 minutes before learners have to start doing threat modeling.
Threat modeling 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: You can quickly focus your developers and testers on performing threat modeling. Follow the 30-minute threat modeling rule.
The threat modeling journey demands constant reinvestigation. Over short periods, features change, applications gain new features, and software continuously evolves. 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.
You’ve studied and decided upon a methodology. You’ve built a program on the Threat Modeling Manifesto’s values. Now it’s time to teach your developers and testers threat modeling and the goodness the Manifesto contains.
You could teach them using the workshop model, where you gather a group for a two-hour session with 30 minutes of instruction and 90 minutes of threat modeling exercises.
Whatever method you choose, could you take the message to those who need to use the 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 from the process.
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 the 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 improve slightly. Take threat modeling to as many people as possible, and you might change the world, one small step at a time.