CompTIA Security_ Deluxe Study Guide_ SY0-201 - Emmett Dulaney [106]
It’s a good idea to include the procedures you’ll generally follow in an incident response plan (IRP). The IRP outlines what steps are needed and who is responsible for deciding how to handle a situation. Carnegie Mellon pioneered this process.
FIGURE 4.15 Incident response cycle
Law enforcement personnel are governed by the rules of evidence, and their response to an incident will be largely out of your control. You need to carefully consider involving law enforcement before you begin. There is no such thing as dropping charges. Once they begin, law enforcement professionals are required to pursue an investigation.
The term incident has special meanings in different industries. In the banking and financial areas, it’s very specific and involves something that includes the loss of money. You wouldn’t want to call a hacker attempt an incident if you were involved in a bank network because this terminology would automatically trigger an entirely different type of investigation.
The next five sections deal with the phases of a typical incident response process. The steps are generic in this example. Each organization will have a specific set of procedures that will generally map to these steps.
An important concept to keep in mind when working with incidents is the chain of custody. When you begin to collect evidence, you must keep track of that evidence at all times and show who has it, who has seen it, and where it has been. The evidence must always be within your custody, or you’re open to dispute about whether it has been tampered with.
Step One: Identifying the Incident
Incident identification is the first step in determining what has occurred in your organization. An internal or external attack may have been part of a larger attack that has just surfaced, or it may be a random probe or scan of your network.
An event is often an IDS-triggered signal. Operations personnel will determine if an event becomes an incident.
Many IDSs trigger false positives when reporting incidents. False positives are events that aren’t really incidents. Remember that an IDS is based on established rules of acceptance (deviations from which are known as anomalies) and attack signatures. If the rules aren’t set up properly, normal traffic may set off the analyzer and generate an event. You don’t want to declare an emergency unless you’re sure you have one.
One problem that can occur with manual network monitoring is overload. Over time, a slow attack may develop that increases in intensity. Manual processes typically will adapt, and they may not notice the attack until it’s too late to stop it. Personnel tend to adapt to changing environments if the changes occur over a long period of time. An automated monitoring system, such as an IDS, will sound the alarm when a certain threshold or activity level occurs.
When a suspected incident pops up, first responders are those who must ascertain if it truly is an incident or a false alarm. Depending upon your organization, the first responder may only be the main security administrator, or could consist of a team of network and system administrators.
After you’ve determined that you indeed have an incident on your hands, you need to consider how to handle it. This process, called escalation, involves consulting policies, consulting appropriate management, and determining how best to conduct an investigation into the incident. Make sure that the methods you use to investigate the incident are consistent with corporate and legal requirements for your organization. Bring your human resources and legal departments into the investigation early, and seek their guidance whenever questions involving their areas of expertise appear.
A key aspect, often overlooked by system professionals, involves information control. When an incident occurs, who is responsible for managing the communications about the incident? Employees in the company may naturally