Partager via

Random Threat Modeling Thoughts

  • Article

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>

Comments

  • Anonymous
    September 07, 2004
    For the first thought, I think MS has enough internal data (threat models) developed across different app/product to create some 'expert rules' to automagically generate the threat tree to a certain degree. So far, the threat modeling defines how developers should analyze their app/product to create the tree, maybe a knowledge base should be built such that a model can be derived so when you say my app is in classification A, with CRUD functions here and there, then a threat tree can be generated. In order to do this, you can:

    1. Collect and classify current app/product that has existing threat models.
    2. Build knowledge base from such data to build the model
    3. Have threat modeling tool or other thing to refer to that tool.
    4. You can also record the feedback from developers as part of the data to adjust the model too.

    I don't have the data, but I think this is feasible. :)

  • Anonymous
    May 31, 2009
    PingBack from http://patiochairsite.info/story.php?id=319

  • Anonymous
    June 17, 2009
    PingBack from http://pooltoysite.info/story.php?id=2352