Ask HN: Why hasn't Threat modeling picked up like DevOps/DevSecOps has?

[arunsivadasan]

Why hasn't the industry embraced threat modeling development inspite of many frameworks available? While DevOps (and DevSecOps) has gained traction? Even within companies that claim to practice DevSecOps, threat modeling is often ignored.

What is HN's opinion on this?

This CMU post lists 12 different Threat Modeling approaches: https://insights.sei.cmu.edu/blog/threat-modeling-12-available-methods/

[jonahbenton]

Threat modeling is in the "best practices" Neverland between the necessary pillars of getting code to production (DevSecOps, the sneaky rebranding of the Dev-Ops conversation to include someone from Security) and satisfying auditors (re various compliance regimes, that are broken down to specific evidentiary controls, many of which are to attest to specific threat model principles like non-repudiation).

Threat modeling can help indirectly with both getting code to production securely, and satisfying auditors, but it's neither necessary nor sufficient for either, so rarely makes sense for a company to practice themselves.

Instead there may be an aspect of threat modeling carried out by a third party pentester, but mostly what that will do is raise the direct cost of the pentest and maybe lead to more expensive remediation costs as well.

One can look at fuzzing- architectural as well as endpoint- as an actual automatable, codeable DevSecOpsy activity that is kind of distilled, operationalized threat modeling. Eg automatically build a fuzz plan from Terraform as well as as from OpenAPI schemas. It needs a clever name.

[motohagiography]

Developed a failed threat modelling product, some of what I learned:

- companies want to be told by a 3rd party what their threats/risks are for liability and insurance purposes. Doing it themselves might be accurate and make things better, but it doesn't add value by transfering risk to E&O policies of consulting firms who provide the advice.

- many of the risks threat modellers identify are risks product managers are tacitly taking and managing onto users and customers and other counterparties. Security people are often playing chess against poker players, where security people idealize a perfect information game, and managers create value through imperfect information games. Threat modelling increases information but not necessarily value.

- the threat model is the contra case for the business model. e.g. what happens if an assumption or a business factor fails. the real business models of software are often secret from the developers. Until you have established PMF, nobody actually knows what the business model will be anyway, so submitting to a threat scenario discussion prematurely problematizes solutions and can create fatal disalignment on the team.

- if you tell everyone the risks, some of them are going to defect from the team and use them as leverage in local struggles.

- the threat scenarios discussion is a forcing function in dynamics that need to be sustained to get value from them. e.g. do you solve this existential design problem, or do you launch/deliver a feature to get your next round to survive and then grow your way out?

- knowledge is liability, and creating a paper trail of who knew what when in a threats exercise can be disruptive in a lot of orgs, particularly government.

That's the short list. I actually use threat modelling myself in my own consulting work, because the other thing I learned is that in security, the threat model defines the product. What does your tech do? It mitigates threat-X.

What I had really built in my threat modelling scheme was a security product idea generator meets fridge magnet poetry, where each threat scenario and mitigation feature it generated were potential products themselves.

I like threat modelling, it's important, but it's a kind of luxury I don't think the vast majority of teams can apprehend.