Chapter 14: Incident Response | Protect Your Information with Intrusion Detection (Power)

Overview

And so, you have now managed to customize your intrusion detection system, and the first message has appeared on its console. What now? How should you react to this message? Discard it as a meaningless one, or start the investigation of this incident? The decision-making process when detecting intrusions and for the subsequent implementation of these decisions is known as incident response.

Historically, it just so happened that intrusion detection and incident response developed as independent processes. However, the difference between them is gradually being eliminated, and it is currently impossible to imagine contemporary intrusion detection systems without incident response mechanisms. Notice that the response can be two-fold. The first type of response has been mentioned several times in this book. It assumes the implementation of specific actions in response to a registered event. For example, this can be reconfiguration of the firewall, or administrative notification of an active attack. One can conclude that this type of response operates only with the security events covered in Chapter 2. However, let's consider a situation when someone initiates a Denial of Service attack on your network and spoofs his or her actual address. We already looked at this example earlier in this book. In such a case, you must have at your disposal a special procedure or mechanism to identify the exact address of the intruder, in order to be sure that your system does not block an authorized user. The capability of identifying the incident source correctly is extremely important; otherwise, the response to that incident can become the cause of a new incident. A user account lockout after exceeding the predefined number of failed logons can serve as an example of such an incident. An intruder desiring to lock out an authorized user can undertake several attempts of logging on under that user's login name. As a result, the account of that user will be locked. By the way, you should bear this fact in mind when using security scanners that investigate the stability of password protection.

A Practical Example

In my practice, I once encountered a case in which a customer used an Internet Scanner to check the host that played the role of domain controller. The user account management subsystem was set up in such a way that the user account was locked after the third failed logon attempt (see Fig. 4.1). The Internet Scanner, in the course of checking the domain controller, actually managed to lock all the accounts of domain users.

Consequently, the capability of differentiating an attack source is very important for selecting a specific type of response. The example provided above is rather simple, but it does not mean that the problem is not pertinent. To illustrate this statement, let's consider a more complicated situation. For example, practically everyone knows of the famous thriller WarGames, where a young hacker penetrates a military computer system and imitates an intrusion into US territory. The computer of the Department of Defense considered this imitation a real attack, and took counteractions—the US Army, Navy, and Air Force were brought to a state of Red Alert. Thus, only a few seconds separated the world from the beginning of a nuclear war. And this is not pure fiction. Such a situation could arise even now.

Note that most incidents create situations that make some types of responses worthless. For example, the Morris Worm that created such a mess in 1988 locked most of the Internet hosts used by security specialists from different countries all over the world for coordinating their activities. In this situation, e-mail was the only communication tool available to them. A similar situation arose in the US quite recently. Due to the emergency, a large number of pagers ceased to function, among which were many pagers used by Response Teams. Thus, a reliable type of response must be independent of the consequences of the attack. The Cyber Warning Intelligence Network (CWIN), which is currently under construction, might become one such response variant. On December 4,2001, this network was mentioned by Richard Clarke (the IS consultant to the US President) in his speech at the Global Tech Summit organized by the Business Software Alliance in Washington.

I hope I have assured you that the necessity of unambiguous identification of the attack source is beyond any doubt. However, if you return to Chapter 2, you will notice that that attack model does not work with the concept of an attack source. On the contrary, this concept is introduced only in the incident model. This is the main reason why contemporary intrusion detection systems can not unambiguously identify the source of unauthorized activity. The incident response process helps in solving this problem and allows you to quickly undertake the required counteractions.

As I mentioned in Chapter 7, the first steps that you must take before starting work with the IDS is to define the list of employees that will operate and control it. It does not make any sense to have a qualified expert sitting at the IDS console and waiting for an alert signal. In most cases, this function can be delegated to operators who might even lack much knowledge in the field of network security. Usually, such persons do not even know the meaning of such things as Ping of Death or Windows OOB. Most contemporary intrusion detection systems rate detected events by the level of risk, but practically none of them provides recommendations concerning the actions that should be taken when such attacks are detected.

Because of this, it is necessary to develop and approve documents that describe all actions that the operator must take when an attack is detected. Notice that the response to the same attack might be different depending on the concomitant factors. Consider, for example, a situation in which you have registered port scanning on your firewall. If the firewall is correctly configured, this is a minor threat that only requires you to identify the intruder's address. However, if your firewall supports VPN functions, and port scanning is performed from your partner with whom you have established a protected connection, this situation is much more dangerous than the previous one. This means that either your partner's network has been compromised or one of his or her employees is attempting to penetrate your network. Consequently, this incident requires a more detailed investigation, and is beyond the operator's competence. Note that since the operator usually lacks the required knowledge and experience, he or she might discard the second option without giving it any serious attention if there are no appropriate directives and documents.

Even for an experienced operator, most IDS messages look cryptic. For example, the management console might display messages on the detection of the "dot-dot" or "statd buffer overflow" vulnerabilities. The intrusion detection system should describe each of these detected events. Unfortunately, security tools that fully implement this function are not numerous. According to the results of numerous tests on this criterion, the system best explaining each of the detected attacks is RealSecure from ISS. Left-clicking a message corresponding to the detected attack displays a window containing a detailed interpretation of the attack, including a description of its working mechanism, a list of vulnerable operating systems, cases of false positives, and detailed directions for eliminating the possibility of this attack being implemented in the future. Cisco and ISS provide the capability of customizing IDS messages, which significantly simplifies the use of their systems for the customer.

Now let us suppose that the operator has correctly identified and registered an attack. He determined that this is not a false positive, and that the attack has a high level of risk. What should be done next? What actions must he perform when the detected event proves to be a real incident? Consider, for example, a case in which the intruder has exploited a web server vulnerability, gotten administrative privileges, and defaced the home page of the server. What should the operator do in this case? Disconnect the web server from the network and contact the Web master? Reinstall the operating system and web server software? Perhaps, add automatic locking of the connection from the identified IP address in order to prevent further attempts of attacks originating from that address? Or something else maybe?

Incident handling is a rather sophisticated mechanism, which intrusion detection systems can not implement without external assistance. In a best case scenario, depending on the attack target, type, and level of risk, an IDS can perform a predefined action, for example, close the connection with the attacking host, or reconfigure the router or firewall. Still, there remain quite a large number of questions. First, it is necessary to make the correct decision concerning the proper type of reaction to the detected event. A human must make this decision, while the intrusion detection system need only implement this decision. Secondly, an automatic response might also have negative consequences, as was demonstrated earlier.

All these facts allow us to draw the conclusion that incident response functions must be delegated to a special team, which must fulfill, coordinate, and support responses to incidents that affect information systems within the limits of a predefined area of responsibility. Such a group, known as a Computer Security Incident Response Team (CSIRT) must act within the framework of the procedures described in the security policy. The security policy adopted in the organization must strictly define the area of competence for the CSIRT group, in order to prevent a situation in which the CSIRT duplicates the functions of the IT department that users address for any occasion, both important and unimportant. In general, you must implement the following efficient security measures.

When creating the CSIRT group, define the list of employees who must be contacted whenever an incident is reported. If your company is not a widely known one or an Internet portal, it is not necessary to free CSIRT members from other duties (although it is highly desirable). After all, your company does not become the target of an attack every day. For example, the incident response group might include employees from the telecommunications, IT, and IS departments, etc.
Develop guidelines describing variants of response. For example, you must decide whether you will have the intruder accomplish his attack or stop it immediately. Sometimes, especially if you want to gather proof for court, it is best not to stop the attack and let the intruder to accomplish it, in order to gather additional information on the attacker and his actions. For this purpose, you can use deception systems ("honey pots").
You need to develop and approve guidelines specifying variants of communication with other individuals in case of attack detection. Will you inform only the boss, managers, and upper managers of the company, or will you distribute information about the attack to other concerned parties? Do you participate in such organizations as FIRST? Will you inform someone outside the company, or will you consider this information as company confidential? Will you notify your partners that are connected to your network, and who are therefore also exposed to the risk? Will you inform the mass media? All these questions must be answered in this document.
Inform all employees of the creation of the CSIRT group and its functions. First, you can do this by distributing a document within your company describing the aims and tasks of the CSIRT group. You can also create an internal web server containing information on registered incidents and special forms that the user must fill in when such a situation arises. An example of such a form was created by the CERT incident response group (ftp://info.cert.org/incident_reporting_form).

Besides incident response functions, the CSIRT group might be engaged in the following activities [Brown1-98].

Publishing information on detected vulnerabilities (such as the X-Force group does)
Creating technical reports on specific attacks and vulnerabilities
Training users
Analyzing security and evaluating risk
Providing consulting services in the field of information security
Developing incident response tools and tools for tracing the intruder

Such groups can work within the framework of the whole Internet community (for example, CERT), within the limits of specific country, and within the framework of specific department, manufacturer, or company [Brown1-99]. Let's concentrate on the latter variant.

The incident response process is made up of 6 steps [SANS1-98].

Preparation. This step includes the development of the security policy and several other guidelines that were already covered in this chapter.
Identification. At this stage, it is necessary to determine if the incident really took place. If the incident is confirmed, you need to determine its parameters (including the intruder's address, attack route, proof, etc.).
Moderation. Here you must localize the incident as soon as possible, and prevent it from propagating further.
Elimination. This step aims to eliminate the problem (such as vulnerability) that has resulted in the incident.
Recovery. The result of the action performed at this step is the complete recovery of the system after the incident.
Feedback. At this final step, it is necessary to investigate and explore the registered incident in as much detail as possible, in order to develop adequate measures for preventing such incidents from happening in the future.