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.
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
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
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.
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:
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.
The constituency is not a part of the incident-response team itself, but is a stakeholder in the incident. This
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.