Last updated at Wed, 13 Dec 2017 18:47:51 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 three articles in this series, I introduced and discussed ISO/IEC 27035-1 standard, formally named “Information technology – Security techniques – Information security incident management – Part 1: Principles of incident management”.

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 start a short review of ISO/IEC 27035-2.

Information security incident management policy

This the most important high-level document covering incident handling. It should be created first and any detailed plans should be created based on this policy, and not the other way round. The policy should be signed by top management and should have constant top management commitment.

ISO/IEC 27035-2 gives detailed guidelines on the incident management policy content. This guidelines can be directly used to formulate such policy. Of course it should be adjusted to organization’s goals, size, operating characteristics etc.

The policy is a public document and it should be known to all employees and contractors.

ISO/IEC 27035-2 states that information security incident management policy should address:

  • the importance of incident handling;
  • management commitment;
  • an overview of security events assessment approach;
  • an overview of incident management cycle;
  • the importance and approach to incident actions logging;
  • the importance and approach to evidence gathering and preservation;
  • an overview of vulnerabilities and events/incidents reporting;
  • responsibility and access to detailed procedures;
  • an overview of the incident response team (IRT);
  • an overview of awareness and training programs;
  • legal aspects.

It is important to remember not get into details when preparing such policy. Its purpose is not to be a procedure or sets of procedures. Its purpose is to be, say, a management-level statement on incident handling approach.

The policy should be written in a language and using notions that are clear for a reader from any department and any level in the organization. An organization might decide that each employee and contractor commits to such policy by signing it.

The information security incident management policy should not live “separate life” from other policies related to information security (cybersecurity). It is related to (or can be a part of) general information security policy. It is also related to business continuity policy. These relationships should be properly taken care of.

Information security incident management plan

ISO/IEC 27035-2 gives also detailed guidelines for the information security incident management plan. This is detailed, internal document, containing standard operating procedures for incident handling.

The information security incident management plan, although it contains word “incident” in its name, is activated earlier than incident is detected. It is activated always when:

  • an information security event is detected;
  • an information security vulnerability is detected.

The plan must cover procedures for:

  • vulnerability reporting;
  • event/incident reporting;
  • incident handling cycle.

ISO/IEC 27035-2 details the contents of an information security incident management plan. For these details, please refer to the standard.

I’d like to comment here on a couple of chosen important items related to this plan, as detailed in the standard:

For “Plan and prepare phase”:

  • vulnerability/event/incident central database is a must – effective incident handling is impossible without one;
  • event/incident classification must be defined upfront – it is essential to decide and prioritize (the standard helps with examples of classification, which are given in an annex – these can be easily adopted to specifics of an organization);
  • escalation procedures must be defined – this is critical point sometimes, too early escalation means too much resources consumed for no reason, too late escalation might mean serious adverse effects;
  • procedures fo the decision on attacker surveillance must be defined – again here a balance needs to be found between evidence gathering and risk to the organization.

For “Detection and reporting” phase:

  • procedures should be included in the incident management plan so that all detected events should be recorded in the incident/event database – but this does not mean that all irrelevant events should also be recorded; an IRT can’t be flooded with information that it is unable to handle (you can consider security automation software to help the IRT automate initial filtering of information);

For “Assessment and decision” phase:

  • procedures should be included in the incident management plan that separate activities of the PoC (point of contact) from activities of the IRT; the goal is to free the IRT from initial assessment (and save IRT resources for more demanding tasks).

For “Responses” phase:

  • a “map” of all internal and external entities/teams/departments involved in incident handling should be a part of procedures in this part of incident management plan – this is very important, the incident handling process is managed by the IRT, but many other parties are involved and without proper procedural plan the incident response might become chaotic;
  • the standard states that even for unforeseen types of incidents, the response should be structured – to it is wise to assign an incident response procedure to events/incidents that cannot be classified using existing scheme.

For “Lessons learnt” phase:

  • a method of measurement of incident response (handling) effectiveness should be a part of incident handling plan – it is very important that such method is applied regularly to IRT activities (please remember that this cannot be something very simple, as e.g. response time, because such simple parameters are only part of the equation).

What next?

In next article, I will discuss further guidelines and requirements set in ISO/IEC 27035-2.

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