Analyze for Threats and Vulnerabilities

A threat is the potential for an attack. Vulnerability is the degree to which your computer, network, or application is susceptible to an attack. Damage is done when a threat is executed—an attack is launched—against a vulnerability. Damage related to a threat against a particular vulnerability can be avoided in several ways:

• Luck The threat never materializes as an attack.

• Prevention The vulnerability is extricated before the attack can be launched.

• Deterrence The perceived risk of getting caught outweighs the reward.

• Relative nonvalue Other vulnerabilities might be more attractive to the attacker.

If a threat against an existing vulnerability never materializes, it’s because either pure luck prevented an attack from happening (an attacker has yet to discover the vulnerability); you fixed the vulnerability exposed by your computer, network, or application before the attacker discovered it; the risk of getting caught and punished is perceived to be too high; or the attacker didn’t see any gain by launching the attack. Having a vulnerability in your computer, network, or application is analogous to leaving your car unlocked in a public parking lot with the keys in the ignition and returning several hours later to find that the car had not been stolen. The car might not have been stolen for the following reasons:

• A thief never discovered the car.

• You quickly discover that you left the keys in the car and then return and retrieve them.

• Parking-lot security cameras and an on-site security guard deter the thief.

• The thief considers the rusty, green, 1975 AMC Gremlin not worth stealing and is drawn to an unlocked 2002 Ford Explorer parked next to it.

Threat analysis is the process of reviewing your application and identifying threats to the application, including threats to the computer or network where the application is running. Unless you’re planning on luck to keep your computer, network, and application safe from attack, you should apply threat analysis to identify threats and resolve them before an attacker has a chance to wreak havoc.

Threat analysis involves taking a close look at the components that make up your application and how they relate. You start by identifying all threats to your application, including threats that might seem insignificant and remote. You then prioritize the list to help focus your efforts on stamping out the greatest threats to your application.

Note

Although threat analysis can be performed at any point in the development cycle, it’s best to incorporate threat analysis in the design phase. Doing so enables you to identify design issues that might expose your application to unnecessary threats. Identifying vulnerabilities in the design phase gives you a chance to modify the application design rather than face a difficult and expensive redesign or feature-rework decision when a vulnerability is uncovered late in the development cycle.

Identify and Prioritize

Life is full of risks. Every day is an adventure into the unknown. Many threats endanger your very existence, for example:

• A powerful solar flare that rips away the Earth’s ozone layer

• Secondhand smoke

• Other drivers

Elements that endanger you or your company’s computers, network, and applications include threats such as:

• Worms or viruses that can bring down your network

• Password-cracking applications used to gain unauthorized access to your computer

• Con artists intent on manipulating company employees to acquire sensitive information

The steps you take to analyze your application for threats are prerequisites for forming an effective plan of action, and they work equally well for both life- endangering threats and computer-related threats. The steps are:

1. Identify all threats—real or imagined—that are possible.

2. Prioritize threats on the likelihood of occurrence and their severity, and prioritize vulnerabilities on the likelihood of exposure and severity of the risk.

Identify Threats

You should make an exhaustive list of all the threats that you can identify. Brainstorm and think like an attacker to create a list in the same way that you created an exhaustive list of security test scenarios in Chapter 9. This involves:

• Looking at the overall design of your application and the components—.EXE and .DLLs—that make up the application

• Identifying all public methods exposed by your application

• Identifying all inputs to your application, as described in Chapter 7, including user input, registry settings, and input files

• Considering how your application reports errors, as discussed in Chapter 8

• Looking at all channels of communication—such as HTTP and database connections—between your application components

• Enumerating the type of data passed through those communication channels. Chapter 15 walks you through the process of enumerating threats for the employee management system (EMS) sample application

STRIDE—Categorizing Threats

A popular technique used within Microsoft to perform threat analysis is to classify each threat among the areas of potential attack by using the STRIDE security threat model defined by the Microsoft Security Task Force. STRIDE is an acronym that encompasses the types of threats listed in Table 14-1, the first letter of each threat spelling out the word STRIDE. Table 14-1 describes these categories for classifying threats.

Table 14-1: STRIDE Threat Categories

Attack	Description
Spoofing of user identity	A simple example is an attacker who logs on as another user without that user’s knowledge or permission. The attacker could then do whatever the user could do when logged on. The potential damage could be mitigated if the system prompts for additional information that the attacker doesn’t know. For example, in an online shopping application, an attack would be thwarted if the attacker was prompted for a credit card number he didn’t know.
Tampering with data	Any data an attacker could change without authorization relates to this category. This includes data such as personal data stored in a database, registry-key entries, contents of executable files, and application settings stored in an on-disk file.
Repudiation	This involves one party denying having performed an action, while the other party is unable to prove otherwise. For example, a user of your online store denies having bought certain high-priced items, claiming someone else did it using her account fraudulently. You, as the store owner, need to implement trace functionality to counter repudiation threats. In general, nonrepudiation means that you must gather evidence about every step taken in your application or business process.
Information disclosure	Any attack where an attacker can obtain unauthorized information—no matter how trivial—falls into this category. For example, if your Web application sends back HTML containing script and comments that reveal database names and the directory structure on the server, the attacker could use this information to mount other forms of attack aimed directly at the server.
Denial of service	The SQL Slammer virus unleashed during the writing of this book is an example of a denial of service attack. This attack comes in many forms and affects Web servers and networks.
Elevation of privilege	This form of attack involves being granted more privileges than you ordinarily should. For example, if an attacker can log on to a system and input SQL statements into a standard input field, and the SQL statements are executed by the application connected to the back-end SQL server as an administrator, the attacker can effectively run queries against the back-end SQL server as an administrator.

Prioritize Threats

Some threats are more imminent and important—more real—than others. For example, if you drive frequently, other drivers are more of a threat to you than if you stayed home and didn’t travel. And if you opted to travel along the road by foot or bike, cars would be a greater threat to your survival than if you drove. Likewise, certain threats to your application are more important than others. The severity of any given threat is based on the following two factors:

• The likelihood that an attack will be waged based on the threat.

• The potential extent of loss or damage as the result of the attack.

Threats that rank high in both of these categories should be given high priority in your list. If your application is an Internet online banking application that allows users to view and update their personal information—such as name, address, and phone number—it’s a good starting point for an attacker to steal a user’s identity. A threat to the application is an attacker who pieces together enough information (by discovering it on the Web or intercepting it en route between a client and a Web server) to assume a user’s identity and steal money from the user’s account. The likelihood of the attack is high, given the visibility of the application. In addition, the potential for loss is high. A bank that has to repeatedly report the theft of personal account information will quickly lose the trust of its customers. This type of threat should be ranked high on the list.

On the other hand, a computer game you’ve written that’s intended to be installed and run on a customer’s computer might be vulnerable to the threat of an attacker modifying the high-score list. In this case, you might rank the likelihood of the attack as low because the attacker would need to have direct access to the computer and the application binary to modify the high-score list. (Although if the game is running on a Microsoft Windows XP computer hooked to the Internet and accessible as a Terminal Server, this might not be as hard as you think.) The likelihood of the attack is low also because the attacker has little to gain by launching such an attack—except the warped satisfaction from injuring the pride of the customer whose high score has been toppled by an unknown assailant.

Note

Don’t be fooled into thinking that certain types of applications are inherently more secure than others. For example, as implied in the preceding example, you generally don’t think of games as being a security risk or the focal point for an attack. However, what if the game you developed required that the user be logged on as an administrator in order to play the game? A game requiring administrative access leaves the computer more vulnerable to attack. An attack launched using the privileges of the logged-on user—a user forced by the game to be an administrator in this case—would be able to wreak a great deal of havoc on the machine. This is because the attacking application would be able to read or delete almost every type of resource— such as files, registry entries, and database data—on the computer. It’s your responsibility to not only make sure your application is secure, but ensure it will perform acceptably in a secure environment.

An excellent way to track all the threats you’ve identified is to enter a single bug for each threat. Even if you don’t use a bug-tracking tool, you should keep track of all issues somewhere, such as in a Microsoft Excel spreadsheet, Microsoft Access database, or Microsoft Word document. Tracking threats in this manner forces security issues to be dealt with in the same way you deal with all your other bugs. The bug should include the following information:

• A full description of the threat

• Optionally, one or more categories the threat falls into—ideally, using the STRIDE analysis shown in the “STRIDE—Categorizing Threats” sidebar

• The priority of the threat, which should be set to represent the general priority you’ve established and based on the likelihood of the threat and its severity

The advantage of including threat information in your bug database or issues list is that all issues concerning the quality of your product—bugs and security issues—are kept in the same location. You don’t have to worry about maintaining separate documents. Such an approach helps to avoid the “out of sight, out of mind” problem that can occur if all threat information is stored in a document or across several documents that you create once but never look at again before you ship.

After you complete a threat analysis of your application and determine the most significant vulnerabilities, you must decide how you’re going to deal with each vulnerability. You could ignore the vulnerabilities, throw caution to the wind, and hope your good luck holds up; or you can take corrective action to mitigate the threats you’ve identified.