Last updated at Wed, 13 Dec 2017 18:44:09 GMT

Synopsis

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

I introduced these standards in the first article in this series and later in this article I started reviewing the incident response life cycle of NIST SP 800-61.

In the previous article, I discussed first two phases of ISO/IEC 27035 incident management cycle. In this article, I continue the review of ISO/IEC 27035 incident management cycle.

Assessment and decision

ISO/IEC 27035-1 defines two-tier assessment approach. First event assessment is done by so called PoC (point of contact) which may not be an incident response team (it can be e.g. helpdesk). The PoC has to follow the SOP (standard operating procedure) to determine whether an event is an incident or not. The standard defines three areas of assessment that influence categorization of an event as an incident:

  • impact domain (physical, logical);
  • affected processes, information and assets;
  • effect on core services of an organization.

Such approach ensures that:

  • false alarms and other non-important events are eliminated from further processing;
  • the incident response team is not being involved in activities not related to real incidents (and thus IRT resources are nor wasted).

The PoC then decides if an event should be passed to the IRT. If yes, the IRT conducts the second assessment, to re-confirm (or change) the PoC event classification. If the event is categorized as an incident, the IRT task is to prioritize and plan relevant activities.

The standard also requires that this phase includes:

  • formal assignment of incident response actions to appropriate persons, together with relevant procedures (it is important to understand that some activities might be conducted outside the IRT and even outside cybersecurity team);
  • proper logging of all actions of the IRT (which is essential for further analysis of IRT performance and for improvement of incident response tools and procedures);
  • electronic evidence gathering.

Responses phase

The plural used for this phase name might sound strange at the beginning, but it correctly emphasizes that there is never a single “incident response”. These are multiple actions and need to be handled and managed correctly.

During this phase, the actions decided on in the previous phase are executed. ISO/IEC 27035-1 differentiates between “crisis” state and “non-crisis” state. It is a very important differentiation in terms of business continuity management. Many incidents, although serious, do not threaten business continuity and as such do not require crisis handling procedures to be activated. It is important not to activate “global crisis” if there’s no real reason for it. So, if the IRT is capable of taking control of an incident, it should handle the incident and ensure the organization has recovered from the incident. If it is not possible, then incident handling should be escalated to crisis handling.

There are separate ISO standards covering business continuity. These are out of the scope of this article, but I strongly suggest you familiarize yourself with them, they might be very useful in your business continuity planning.

As in the previous phase, the standard requires that all IRT actions are properly logged and all incident evidence is gathered and properly secured. Some forensics analysis might also be needed, but only up to the level needed to handle the incident (that is to eradicate its impact or change its priority).

An important part of this phase is incident communication. No communication external to incident response team is needed in previous phases. But while responding to an incident, proper communication from the IRT can be critical. ISO/IEC 27035-1 states that such communication should not only be done internally in the organization, but it should also go to any external organizations that might be needed to handle the incident properly.

Lessons learnt

This phase is used to improve security. Each incident, after it’s closed, must be used to learn from it and improve:

  • security tools, configurations and procedures (called “controls” in ISO naming);
  • cybersecurity risk management processes;
  • incident management processes.

An organization might also decide to share the “learned lessons” with other organizations or security community.

Iterative process

Finally, ISO/IEC 27035-1 states again that “information security incident management activities are iterative”. We all should remember about it.

Besides, all ISO standards related to ensuring quality management (including quality of security) are based on the Deming cycle – Plan, Do, Check, Act. This cycle ensures that all processes undergo constant improvement.

Relation to ISO/IEC 27001

ISO/IEC 27001 is the most important international standard on information security management. Discussion on this standard is out of the scope of this article (I may come back to this standard in one of my Komunity articles in future). ISO/IEC 27001 defines requirements for so-called Information Security Management System (ISMS). This – in short – is a set of procedures (and technical solutions used by these procedures) that are used to plan, maintain and continuously improve information security in an organization. One of ISMS elements is incident management. And the goal of ISO/IEC 27035 standard is not only to be used as stand-alone systematic guidance for information security incident management. Its second goal is to help fulfill requirements set by ISO/IEC 27001 in this area. To help ISO/IEC 27035 achieve this goal, a reference table is included in ISO/IEC 27035, cross-referencing this standard with ISO/IEC 27001.

So, which one to use? NIST SP 800-61 or ISO/IEC 27035?

Firstly, in my opinion, both of them can be effectively used to build and maintain effective incident management processes and teams.

If your organization is dealing with European (or other international) businesses it might be easier to find a common language of communication on incident management if it’s based on an ISO standard instead of NIST recommendation.

Also, an important factor is certification. Increasing number of organizations get certified for ISO/IEC 27001 information security management standard. It is not only a way to have set of processes in place to properly manage cybersecurity, but also a way to communicate outside that cybersecurity has been properly taken care of (without revealing details of security techniques used). One can assume that in future also certification for other ISO cybersecurity standards will be available. So, looking from this point of view, it is wise to go in ISO direction.

You should discuss it internally and make a choice that is best for your organization in terms of its business goals.

What next?

In next articles in this series, I will discuss in more detail the second part of this standard – ISO/IEC 27035-2, formally named “Information technology – Security techniques – Information security incident management – Part 2: Guidelines to plan and prepare for incident response”.

References and further reading

ISO/IEC 27035-1 (Principles of incident management)
ISO/IEC 27035-2 (Guidelines to plan and prepare for incident response)
Introduction to Incident Response Life Cycle of NIST SP 800-61