ISO/IEC 27035
ISO27k-aligned security awareness service

ISO/IEC 27035:2011 Information technology — Security techniques — Information security incident management Updated March


Information security controls are imperfect in various ways: controls can be overwhelmed or undermined (e.g. by competent hackers, fraudsters or malware), fail in service (e.g. authentication failures), work partially or poorly (e.g. slow anomaly detection), or be more or less completely missing (e.g. not [yet] fully implemented, not [yet] fully operational, or never even conceived due to failures upstream in risk identification and analysis). Consequently, information security incidents are bound to occur to some extent, even in organizations that take their information security extremely seriously.

Managing incidents effectively involves detective and corrective controls designed to recognize and respond to events and incidents, minimize adverse impacts, gather forensic evidence (where applicable) and in due course ‘learn the lessons’ in terms of prompting improvements to the ISMS, typically by improving the preventive controls or other risk treatments.

Information security incidents commonly involve the exploitation of previously unrecognised and/or uncontrolled vulnerabilities, hence vulnerability management (e.g. applying relevant security patches to IT systems and addressing various control weaknesses in operational and management procedures) is part preventive and part corrective action.

Scope and purpose

The standard covers the processes for managing information security events, incidents and vulnerabilities.

The standard expands on the information security incident management section of ISO/IEC 27002. [The updated 2016 version will cross-reference that section and explain its relationship to the ISO27k eForensics standards.]

Structure and content

The standard lays out a process with 5 key stages:

  1. Prepare to deal with incidents e.g. prepare an incident management policy, and establish a competent team to deal with incidents;
  2. Identify and report information security incidents;
  3. Assess incidents and make decisions about how they are to be addressed e.g. patch things up and get back to business quickly, or collect forensic evidence even if it delays resolving the issues;
  4. Respond to incidents i.e. contain them, investigate them and resolve them;
  5. Learn the lessons - more than simply identifying the things that might have been done better, this stage involves actually making changes that improve the processes.

The standard provides template reporting forms for information security events, incidents and vulnerabilities.

Status of the standard

ISO/IEC 27035 upgraded and replaced ISO TR 18044. It was published in 2011.

ISO/IEC 27035:2011 is currently being revised and extended, splitting it into three parts that are expected to be published in 2016:

ISO/IEC 27035-1: principles of incident management (draft)

Scope & purpose: part 1 outlines the concepts and principles underpinning information security incident management and introduces the remaining two parts. It describes an information security incident management process consisting of five phases, and says how to improve incident management.

Content: the incident management process is described in five phases closely corresponding to the five phases in the first edition:

  1. Plan and prepare: establish an information security incident management policy, form an Incident Response Team etc.
  2. Detection and reporting: someone has to spot and report “events” that might be or turn into incidents;
  3. Assessment and decision: someone must assess the situation to determine whether it is in fact an incident;
  4. Responses: contain, eradicate, recover from and forensically analyze the incident, where appropriate;
  5. Lessons learnt: make systematic improvements to the organization’s management of information security risks as a consequence of incidents experienced.

Annexes give examples of information security incidents and cross-references to the eForensics and ISO/IEC 27001 standards.

Status: at FDIS stage. Some terms differ in the 27035 standards from the definitions stated in ISO/IEC 27000, so be sure to check the definitions when they are published. Updated March

ISO/IEC 27035-2: guidelines to plan and prepare for incident response (draft)

Scope & purpose: part 2 concerns assurance that the organization is in fact ready to respond appropriately to information security incidents that may yet occur. It addresses the rhetorical question “Are we ready to respond to an incident?” and promotes learning from incidents to improve things for the future. It covers the Plan and Prepare and Lessons Learned phases of the process laid out in part 1.

Content: after the usual preamble sections come 8 main clauses:

  1. Establishing information security incident management policy
  2. Updating of information security and risk management policies
  3. Creating information security incident management plan
  4. Establishing an Incident Response Team (IRT) [aka CERT or CSIRT]
  5. Defining technical and other support
  6. Creating information security incident awareness and training
  7. Testing (or rather exercising) the information security incident management plan
  8. Lesson learnt

... plus annexes with incident categorization examples, and notes on ‘legal and regulatory aspects’ (mostly privacy in practice).

Status: at FDIS stage, might possibly surface later this year. Updated March

ISO/IEC 27035-3: guidelines for incident response operations (draft)

Scope & purpose: part 3 offers guidance on managing and responding efficiently to information security incidents, using typical incident types to illustrate the approach. It describes the Detection and Reporting, Assessment and Decision, and Response phases of the process laid out in Part 1, plus Post Incident Activity (an important sixth phase which isn’t actually identified as such in Part 1!).

Content: there are two main clauses covering incident response operations (incident criteria and response processes i.e. monitoring, detecting, assessing, analysing, responding, reporting and learning lessons); and generic examples of common types of incident (such as denial of service and malware incidents). Annexes offer criteria for categorizing incidents and template forms.

The published version may refer to the ISO27k digital forensics standards since incident response is often the first opportunity to identify that a situation may end up in court, hence the forensic process often starts here.

Status: at PDTS stage. This will be a “technical specification” rather than an “international standard” - an obscure change with little real-world impact except that (in theory, at least) it will be possible to update the standard more often, implying that this is a fast moving field of development ...Updated March

Personal comments

Notwithstanding the title, the standards actually concern incidents affecting IT systems and networks although the underlying principles apply also to incidents affecting other forms of information such as paperwork, knowledge, intellectual property, trade secrets and personal information. Unfortunately (as far as I’m concerned), the language is almost entirely IT related. That, to me, represents yet another opportunity squandered: an ISMS includes but goes beyond ‘cyber-security’.

I don’t understand why this standard was split into three: the separate parts are of little value as discrete standards, divorced from the whole. The poor old customers (hey, remember them?) are presumably expected to buy three standards instead of one.

I’m intrigued by the proposed change of part 3 from an IS to a TS. On the one hand, it is just one letter different: I believe the published standard will look basically the same either way. On the other hand, this arcane change will apparently allow the standard to be updated more often ... which seems to me a very odd line of reasoning given that we’ve been operating incident response processes for decades, nay millennia. It’s hardly at the cutting edge of innovation! I smell a rat: perhaps the standard simply needs more work before it is ready to be published (regardless of type), which perhaps hints at problems within the project? Perhaps this is why the standard was split into three?  [Cue conspiracy theorists]

Copyright © 2016 IsecT Ltd.