Last updated at Wed, 13 Dec 2017 15:53:02 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. In the previous article, I reviewed the standard’s guidelines on awareness, training, and incident management plan testing. In this article, I will discuss ISO/IEC 27035-2 guidelines on incident classification and legal/regulatory aspects.

The incident classification guidelines are contained in Annex C of the standard, legal aspects are discussed in Annex A of the standard. Annex B contains example reports and forms. Annexes are “informative” – this means that are not part of the standard itself – their purpose is to support standard implementation.

Why is incident classification important?

There are several reasons, main ones are:

  • categorization directly helps improve incident management;
  • it also helps event/incident long-term analysis;
  • it supports incident information exchange;
  • categorization helps automate event/incident reporting and response.

As for the last item, it is worth noting that security automation software can be used to automate incident reporting and response.

Incident classification and categorization

ISO/IEC 27035-2 describes two example approaches.

Example 1

The standard differentiates incident category and incident class.

Incident class is related to the severity of an incident, so it is also called severity class. The standard proposes four-level severity class scale, from least significant incident to “very serious incident”. Of course, the naming of severity classes is useless without the precise definition of each class. Proposed definitions are given in the standard. It is worth noting that these definitions still need to be adjusted to specifics of an organization. For example:

  • if a part of the definition of class “very serious” is “result in especially serious business loss”, such loss needs also to be defined in numbers when applying the scheme to an organization (otherwise a room would be left for human judgment which should not be the case);
  • if a part of the definition of class “serious” is “lead to important social impact”, such social impact needs also to be precisely defined when applying the scheme to an organization.

The standard helps by additional sections commenting on these matters.

Each incident is assigned a severity class, but it is also assigned a category. In this example approach, ISO/IEC 27035-2 uses example incident categorization based on threats as categorization factor. Examples of categories are: natural disaster, infrastructure failure, technical attack etc.

Example 2

The second example of incident classification/categorization given by ISO/IEC 27035-2 is a bit more complicated.

In this example, incidents are categorized by the loss of confidentiality, integrity or availability.

Classification is done according to adverse consequences of an incident. 1 to 10 scale is used. More precise definitions of classes are given (but these still need inserting details related to an organization). The example classes of adverse consequences are:

  • financial loss;
  • loss of personal data;
  • loss of goodwill.

An interesting approach is used to assign a scale level to adverse consequences related to legal or regulatory obligations. Fine level and prison term period are used to calculate the scale level (e.g. “criminal offense resulting in in penalty between x and y or a prison term of up to two years”). This is actually quite realistic because the level of financial penalty has a direct influence of business (not mentioning imprisonment of a person from the management).

It is important to remember all the time that although security incident management and response activities are often mainly technical ones (at least at the beginning of incident reaction process), the incident management is strongly related to general business activities.

This leads us to:

Legal and regulatory aspects

Annex A of ISO/IEC 27035 contains considerations related to legal and regulatory aspects. These should be included in incident management policy (and in incident management plan). There are several legal aspects of incident management mentioned by the standard. They are related to a.o.:

  • personal data protection;
  • security monitoring legality;
  • employee rights in relation to disciplinary actions;
  • law enforcement requirements;
  • evidence gathering.

As for personal data protection, it is very important not to process (or worse, disclose) any personal data related to an incident, without the consent of the person whose data are processed. Sometimes an incident data contain personal information. Such information should be stripped before further processing (unless it is needed as evidence).

On the other hand, it is critical for successful legal action to preserve as much evidence as possible. So the incident management plan and procedures should include all needed activities to gather, preserve and secure such evidence.

Any disciplinary action included in the incident management policy should be consistent with local regulations on employee relations. There is no purpose in including any actions on paper that cannot be enforced in practice.

Related to employee rights is the issue of security monitoring. Normally technical means are used to monitor activities on employees computers and mobile devices, to automate detection of anomalies and to help automate incident management and response. Such monitoring software also monitors user’s activity, sometimes monitoring is very detailed. It is important to obtain formal consent from employees for such monitoring, if such consent is legally required. If this is not taken care of properly, introducing an incident management plan can have positive effect on incident management, but can introduce serious legal risks.

What next?

In next article, I will attempt to compare NISP SP 800-16 with ISO/IEC 27035.

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
Common Vulnerability Scoring System