Share via

Introduction to Threat Modeling

  • Article

Part of my work at Microsoft is ensuring that we get a high quality threat model tool out to the public.  I want to take this post to introduce developers and architects to the idea.  Using the beta version of the SDL Threat Modeling Tool v3 located at https://msdn.microsoft.com/en-us/security/dd206731.aspx, I created the following diagram.  You can do this with any drawing tool, but using the SDL tool is much easier and much faster.  Note that what I am going to discuss might deviate from the official tutorial and introduction articles since this is my own perspective on threat modeling.

Here, a credit card user gives his card to a POS(point of sales) device, which then gives the card number and amount to be deducted to some credit card database system.  The system either deducts that amount and tells POS deduction succeeded or tells POS the deduction failed because the limit has been reached.  Finally, POS produces a receipt.  In between the user and the POS, we have the dotted red line, which is a trust boundary, marking the fact that anything could come from the user side, and our system to the right should take that data with a grain of salt.

What I am describing is not a software system, traditional targets of threat modeling, but a common physical and software system that exists in the real world.  It will demonstrate the idea of threat modeling nevertheless.  Given the system above, what are all possible attacks?  If we have a list, then we can go step by step and check each of the items off the list to prevent all possible attack against the system design.  Note that this is not a claim against 0 vulnerability system.  Vulnerabilities can still exist in the implementation.

An example. The card number going from the user to the POS can have following threats against it.

  • Tampering.  Did the cashier at any point change the number?  How do we verify that the card number handed by the user is the one entered into the system?  Do we require user confirmation?  This is probably not a big threat in the real world since people wouldn't mind if cashier used the wrong number.
  • Information Disclosure.  Can other people read that numbers off the card?  Information disclosure is when the information can be read by an unauthorized party.
  • Denial of Service.  Is there a way for the person to quick swipe his card at a POS 100 times in a row and cause the POS to crash?

If you entered the above system into the SDL Threat Modeling Tool v3, these threat types would automatically be generated by the tool.  All of a sudden, we have covered 3 different types of attacks possible against our card number and POS.  There are of course more, but for the purpose of this post, I've only looked at that small portion of our system.  Using this methodology, we can solve a lot of security risk at design time!