Skip to content

Page292

Incident Management

Although this chapter has provided many operational security measures that would aid in the prevention of a security incident, these measures will only serve to decrease the likelihood and frequency with which security incidents are experienced. All organizations will experience security incidents; there is little doubt about this fact. Because of the certainty of security incidents eventually impacting organizations, there is a great need to be equipped with a regimented and tested methodology for identifying and responding to these incidents.

Exam Warning

The exam outline uses the phrase incident management when referencing the process of dealing with security incidents. Note that the terms incident response and incident handling refer to the same process and can be used interchangeably with incident management.

We will first define some basic terms associated with incident management, which, as noted above, is also very commonly referenced as incident response or incident handling. To be able to determine whether an incident has occurred or is occurring, security events are reviewed. Events are any observable data associated with systems or networks. A security incident exists if the events suggest that violation of an organization’s security posture has or is likely to occur. Security incidents can run the gamut from a basic policy violation to an insider exfiltrating millions of credit card numbers. Incident management, incident handling, or incident response are the terms most commonly associated with detailing how an organization proceeds to identify, react, and recover from security incidents. Finally, a Computer Security Incident Response Team (CSIRT) is a term used for the group that is tasked with monitoring, identifying, and responding to security incidents. The overall goal of the incident management plan is to allow the organization to control the cost and damage associated with incidents, and to make the recovery of impacted systems quicker.

Managing Security Incidents

Managing security incidents can be a highly stressful situation. In these high-pressure times it is easy to focus on resolving the issue at hand, overlooking the requirement for detailed, thorough documentation. If every action taken and output received is not being documented, then the incident responder is working too quickly, and is not documenting the incident to the degree that may be required by legal proceedings. It is difficult to know at the beginning of an investigation whether or not the investigation will eventually land in a court of law. An incident responder should not need to recall the details of an incident that occurred in the past from memory: documentation written while handling the incident should provide all necessary details.

Methodology

Different books and organizations may use different terms and phases associated with the incident management process; this section will mirror the terms associated with the examination. Though each organization will indeed have a slightly different understanding of the phases of incident management, the general tasks performed will likely be quite similar among most organizations.

FIG. 8.3 is from the NIST Special Publication 800-61r2: Computer Security Incident Handling Guide (see https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf), which outlines the incident management lifecycle in four steps:*

  1. Preparation
  2. Detection and Analysis
  3. Containment, Eradication, and Recovery
  4. Post-incident Activity

FIG. 8.3 NIST incident management lifecycle [5].