John Steven is the Internal CTO of Cigital. John's expertise runs the gamut of software security from threat modeling and architectural risk analysis, through static analysis (with an emphasis on automation), to security testing. As a consultant, John has provided strategic direction to many multi-national corporations, and his keen interest in automation keeps Cigital technology at the cutting edge.
This is the last in a series of interviews with appsec experts about threat modeling.
1. Threat Modeling is supposed to be one of the most effective and fundamental practices in secure software development. But a lot of teams that are trying to do secure development find threat modeling too difficult and too expensive. Why is threat modeling so hard - or do people just think it is hard because they don't understand it?
"Effective in what regard?" The world's conception of what threat modeling is, what it produces, and what it accomplishes remains in flux. Many find appeal in thinking through "who may be able to do what to your system where" but we as a community can't even agree on the vocabulary. I addressed this issue in a blog post. Microsoft, security "big spender", published a threat modeling book and tool and still suffers divergence between the STRIDE+DREAD camp and its security testers on what it means to threat model. Without clear and consistent direction: what it is, what goes into the process, and how you use its output; threat modeling will remain hard.
Difficulty buttresses threat modeling misunderstanding. The security community understands vulnerability discovery fairly well. We've systematized techniques and automated with tools (for a fun distraction, start with Gunnar Peterson's thoughts on checklists). Unfortunately some assessment gurus continue to couch threat modeling as the vulnerability discovery box labeled "think": threat modeling becomes the catch-all for hard stuff we've not yet been able to bake into a tool or checklist.
And, yes, threat modelers operate at distinct disadvantages. Modelers almost never possess adequate source material (requirements, a design diagram, or entitlement data). They're often forced to operate within an aggressive release schedule as well.
Summarizing: It can be tough, security experts aren't doing the best job of providing support, and downward pressure on time/LoE squeezes quality.
2. What are the keys to building a good threat model? What tools should you use, what practices should you follow? How do you know when you have built a good threat model - when are you done?
My clients and I have surveyed a plethora of open source and commercial tools. We agree that they often create more drag than the lift they provide. So, with deference to good work that SD Elements has done, I don't recommend starting with a tool: it's distracting.
Combat threat modeling ambiguity with a "Threat Traceability Matrix". Create your own simple spreadsheet tool if you like. Simply document:
- WHO - threat: an agent capable of doing you harm
- WHAT - misuse/abuse a threat intends to promulgate
- WHERE - attack surface on which a threat will conduct a misuse/abuse
- HOW - specific attack vectors (what -> how creates an attack tree)
- IMPACT - negative effect on a business objective or violation of policy
- MITIGATION - cell to track risk acceptance, transfer, or mitigation
Managing this table throughout the threat modeling, vulnerability discovery, and risk management loop will serve you well remaining largely agnostic of threat modeling religion. I like Cigital's threat modeling-it's very software and design centric, with roots in risk. Others like a more asset-centric approach. IMPORTANT: Use whatever practices effectively add high-value "whos" "whats" or "hows" that your vulnerability discovery techniques currently omit.
Combat difficulty and LoE/cost constraint by recognizing threat modeling will be an iterative and incremental process. Your context will govern whether you decide to go depth-first (into a threat, or a component) or breadth-first across the whole system/threat-space.
You're probably never done. As you add to or refactor your system, your threat model's fidelity decays. Update a threat model when new attacks are discovered (what/how), or when motivation/skill/access amongst your adversaries (the "who") change. Your risk management framework (RMF) governs when you stop.
3. Where should you start with threat modeling? Where's your best pay-back, are there any quick wins?
- Draw a diagram - Give developers & modelers a 'one-pager' to work from in concert. Start with the attack surface. Focus on the software, not just systems & network.
- Organize your work - Start by drawing up the traceability matrix.
- Cut-and-paste - When you threat model application Y pull in application X's threat model and evaluate applicability of its content.
- Produce output that someone else consumes - Identify attack vectors ("hows") that can be explored with other vulnerability discovery techniques (dynamic testing, code review, and even design review).
- Pass-by-reference - Keep "what" enumeration conceptual. If attacks vectors fall into the AppSec canon don't spend too much time describing "hows". There's little pay-back in re-treading what your tools and penetration testers discover well already.
- Model what's changing - Projects start green-field only once. The rest of the time you're changing or extending existing functionality. Rather than stopping everything to model the complete system, start with what's changing in this release and those key components on which changes depend. This confines scope and keeps work relevant to current development.
