Analyzing a Security Incident

Once an incident has been identified regardless of who identifies it the information needs to be communicated to the incident response team. Following that communication, a number of steps must be taken by the response team. The approach taken will differ depending on the specifics of the incident, but the underlying intent remains the same. These are the steps:

Determine the cause.
Prevent further exploitation of the attack vector.
Avoid escalation and further incidents.
Assess the impact and damage of the incident.
Restore the computers services.
Update policies and procedures as needed, based on the lessons learned from the security incident.
Find out who launched the attack (if appropriate and possible) and take business-appropriate action.

For more information on incident response teams and plans, see Chapter 26, Planning for Incident Response.

Determining the Cause

At the outset of the investigation, the incident response team will need to determine the cause of the behavior, which software might be involved, how the software has been compromised, and the scope of the compromise. If hostile code is involved, the team should assess the capability and propagation methods of that code. Frequently, such analysis assistance can be obtained on the Web site of your antivirus software vendor.

Microsoft provides a free support hotline for viruses, worms, and similar attacks. The U.S. telephone number for this hotline is 1-866-PC SAFETY. Customers with a Premier Support agreement have additional support options and should contact their technical account manager. For international support, see http://support.microsoft.com/common/international.aspx?gssnb=1.

Preventing Further Exploitation

Following the initial analysis, the team should take steps to prevent further exploitation of this type of attack. See the Conducting Security Investigations section later in this chapter for important considerations for this stage of your response. This stage can involve many different approaches, including applying an already existing patch for a particular vulnerability to all at-risk systems, modifying the network topology, temporarily suspending a service or application, and performing user awareness activities. The specific response will vary based on the details of the incident.

Avoiding Escalation and Further Incidents

The next step in an incident response is to avoid escalation of the existing incident and further incidents. This is a large concern when an attacker has interactive access to one or more of your systems. Shutting down the attacker s session might result in new and potentially more destructive attacks. This can also be an issue with automated attacks, such as the Nimda and Code Red worms. In those cases, the escalation is the spread of the worm or an attacker taking advantage of your vulnerable state to launch new attacks on your network.

Restoring Service

Restoration of service occurs next, once the scope and damage of the incident are fully understood. Service must be restored in a secure manner or workarounds must be put in place to enable the business activities requiring those services. Systems not being used as evidence in an attack investigation need to be brought back online without reintroducing a security threat to the network.

One of the most difficult decisions a response team can face is determining the appropriate course of action to restore a system to service after it has been compromised. Although immediate restoration of service is laudable and appears to be in the best interest of the firm, it often is a poor choice. For example, if an attacker compromises one of your servers and you decide to secure the system as it stands and bring it back online, several events can happen:

The process of securing the system could overwrite evidence, making it difficult or impossible to determine the source of the attack.

More importantly, short of comparing known good file hashes for every file on the system, you cannot know whether the compromise extends beyond the elements you have identified. Too often an attacker will enter your system by exploiting one avenue and then expand her influence by installing additional software tools or Trojan horse applications. In such cases, the system might seem to be behaving normally, when instead, it is camouflaging its own improper behavior.

Although you have identified one intrusion, others that you are unaware of might exist. The system fell to one attacker, and it is folly to think that such a system could not be hosting others with ill will.

The process of taking a system offline; verifying the checksum of every file on the system against a known good baseline (using trusted executables from your forensics workstation or tools CD); reviewing and understanding every .ini file, registry entry, setting, and service; and correcting anything found to be out of line takes considerably more time than simply rebuilding the system from known clean media, securing the system before it is brought online, and restoring service on the rebuilt system. Having spare hardware can enable you to preserve evidence by restoring affected services to different equipment, thereby leaving the impacted systems untouched. Also, if your organization has automated a process for installing the OS, you can create a single installation media that incorporates the latest service packs and hotfixes. By incorporating security updates into the media used to install the OS, a process often called slipstreaming, you can decrease the time it takes to recover the computer s services.

Once you have the situation under control, you should assess the impact and damage the event has caused. To better allocate resources for securing the network, you should determine the costs associated with the loss of productivity because of the security incident and the costs of recovering the disrupted services.

Incorporating Lessons Learned into Policy

Every incident is a learning experience. Your incident response team will learn about new techniques and tools as a result of the security breach, and your organization will learn where its policies and procedures might not sufficiently address risks to your environment. At this stage, it is essential to hold an incident debriefing and examine the lessons learned from the experience. Look at the cause of the event and how it could have been prevented. If your policy does not address the behavior or processes that allowed the incident to occur, look at what revisions might be necessary. If your policy does support such preventative behavior or processes, look to where the policy broke down and see what you can learn from that.

Tracking the Attacker

After you have incorporated the lessons learned into your operations, determine whether it is appropriate to track the intruder. Using the information collected from your investigation (logs, packet traces, timestamps, process lists, methods, and so on), you can trace the attacker s steps to determine his origin. To do so, use the data shown in your logs to determine the owner of the IP address or domain. You can trace the IP address or domain used by the attacker by performing a whois search at http://www.arin.net, http://www.samspade.org, or another site that provides the whois search capability.

Although possible, more extensive tracing of attackers might be illegal in some countries. You should discuss this issue with your organization s IT management and legal representatives before taking any action. Based on your detective work, you might find an individual working alone, a corporation, or a government at the other end of the attack. Or you might hit a dead end and find that intervening network providers are unable or unwilling to cooperate without a subpoena. Knowing this type of information can help you to determine whether your team is able to undertake this aspect of the incident response themselves or if additional assistance is required.