A good threat model does more than tell an organization how adversaries will attack their systems and assets. It can also identify previously unknown vulnerabilities, gauge how much risk a company is incurring, allow war gaming of different security scenarios and estimate the collateral effects of different mitigation strategies in advance, instead of on the fly during an ongoing attack.
But companies can’t reap those benefits if they don’t have a model in the first place, or if they develop one under the wrong conditions. And many don't: A 2019 survey conducted by Deloitte found that just 47 percent of c-suite leaders said they are doing threat analysis and modeling at least once a quarter.
That risk has led a group of 15 security and privacy researchers to band together in order to publish a new manifesto designed to guide organizations on their threat modeling journeys.
It started out as an idea kicked around by a small handful of researchers back in June, who then slowly brought other contributors onboard to a working group. While each member brought their own background or approach, they were connected by a common frustration in observing organizations struggle to implement coherent and relevant models. Other entities sometimes do the work but end up creating a faulty product because they lost sight of what they were expecting to get out of the exercise, or never bothered to ask in the first place.
“We’re all having struggles in getting threat modeling adopted for it’s true value,” said Alyssa Miller, a security researcher who was part of the working group. “At its core, we wanted to help enable people by showing them…what threat modeling means to them and then showing them how to achieve that value.”
The manifesto itself is short, approachable and deliberately written in plain english. Several of the authors said they took pains to avoid technical jargon normally used in information security literature that might undercut one of their primary goals: signaling to c-suite executives, developers, managers and other within an organization that this an issue that also affects them and requires their input.
All threat modeling, the researchers argue, essentially comes down to an organization attempting to answer four straightforward questions about itself: What are we working on, what can go wrong, what are we going to do about it and did we do a good enough job? They’re all essentially business questions that can be answered without an advanced computer science degree. Which speaks to the point the researchers are trying to make: a threat model that can’t be understood outside of the security team doesn’t make you safer.
“Traditionally threat modeling has been this big, onerous, really heavy weight methodology where you had to create all these diagrams and use all these frameworks and people just thought it was really tough and associated it with security,” said Miller.
Companies that hand off all their threat modeling work to the IT security team without a larger organizational buy in are missing the point since that siloed approach often leads to “just stumbling against everybody else [in the organization] wondering ‘why are we doing this thing and why is it in our way?” said Brook Schoenfield, a security architect and author who was also part of the working group.
“People who study threat modeling and attacks and defenses, and how these unfold, bring something really important to the table, but even people who are talking to customers need to understand what threat modeling is and why it’s important,” said Schoenfield. “The managers and executives who will have to pay for threat modeling – as opposed to delivering a feature that maybe can more obviously generate revenue – needs to understand why threat modeling is important.”
The document itself is surprisingly agnostic about the specific methods an organization must follow, with the authors stressing to SC Media that they did not set out to create a prescriptive, step-by-step “how-to” guide on threat modeling. Instead, Miller said the group wanted to lay out high-level values and principles that an organization should keep in mind as they set up their own modeling. Most importantly, they wanted to focus on illustrating the benefits an organization can reap from good threat modeling and how it can protect the business.
In fact, it’s sometimes more specific about what organizations shouldn’t do. The manifesto advises companies to avoid pitfalls or “anti-patterns” in the threat modeling process that routinely set back an organization’s security posture, like the desire to create the “perfect” model, articulating security holes without defining potential solutions and creating a model that only other technically-minded security employees are capable of parsing.
In keeping with the group’s aim at a more general business audience, the values are also relatively straightforward. They include things like instilling a workplace culture where fixing problems – not compliance – rules the day, emphasizing people and teams working together over the implementation of flashy new tools or technologies and continuously updating or tinkering with that model as new information becomes available.
If that sounds a bit like agile development, it is. The group generally endorses the use of an agile development process and believes its iterative, cyclical philosophy of constant evaluation and improvement fits well in the threat modeling space, where too many organizations tend to settle for a static snapshot of an organization’s security needs, frozen in time.
That broadly tracks with the way IT teams are increasingly adopting agile principles in their security work. The same Deloitte survey of executives predicts that “as the DevSecOps trend gains momentum, more companies will likely make threat modeling, risk assessment and security task automation foundation components of product development initiatives, from ideation to iteration, to launch, [and] to operations.”
“One of the common misconceptions about threat modeling is that it’s like this big chunk you need to do and it takes a lot of time and then it’s done,” said Kim Wuyts, an academic privacy and security researcher at Belgian research university KU Leuven and another contributor the working group. “That doesn’t fit into agile or DevOps [which is] a continuous thing, a journey.”
