September 01, 2005
High Level Network Threat Modeling
Threat modeling has been a hot topic in the last year or so. Microsoft has an entire center of information on the topic, ranging from threat defense webcasts to pointers to an excellent book written by Frank Swinderski and Window Snyder and published by Microsoft Press descriptively called "Threat Modeling". (Great book btw... here is my book review on it)
Some of my favorite articles include two from Peter Torr on the subject, the first being on "High Level Threat Modeling" and the second on "Guerilla Threat Modeling". What's interesting though is that all the information out there is focused on using threat modeling to write secure code. It is focused on finding threats to applications, which sometimes may include network access, but rarely goes past that.
With permission from Peter to format my thoughts in the same manner he did in his first article, I thought I would talk about how you can apply the same basic principles of threat modeling to analyze the risks that exist on your network infrastructure. The following is my take on "High Level Network Threat Modeling", borrowing HEAVILY from Peterís original thoughts:
Suggested Network Threat Modeling Process
This document outlines a suggested threat modeling process for "network operations" teams. It is designed to assist network operations in building high-quality threat models of their network infrastructure without turning everyone into a "security expert" and without overly taxing the resources of existing "security experts" that may exist in the team.
The process consists of six (possibly repeated) steps, outlined below in more detail:
The head network administrator and his team, thinking like an adversary, identify Entry Points, Trust Levels and Assets of Interest. The team builds a network topology diagram of all primary systems with assets of interest and uses this information to build one or more data flow diagrams (DFDs) showing how data assets move around the network. They also identify all known consumers of the systems identified and which entry points these consumers use to access the assets on those systems.
In this phase, the network operations team works from the network topology and data flow diagrams to perform a STRIDE-based modeling against the network. This will identify the threats against the assets on the network, and highlight any possible weaknesses or vulnerabilities that need to be addressed.
After the brainstorming session, the head network administrator takes all the ideas generated from the meeting and organizes them into a Threat Model document as appropriate. This document will contain the (potentially updated) DFDs, the entry points, trust levels, catalog of assets of interest, and all identified threats along with their mitigating factors (if any).
After the threat model has been drafted, it is subjected to a normal review process like any other document. At this stage there may be minor (cosmetic) changes required to the document, or it may need to go back through a more thorough drafting phase. In the worst case, where a fundamental assumption is shown to be false or some other deep issue invalidates the work done so far, the process may need to go back to the original Preparation step and be repeated.
Once the threat model is reviewed, the network operations team updates existing network test plans and augments existing vulnerability assessment and penetration tests to verify assumptions made in the brainstorming phase and to perform directed testing on identified weaknesses.
Based on the review, the head network administrator makes final edits to the threat model and publishes it (including all diagrams, results from vulnerability assessments and penetration tests etc) to the network operations team. The network administrator also logs findings for investigating and fixing of potential weaknesses in the network topology that were identified during this process.
If you have read Peter's original article, you will find I pretty much plagiarized the whole thing. THAT'S THE POINT! Threat modeling is NOT about finding bugs in software. Threat modeling is about identifying risk by understanding the threats that an asset is susceptible to. Without knowing that, you can never build secure systems. Be it software applications, network topologies or physical security defenses. In this case, applying threat modeling to your network will allow you to identify risks to your organization by understanding the assets an adversary may be interested in, and how you can protect those assets with technical safeguards and security policy strategies. Remember that in the context of threat modeling, a threat cannot exist without an adversary having an interest in an asset. The goal in the threat model is to identify what threats exist, and identify mitigating strategies that can be put in place to lessen the impact and therefore lessen the risk to your business.Posted by SilverStr at September 1, 2005 01:15 PM | TrackBack