NIST SP 800-61

Even though information security professionals plan to effectively manage risk, incidents still occur. NIST SP 800-61 is the National Institute of Standards and Technology (NIST) special publication that gives guidelines for organizations on how to handle security incidents. Read section 2.2 on page 6 to learn more about the need for, and the benefits of, an incident response capability. Also read section 3 on pages 21-44 to learn how to appropriately handle information security incidents. Before you move on, make sure you can explain the four stages of the incident response process: preparation; detection and analysis; containment, eradication, and recovery; and post-incident activity.

Handling an Incident

2.2. Signs of an Incident

For many organizations, the most challenging part of the incident response process is accurately detecting and assessing possible incidents – determining whether an incident has occurred and, if so, the type, extent, and magnitude of the problem. What makes this so challenging is a combination of three factors:

  • Incidents may be detected through many different means, with varying levels of detail and fidelity. Automated detection capabilities include network-based and host-based IDPSs, antivirus software, and log analyzers. Incidents may also be detected through manual means, such as problems reported by users. Some incidents have overt signs that can be easily detected, whereas others are almost impossible to detect
  • The volume of potential signs of incidents is typically high – for example, it is not uncommon for an organization to receive thousands or even millions of intrusion detection sensor alerts per day. (See Section 3.2.4 for information on analyzing such alerts.)
  • Deep, specialized technical knowledge and extensive experience are necessary for proper and efficient analysis of incident–related data.

Signs of an incident fall into one of two categories: precursors and indicators. A precursor is a sign that an incident may occur in the future. An indicator is a sign that an incident may have occurred or may be occurring now.

Most attacks do not have any identifiable or detectable precursors from the target's perspective. If precursors are detected, the organization may have an opportunity to prevent the incident by altering its security posture to save a target from attack. At a minimum, the organization could monitor activity involving the target more closely. Examples of precursors are:

  • Web server log entries that show the usage of a vulnerability scanner
  • An announcement of a new exploit that targets a vulnerability of the organization's mail server
  • A threat from a group stating that the group will attack the organization.

While precursors are relatively rare, indicators are all too common. Too many types of indicators exist to exhaustively list them, but some examples are listed below:

  • A network intrusion detection sensor alerts when a buffer overflow attempt occurs against a database server.
  • Antivirus software alerts when it detects that a host is infected with malware
  • A system administrator sees a filename with unusual characters
  • A host records an auditing configuration change in its log.
  • An application logs multiple failed login attempts from an unfamiliar remote system.
  • An email administrator sees a large number of bounced emails with suspicious content.
  • A network administrator notices an unusual deviation from typical network traffic flows.