Last updated at Wed, 13 Dec 2017 16:12:45 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.

ISO/IEC 27035 is a multi-part standard. Its first part introduces incident management principles. Its second part, ISO/IEC 27035-2, gives detailed guidelines for incident management preparation and planning. It is formally named “Information technology – Security techniques – Information security incident management – Part 2: Guidelines to plan and prepare for incident response”.

In this article, I continue a short review of ISO/IEC 27035-2, which I started here.

The importance of standardized incident forms

The standard stresses the importance of standardized incident form. It should be implemented as electronic form and linked to event/incident database. It should allow reporting all suspicious events related to information processing, including suspected vulnerabilities. It is up to the IRT (Incident Response Team) to decide whether what was reported will be classified as an incident. Every user should be trained to know where to find such form. It is worth remembering that in case of an incident, such form might not be accessible. So alternative methods of reporting should be made available to users for such circumstances.

ISO/IEC 27035-2 recommends that all data gathered and exchanged on events/incidents are processed using some standardized formats (which also influences contents of event/incident reporting form). An example of such standardized format is The Incident Object Description Exchange Format (RFC 5070).

It is worth noting that security automation software could be considered to execute pre-processing of data collected in such forms.

The importance of standardized procedures

I already wrote many times about the importance of standardized procedures (SOP) in incident management. This is again reiterated in ISO/IEC 27035-2.

The incident management procedures should detail actions that are to be taken according to the incident management policy and incident management plan. There should be separate procedures for diverse types of incidents (each type of incident might be handled differently, this is related to e.g. diverse types of technical systems such incident might be related to). Also, there should be a separate procedure for an incident of unknown type, that is an incident that cannot be assigned to any known class of incidents. (Please note that the list of incident types should be defined upfront and then reviewed regularly.)

The standard stresses the importance of evidence handling elements of incident management procedures. One should always remember that there are two goals of incident handling: an immediate goal is incident containment/eradication, but the secondary goal is evidence preservation (which might not be of critical importance for incident containment/eradication but will certainly be critical for any legal action).

And, last but not least, the standard recommends carefully deciding which procedures should be available to all employees and which should not. An attacker might use knowledge of detailed incident handling procedures to his/her advantage.

The importance of trust

In this section, ISO/IEC 27035-2 covers recommendations regarding two issues:

  • building trust to the incident response team;
  • anonymity (or lack of it) when reporting incidents.

The IRT should be a trusted body – so that employees do not hesitate to share event/incident information with the IRT. This trust can be achieved in two ways:

  • providing assurance for all employees that the event/incident information they pass will not be used against them in any way (unless they are the source of a deliberate incident, of course);
  • awareness campaigns for employees teaching them the value of proper incident management.

It should also be decided upfront whether the reporting should be done in an anonymous way, the standard explains pros and cons.

Also, the standard raises one strategic issue in IRT trust area that is often neglected. The standard recommends separating the incident and vulnerability reporting from operational management and to separate the financing of all incident management capabilities from other departments, to minimize the risk of, as it is called, “undue influence”. This matter is very important, because, for example, if the IRT is a part of IT department, the IRT will never be fully independent to investigate incidents that are related to IT department.

Related to trust is the issue of confidentiality of sensitive information that might be processed together with event/incident information. Such confidential information should be properly protected by incident management procedures (and systems used for incident management support). Also, if needed, such information should be anonymized.

Recommendations on Incident Response Team (IRT)

A separate section in ISO/IEC 27035-2 is devoted to the Incident Response Team (IRT). The standard points out that an IRT a.o. contributes to the reduction of various types of damage caused by an incident. So sometimes the role of an IRT might be critical to the survival of an organization.

The standard defines three types of IRTs: dedicated team, virtual team, and mixed team. A dedicated team does not have any other tasks than incident management (i.e. all tasks related to incident management process). Virtual IRT team consists of members who share other duties with incident management duties. A mixed team is an IRT that consists of members of both types. An organization should weigh pros and cons of these approaches and relate team type and size to its needs. Sometimes it’s not an easy task, especially for new organizations, because it is really hard to estimate how much resources will be needed for incident handling. So a virtual IRT team might be a good solution for new organizations or for organizations that start to implement incident management processes.

The standard recommends that an IRT is led by a senior manager (which is also related to the trust remarks above). It is also important to remember that incident management, although often related to IT environment, involves various departments – so an IRT should have members from other departments (e.g. legal, PR).

What next?

In next article, I will discuss ISO/IEC 27035-2 guidelines on awareness, training and incident management plan testing.

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
The Incident Object Description Exchange Format