Value Driven Threat Modeling - Avi Douglen
AppSecUSA 2018 investigates Value Driven Threat Modeling - Avi Douglen.
Summary
### Overview In this talk, Avi Douglen addresses the cultural and operational divide between security teams and software developers. With an industry ratio of roughly one security professional for every 100 developers, centralized security teams cannot scale to review every piece of code or architecture change. Traditional threat modeling methodologies—such as STRIDE, Attack Trees, and PASTA—are often too heavyweight, waterfall-oriented, and slow for modern agile sprints. Douglen argues that if security is to scale, developers must perform threat modeling themselves. To make this feasible, threat modeling must shift toward an agile, lightweight approach centered on business value rather than exhaustive attacker modeling.
### Key Topics - **The Security-Developer Disconnect**: Traditional security approaches demand deep attacker mindset analysis, heavyweight documentation, and weeks-long turnaround times, conflicting with fast two-week agile sprint cadences. - **Traditional Threat Modeling Frameworks**: Methodologies like STRIDE (Microsoft), Attack Trees, and PASTA (Process for Attack Simulation and Threat Analysis) provide high assurance and thoroughness but do not fit smoothly into lightweight developer workflows. - **Reframing the Four Core Questions**: Adapting Adam Shostack's four foundational threat modeling questions into value-focused developer questions: 1. *Why are we building this?* (Identifying business value, revenue, or safety impact rather than just re-analyzing known architecture). 2. *What needs to happen to make sure we achieve that value?* (Defining explicit conditions and failure states for success). 3. *How do we ensure those conditions actually happen?* (Translating security countermeasures into explicit functional assumptions, validations, and unit tests). 4. *Did we do a good enough job?* (Evaluating sufficiency within the agile retrospective). - **Embracing Useful Imperfection**: Embracing the aphorism adapted from modeling philosophy: "All threat models are wrong, some are useful."Douglen argues teams should lean into this reality by prioritizing immediate usefulness to delivery over unattainable theoretical perfection.
### Technical Details & Implementation Techniques Douglen outlines concrete integration points for developers within existing agile workflows: - **Baseline Knowledge & Threat Libraries**: Avoid wasting modeling time on standard code hygiene issues (OWASP Top 10 vulnerabilities like SQLi or XSS, or basic transport layer security) that should be handled by templates, baseline libraries, or training. - **User Story Integration**: Threat modeling occurs directly during discovery or sprint planning per user story/feature rather than as a standalone document. - **The "Without" Clause**: Adding a constraint clause directly into the standard user story template: *"As a [role], I want [action], so that [value], without [security catastrophe / loss of value]."* - **Acceptance Criteria & Definition of Done**: Embedding threat models and explicit security acceptance criteria (e.g., account lockouts after specific failed attempts) directly into user stories and automated unit tests. - **Abuser Stories & Value Piracy**: Reorienting abuser stories to protect core business assets (e.g., stealing customer orders/juice boxes). - **Threat Pyramids**: Prioritizing defenses logically—addressing high-impact risks (remote code execution, direct monetary theft) before lower-tier concerns (denial of service, spam). - **"Sorry Points" for Risk Escalation**: Using a relative risk-scoring mechanism ("sorry points") to measure how disastrous failure would be, helping developers determine whether a story can be modeled independently or requires escalation to security champions or dedicated specialists. - **Translating Vulnerabilities to Business Impact**: Communicating findings in terms of value (e.g., translating CSRF into "unallocated cash transfers" or authorization bypass into "diverted product shipments").
### Takeaways & Trade-Offs Value-driven threat modeling offers speed, scalability, native agile integration, and better alignment with developer priorities. However, Douglen acknowledges clear trade-offs: it does not produce complete threat models, lacks high assurance, and may miss subtle threats. High-consequence environments like banking core systems or defense projects will still need rigorous formal reviews. Nevertheless, for day-to-day agile development, empowering developers to perform imperfect, value-focused threat modeling is far superior to performing no threat modeling at all.
Related talks
OWASP Foundation·45 min
Presenters detail vulnerability discovery and exploitation in Developer-Centric Threat Modeling: Embedding Security in Agile Workflows.
OWASP Foundation·46 min
Engineers explore architecture and security mechanisms for Threat Modeling Developer Behaviour: The Psychology of Bad Code.
OWASP Foundation·48 min
AI Solutions
Challenges examines Automating Threat Modeling.


