Threat modeling: mandatory or nah?

Management
1

Original post by @joshdub

I came across an article that I can’t seem to find again. It asked if threat modeling should be a mandatory practice. We might all want to agree that it should (as we are a threat modeling community). However, I don’t believe the answer is binary. I think there is a spectrum that the answer lies on, and every organization has its point on that spectrum that they will be at that will evolve at some rate.

I’d love to discuss everyone’s thoughts on this subject. Maybe a specific practice worked at one place but didn’t work at another.

Also, something I think is interesting. Does trending threat modeling toward being mandatory help define a mature threat modeling process?

2

Original post by @Hoss

I think the compliance conversation is really interesting. We all see value in threat modeling, and we want teams to adopt the practice and see first hand the immense value it brings. One potential path to adoption is compliance, such as adding threat modeling as a required step in an SDLC or similar framework. I see this as a kind of lazy approach, but one that some teams may feel they need to execute on due to their small size or lack of resources.

I’m not totally sold on the compliance approach, but lets take a look at how this may be implemented.

If we want to take a page from some of the large and well known compliance requirements (NIST, HIPAA, PCI-DSS, etc) we know that there is a base control/standard. These controls also have enhancements to augment the control to bolster the control strength or assurance. I wonder if there is a way to ensure that threat modeling is considered a standard approach, but when an application, system, process, etc is deemed critical we have a series of enhancements to ensure that threat modeling is done in a more mature and frequent basis.

I am interested to hear other’s opinions and successes through both approaches.

3

Original post by @Jono

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, overall - 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.

4

Original post by @EricWHart

Like @Jono, I found that making it something that is a requirement is not especially easy, even in a regulated environment. I’ve spent the past 5+ years in healthcare and it’s not a simple and straight-forward issue. When backing healthcare up against a standard such as FHIR or HL7, it’s easier because the ‘bad guy’ is the regulation authority and not the security team.

The few use cases where velocity wasn’t affected came down to narrowing the scope to a few things:

  1. Focus on applications, microservices, etc., that handle sensitive data that is deemed critical to the business.
  2. Don’t “boil the ocean” and insist every component undergo TM. Instead focus on the edge and most vulnerable components first, making sure the backlog is groomed and current, then move on to the remaining components.
  3. Employ a “Systems Thinking” mindset and getting to the “whole of the system” instead of individual microcosms.

So to answer the question should it be a matter of trending, the solution, in my humble opinion, is to get that first step under the team’s belt, so to speak, then support a regular cycle of maintenance to the threat model(s) as a best and regular practice.

5

Original post by @simonec

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.

6

I’m 100% with @Jono, but wanted to address one part of @joshdub’s question, “Does trending threat modeling toward being mandatory help define a mature threat modeling process?”

I think the flip is more true - maturing a threat modeling process makes it easier to make it part of what engineers expect of each other, and once it’s expected, we can decide if mandates are appropriate.

Another part of this is that I’ve said that just asking the Four Questions is threat modeling, and so perhaps a implicit part of your question is ‘what do we mandate?’

7

Original post by @nznigel

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-).

8

Original post by @Hoss

I really like where you are going, but I just do not have faith in organizations (especially large or highly regulated) to actually carry this out well. I’ve come across lots of processes with the same goal, but rarely are they as effective as they could be.

I’m not sure how to drive this change or level set these high expectations across the board, but I guess the best way to start is taking small steps.

9

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.

10

Original post by @markmerkow

When a new project or significant enhancement project comes before the Arch Review Board, the initial review helps to determine if threat modeling would add value to the process as it’s being designed. Based on the complexity, newness, or ability of the team to actually describe what they’re wanting to do leads to a common decision rather quickly whether to threat model or not.

11

Original post by @brookshoenfield

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 @adamshostack 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.