How I Explain Threat Modeling to Customers

Note: This article is updated at How I Explain Threat Modeling to Customers.

Here's my trying to explain threat modeling (actually core modeling) to a customer …

My core theme of the modeling is this:

• Define what good looks like (e.g. objectives)
• Establish boundaries of good (constraints, goals -- what can't happen, what needs to happen, what's nice to happen)
• Identify ests for success (define criteria ... entry criteria and exit criteria ... how do I know when it's good enough)
• Model to play 'what if' scenarios before going down long-winded dead ends
• Identify and prototype the high risk end-to-end engineering decisions (to provide feedback, inform the direction, update the objectives)
• Use an information model (e.g. the web app security frame -- use 'buckets' to organize both decomposition as well as package up the principles, practices, and patterns) ... another trick here is that the frame encapsulates 'actionable' categories ... you're modeling to inform choices and build on other's knowlege
• Leverage community knowledge.  (The information/model frame also helps leverage community knowlege - you don't have to start from scratch or be a subject matter expert - to speak to the dev, you can use patterns, anti-patterns, code samples)
• Model just enough to reduce your key risks and make informed decisions (look before you leap)
• Incrementally render your information (you basically spiral down risk reduction ... you identify what you know and what you need to know next
• Use a set of complimentary activities over a single silver bullet (use case analysis is complimentary to data flow analysis is complimentary to subject object matrix ... etc.; threat modeling does not replace security design inspection or code inspection or deployment inspection)

This is the approach I use whether it's security or performance or any other quality attribute.  In the case of threat modeling, vulnerabilities are the key.  These go in your bug database and help scope test.