I talk to many people about threat modeling. All the time! Invariably, an idea pops into my head about about ways to streamline things, or make them more concrete or usable. Just recently, I scribbled down some notes about threat modeling. I assume you have read Ch4 of Writing Secure Code 2nd, or the Threat Modeling book.

<ramble>

  • From threat trees: the goal of a good pen-tester is to find other conditions in the threat tree; pen-testers should have access to all the existing trees, and then you say, “here’s a starting point – find other conditions”
    • I wonder if there is a systematic way to find other tree conditions, or at least some heuristics to apply?
  • Developers can help define attack surface reduction. When reviewing code, you should identify all the anonymous threat paths. A large number of said paths means you may have an over-large attack surface. Hence, consider reducing the attack surface by limiting access to the code using authentication or authorization.
    • Every anonymous path should have a note saying WHY it must be anon!
  • Depending on the attacker, most denial of service threats against data stores and data flows are NOT against the data store or data flow, but against the processes at either end of the flow or store.
    • Sure, you could put a pick-axe through the fiber-optic cable, but that’s sabotage, not a hack. It’s a real threat, but perhaps out of scope for many people!
  • I’ve really come to the view that attack surface reduction is just as important as getting the code right. Developers will *NEVER* get 100% of the code 100% right. Ever! Because we can never know everything, especially when the scope of possible defects is not totally known. Why? Because the landscape is constantly changing.
  • Privacy issues are a combination of Info Discovery threats and the nature of the data (PII etc)!

</ramble>