Outcome Oriented Security
summary
Argues for a six-step threat-model that goes from actors assets and actions to hazards via data-flow diagrams use cases and hazop analysis, producing concrete security objectives that enter requirements. Recommends the Trike tool and shows how modeling finds workflow and business-rule bugs before code. Pushes an assume compromise posture: detect notify recover, prefer heterogeneity, and remove whole classes of low-level bugs in frameworks so deployed systems actually work.
AI-written summary · about
chapters (12)
- 0:00Start
- 1:07What is Security?
- 2:14What is a Security Objective?
- 3:17No one actually writes security objectives.
- 4:39What is a Threat Model?
- 7:48How do You Make a Threat Model?
- 15:41How: Failure Modes and Mitigations
- 17:30No threat model, no idea what security means Detect issues at the business rules level
- 26:19Outcome-Oriented Security, You, and Your Customer
- 30:58Usability and [In]Security
- 36:50The Exception: Bug-Class Killing and Platforms
- 38:21Your Responsibility to the Internets
related talks
18mDesigning for Security Outcomes
39mValue driven threat modelling - security by design
22mEmpowering Developers through Threat Modeling Excellence
43mThreat modeling
35mValue Driven Threat Modeling
57mUnlocking Threat Modeling
50mThreat Modeling With Architectural Risk Patterns
57mWhat Could Possibly Go Wrong? Plain Language Threat Modeling in DevSecOps
