Archive for May, 2009

Threat Modeling – The Modeling Process

This is the second post regarding Threat Modeling. On the previous post I talked about information gathering before starting with the process of threat modeling per se.

On this second post I’ll explain that process in a theoretical way, and, on a future post, show how this can be applied using Microsoft SDL Threat Modeling Tool.

Threat Modeling Process

The threat modeling process has four main steps and it’s intended to help identifying those areas of higher risk within the application, and will also be useful for creating test cases on a future security test plan.

  1. Identify threat paths
  2. Identify threats
  3. Identify vulnerabilities
  4. Rank/prioritize the vulnerabilities

Identify threat paths

The first step is mainly summarized in my previous post, Threat Modeling - Information Gathering, the main objective is to identify overall threat paths (data flows and components) and gather knowledge that will allow us to define the threat level that each component or data flow has.

Identify threats

For each threat path, we should dig deeper on the processing done, and identify the threats of each individual process.

TIP: Useful questions we should address:

  • What processing does the component perform?
  • How does it determine identity?
  • Does it trust data or other components?
  • What data does it modify?
  • What external connections does it have?

Identify vulnerabilities

The next step is to identify the actual vulnerabilities for each component.

For this I use the “STRIDE” chart but any categorization should work if you adjust it to your solution/company needs.

image

TIP: A way of identifying these vulnerabilities is by testing itself (trying to break the system).

Rank/prioritize the vulnerabilities

Nothing that will require too much explanation here, the DREAD model is proven to be highly effective for this:

  • Damage Potential: How much damage could this cause?
  • Reproducibility: How easy can it be reproduced?
  • Exploitability: How much effort is required?
  • Affected users: How many/which users could be affected?
  • Discoverability: How easy is to discover the threat?

Then add up the results and the higher DREAD scores should come first when fixing vulnerabilities.

Hope you find this information useful; feedback and comments are always welcomed :) !

Threat Modeling – Information Gathering

In this post, I’ll explain the concept of Information Gathering, the first step for creating a threat model, and some tips to ensure the right data has been collected before creating the actual threat model.

 

Information Gathering

As said before, Information gathering is the first step to creating a Threat Model. During this process the following items should be identified:

  • Entry Points to the solution.
  • Assets to be protected from possible attackers.

For this process, you need to be certain that the whole solution is being considered (and not just a part of it e.g. the database,) a good way of doing this is:

  • Reviewing the solution diagrams.
  • Meeting with the architects of the solution.
  • Analyze the solution with debugger tools.

TIP: Documents may be out of date, so you shouldn’t rely on them

 

Output

The output of information gathering, as you may have already realized, should be a complete set of architecture diagrams in which the different components and data-flows are identified. Especially those that come from the outside (should be least trusted.)

 

Sketching the architecture diagram

The architecture diagrams should be based on the documentation that is already created for the solution (remember not to rely in documentation), and updated with all information that comes up after reviewing them, and meeting with the architects of the solution.

Once the architecture diagrams are created, it’s wise to check the gathered information with what actually happens in the solution, by doing some runtime inspection, also called application footprinting (this is where debuggers and external tools come in) which is intended to identify how the application receives input from the environment.

 

TIP: It’s important to identify what processing occurs on the data after it enters the system, to analyze validations, authentications, or any other security measures that should or must be taken.

 

At this point, you should have enumerated all the application’s entry points, noting for each one of them if it’s remote, encrypted, which protocol is using, which interface type it has, and if the interface has authentication and session management, etc.

 

Next Steps

On my next posts I’ll be describing the process of threat modeling per se, and the usage of Microsoft SDL Threat Modeling Tool.

 

Hope you find this information useful; feedback and comments are always welcomed :) !

 

You can find some useful resources below.

 

External Data Flows

  • Networks I/O
  • File I/O
  • Registry
  • Named pipes, shared memory, any OS object.
  • Windows messages
  • Others…

Useful Tools for Application Footprinting

Related Links

Recommended Reads