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
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
Designing an Incident-Response Methodology
When responding to an incident, it is very important that there be a sound methodology to follow. A
is a set of working
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:
Figure 13-2: Six-stage incident-response model
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
stage happens when a possible incident has occurredit is the first reactive stage in the process. Typically the incident will have been
stage, decisions and actions need to be made about how the incident can be prevented from
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.
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
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
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
targetedby 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
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
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:
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 teamsand 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
groupmay 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
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
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
Denial of service (DoS) attacks
It is a good practice to filter outbound IP packets to avoid having them be used in a spoofing attack on someone else.