Pragmatic Threat Modeling

Lately I have been doing training around the Microsoft prescribed threat modeling practice.  Today, in providing such a training, I realised the majority of my work has been focused around “what” the components are, but not as much about -how- to actually do a threat model.

To that end, I hereby offer some more pragmatic tips around the actual practice of threat modeling.

Not all Entites are Created Equal

All the world’s a stage, And all the men and women merely players: They have their exits and their entrances; – William Shakespeare

In the world of threat modeling we like to identify and quantify “things”. These things range from, assets, actors, data sources, data flows, to processes and roles.  The purpose of knowing what types of entities these things represent is simple; Every entity represents and inherits different types of risk. Additionally, How and why entities talk to other entities represents risk.

In order to document entities and their relationships in a given context, Microsoft prescribes the usage of Data Flow Documents (DFD).  These DFDs are only a small handful of entity types that they’ve found describe the various “things’ inside of their systems.  Specifically they include; External Entities, Process, Data Store and Data flow.  A custom item to DFD is the red dotted line which represents where data is sent from one trust location to the next.

A simple data flow might look as follows:

Given the above, you can see how a user requests a login, the servlet passes the request to a login process, the login process authenticates to the database, and then flows backwards to the user who requested to login.  So far, this should be pretty straight forward.  But you might be wondering, okay after I created this how do I figure out what vulnerabilities I need to mitigate?  This is where the rubber hits the road.  Or, in other words, where the design hits STRIDE

What it Feels like

STRIDE is a classification system that Microsoft uses to identify risk types.  It stands for, Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Escalation of privilege.  By default, by simply BEING one of the aforementioned entity types, you inherit risk. For instance, by simply being an external entity, you inherit the risk of being spoofed and needed to be proven (repudiation) as that item.  On the contrary, data that is in transit (data flow) might be tampered with, read by someone who shouldn’t, or may be denied access to even work.

In Oct 2007 Microsoft released a diagram that better shows how that might look:

Keeping your Balance

  • Using the STRIDE element diagram buys you some immediate traction on how to start looking at a DFD and making some informed decisions.
  • Risks will further vary by understanding the actual type of element of each element, that is; a process which is a .dll will have different risks then one that is a windows service. Both can be spoofed, but the way in which spoofing could happen is different.
  • The chart above was designed for Microsoft and it’s needs.  Build one for yourself to help YOU understand YOUR problems.
  • The more experience your team has in security the better you will understand the various risks and threats to each element by it’s type.

* DFD image is borrowed from OWASP (http://www.owasp.org/index.php/File:Data_flow2.jpg)
* STRIDE image is borrowed from SDL Blog Article (http://blogs.msdn.com/sdl/archive/2007/10/29/the-stride-per-element-chart.aspx)

Advertisements
Post a comment or leave a trackback: Trackback URL.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: