Lean Developer Friendly Threat Modeling

The talk starts by questioning the data flow diagram approach to threat modeling, using a Microsoft-style diagram as the example. The speaker argues that STRIDE-style enumeration produces long lists of low-value threats, such as a file system being flooded or an OS process being spoofed, that barely affect the business. Completeness is out of reach anyway, because a system cannot be fully reasoned about, so repeating the exercise with different people will never yield identical results.

The middle of the talk proposes flipping the starting point. Assets should be the business outcomes an organization depends on, such as compliance standing, perceived reliability, subscription revenue, or trust in its stated values, rather than servers or keys. A threat is anything that reduces the future benefit from an asset, and a control is any response that lessens that loss. Developers identify the assets and the failure scenarios they worry about, while the security professional checks whether the assets are real, whether the threats are reasonably complete, and whether the controls make sense. A worked example breaks a user data confidentiality asset into a credential leakage threat, with controls such as prefixed and randomly generated credentials.

The closing point is that the security team's role should shrink to facilitating conversation and validating that tracked controls stay in place. Red teamers can add newly discovered threats to a shared control baseline, and blue teams can then address the gaps they reveal. The takeaway is that threat modeling is a repeated, subjective brainstorm rather than a checklist, unless a system is simple enough for formal verification.