SY0-501 Section 2.5 Summarize common incident response procedures

Preparation

Preparing for incident response involves multiple factors. The first step is outlining how you intend to respond to specific incidents. Formulating an IRP is part of that preparation. You also will need to identify the personnel and resources needed for your response. For example, if you intend to take a server offline in the event that it is breached, do you have a backup server available? In the event of a suspected computer crime, which of your personnel are qualified to perform the initial forensic processes? If no one is qualified, you need to identify a third party that you can contact.

Incident identification

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 deter- mine if an event becomes an incident. An easy way to think of the two is that an event is anything that happens, whereas an incident is any event that endangers a system or network. 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. Be sure to doublecheck your results because you don’t want to declare a false emergency. 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 adaptto changing environments if the changes occur over a long period of time. An automated monitoring system, SUCH AS IDS, will sound the alarm when a certain threshold or activity level occurs. When a suspected incident pops up, first responders are those individuals who must ascertain whether it truly is an incident or a false alarm. Depending on your organization, the first responder may be the main security administrator or it could consist of a team of network and system administrators. The very first step, even with a suspected incident, is isolation. If you think, for example, a given machine is infected with a virus, you must isolate that machine, and even before you are sure it is indeed infected. That involves quarantining the machine(s) that you suspect of being infected. Literally disconnect them from the network while you analyze the situation. In some cases this is accomplished with simple device removal: Just remove the device from the network by unplugging the network cable. 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 arise.

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 be curious about a situation. A single spokesperson needs to be designated. Remember, what one person knows runs a risk of one hundred others also finding out.

Mitigation steps

CompTIA is fond of risk mitigation and confronting it through the use of routine audits that address user rights and permission reviews, change management—the structured approach that is followed to secure a company’s assets—and incident management—the steps followed when events occur (making sure controls are in place to prevent un-authorized access to, and changes of, all IT assets). Policies addressing data loss or theft need to be in place, and technology controls should be enforced.

Reporting

During the entire process of responding to an incident, you should document the steps you take to identify, detect, and repair the system or network. This information is valuable; it needs to be captured in case an attack like this occurs again. The documentation should be accessible by the people most likely to deal with this type of problem. Many help-desk software systems provide detailed methods that you can use to record procedures and steps. These types of software products allow for fast access. If appropriate, you should report/disclose the incident to legal authorities and CERT (www.cert.org) so that others can be aware of the type of attack and help to look for proactive measures to prevent it from happening again.

You might also want to inform the software or system manufacturer of the problem and how you corrected it. Doing so might help them inform or notify other customers of the threat and save time for someone else.

First responder

When a suspected incident pops up, first responders are those individuals who must ascertain whether it truly is an incident or a false alarm. Depending on your organization, the first responder may be the main security administrator or it could consist of a team of network and system administrators.

Incident isolation

Forensics refers to the process of identifying what has occurred on a system by examining the data trail. It involves an analysis of evidence found in computers and on digital storage media. Incident response encompasses forensics and refers to the process of identifying, investigating, repairing, documenting, and adjusting procedures to prevent another incident. An incident is the occurrence of any event that endangers a system or network. We need to discuss responses to two types of incidents: internal incidents and incidents involving law enforcement professionals.

Damage and loss control

One of your first considerations after an incident is to determine how to restore access to resources that have been compromised. Then, of course, you must reestablish control of the system. Most operating systems provide the ability to create a disaster-recovery process using distribution media or system state files.

After a problem has been identified, what steps will you take to restore service? In the case of a DoS attack, a system reboot may be all that is required. Your operating system manufacturer will typically provide detailed instructions or documentation on how to restore services in the event of an attack.

If a system has been severely compromised, as in the case of a worm, it might not be possible to repair it. It may need to be regenerated from scratch. Fortunately, antivirus soft- ware packages can repair most of the damage done by the viruses you encounter. But what if you come across something new? You might need to start over with a new system. In that case, we strongly advise you to do a complete disk drive format or repartition to ensure that nothing is lurking on the disk, waiting to infect your network again.