Incident Response Plan

sepola
bd_ch_10_sect_02_05.html
Home>Computer Science homework help>Incident Response Plan

Reacting to Incidents

Once an actual incident has been confirmed and properly classified, the IR plan moves from the detection phase to the reaction phase. NIST SP 800-61, Rev. 2 combines the reaction and recovery phases into their “Containment, Eradication, and Recovery” phase.*

Cichonski, P., Millar, T., Grance, T., and Scarfone, K. “Special Publication 800-61, Rev. 2: Computer Security Incident Handling Guide.” Accessed 7/12/15 from http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf.

The steps in IR are designed to stop the incident, mitigate its effects, and provide information for the recovery from the incident. In the IR phase, a number of action steps taken by the CSIRT and others must occur quickly and may take place concurrently. An effective IR plan prioritizes and documents these steps to allow for efficient reference in the midst of an incident. These steps include notification of key personnel, assignment of tasks, and documentation of the incident.

Notification of Key Personnel

As soon as the CSIRT determines that an incident is in progress, the right people must be notified in the right order. Most “reaction” organizations, such as firefighters or the military, use an alert roster A document that contains contact information for personnel to be notified in the event of an incident or disaster. for just such a situation. Organizations can adopt this approach to ensure that appropriate personnel are notified in the event of an incident or disaster.

There are two ways to activate an alert roster: sequentially and hierarchically. A sequential roster requires that a contact person call each and every person on the roster. A hierarchical roster requires that the first person call designated people on the roster, who in turn call other designated people, and so on. Each approach has both advantages and disadvantages. The hierarchical system is quicker because more people are calling at the same time, but the message can become distorted as it is passed from person to person. The sequential system is more accurate, but slower because a single contact person has to contact each recipient and deliver the message. Fortunately, many automated systems are available to facilitate either approach.

For more information on selecting an automated notification system, read the article by Steven Ross on Tech Target’s page at http://searchdisasterrecovery.techtarget.com/feature/Selecting-an-automated-notification-system-for-data-center-disasters.

The alert roster is used to deliver the alert message A description of the incident or disaster that usually contains just enough information so that each person knows what portion of the IR or DR plan to implement without slowing down the notification process. , which tells each team member his or her expected task and situation. It provides just enough information so that each responder, CSIRT or otherwise, knows what portion of the IR plan to implement without impeding the notification process. It is important to recognize that not everyone is on the alert roster—only those individuals who must respond to a specific actual incident. As with any part of the IR plan, the alert roster must be regularly maintained, tested, and rehearsed if it is to remain effective.

During this phase, other key personnel not on the alert roster, such as general management, must be notified of the incident as well. This notification should occur only after the incident has been confirmed but before media or other external sources learn of it. Among those likely to be included in the notification process are members of the legal, communications, and human resources departments. In addition, some incidents are disclosed to the employees in general, as a lesson in security, and some are not, as a measure of security. Furthermore, other organizations may need to be notified if it is determined that the incident is not confined to internal information resources, or if the incident is part of a larger-scale assault. For example, during the distributed denial-of-service attack on multiple high-visibility Web-based vendors in late 1999, many of the target organizations reached out for help. In general, the IR planners should determine in advance whom to notify and when, and should offer guidance about additional notification steps to take as needed.

Documenting an Incident

As soon as an incident has been confirmed and the notification process is under way, the team should begin to document it. The documentation should record the who, what, when, where, why, and how of each action taken while the incident is occurring. This documentation serves as a case study after the fact to determine whether the right actions were taken and if they were effective. It also proves, should it become necessary, that the organization did everything possible to prevent the spread of the incident. Legally, the standards of due care may offer some protection to the organization should an incident adversely affect individuals inside and outside the organization, or other organizations that use the target organization’s systems. Incident documentation can also be used as a simulation in future training sessions on future versions of the IR plan.

Incident Containment Strategies

One of the most critical components of IR is stopping the incident and containing its scope or impact. Incident containment strategies vary depending on the incident and on the amount of damage caused. Before an incident can be stopped or contained, however, the affected areas must be identified. Now is not the time to conduct a detailed analysis of the affected areas; those tasks are typically performed after the fact, in the forensics process. Instead, simple identification of what information and systems are involved determines the containment actions to be taken. Incident containment strategies focus on two tasks: stopping the incident and recovering control of the affected systems.

The CSIRT can stop the incident and attempt to recover control by means of several strategies. If the incident originates outside the organization, the simplest and most straightforward approach is to disconnect the affected communication circuits. Of course, if the organization’s lifeblood runs through that circuit, this step may be too drastic; if the incident does not threaten critical functional areas, it may be more feasible to monitor the incident and contain it another way. One approach used by some organizations is to apply filtering rules dynamically to limit certain types of network access. For example, if a threat agent is attacking a network by exploiting a vulnerability in the Simple Network Management Protocol (SNMP), then applying a blocking filter for the commonly used IP ports for that vulnerability will stop the attack without compromising other services on the network. Depending on the nature of the attack and the organization’s technical capabilities, ad hoc controls can sometimes gain valuable time to devise a more permanent control strategy. Typical containment strategies include the following:

  • Disabling compromised user accounts

  • Reconfiguring a firewall to block the problem traffic

  • Temporarily disabling the compromised process or service

  • Taking down the conduit application or server—for example, the e-mail server

  • Disconnecting the affected network or network segment

  • Stopping (powering down) all computers and network devices

Obviously, the final strategy is used only when all system control has been lost and the only hope is to preserve the data stored on the computers so that operations can resume normally once the incident is resolved. The CSIRT, following the procedures outlined in the IR plan, determines the length of the interruption.

Consider the chapter-opening scenario again. What if, instead of a fire, the event had been a malware attack? And what if the key incident response personnel had been on sick leave, on vacation, or otherwise not there? Think how many people in your class or office are not there on a regular basis. Many businesses involve travel, with employees going off-site to meetings, seminars, training, vacations, or to fulfill other diverse requirements. In addition, “life happens”—employees are sometimes absent due to illness, injury, routine medical activities, and other unexpected events. In considering these possibilities, the importance of preparedness becomes clear. Everyone should know how to react to an incident, not just the CISO and systems administrators.

Incident Escalation

An incident may increase in scope or severity to the point that the IR plan cannot adequately handle it. An important part of knowing how to handle an incident is knowing at what point to escalate the incident to a disaster, or to transfer the incident to an outside authority such as law enforcement or another public response unit. Each organization will have to determine, during the BIA, the point at which an incident is deemed a disaster. These criteria must be included in the IR plan. The organization must also document when to involve outside responders, as discussed in other sections. Escalation is one of those things that, once done, cannot be undone, so it is important to know when and where it should be used.

Listen webReader by ReadSpeaker Open/close toolbar