Key concepts in this chapter are:
Conducting a threat and vulnerability analysis
Taking preventative measures
Detecting when an attack is in progress
Responding to an attack
Hacking is an odd sort of business where high crime can lead to notoriety and a secure, high paying job, at least for some in the long run. This is exemplified by the story of Kevin Mitnick. In January 2003, Kevin Mitnick—perhaps history’s most notorious hacker, who over an eight-year period reportedly broke into some of world’s largest and presumably most secure companies—was released from probation and allowed to reconnect to the Internet. Upon the news of his release, Kevin Mitnick was presented with a number of offers from companies who wanted to hire him as a corporate security consultant.
This story reflects the fact that corporations are hungry for anyone who can provide a hacker’s view of their security systems. Corporations value getting advice straight from the horse’s mouth on how to break these systems and, more importantly, they want to know how to harden their systems against attack. Who better than a reformed hacker to do the job?
While stopping short of hiring a legendary reformed hacker, this chapter identifies steps you can take to:
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.
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:
Identify all threats—real or imagined—that are possible.
Prioritize threats on the likelihood of occurrence and their severity, and prioritize vulnerabilities on the likelihood of exposure and severity of the risk.
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
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.