Better Taught Than Caught!
Informal training may work in some cases, but Threat Modeling skills should be passed on through more formal means.
So Chris Romeo has a blog post, “Threat modeling: better caught than taught” [link to https://blog.securityjourney.com/threat-modeling-better-caught-than-taught/ no longer works]. In it, he advocates for threat modeling being a skill passed on informally. And, like many things in threat modeling, that's attractive, sounds fun, and is utterly wrong.
Let's threat model this:
- What are we working on? Scaling threat modeling across all developers. (Cool!)
- What can go wrong? A game of telephone, where one person tells another something, and they pass it on. And we all know how well the last person gets the message. But it's worse than telephone: people will do web searches, and find all sorts of crazy advice, from "think like a hacker" to "develop a list of assets," or worse. And because they only sort of got what they were doing, and because we don't name and version our techniques, they'll end up with a scrum of continuously integrated ideas in their heads. And odds are that will be confusing.
- What are we going to do about it? We're gonna train, thoughtfully.
- Did we do a good job? We can tell using surveys; using tools to see if threat models are similar across teams. We can tell by dropping in and observing.
All that said, and teasing aside, Chris is right in much of what he says: diving in and threat modeling is a win. Asking leading questions is a helps people get to the answers. Learning by doing is the only way to learn. There's also a reality that some people come in with adjacent security knowledge, from which they can bridge to threat modeling. Others don't. The ones without that knowledge need more structure and more granular structure to help them learn. That includes proper labeling of what we're doing: DFD3, STRIDE, asset/attacker/technical centering. Without those labels, students are left struggling with 'what is this threat modeling thing you want me to learn?' Calling yet another set of steps 'agile threat modeling' hurts everyone, or at least everyone who uses a search engine for supplemental information.
He's also right that talking to developers about the relationship between STRIDE and PASTA is a mistake. They don't need to know about that. The threat modeling experts need to know about that. The security champs might need to know about that. In my core 201 class ("Threat Modeling for Architects") there's exactly one way to answer each question (DFDs (DFDv3, in fact), STRIDE, bugs, retrospectives). That class takes about a day in person and a week at a couple hours a day when it's delivered distributed. There's lecture, exercise and discussion to help ensure that the lesson lands well.
Good training involves carefully setting the stage for students to catch the lessons. It requires defining what you want a student to catch, what you're going to make them do to catch it. One of the first goals is the why: showing the students that threat modeling helps them find real problems quickly. When I train, I am to be showing that inside of the first 30 minutes. As Chris says, lectures on
Look, I have a bias for training. It's a big part of my business. Consistency doesn't happen by accident, and that's why you need a teaching and learning plan for your organization's security journey. And for those who don't know Chris, his company, Security Journey helps build culture. We share the perspective that culture is an important part of that journey, and having the last part of the "fan-out" be carefully designed "catching" of threat modeling can be a great plan.
Image from Derek Owens, on Unsplash.