The Incident-Response Process

The incident-response process consists of several steps. The first is to do a proper risk analysis, design a proper methodology, and create a response team that will follow the methodology. The following sections discuss these issues in more detail.

Performing a Risk Analysis

The first step in developing and understanding the incident-response process is to do a risk analysis. Risk analysis involves identifying risks within your organization and the potential loss resulting from those risks. It is imperative that this is done so that a proper response can be put in place, based on the amount of risk. For example, information that is critical for the organization may be protected with all means necessary, while less important resources will not be protected in the same manner.

Risk can be looked at from either a quantitative or qualitative point of view. While it is beyond the scope of this book to get into the details of how to analyze and compute risk, it is important to understand the basic concepts. Quantitative risk analysis attempts to assign an objective numeric value, usually monetary , to components of the risk assessment and to potential loss. Quantitative risk will typically use annual loss expectancy (ALE) to determine the amount of loss that is associated with a particular risk. ALE can be calculated by multiplying the probability of the loss by the value of the loss itselfthis produces the risk loss (Probability Loss = Risk). For example, if the probability of a virus attack is 4 percent, and the average loss for this type of event is $150,000, the risk would be $6,000.

Qualitative risk analysis does not assign numeric values to components of the analysis-but uses a more intuitive approach. For example, you can look at how likely an attack is to succeed and how critical the target of the attack is, and then rank them on a scale, such as from 1 to 10. Then you can also rank the countermeasures you have in place from 1 to 10. The formula would look like this:

(Attack Success + Criticality) (Countermeasures) = Risk

The problem with this sort of approach is that it is very subjective . Who is to say how likely an attack is to succeed or what collateral damage you should base the criticality on? There are too many variables to consider for this to produce an accurate assessment of risk.

Designing an Incident-Response Methodology

When responding to an incident, it is very important that there be a sound methodology to follow. A methodology is a set of working methods for a discipline, in this case incident response. A good methodology gives the incident-response team a set process to follow when responding to an incident. In addition, the use of a sound methodology helps demonstrate an organization’s due diligence, especially when legal repercussions are possible.

There are several methodologies that are used, and many organizations use variations on different models, but the model presented here is the most thorough. The model (see Figure 13-2) consists of six stages:

Preparation
Detection
Containment
Eradication
Recovery
Follow-up

Figure 13-2: Six-stage incident-response model

The preparation stage is when information is gathered on how you would respond to various incidents. The first thing you need to do is gather as much information as possible about the network and the constituent hosts as possible. This includes network diagrams, a list of populated IP space, previous vulnerability scanning records, and if possible, a list of individual hosts’ operating systems and arpwatch or DHCP (Dynamic Host Configuration Protocol) data. You then must gather tools for creating procedures and policies, set up predetermined roles and a list of contacts (such as staff from Legal, Human Resources, and Management) for an emergency situation. In addition, you will want technology deployed that will enable a better response to possible attacksthis includes an IDS or IPS, backups , and enhanced logging. This preparation stage is relied upon throughout all the following stages.

The detection stage happens when a possible incident has occurredit is the first reactive stage in the process. Typically the incident will have been detected through logs, IDS alerts, or other similar methods. Once the detection has occurred, it is imperative that the incident be recorded. This includes the date and time, who is involved, any direction from management, the nature of the attack, and what is being attacked . In addition, the scope of the incident needs to be determined, because this will be important in deciding how the incident can be contained and who should be involved. The scope of the incident will determine the overall impact of the attack on the organization.

In the containment stage, decisions and actions need to be made about how the incident can be prevented from causing more damage, and how it can eventually be eradicated. For example, if your web server is being attacked by a ping flood, the containment measure could be to turn off ICMP echo requests on your network. Containment may include shutting down ports on a firewall, disconnecting from the Internet, disabling services or accounts, or shutting a system down. It is important to remember that each of these steps is only a temporary solution to help stop the spread of the attack. It is also important to weigh the impact of taking or not taking these steps against the impact on the business or organization.

Once the event has been contained, it must be eradicated. Eradication is the process of eliminating the root cause of the incident, whether it was a back door, virus, or operating system vulnerability. Processes and procedures should have been put in place during the preparation stage to enable the incident team to handle this process.

The recovery stage is when you get all systems back up and online as they would normally be. This process assumes that the eradication has taken place and that processes and procedures are followed to bring the systems back up. This often involves using known good media dating from before the incident, and this is why proper backups are important.

The follow-up stage is very important, as it reviews the previous steps and analyzes what was done correctly and what could be improved upon. Any improvements can be made a part of the preparation stage for the next incident. Follow-up also includes
making sure that steps are put into place to mitigate this type of event in the case of it
happening again. For example, a better OS patch-management system could be implemented to prevent known vulnerabilities from being exploited.

Once a methodology, such as the one previously discussed, is put into place, there are other things that should be developed:

Guidelines on system outages Be sure to log how long a system can be disconnected from the network without disrupting critical business function.
Backup and restoration plans Identify tools that are likely to be needed in an incident. It is recommended that you have a tool kit with the software and utilities needed to respond appropriately to attacks.
Incident-reporting and contact forms Create forms on which you can record the people contacted, the systems and networks targeted by the attack, purpose of the attack, and evidence of the attack. Figure 13-3 shows a sample incidentreporting form.

Figure 13-3: Incident identification form

Note
It is important to remember that all the information needs to be stored on more than one server, in case that machine is attacked or becomes unusable.

Creating an Incident-Response Team

The incident-response methodology assumes that there is a team that is dedicated to understanding the incident-response process and is ready for action when needed. The reason for having an incident-response team is to ensure that the coordination of the effort goes smoothly. With a team, you have the properly trained experts on hand when neededthe organization identifies with these individuals, and they have a distinct role in the organization during incidents. Depending on the size of the organization you may or may not need to have a full-time dedicated team.

It is best if there are specific roles laid out for individuals. Each organization will define the roles differently, but these are some common roles:

Incident Coordinator (IC) The role of the incident coordinator is to be a liaison between the different groups that are affected by the incident, such as Legal, Human Resources, different business areas, and management. The IC can help play an important role coordinating between the security teams and networking groupsduring an attack is not the appropriate time to be dealing with who should configure what. The IC will help with the communication process and keeping everyone updated as needed. The IC should have solid communication skills, as well as a good technical and business understanding of the organization.
Incident Manager (IM) The role of the incident manager is to focus on the incident itself and on how it is being handled from both a management and a technical point of view. The IM is responsible for the actions of the incident analysts and for reporting that information to the IC for further communication. The IM should be a technical expert with a broad understanding of both security and incident management.
Incident Analyst (IA) The incident analysts are the technical experts in their particular area. They are responsible for direct interaction with the technology and for trying to contain, eradicate, and recover from the incident. These individuals are technical experts in many technologies, as well as technical incident response and security.
Constituency The constituency is not a part of the incident-response team itself, but is a stakeholder in the incident. This group may include various business areas, as well as technical and management teams.

Responding to an IDS or IPS Incident

One of the most important aspects of incident response and intrusion detection and prevention is being able to handle the alerts that are generated. An IDS can generate large numbers of alerts. Being able to identify which ones are legitimate and which are false is crucial. The most common attacks detected by both IDSs and IPSs are scanning attacks, penetration attacks, and denial-of-service attacks, which were covered in Chapters 2 and 3.

Scanning attacks are very commonhackers can download scanning tools from the Internet and can start scanning IP ranges trying to find vulnerable targets. Scanners will help identify open ports and applications that are vulnerable to attack. Nmap is one such tool, and it even has some IDS-evasion capabilities (see Figure 13-4). As discussed previously, throttling is one method that can help against script scans .

click to expand
Figure 13-4: Nmap scanning tool

Penetration attacks are attacks that try to exploit known vulnerabilities to break into a system. This can include any exploit that has been discovered in an OS that makes the system vulnerable. Attackers can either launch large untargeted attacks, hoping to find a vulnerable system, or they can do OS-fingerprinting for a specific system to find out what it is vulnerable to and then attack.

Denial of service (DoS) attacks violate a system or network by diminishing the system’s ability to function as expected under normal circumstances, hence the name denial of service . Several forms of DoS attacks were discussed in Chapters 2 and 3. Both IPSs and IDSs look at many different signatures and behaviors to detect DoS attacks.

Note

It is a good practice to filter outbound IP packets to avoid having them be used in a spoofing attack on someone else.

Buy on amazon.com >>

Endorf C. F., Schultz E., Mellander J.

<< Previous page

Table of contents

Next page >>