Nahuel Beni’s Blog

This is the third post on a series of Threat Modeling post, previously I wrote about Information Gathering and The Modeling Process. On this opportunity I’d like to introduce you to a very useful tool provided by Microsoft, the SDL Threat Modeling Tool.

Creating Architecture Diagrams

Using Visio’s engine, this tool helps us in the process of creating Architecture Diagrams.

So, let’s take as an example, a simple system in which we have a SQL Server, a Web Page and the user which uses the page.

(This is a simplistic scenario specially thought for this example; it does not in any way suggest a way of designing or programming)

First, identify the components of the solution. In our example, we have The User/Browser (External Interactor), the Web Page (Process), and the SQL Server (Data Store).

(Let’s assume we have gathered all required information following the steps described in my previous post and move to using the tool, threat modeling)

Modeling with the tool is quite simple, just drag and drop the elements in the canvas (Visio-Like) and then join with the flow arrows.

Identifying Threats

The tool automatically generates “threats placeholders” following the STRIDE Chart, mentioned in my previous post, for each component and flow of the diagram. It also provides us with some tips to identify those threats.

NOTE: The tool also has TFS integration, so you will be able to open a bug (see “file bug” in the screen) directly from the tool.

At this point you should complete the placeholders for each element with the corresponding threat, or certify there is none for it. I’ll add one just as an example.

Let’s suppose that the webpage does not parse the user/password requested in the login. Then we have a SQL Injection Threat (could be either Tampering or Information Disclosure depending on the solution.)

At this point, we should file a bug, and, once the bug is closed, update the threat model with the corresponding mitigation.

There’s a lot more to investigate, I leave that to you

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

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.

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.

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 !

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.

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.

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

• Sysinternals – Process Explorer
• Sysinternals – TCP View
• Sysinternals – Process Monitor
• Wireshark

Related Links

• http://msdn.microsoft.com/security/securecode/threatmodeling/acetm/
• http://msdn.microsoft.com/en-us/library/ms998408.aspx

Recommended Reads

• The Art of Software Security Testing
• Threat Modeling (Microsoft Professional)