Threat modeling: mandatory or nah?

I’ve found very little success in making “requirements” for developers. To be honest, they can slow down velocity, especially if the inputs, expected outputs, and overall practice hasn’t been defined. 

However, it can be useful to work up to making it a requirement, especially in regulatory environments. This can be useful if the Threat Modeling processes are practices and offered by platform teams as part of their onboarding, in lieu of things like a CAB - if some of the CABs functions can be subsumed into the Threat Modeling process. This requires cross collaboration between stakeholder groups, and potentially cross-vertical buy-in, which can be its own challenge. But, over all - enabling each team to practice Threat Modeling is much more sustainable than requiring each team to practice it.

Offering an internal Threat Modeling training program - where a core group of evangelists are helping train Threat Modeling facilitators - and pairing it with Visible Threat Models to stakeholders, helps create a culture where it’s less a matter of mandate, and more about an encouragement to participate and grow the skillset within an Organization.

Interesting conversation. It recalls me an article from Adam Shostack: NIST Brings Threat Modeling into the Spotlight (darkreading.com).

Personally, I am convinced that in most situations it is not possible to adopt Threat Model for every project, at least during the initial phases of the adoption. And even when the organization is mature, it makes sense to have different processes, to account for factors like:

• Risk levels of the application (Exposure, type of data managed, etc.)
• Business sensitivity
• Project size

For example, for big, important projects I would adopt a more thorough and structured process, while for smaller projects representing a limited risk, I would be happy to adopt an Agile process cutting most corners: a simple brainstorm involving some expert for a couple of hours may be enough, for many of those situations. The simplest projects may even be exempted from doing Threat Modeling.

Most importantly, I am a little scared by the possibility of considering Threat Modeling as a Compliance requirement, because most of the times it becomes in turn a Compliance process. I’ve seen it in various organizations. The result is that the cost of the Threat Model increases, while the produced value declines. Business Decision Makers are sensitive to those situations, and I’ve seen more than once this leading to increasing resistance.

I think that we should instead work to make the Business want Threat Modeling done. This can be achieved by providing them the information they need to make decisions and be successful, while at the same time decreasing the required effort to reasonable amounts. In that sense, differentiating the practice may pay dividends.

The ‘what do we mandate’ is the critical piece (IMHO).

The approach that we’re taking is mandating threat modeling - but in some respects leaving it to teams to determine what level and/or process makes most sense for them. Some will do a high level system diagram and use the 4 questions; others will create elaborate spreadsheets and argue for hours over DREAD scoring - but realistically, I don’t care - as long as they are threat modeling.
Through discussion and review of models+approaches, the teams will (amongst themselves) agree upon what’s best - giving them ownership of the process (resulting in a longer term acceptance).

Maybe that needs to be another anti-pattern in the manifesto:
Fixation with doing Threat Modeling “correctly”

In my experience, this is exactly what kills threat modeling in an organization and results in

(1) Teams fearing failure of “not doing it right”.
(2) Businesses obsessing over measuring outcomes 

Maybe the problem with #2 is that the term threat modeling requires explaining?
If you described it as “Identifying, mitigating and/or remediating issues that could cause serious problems to us or our customers”, would people put as much scrutiny around explaining the value of doing it?
And in turn, would mandating it (when described that way) result in people/managers going “Well that just makes sense”.

My 2cents 8-).

Compliance requirements sometimes turn into checkboxes for teams instead of value added processes that inform on and reduce overall risk. I would advocate for a cultural requirement around the value of threat modeling that is communicated often, demonstrated vertically and horizontal across the org, and rewarded as a valuable part of the security ecosystem. 

Doesn’t hurt to make it a compulsory item but it should stop at the policy and procedural level. 

I inherited a programme where the past administration had mandated that “every change be threat modelled”. Further, when asked by development teams how to threat model, that administration told developers explicitly that threat modelling was strictly the province of security architects working in product security architecture. Too sensitive for mere developers. (true story!)

In my very humbled experience, mandates never work. At least in software security, I’ve never seen mandates work all by themselves as the “solution”. The mandate is just the starting point or the fallback.

If my only tool to gain developer execution is the mandate, I believe that I have completely failed.

Forcing people to do things via fear and punishment does not foster creativity and innovation (supposedly, what we are trying to do with our software). Mandates alone just make people figure out ways around the mandate. Not what I want. Mandates may make those who issue them feel effective? but human systems do not work that way. And particularly, delivery that counts upon craft and analysis (i.e., programming) is particularly resistant to command and control techniques.

I’m not saying we shouldn’t have policy and constraints, that we shouldn’t specifically call out what must be done. That’s what the Security Development Lifecycle (SDL) is for. It’s just that this is just one part of a whole - and must not be mistaken for ‘the programme”.

In the role I mention above, I had to dig myself out of the hole that my predecessors left me in. I had to regain developer confidence and partnership, which took a lot of doing, proving, and a whole lot of travel (usually in coach. ugh). I didn't appreciate that hole, I can tell you.

Mandate that threat modelling is a critical and required part of software security (the SDL). That said, make it real: not every change affects the model. Many changes have little to zero security implications. Smart engineers understand this.

At the same time, make clear what sorts of changes will require review of the existing model. Review is a lot quicker and more discreet that building a brand new model. If there’s already a model, why rebuild it? threat models are living documents. (My last 2 books and many of my public presentations describe what those threat modelling triggers are, probably in far too much detail.) 

One of my techniques is to be the expert in the sorts of things that will build appropriate, robust software security. At the same time, how we collectively do those is nearly always a matter for those who do the work, not me sitting in my high tower of supposed (perceived?) authority. There are many effective ways to threat model. Like @Adam Shostack noted above: I don’t care how folks do it, as long as they do it, and get better through whatever process works for them. Remembering that nothing is perfect in security. Certainly not me.

There’s an old dictum: “those who work decide”. I do my best (in my limited capacity as a human being) to follow that bit of advice.

Sure - like it or not, ARBs are not going away in large IT shops, so as long as they’re there, we might as well co-opt them as we can to improve software security.  I’m a big fan of reuse, including legacy committees or boards or however people decide to review new work.