BruCON 0x06 - Keynote

### Overview In this BruCON keynote address, Adam discusses threat modeling principles and lessons illustrated through examples from Star Wars and software engineering experience. He emphasizes that threat modeling should be an accessible, systematic practice for everyone building or deploying software, rather than an esoteric skill reserved only for security specialists. The core goal is moving beyond ad-hoc intuition into structured, composable frameworks to find and fix architectural flaws early.

### Key Topics Adam centers threat modeling around four fundamental questions: (1) What are you building? (2) What can go wrong? (3) What are you going to do about it? and (4) Did you do a good job? To answer what can go wrong systematically, he introduces STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) using Star Wars analogies. He highlights ten common traps organizations encounter: 1. *Think like an attacker:* Demanding untrained builders to think like attackers fails just as asking amateur cooks to manage restaurant logistics does without structure. 2. *You're never done:* Depicting threat modeling as an infinite hamster wheel causes project managers to reject it; it must be unrolled into a manageable, linear schedule. 3. *The way to threat model is...:* Threat modeling is not monolithic. Composable building blocks like data flow diagrams, swimlanes, STRIDE, CAPEC, attack trees, or privacy frameworks (e.g., contextual integrity) can be combined based on context. 4. *Threat modeling as a single skill:* It encompasses distinct techniques (diagramming, threat identification) and accumulated repertoire. 5. *Believing threat modeling is born, not taught:* Like playing violin, practitioners need manageable exercises to build competence. 6. *Wrong focus:* Starting strictly from assets or attacker lists leads to confusion, omissions, and arguments. Focus instead on the system diagram and fixing issues. 7. *Believing threat modeling is only for specialists:* Like version control, baseline threat modeling should be known by every developer and sysadmin. 8. *Threat modeling in a vacuum:* Threat mitigation spans the entire supply chain and operations, requiring tools like early security operations guides and non-requirements. 9. *Laser-like focus on threats:* Threats, mitigations, and requirements interact dynamically. Often what changes over time (e.g., post-Snowden) is business requirements, not underlying threats. 10. *Threat modeling at the wrong time:* Modeling late (like analyzing an attack run in mid-battle) prevents effective structural changes.

### Technical Details Adam notes that data flow diagrams (processes, data stores, data flows) work well because threats follow data flows, while swimlane diagrams suit network protocols. Complementary frameworks include CAPEC for detailed attack catalogs, Dan Solove's taxonomy of privacy harms, and Helen Nissenbaum's contextual integrity model. Checklists have limited utility for covering known omissions (per Atul Gawande's *The Checklist Manifesto*), but cannot replace threat modeling novel software. He also addresses human factors, citing Daniel Kahneman's *Thinking, Fast and Slow* and behavioral conditioning to point out how dialog fatigue and UI indicator placement affect security decisions. For training, he highlights the *Elevation of Privilege* physical card game designed to gamify STRIDE modeling.

### Takeaways Threat modeling should begin broadly during initial design and deepen incrementally as specific components or sprints are implemented. Success is evaluated via QA testers and penetration testing feedback: if pen testers find bugs in areas predicted by the model, execution failed; if they find bugs outside the model, the modeling technique needs improvement. Organizations can see value in as little as an hour by identifying high-impact bugs early.