• Illustration: Threat Tool Attack Library

A new tool aims to help IT architects identify business threats posed by security vulnerabilities in their software and gives guidance on effective countermeasures. Version 2.0 of the Threat Analysis and Modeling Tool, currently in beta, allows developers and architects to evaluate the potential threats contained in their applications by building a model of the application and comparing it with a library of known attacks. However, the current version of the tool is not integrated with any of Microsoft's Visual Studio modeling tools.

Key Components of a Threat Model

The Threat Analysis and Modeling Tool is based on the Security Development Lifecycle method (SDLC) that Microsoft developed as part of its Trustworthy Computing initiative. At the heart of the SDLC and the Threat Analysis Tool are four key terms.

A threat is the possibility of some undesired business effect. Examples of threats include loss of confidentiality (such as the disclosure of credit card information), loss of application integrity (such as incorrect price information being stored in a product catalog), and loss of application availability (through denial of service). Threats are exploited through attacks that take advantage of vulnerabilities in the software. Countermeasures are steps a developer or IT architect can take to prevent attacks from being successful or to mitigate the damage done.

For example, an online shopping site faces a threat that it could accidentally disclose customers' credit card information. That threat could be realized by an attack that sends specially crafted text inputs to the Web site in order to exploit a buffer overrun vulnerability. The developer of the site can use countermeasures, such as using programming languages like C# that make buffer overruns much less likely or reviewing the source code to ensure that user inputs are properly validated.

Building Threat Models

The Threat Analysis and Modeling Tool allows IT architects to describe how an application is built, to test various use scenarios against a library of attack types to determine potential threats, and to view countermeasures for potentially successful attacks. To use the tool, an architect defines the roles, data, and components that make up the application and connects them to use cases (scenarios) for the application. (For a screen shot of the tool showing the attack library, see the illustration "Threat Tool Attack Library".)

Roles can describe users as well as the services and components that make up the application. An e-commerce site, for example, might have user roles for registered users, unregistered users, and administrators, and service roles for a database and Web service.

Data not only describes the information stored and accessed by the application but it also defines which roles are allowed to create, read, update, or delete data. For example, an e-commerce site might contain a product catalog, a set of customer accounts, credit card information, and order history. Users in all roles might be allowed to read from the product catalog, but only administrators might be allowed to create, update, or delete information.

In addition, constraints can be applied to each data type. For example, orders could be read only by the user who created them.

Finally, each data type has an associated business impact that describes the gravity of potential threats associated with that data type. A product catalog, for example, would have a lower business impact than a credit card database, as attacks on the product catalog would be less damaging to the overall business than attacks on a credit card database.

Components are the actual implementation of the application. The tool supports several types of components, including thick-client applications, Web sites, Web services, and databases. In addition to specifying the type of component, the architect specifies the technology used to implement the component, choosing from options such as .NET Framework 1.1 and 2.0, SQL Server 2000 and 2005, and Microsoft Message Queuing (MSMQ) and C/C++ code. Defining the technology used to implement a component helps the tool determine which of the possible attacks in the attack library are relevant.

Use cases define. Registering a user, how users interact with the application and how those interactions change the components for example, results in new records being created in the Customers database. Logging on involves a user sending information (e.g., a username and password) to the Web site, which in turn verifies the user's credentials by reading information from the accounts database.

Analyzing the Threat

Once a model of the application has been built, the tool compares the model with an attack library. The library contains a number of commonly used attack techniques, including buffer overflows, man-in-the-middle attacks, and SQL injection. The library is extensible, and Microsoft will provide its own updates, but Microsoft also hopes that third-party security experts will contribute attack definitions.

Analyzing the model gives the user a list of possible threats to the application's confidentiality, integrity, and availability and offers a set of possible countermeasures that mitigate the threat. For example, a Web site that submits an order to an orders database represents a potential threat, since it contains sensitive information such as a user's credit card number. Because the tool knows the technologies used to implement the various components, it can provide a list of potential vulnerabilities, attacks that could exploit those vulnerabilities, and countermeasures to mitigate the threat. In the case of a Web site accessing a SQL Server, the tool suggests a number of ways to block man-in-the-middle attacks, such as using a secure communication channel or mutually authenticating both systems.

Tools Support Lacking

Building a threat model can be a time-consuming task—a situation worsened by the fact that the current version of the Threat Analysis and Modeling Tool is not integrated with Microsoft's Visual Studio modeling tools. This means that IT architects using Visual Studio end up building two models of their applications—one for Visual Studio and one for the threat-modeling tools—and they must make sure the threat model is changed each time the underlying application is changed.

Microsoft hopes to improve the situation in future versions by importing Visual Studio models into the tool and exporting a set of countermeasures into Visual Studio's work-item tracking system. Until that integration happens, IT organizations must decide if the benefits of the Threat Analysis and Modeling Tool are worth the hassle of building and maintaining yet another model.

Resources

The Threat Analysis and Modeling Tool can be downloaded from www.microsoft.com/downloads/details.aspx?familyid=aa5589bd-fb2c-40cf-aec5-dc4319b491dd.

The Microsoft Security Development Center has a section on application threat modeling at msdn.microsoft.com/security/securecode/threatmodeling/acetm.

A team blog on threat analysis can be found at blogs.msdn.com/threatmodeling.

Visual Studio's modeling tools are described on page 31 of the Nov. 2005 Research Report, "VS 2005 and Team System."