Responding to Intrusions

Garfinkel and Spafford (1996) recommend two important responses. First, remain calm and don't panic. Psychological research shows that humans do not perform well under stressful conditions, unless the task is one that the human already executes exceptionally well. Professional athletes often perform well under stressful conditions because they already are very good at running, kicking, shooting, or blocking. Chances are the same cannot be said of incident response teams. Thus, it's important to remain focused on the facts and carry out the plan you've already practiced a number of times. The next recommendation is to document everything. There isn't much elaboration on this point. Just do it.

A different set of suggestions is found in Chapman and Zwicky (1995):

1st step: Evaluate the situation and decide what response is required. You do this evaluation by accurately assessing the damage. Ask what the intruder is doing now, how far did the penetration get, what information was compromised, what changes were made to the systems, were back doors left, and other questions that describe the current state of the problem.

2nd step: Disconnect or shut down resources if necessary. As a rule, you do not want to let the hacker continue to work through your systems (see the next section). Responding to an incident is much like disaster recovery. If the compromised system is your public Web server, and you do not have a second site, shutdown may not be an option. At least you should be able to reset or kill the network connection. The hacker may try another network connection later, but you will have eliminated the current threat. Think of it as triage.

3rd step: Analyze and respond to the incident. Here, the importance of teams with designated roles becomes apparent. You cannot have the same team member digging through log files or source code and also worrying about the next weaknesses the attacker will exploit. Part of the team should be responsible for analyzing the problem, and another segment of the team should be attentive to any new incoming threats. When you are ready to repair the problem, thoroughly consider your responses. The last thing you want to do is make the situation worse. Disabling the wrong sub- net addresses in your firewall could limit your ability to detect new intrusions while not affecting the hacker at all. That's why it's important to remain calm and think through your steps carefully. On most systems, you'll be working with superuser or Administrator privileges. Have someone look over your shoulder and verbally state each step before you do it to minimize errors.

4th step: Alert other people according to your response policy. You can do this in parallel with the previous steps if your team is large enough. The incident response document you prepared in advance will contain the names, phone numbers, e-mail addresses, pager numbers, and other critical information for the contacts. If you diagnose a problem in a purchased product, contact the vendor's response team as soon as possible. They already may be working on the problem but have not publicized the issue yet for fear of increasing the number of attacks. Do not leek information outside the response team and those with a need to know. Most crimes involve internal collusion, so your team should not involve other internal employees unless you are sure they were not involved.

5th step: Save the system state. Back up as much of the system as you can in real time. Take the backup to a victim machine on a detached network and restore the image. This machine is where you will do your debugging. Keep in mind any privacy issues with data that may appear on the backup. Medical records and credit card numbers should not be forwarded to vendors for debugging unless adequate controls are in place. Know your legal limits in advance.

6th step: Restore hacked systems. If you have detected that system binaries have changed, restore them from certified original product media. To be safe, you should restore the system from scratch. Note that this restoration can be tricky because a system may have many additional products installed and configured on top of it. Getting the system back into the state before compromise may not be a simple task and could introduce other security problems. If you've kept accurate change logs, and your IDS can tell you exactly what has changed, you can get by with replacing only the programs patched by the hacker. Remove any hidden files or directories added by the hacker. Watch out for symbolic links. You don't want to remove a system file that has a symlink from a file planted by a hacker.

7th step: Document what happened. Communicate the incident as necessary. Carry out a defect prevention process that will ensure that the problem does not occur again. Finally, increase monitoring if necessary. For example, if the incident went undetected for several weeks, you definitely were not monitoring the appropriate activities.

In responding to an event, you immediately will be faced with a crucial decision—how to handle the intruder. You have several options. The best advice is to disconnect or kill the network connection. If the event is an internal misuse that was flagged by an IDS, you have different legal options. Upper management will help you decide whether to allow the misuse to continue for gathering evidence (with the appropriate concern for privacy of any compromised information).

Stories of administrators contacting the intruder are plentiful. In some cases, the intruder was a friendly hacker who offered security advice and described the weaknesses ₇ exploited. Because you never know whether you have a curious hacker or a sociopath on the end of the connection, this type of contact can be risky. The intruder might not know what type of evidence could be left behind, and your open acknowledgment of detection could result in a hasty exit that also erases your entire system.