I found Adam Shostack’s paper Experiences Threat Modeling at Microsoft in my bag tonight. Goodness only knows how long I’ve been totting it around. It’s a nice little behind the scenes look at how the empire analyzes its code for security issues. Here are the nuggets that jumped out at me (most of which apply to things outside of security).

  • The term “threat” is used to mean both ‘threat-agent,’ that is, the person attacking a system, and as a risk, that is, what might go wrong.
  • Threat modeling can be asset-centric, attacker-centric or software-centric.
  • There are at least two reasons it may make sense to perform threat modeling without experts. First, experts might not be available because they are in short supply for financial or other reasons. Second, having the people who will build a system – not all of whom are security experts – involved gives them a sense of ownership and an understanding of the security model.
  • There is no single “best” or “correct” way of performing threat modeling, but rather, a complex and multi-dimensional set of tradeo?s which might be made in order to meet a some set of implicit or explicit goals.
  • Cost includes getting started (training, setup, software) and ongoing time commitments within a project.
  • Methodologies evolved, and they evolved and continue to evolve in response to needs we discovered as we worked
  • Current SDL threat modeling methodology is a 4 step process: diagramming, threat enumeration, mitigation and verification
  • Use standard Data Flow Diagrams (DFD), with the addition of “trust boundaries”
  • Microsoft often uses ‘feature crews’ of developers, testers and program managers who are very focused on their feature or features.
  • STRIDE
  • One of the anonymous reviewers asked for evidence that ‘the approaches taken are the right ones.’ I make no such claim. I do claim that the approaches are useful, for the challenges that we have identified and which I have discussed. In light of the many meanings of threat modeling and the many goals which processes may serve, I don’t believe that there is a right or wrong approach, only ones that are more or less useful.
  • DREAD
    • Damage potential: How great is the damage if the vulnerability is exploited?
    • Reproducibility: How easy is it to reproduce the attack?
    • Exploitability: How easy is it to launch an attack?
    • Affected users: As a rough percentage, how many users are affected?
    • Discoverability: How easy is it to find the vulnerability?
  • A failure to effectively model people leads to problems
  • Clearly state your expected user and their skillset [of your threat model]
  • Design explicit development integration points for the security modeling methodology. The integration points may seem obvious to the designer, but might not be to someone learning the system for the first time.
  • Processes which can be used by any intelligent and skilled engineer will be more broadly used than processes which require unusual skills.
  • Ease of use and clear documentation are important, and often receive little attention, even in work labeled “practical.”
  • Data is not generically trustworthy, it’s trusted for some set of purposes. Defining that set of things is easy for small problems, and seems to be hard to generalize