Handling Incident Response
You learned earlier in this chapter that there are six steps to responding to a security incident. These steps are not purely linear. You may repeat some steps several times while responding to incidents. Each step is important because it isolates a specific area of concentration that you must address to respond well to any incident.
For simple incidents, several steps may be combined or are trivial. Regardless of an incident’s simplicity, however, each step is important. A solid incident response plan ensures a CSIRT will address each step for all types of incidents.
Preparation
The first step in a proper incident response is to prepare for the incident. In other words, get ready for incidents before they occur. Taking the time to prepare to respond to an incident after it occurs likely will worsen the incident’s effects. Being prepared greatly increases the probability that you can respond to an incident in a positive, professional manner. If you have a comprehensive response plan, a complete and trained CSIRT, and all of the supplies the team will need, you should be ready to handle incidents.
Identification
The main purpose of the identification step is to decide the next course of action. The first question is whether an incident has occurred at all. Many incidents go unnoticed while other events that are harmless are reported as incidents. Identifying incidents starts with a complete definition of what an incident is. In your plan, include procedures to identify incidents your security policy defines. Some events such as defacing a website are obvious incidents for any organization. Other events such as an attempt to use an incorrect password five times may or may not be an incident. Each organization’s security policy should contain enough details to decide whether any event is an incident.
Once you decide to implement a formal incident response, create a method to report suspected incidents and publicize the proper reporting steps. You could publish an incident reporting form on an intranet page, use an emailed form, or hard-copy forms. In some organizations, the help desk is the primary point of contact for incidents. Help desk personnel would likely be the ones to determine whether to refer an event to the CSIRT. When this is the case, the CSIRT should have a help desk representative as a member. The procedure you decide to use should be standard for your organization and should contain enough information to determine the next step. FIGURE 13-1 shows a sample incident reporting form.
FIGURE 13-1
Sample incident reporting form.
© Jones & Bartlett Learning.
Once you have an incident reporting form available for your users, train the person who might report a violation on the proper reporting procedures. The initial part of incident reporting training is to help users identify potential incidents. First, teach users how to find out if any scheduled maintenance or known issues are causing the events. If no known issues are present, users should report a potential incident if any of the following events occur:
A password has been changed without taking any action.
They are asked for their password or other private information by someone who does not have a need to know. This includes requests that users change their password to one an outside party supplies.
They notice email responses to messages they did not send, messages in their Sent Messages mailbox they didn’t send, or an increase in spam.
Their web browser home page changes, or they can’t close pop-up ads.
They notice changes in the way their desktop appears when they log on.
They can’t connect to servers or webpages they need to complete tasks.
Noticeable increases in disk activity, network activity, or wait time to complete any task occur.
New files or folders appear that they haven’t seen before.
Once users suspect that an incident has occurred, they should save their work, leave all applications open, and notify the CSIRT using the published notification procedure. Users should leave the computer in its current state rather than shut it down or reboot. The CSIRT will likely want to see what the computer is doing before making any changes to its configuration.
Once the CSIRT receives the suspected incident report, it is assigned to a team member. That team member becomes the incident lead. The incident lead reviews the information and begins an investigation. The first step is to determine whether the report contains information about an incident or some other event. This is where you will rely on the technical expertise of your team members. If the incident lead validates the incident, the next activity is to determine the incident’s attributes. The three main attributes of an incident that direct subsequent action are:
Classification—What type of incident is this? An incident’s classification tells the CSIRT what actions to take. TABLE 13-3 lists common suggested incident classifications.
Scope—How many computers or users does this incident affect, and how long has the issue existed? Knowing the incident scope helps the CSIRT determine if it needs more resources and how to handle communication.
Severity—How bad is this incident? Setting the severity level helps the CSIRT and management allocate resources efficiently. More severe incidents get higher priority and more resources as needed. TABLE 13-4 lists suggested incident severity levels.
TABLE 13-3 Incident Classifications |
|
|---|---|
| CLASSIFICATION | DESCRIPTION |
| Unauthorized access of a privileged account | An unauthorized user has gained access to a privileged account, either by an unauthorized logon or a privilege escalation. |
| Unauthorized access of a limited account | An unauthorized user has gained access to a limited account, either by an unauthorized logon or a privilege escalation. |
| Failed attempt to access any account | An attempt to log on or change user accounts has failed. |
| Unauthorized scan of one or more systems, or even users, as in social engineering queries | A port scan has targeted one or more computers or devices to collect information about the computers or devices. In the case of social engineering attacks, calling multiple users with the same request could be a process to identify potential victims. |
| AUP violation | A user action violates AUPs, including both accidental and malicious actions. |
| DoS attack | An attack has resulted in a reduction or total DoS. |
| Malware infection | Malware infection has occurred. |
| Hardware or software failure | A computer, device, or software error or failure not related to malicious activity has occurred. |
| Infrastructure failure | Any failure of supporting services and utilities, including power, Heating, Ventilation, and Air Conditioning (HVAC), and communications, has occurred. |
© Jones & Bartlett Learning. |
|
TABLE 13-4 Incident Severity Levels |
||
|---|---|---|
| SEVERITY | DESCRIPTION | RESPONSE EFFORT |
| Severe | Potential long-term negative effects on an organization’s reputation or the ability to conduct critical operations. One or more critical systems have been compromised. An example would be discovering that an intruder extracted a large number of credit card numbers from your customer database. | Invoke the DRP. |
| High | Compromise of one or more noncritical systems or a verified threat of an imminent attack, such as the theft of a laptop that contained only sales presentation information. | Expend substantial effort for an extended period of time. |
| Moderate | Verified threat of a future security incident, such as identifying infection of malware that triggers on a certain date and time. | Expend a moderate amount of effort for a limited amount of time. |
| Low | Indication of a potential future security incident, such as a port scan or multiple telephone calls from a person asking users to disclose information. | Expend minimal effort. |
© Jones & Bartlett Learning. |
||
This step may also include notifying other parties, including law enforcement, of certain types of incidents. If your investigation produces evidence of illegal material, such as copyrighted material or child pornography, the law requires you to report it to the proper authorities. In such situations, the CSIRT legal representative will provide the direction for the proper course of action.
Containment
The classification, scope, and severity attributes of an incident direct the containment activities. The main purpose of containment is to keep the incident’s scope from expanding. The specific steps you follow to contain an incident vary from one incident to another. The SMEs who participated in developing your incident response plan would have provided the technical details to contain each type of incident.
Steps you take to contain the damage an incident causes depend on several factors. Once you understand the current incident’s nature, the steps necessary to contain the incident should become clear. However, the steps will only be clear if your response plan includes steps to deal with the current incident. There is no substitute for having a comprehensive incident response plan that includes input from SMEs in several areas. The SMEs you use to help develop your incident response plan or carry out investigations don’t have to be CSIRT members. The CSIRT has the flexibility to use the best available resources for each investigation. The steps you take to contain incident damage may include some of the following actions:
Disable networking services.
Physically detach the computer or device from the network and disable wireless adapters.
Logically separate the affected computers or devices into a separate subnet.
Turn off the computer or device.
Terminate one or more programs or services.
Remove software from the computer or device.
Restore the computer or device to a previous state.
Initiate appropriate communications to let interested parties know an incident’s status.
Regardless of the option your SMEs select, the most import consideration in the containment step is to keep the incident damage scope from expanding. Consider any incident to be like an infectious disease. Setting up a quarantine area can help keep the disease from spreading and making healthy people sick.
Eradication
Containment stops the incident damage from expanding. This allows you to remove the vulnerability that allowed the incident to occur in the first place. The steps you take will depend entirely on the incident’s nature and the course of action your SMEs recommend. In general, pursue the least intrusive course of action that will completely remove any vulnerability to prevent further incidents. Note that the eradication step doesn’t remove the incident’s effects—it just removes the vulnerabilities that allowed the incident.
Depending on the nature of the incident, the eradication step can include any of the following actions:
Modifying firewall rules to close one or more ports or block Internet Protocol (IP) addresses
Installing operating system or application software patches or updated software
Removing malware
Providing targeted user training
Removing or detaching hardware devices or device drivers
Restricting remote access to deny offending computers
Replacing or repairing failed hardware
Firing a disgruntled employee and terminating her account access
IT SMEs will provide the best course of action to eradicate each type of incident.
Recovery
The final technical step is to return the affected computers or devices to a fully operational state. That means to restore the hardware, OS, software, and data to a state that is usable in your environment. The incident’s severity and nature will direct team actions in this step. Minor incidents may require no recovery. For example, suppose your web server encountered a series of unauthorized scans from a specific range of IP addresses. During the eradication step, you could add rules to your firewall to block any traffic from the range of IP addresses that initiated the scan. Unless complicating circumstances arise, you wouldn’t need to take any further recovery steps. The recovery step is unnecessary in this situation.
While some incidents require no restore activity, others require austere measures. Suppose your incident investigation revealed that a critical server contains a rootkit. Further investigation reveals that the rootkit exists on several recent backups. In most cases, you’ll have to rebuild the server from bare metal. From there, you’d identify the usable parts of your backups to extract the latest data possible. Sometimes, restoring a computer isn’t as easy as just restoring a backup.
Lessons Learned
Regardless of the effort required to respond to an incident, formally review the incident and all team actions. Larger incidents should be reviewed by the whole team. Analyze what went well and what didn’t work so well. Use the information you uncover after each incident to improve the plan. Review incidents as soon after the actual events as possible. Memory fades and takes valuable insight with it. The lessons learned can keep you from repeating mistakes and help you avoid making new mistakes.
It is also a good idea to learn from other organizations’ mistakes and successes as well. Be on the lookout for any stories about security incidents and how organizations handled them. You can learn a lot from how others handle the same issues you encounter.