Last updated at Wed, 13 Dec 2017 19:57:24 GMT

Synopsis

In the series of articles titled “Incident Response Life Cycle in NIST and ISO standards” we review incident response life cycle, as defined and described in NIST and ISO standards related to incident management.

We introduced these standards in the first article in this series.

In previous article in this series we discussed the “Preparation” phase of the incident response life cycle as described in NIST Special Publication (SP) 800-61.

In this article we are discussing the second phase of this cycle – “Detection and analysis” phase.

Purposes of “Detection and analysis” phase

The main purposes of this phase are to determine whether the incident is really occurring and analyze its nature. These might not be easy tasks.

NIST SP 800-61 lists several steps of “Detection and analysis” phase. These are:

  • noticing signs of an incident (called “precursors” and “indicators”);
  • analyzing these signs;
  • documenting the incident;
  • prioritizing incidents;
  • incident notification.

At this stage of incident response life cycle incident response team should not yet try to eradicate the incident. It is very important not to start eradication activities without proper incident analysis. If this rule is not observed, the incident response team might waste time and resources on activities that are directed against events that turn out not to be an incident.

For example, incident handling team should not react emotionally to user reports of problems with email service and jump into action assuming that this service is attacked. Each such report should be carefully listened to and noted (preferably in incident reporting and handling management system), but actions should be taken only if analysis results indicate that an incident is occurring.

“Precursors” and “indicators” – signs of an incident

NIST recommendation document divides signs of an incident into two groups – “precursors” and “indicators”.

“Precursors” indicate that incident may occur in future. “Indicators” give information that incident might have occurred or is happening now.

A simple example of a precursor might be contents of the web server log showing usage of vulnerability scanner.

A simple example of an indicator might be antivirus software alert.

Precursors can be used to prevent incident from occurring (by e.g. blocking the source of vulnerability scanning). However, it is rare that precursors for actual incidents are available for incident response team. The most common situation is that what users and/or incident response team sees first are indicators – signs that the incident is occurring now.

NIST SP 800-61 lists several different possible sources of precursors and indicators. This list can be used by your incident response team to check whether you maintain comprehensive list of precursors and indicators sources. On the other hand, you should keep them in relation to what your incident response team can really handle. Indicator sources that cannot be analyzed are worthless.

Analyzing precursors and indicators

Indicator sources can produce thousands (or more) alerts a day. Many of them can be false positives. Users can also report large numbers of indicators. All these signs need to be analyzed to determine whether a real incident is occurring. And, as NIST document states, incident handlers face information that is often “ambiguous, contradictory, and incomplete”.

Detecting a real incident can be achieved by using a combination of:

  • technical tools;
  • standard operating procedures (SOPs) – with a dose of flexibility;
  • knowledgeable and experienced team.

Technical tools are used to generate indicators and possibly perform initial analysis of an indicator. Example of such tools could be IDS/IPS systems, packet sniffers, log analyzers, cryptographic hash (checksum) verification software. Security automation software can be also a useful tool here – see below.

SOPs are used to standardize approach to diverse classes of incidents. Some of them could be automated.

Technical tools and SOPs must be maintained and controlled by a knowledgeable and experienced team that undertakes final decision on whether what is indicated as an incident is indeed one.

Automating analysis of “technical” precursors and indicators

It is worth noting that precursors and indicators can be of “technical” or “human” type. The simple examples given above are a technical precursor and a technical indicator.

Such technical signs of an incident can be an input to a security automation software that undertakes initial analysis, leaving incident response team time and resources to be used for analyzing “human” type indicators, that is reports from users within an organization or reports from other organizations (i.e. saying that your organization’s IP addresses are sources of attack).

Different sources of incident indicators can be “fed” into one single security automation software that performs initial analysis based on previously defined criteria and informs humans only if human action or decision is needed.

Attack vectors

NIST SP 800-61 lists several so called “attack vectors”, that is methods of attack. These help categorize incidents.

Since incident handling team should work based on SOPs, these attack vectors might be good starting point to create the first list of SOPs (if creating a new incident handling team) or to categorize existing SOPs and align actions with methods of attack. These attack vectors are for example removable media, web, email, theft (see NIST document for full list).

Prioritizing incidents

As NIST recommendation states, prioritizing incidents is critical for proper incident handling. Using incident response team resources for incidents that should be low priority can create a serious risk that important incidents are not handled properly or at all. Each event that after initial analysis is categorized as incident, should be assigned a priority. Incidents should be served based on priority.

NIST recommends prioritizing incidents based on:

  • functional impact (impact of the incident on internal business processes);
  • information impact (impact of the incident on confidentiality, integrity and availability of information);
  • recoverability (resources and time needed to recover from the incident).

An example of an incident that should get high priority for handling is an incident with high functional impact and high (that is simple) recoverability.

It is important to note that process of prioritizing incidents will be hard to automate, because it requires much human input and human decisions. It might also require input from people outside the incident response team. So we do not recommend automating this process, as automating it might have adverse effects on effectiveness of incident handling process.

Documenting incidents

Each incident should be fully documented internally. Which part of these data is to be reported outside the organization is the matter of separate decision.

Documenting an incident consists of:

  • detailed documenting of each step taken to handle the incident;
  • saving data, files, system states, messages, media, network traffic flows and any other electronic data in any form that is related to the incident.

Documenting incidents serves two purposes:

  • improving incident handling processes (SOPs);
  • saving evidence that might be needed to improve security of organization’s systems/data – or to be used as evidence in court of law if legal actions takes place later.

Incident documentation and data might contain sensitive information and should be protected accordingly.

Reporting incidents

Incident handling SOPs should contain incident notification and reporting section. Each incident should be appropriately reported internally and some incidents should be reported externally.

NIST SP 800-61 lists most important persons, departments and entities that should be notified.

It is worth remembering that security incidents are not only technical events: they touch HR, public relations, legal department etc.

Also, as we noted already, there are legal obligations related to incident notification – your incident response team and your organization should familiarize themselves with these obligations and act accordingly.

(In next articles in these series, we will be discussing further phases of NIST SP 800-61 incident response life cycle.)

References and further reading

NIST SP 800-61 – Computer Security Incident Handling Guide

How to Create Security Processes That Solve Practical Problems

Recommendations for Incident Response Team of NIST SP 800-61

Introduction to Incident Response Life Cycle of NIST SP 800-61

Preparation Phase of Incident Response Life Cycle of NIST SP 800-61