1/ While this article on threat modeling isn't bad, neither is it anywhere close to how I'd describe "threat modeling".
martinfowler.com/articles/agile…
martinfowler.com/articles/agile…
2/ It mentions NotPetya taking down Maersk, blaming nation-state malware that was weaponise. That's the wrong threat model. The correct threat model is lateral spreading through windows credentials with PsExec.
3/ Likewise, the correct threat model includes entry of NotPetya from the public Internet like historic worms, but from subvertef software updates and from partners over private VPNs.
4/ This reflects the most important problem with threat modeling: instead of expanding understanding to fit the real threats, they shrink the threats to fit what they understand.
5/ This then leads to the second most important problem: teams lack security competency to understand the threats. If nobody on the web team understands SQL injection then all that effort spent on threat modeling is just useless make-work.
6/ That's why so much threat modeling focuses on data flows, because it's grunt work that anybody can do without needing to understand the threats. But it's still only part of the way there, until you understand the threats, you don't really have a model for them.
7/ Instead of a threat modeling guide starting with process, it should start with the threats. Take DNS, for example. Everyone's DNS threat model is similar. You could write an entire book on "DNS threat modeling".
8/ For example, consider Epic Games and it's Houseparty service. It's DNS servers had records like …38-197-97-151.ms.thehousepartyapp.com to refer to an Amazon instance with IPv4 address 138.197.97.151.
9/ They stopped using the Amazon instance, but still had the DNS record in their servers. That meant hackers could get that IP address in their own Amazon instance, then bypass domain HTTPS security by using that address to deliver hostile content.
10/ The list of threats you have to understand is enormous. The various efforts to list vulnerabilities, threats, attack patterns, and so on is a good start (e.g. Mitre Attack framework).
11/ It's something large parts of the organization need to learn to avoid overly politicizing threats, either inconvenient realistic threats people want to ignore, or unrealistic threats that are conveniently exploited to promote internal politics.
12/ My point is this: start with actual threats you understand, and develop process to deal with them. Don't develop process when you lack understanding, hoping that the process will teach you.
