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:

1. Preparation
   
2. Brainstorming
   
3. Drafting
   
4. Review
   
5. Verification
   
6. Closure

Preparation

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.

• This task should take around two hours for a reasonably-sized network with a handful of primary systems of interest. Larger networks may need to be broken up into smaller subnets to make them more manageable, ensuring that trust boundaries between subnets are well defined.
  
• Network topology diagrams should include primary systems of interest, as well as primary network resources (routers, switches, firewalls, etc), and define who the owners/administrators are of those systems.
  
• A "Catalog of Assets" should be documented to ensure that all assets of interest are enumerated
  
• Actual threats are not enumerated at this stage; only the ways in which an adversary can interact with the assets.

Brainstorming

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.

• This task should take around 30 minutes to an hour for each primary system on the network that holds or accesses assets of interest. Additional meetings should be scheduled as appropriate if all avenues are not fully explored.
  
• The results of the Preparation phase (entry points, catalog of assets, DFDs, etc) should be made available to the brainstorming attendees at least 2 days before the session so that the meeting doesn't just become a walk-through of the DFDs.
  
• The existing documents (DFDs, catalog of assets etc) may be updated during the brainstorming session if new information comes to light, or if a particular system was overlooked.
  
• Administrators responsible for managing any systems of interest defined must be present at the brainstorming session to assist with the process, answer questions, and so on.
  
• All reasonable threats are enumerated at this stage, even those that already have mitigating strategies or that have been explicitly designed for. The point is not to just identify security weaknesses, but to document all known threats that the system must protect against, and how it does so.

Drafting

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).

• This task should take one or two hours, depending on the amount of the data captured in the brainstorming session

Review

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.

• This task should take one to two hours, similar to a normal spec review.
  
• The draft threat model must be made available at least 2 days before the meeting.
  
• The members of the brainstorming session should be present, during this review process
  
• Although the document may undergo cosmetic changes at this stage, it is not acceptable to merely patch it up if a serious hole is found in the document. The process must be re-started, and all assumption re-evaluated.

Verification

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.

• Although this phase can actually start after the brainstorming phase, it is recommended to not do so until the review phase is complete and all possible changes are documented.
  
• If necessary, external teams may be called in to help with penetration testing or other attack strategies if the details of a particular threat are not well understood, or if the mitigation strategies are believed to be lacking.

Closure

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.

• This task should take one to two hours
  
• Remember that threat modeling is never really done! New classes of attacks are always being found, and bugs in dependencies or changes that invalidate may manifest themselves as new vulnerabilities in the systems.

Epilogue

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