ISO/IEC 27035-1
ISO/IEC 27035-1:2023 — Information technology — Information security incident management — Part 1: Principles and process
(second edition)
Abstract
ISO/IEC 27035 part 1 “is the foundation of the ISO/IEC 27035 series. It presents basic concepts, principles and process with key activities of information security incident management, which provide a structured approach to preparing for, detecting, reporting, assessing, and responding to incidents, and applying lessons learned.
The guidance on the information security incident management process and its key activities given in [ISO/IEC 27035-1] are generic and intended to be applicable to all organizations, regardless of type, size or nature. Organizations can adjust the guidance according to their type, size and nature of business in relation to the information security risk situation. [ISO/IEC 27035-1] is also applicable to external organizations providing information security incident management services.”
[Source: ISO/IEC 27035-1:2023]
Introduction
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 organisations 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.
The ISO/IEC 27035 standards concern managing information security events, incidents and vulnerabilities, expanding on the information security incident management section of ISO/IEC 27002.
The standards describe a 5-phase process:
Prepare to deal with incidents e.g. prepare an incident management policy, and establish a competent team to deal with incidents;
Identify and report information security incidents;
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;
Respond to incidents i.e. contain them, investigate them and resolve them;
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.
Scope
Part 1 outlines the concepts and principles underpinning information security incident management and introduces the remaining part/s of the standard. It describes an information security incident management process consisting of five phases, and says how to improve incident management.
Structure
Main sections:
4: Overview
5: Process
Annex A: Relationship to investigative standards
Annex B: Examples of information security incidents and their causes
Annex C: Cross-reference table of ISO/IEC 27001 to the ISO/IEC 27035 series
Annex D: Considerations of situations discovered during the investigation of an incident
Status
The first edition of ISO/IEC 27035 was published as a single standard in 2011, replacing ISO TR 18044.
It was subsequently split into four parts ...
The current first edition of part 1 was published in 2016.
Having been revised for ISO/IEC 27002:2022, the second edition was published in 2023.
Commentary
Information security incident management is described overall, and then as a process with five phases:
Plan and prepare: establish an information security incident management policy, form an Incident Response Team etc.
Detect and report: someone has to spot and report “events” that might be or turn into incidents;
Assess and decide: someone must assess the situation to determine whether it is in fact an incident;
Respond: contain, eradicate, recover from and forensically analyse the incident, where appropriate;
Learn lessons: make systematic improvements to the organisation’s management of information 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.
In addition to actual events and incidents, we should be systematically exploring and learning from near-misses i.e. situations that thankfully caused little if any impact on the business, such as:
An alert worker noticing and reporting a phishing or Business Email Compromise attack;
An infection by defective/nonfunctional malware or scareware;
A colleague spotting confidential papers left on someone’s office desk after they have gone home, and tidying them away;
A manager casually disclosing a commercially-sensitive detail in conversation with a supplier or competitor who appears not to have noticed it;
A neighbouring office being ram-raided, burgled, vandalised, burnt or flooded;
A competitor, business partner, customer or supplier suffering a noteworthy incident;
Any incident from which the organisation successfully recovered e.g. by restoring backups;
Incidents that, by sheer good fortune, were trivial (incidental!), and could easily have been much worse e.g. if they had occurred at a different time or day or point in the business cycle, in other circumstances, or if they had not been spotted so soon.
Although, in the absence of significant impacts and with finite resources already stretched by other priorities, it is tempting for management simply to ignore close-shaves and minor incidents, they present opportunities to:
Identify and study information risks (threats, vulnerabilities, exposures, impacts ...) that might otherwise have remained unrecognised or ignored;
Evaluate the risk management approach, particularly the associated decisions and controls;
Tease out and address specific or indeed general weaknesses with the approach, making improvements;
Gain assurance on the aspects that worked well, or at least went to plan;
Generate case study materials for awareness and training purposes, and information to feed into future risk assessments, including statistics/metrics.
We might not be quite so lucky next time! The aviation industry is a shining example of this approach, with a comprehensive no-blame strategy to identify, report, address and improve as a result of [literal and figurative] near-misses.
Notwithstanding the title, the ISO/IEC 27035 standards specifically concern incidents affecting IT systems and networks although the fundamental 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 an opportunity squandered: ISO27k covers more than IT/cybersecurity. How are organisations meant to handle incidents such as fraud and piracy where the IT elements are incidental to the business?
Explicitly describing the information risks that the incident management process addresses would enhance this standard, I feel. Since it is literally impossible to detect and respond to every single incident, a proportion of the risk has to be accepted (e.g. ‘low and slow’ attacks fly under the radar, while many hacks and malware attacks involve deliberately evading or neutralising both detective and preventive controls), while some might be shared with third parties (e.g. business partners and insurers) or avoided (e.g. by putting even more emphasis on preventive controls). Also, the response to a major incident may well involve invoking business continuity arrangements, hence this standard should in my opinion integrate with or properly cite ISO 22301 etc.