Threat Modeling and the SAFE Framework
My thoughts on an interesting blog post discussing how to bring threat modeling into the Scaled Agile Framework.There's an interesting and detailed blog post from Antti Vähä-Sipilä and Heli Syväoja at the F-Secure blog, Using SAFe® to align cyber security and executive goals in an agile setting.
What I find most useful is the detailed and specific elements of how to bring threat modeling into the Scaled Agile Framework, in particular:
- Security and privacy work need to be visible on backlogs.
- Don’t use non-functional requirements with security. The attackers will not care if you have valiant statements in your acceptance criteria. (👈 ❤️)
- Use different tools to answer the question what can go wrong. At the Epic Refinement phase, look for negative business outcomes; at feature refinement, developers can use something like STRIDE.
(The first two are direct quotes from their "key points" summary, the last is my restatement.)
The article also goes into very interesting detail about failings that they've observed, from 'Perceived barriers to threat modelling' to the importance of documenting risks that have no solution, to problems that result from centralizing work into security epics, and I don't want to re-state their points here, but rather build on them, by pointing out that most of what they have to say is not about the technical skills of threat modeling, but about the organizational discipline that's involved.
If only we had a framework for thinking about such distinctions!
Oh wait, we do! I published the Jenga framework earlier this month as a way of thinking about the organizational, technical and soft skills involved in threat modeling.
I hope that the F-Secure team will be sharing more specifics about and examples of how they're making attacker stories work (I regularly hear that they take too long), and also share the 5 question triage checklist they're using. (Although, I see them as doing threat modeling work, not 'knowing when threat modeling is needed.')