Schedule for Day 1

Section 01: Course objectives and structure

Section 02: Standards and regulatory frameworks
Section 03: Fundamental principles of information security
Section 04: Information Security Incident Management and ISO/IEC 27035 core processes
Section 05: Context establishment
Section 06: Policies and procedures
Section 07: Risk assessment
Section 08: Incident management plan
Section 09: Establish the IRT
Section 10: Relationships and connections

© 2018 PECB. All rights reserved.

Version 2.1
Eric Lachapelle (Editor)
Documents provided to participants are strictly reserved for training purposes. No part of these documents may
be published, distributed, posted on the internet or an intranet, extracted, or reproduced in any form or by any
mean, electronic or mechanical, including photocopying, without prior written permission from PECB.

1/135
Day 1: Introduction to Information Security Incident Management concepts
Section 01: Course objectives and structure
Section 02: Standards and regulatory frameworks
Section 03: Fundamental principles of information security
Section 04: Information Security Incident Management and ISO/IEC 27035-1 and ISO/IEC 27035-2 core
processes
Section 05: Context establishment
Section 06: Policies and procedures
Section 07: Risk assessment
Section 08: Incident management plan
Section 09: Establish the IRT
Section 10: Relationships and connections
Day 2: Information Security Incident Management process approaches and certification exam
Section 11: Information security awareness and training
Section 12: Detect and alert
Section 13: Collection and reporting of information security events
Section 14: Triage and prioritize
Section 15: Containment, eradication, recovery
Section 16: Forensic analysis
Section 17: Lessons learned
Section 18: Continual improvement
Section 19: Performance evaluation
Section 20: Certification process and closing the training
Certification exam

2/135
 Normative references
1. Main standard references

ISO/IEC 27035-1:2016, Information technology — Security techniques — Information security incident

management — Part 1: Principles of incident management.
ISO/IEC 27035-2:2016, Information technology — Security techniques — Information security incident
management — Part 2: Guidelines to plan and prepare for incident response.
NIST SP 800-61 Revision 2: Computer Security Incident Handling Guide.
ISO/IEC 27000:2018, Information technology — Security techniques — Information security management
systems — Overview and vocabulary.
ISO/IEC 27001:2013, Information technology — Security techniques — Information security management
systems — Requirements.
ISO/IEC 27002:2013, Information technology — Security techniques — Code of practice for information
security controls.
ISO/IEC 27003:2017, Information technology — Security techniques — Information security management
systems – Guidance.
ISO/IEC 27004:2016, Information technology — Security techniques — Information security management –
Monitoring, measurement, analysis and evaluation.
ISO/IEC 27005:2018, Information technology — Security techniques — Information security risk
management.
2. Other standard references

ISO 22300:2018, Security and resilience — Vocabulary.

ISO Guide 73:2009, Risk management — Vocabulary.
ISO 31000:2018, Risk management — Guidelines.

3/135
 List of acronyms and abbreviations
BIA: Business Impact Analysis
BCP: Business Continuity Plan
BS: British Standard
CPD: Continuing Professional Development
CSIRT: Computer Security Incident Response Team
EA: European Co-operation for Accreditation
EDM: Electronic Document Management System
FISMA: Federal Information Security Management Act
FTA: Fault Tree Analysis
HVAC: Heating Ventilation Air Conditioning
IAF: International Accreditation Forum
IDS: Intrusion Detection System
IFAC: International Federation of Accountants
IMS2: Integrated Implementation Methodology for Management Systems and Standards
IPS: Intrusion Prevention System
IRT: Incident Response Team
ISIM: Information Security Incident Management
ISMS: Information security Management System
ISO: International Organization for Standardization
ISP: Internet Service Provider
ISRT: Information Security Response Team
ITIL: Information Technology Infrastructure Library
MBCO: Minimum Business Continuity Objective
NIST: National Institute of Standards and Technology
OS: Operating System
PECB: Professional Evaluation and Certification Board
PoC: Point of Contact
RAM: Random Access Memory
ROI: Return on Investment
ROSI: Return on Security Investment
RPO: Recovery Point Objective

4/135
RTO: Recovery Time Objective
SIEM: Security Information And Event Management
SIMP: Security Incident Management Process
SSD: Solid State Drive
SWOT: Strengths, Weaknesses, Opportunities, Threats
WORM: Write Once Read Many

5/135
6/135
To break the ice, participants introduce themselves stating their:
Name;
Current position;
Knowledge of and experience with information security;
Knowledge of and experience with ISO/IEC 27035 and other standards of the ISO/IEC 27000 family
(ISO/IEC 27002, ISO/IEC 27003, ISO/IEC 27004, ISO/IEC 27005, ISO/IEC 27032, etc.);
Knowledge and experience with other management systems (ISO 9001, ISO 14001, ISO 20000, ISO
22301, etc.);
Course expectations and objectives.
Duration of the activity: 20 minutes

7/135
 In case of emergency, please be aware of exits.
Agree on the course schedule and two breaks (be on time).
Set your smartphone on vibration and if you need to take a call, please do it outside the classroom.
Recording devices are prohibited because they may restrict free discussions.
All training course sessions are designed to encourage every candidate to participate and take the most
out of the training course.
Customer Service
To ensure customer satisfaction and continual improvement, the PECB Customer Service has established a
support ticket system for handling complaints and services for our clients.
As a first step, we invite you to discuss the situation with the trainer. If necessary, do not hesitate to contact the
head of the training organization where you are registered. In all cases, we remain at your disposal to arbitrate
any dispute that might arise between you and the training organization.
To send comments, questions or complaints, please open a support ticket on the PECB website, at the PECB
Help Center (www.pecb.com/help).
If you have suggestions for improving PECB‘s training coursematerials, we would like to hear from you. We read
and evaluate the input we get from our clients. You can do so directly from our KATE application or you can open
a ticket directed to the Training Department on the PECB Help Center (www.pecb.com/help).
In case of dissatisfaction with the training (trainer, training room, equipment, etc.), the examination or the
certification processes, please open a ticket under ―Make a complaint‖ category on the PECB Help Center
(www.pecb.com/help).

8/135
9/135
10/135
This course is primarily based on:
Trainer-led sessions, where interaction by means of questions and suggestions is highly encouraged;
Student involvement through various interactive exercises, notes, discussions (participant experiences)
and so on.
Remember: This course is yours; you are the main contributor to its success.
Students are encouraged to take additional notes.
Exercises and practical examples are essential in helping the candidate understand the fundamental concepts,
principles, processes and approaches of information security incident management. The exercises also help the
candidates prepare for the final exam.

11/135
ISO/IEC 27035-1 & ISO/IEC 27035-2
ISO/IEC 27035-1, Principles of incident management (this document), presents basic concepts and phases
of information security incident management, and how to improve incident management. It combines these
concepts with principles in a structured approach to detecting, reporting, assessing, and responding to
incidents, and applying lessons learnt.
ISO/IEC 27035-2, Guidelines to plan and prepare for incident response, describes how to plan and prepare
for incident response. This part covers the ―Plan and Prepare‖ and ―Lessons Learnt‖ phases of the model
presented in ISO/IEC 27035-1.
NIST SP 800-61 Rev 2
NSIT SP 800-61 Revision 2 Computer Security Incident Handling Guide, provides a set of clear
recommendations for building effective mechanisms for responding to Computer Security Incidents. NIST
developed this guide under their responsibilities under the US Federal Information Security Management Act
(FISMA). The guidance makes reference throughout to US Federal Government, however it is also made clear
that this guide can be used by organizations of all types worldwide. It covers key topic areas, including:
Organizing a Computer Security Incident Response Capability, Handling an Incident along with Co-ordination and
Information Sharing. In addition the appendices provide scenarios and detailed templates and techniques.
See: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf
ITIL V3
ITIL V3 describes processes, procedures, tasks, and checklists which are not organization-specific, but can be
applied by an organization for establishing integration with the organization's strategy, delivering value, and
maintaining a minimum level of competency. It allows the organization to establish a baseline from which it can
plan, implement, and measure. It is used to demonstrate compliance and to measure improvement.

12/135
ITIL Incident Management aims to manage the lifecycle of all Incidents. It distinguishes between Incidents
(Service Interruptions) and Service Requests (standard requests from users, e.g. password resets). Service
Requests are not fulfilled by Incident Management; instead there is a new process called Request Fulfilment.
The framework defines a dedicated process for dealing with emergencies ("Handling of Major Incidents").
Furthermore a process interface was added between Event Management and Incident Management. Significant
Events are triggering the creation of an Incident.
COBIT (1994+)
Developed by the ISACA and the ITGI, CobiT (Control Objectives for Business and related Technology) is a
reference frame to manage the governance of information systems. CobiT provides information technology
managers, auditors and users with indicators, processes and best practices to help them maximize advantages
stemming from the information technologies recourse and the elaboration of the governance and the control of a
company.
ENISA - Good Practice Guide for Incident Management
Developed by ENISA (European Network and Information Security Agency), it is a guideline document that
describes good practices and provides practical information and guidelines for the management of network and
information security incidents with an emphasis on incident handling. The ENISA good practice guide provides a
description of good practices for security incident management. The primary scope of incident management is IT
and information security incidents, i.e., incidents that are limited to computer, network appliances, networks and
the information inside this equipment or in transit.

13/135
The objective of certification exam is to ensure that candidates have understood the Information Security Incident
Management concepts and techniques so that they are able to participate in related project assignments. The
PECB examination committee shall ensure that the development and adequacy of the exam questions are
maintained based on current professional practice.
Both competency domains are covered in the exam. To read a detailed description of each competency domain,
please visit the PECB website.

14/135
Passing the exam is one of the pre-requisites for attaining an “PECB Certified ISO/IEC 27035 Foundation”
professional credential. A second important pre-requisite is to adhere to the PECB Code of Ethics. Considering
that the ISO/IEC 27035 Foundation professional certification is an entry-level credential, it is not required that
candidates have professional experience.
The set of criteria and the certification process are explained in detail at the last day of the training.

15/135
After passing the exam, the candidate has a maximum period of three years to apply for one of the professional
credentials related to the ISO/IEC 27035 certification scheme.
Upon certification, the candidate will receive a notification from the system and the candidate can download the
certificate from the PECB Member Dashboard. At the end of the training, more details will be provided.

16/135
PECB is a certification body for persons, management systems, and products on a wide range of international
standards. As a global provider of training, examination, audit, and certification services, PECB offers its
expertise on multiple fields, including but not limited to Information Security, IT, Business Continuity, Service
Management, Quality Management Systems, Risk & Management, Health, Safety, and Environment.
We help professionals and organizations show commitment and competence by providing them with
valuable education, evaluation and certification against rigorous, internationally recognized standards.
Our mission is to provide our clients with comprehensive services that inspire trust, continual
improvement, demonstrate recognition, and benefit the society as a whole. PECB is accredited by IAS
against ISO/IEC 17024, ISO/IEC 17021, ISO/IEC 17065.
The purpose of PECB, as stated in its Bylaws, is to develop and promote professional standards for certification
and to administer credible certification programs for individuals who practice in disciplines involving the audit and
implementation of a compliant management system. This principal purpose includes:
1. Establishing the minimum requirements necessary to certify professionals, organizations and products;
2. Reviewing and verifying the qualifications of applicants for eligibility to be considered for the certification
evaluation;
3. Developing and maintaining reliable, valid, and current certification evaluations;
4. Granting certificates to qualified candidates, organizations and products, maintaining records, and
publishing a directory of the holders of valid certificates;
5. Establishing requirements for the periodic renewal of certification and determining compliance with those
requirements;
6. Ascertaining that certified individuals meet ethical standards and abide by the PECB Code of Ethics;
7. Representing its members, where appropriate, in matters of common interest;
8. Promoting the benefits of certification to organizations, employers, public officials, practitioners in related
fields, and the public.

17/135
18/135
This section will provide information that will help the candidate gain knowledge about the structure of ISO
standards, namely the ISO/IEC 27000 family, and ISO/IEC 27305 series.

19/135
20/135
Until May 2018, there are 178 published ISO standards on information security (JTC 1/SC 27 technical
committee) including the following examples:
ISO/IEC 9798: This standard specifies a general model including the requirements and constraints for the use of
identity authentication mechanisms. These mechanisms are used to demonstrate that an entity is the one that is
claimed. Details on the different mechanisms are explained in different parts of this standard.
ISO/IEC 11770: This standard defines a general model for key management independent of the cryptographic
algorithm used. This standard addresses both the automated and manual keys and the required sequence of
operations. However, it does not specify details on the protocols needed for the operations.
ISO/IEC 15408 series: The scope of this standard series is the use of it as a basis to evaluate the security
properties of IT products and systems. A free electronic copy can be downloaded from the ISO website.
It contains the following parts:
Part 1: Introduction and general model;
Part 2: Security functional components;
Part 3: Security assurance components.
ISO/IEC 21827: This standard specifies the Systems Security Engineering - Capability Maturity Model® (SSE-
CMM®), which describes the essential characteristics of an organization's security engineering process that must
exist to ensure good security. ISO 21827 does not prescribe a particular process or sequence, but captures
practices generally observed in industry. The objective is to facilitate an increase of maturity of the security
engineering processes within the organization.
ISO/IEC 24761: This standard specifies the structure and elements of a mechanism for authentication using
biometrics in the verification process.
ISO/IEC 27033-1: This standard provides an overview of network security and related definitions. It defines and
describes the concepts associated with network security. The various parts of ISO/IEC 27033-1 address specific
topics related to network security.

21/135
The ISO/IEC 27000 family is continually and progressively publishing standards since 2005 due to international
workgroup reflections dedicated to the information security scope. ISO/IEC 27001 is the only certifiable standard
of the ISO/IEC 27000 family; other standards are only guidelines.
ISO/IEC 27000: This information security standard provides the basic concepts as well as the vocabulary
that applies when analyzing Information Security Management Systems (ISMS). A free copy of this
standard can be downloaded from the ISO website.
ISO/IEC 27001: This information security standard defines the requirements of the Information Security
Management Systems (ISMS).
ISO/IEC 27002 (previously ISO 17799): Guide of best practices for the management of information
security. This standard defines objectives and recommendations in terms of information security and
anticipates meeting global concerns of organizations relating to information security for their overall
activities.
ISO/IEC 27003: Guide for implementing or setting up an ISMS.
ISO/IEC 27004: Guide of metrics to facilitate ISMS management; it provides a method to define the
objectives for implementation and effectiveness criteria of follow-up and evolution measurements all
through the process.
ISO/IEC 27005: Guide for information security risk management which complies with the concepts, models
and general processes specified in ISO/IEC 27001.
ISO/IEC 27035-1: Principles of incident management.
ISO/IEC 27035-2: Guidelines to plan and prepare for incident response.

22/135
ISO/IEC 27035-1 provides guidance to plan, implement, manage and improve a process for incident
management for an organization in the context of the implementation of an Information Security Management
System (ISMS). This standard provides additional information on security controls described in ISO/IEC 27001
and ISO/IEC 27002. It should be noted that an organization has no obligation to follow the ISO/IEC 27035-1
recommendations in preparation for the ISO/IEC 27001 certification.
ISO/IEC 27035-1, clause 1 Scope
Thispart ofISO/IEC 27035 is the foundation of this multipart International Standard. It presents basic concepts and
phases of information security incident management and combines these concepts with principles in a structured
approach to detecting, reporting, assessing, and responding to incidents, and applying lessons learnt.
The principles given in this part of ISO/IEC 27035 are generic and intended to be applicable to all organizations,
regardless of type, size or nature. Organizations can adjust the guidance given in this part ofISO/IEC
27035according to their type, size and natureof business in relation to the information security risk situation. This
part ofISO/IEC27035 is also applicable toexternal organizations providing information security incident
management services.

23/135
ISO/IEC 27035-2 provides guidance to plan, implement, manage and improve a process for incident
management for an organization in the context of the implementation of an Information Security Management
System (ISMS). This standard provides additional information on security controls described in ISO/IEC 27001
and ISO/IEC 27002. It should be noted that an organization has no obligation to follow the ISO/IEC 27035-2
recommendations in preparation for the ISO/IEC 27001 certification.
ISO/IEC 27035-2, clause 1 Scope
This part of ISO/IEC 27035 provides the guidelines to plan and prepare for incident response. The guidelines are
based on the ―Plan and Prepare‖ phase and the ―Lessons Learned‖ phase of the ―Information security incident
management phases‖ model presented in ISO/IEC 27035-1.
The major points within the ―Plan and Prepare‖ phase include the following:
information security incident management policy and commitment of top management;
information security policies, including those relating to risk management, updated at both corporate level
and system, service and network levels;
information security incident management plan;
incident response team (IRT) establishment;
establish relationships and connections with internal and external organizations;
technical and other support (including organizational and operational support);
information security incident management awareness briefings and training;
information security incident management plan testing.
The principles given in this part of ISO/IEC 27035 are generic and intended to be applicable to all organizations,
regardless of type, size or nature. Organizations can adjust the guidance given in this part of ISO/IEC 27035
according to their type, size and nature of business in relation to the information security risk situation. This part of
ISO/IEC 27035 is also applicable to external organizations providing information security incident management
services.

24/135
Whilst ISO/IEC 27001 specifies a clause on Information Security Incident Management, it still does not offer a
complete and comprehensive way of handling all types of Information Security Incidents. Indeed, an organization
could comply with and be certified to ISO/IEC 27001 (including clause A16) but this does not mean they will
address the different types of incidents that may occur. This course proposes a comprehensive incident
management approach which will also fulfil the requirements of ISO/IEC 27001 and other related standards.

25/135
26/135
27/135
28/135
Founded in 1901, NIST is a non-regulatory federal agency within the US Department of Commerce. NIST's
mission is to promote U.S. innovation and industrial competitiveness by advancing measurement in science,
standards, and technology in ways that enhance economic security and improve quality of life. One of the areas
where NIST is focused is Cybersecurity. It has a program dedicated to assisting organizations to comply with the
US Federal Information Security Management Act (FISMA) and it has developed a number of specific standards
and guidelines in this area. See: http://csrc.nist.gov/groups/SMA/fisma/
NIST SP 800-61 Revision 2 Computer Security Incident Handling Guide provides a set of clear recommendations
for building effective mechanisms for responding to Computer Security Incidents. NIST developed this guide
under their responsibilities based on the US Federal Information Security Management Act (FISMA). This
guidance is intended primarily for the US Federal Government; however, it can be used worldwide by all types of
organizations. It covers areas such as: organizing a Computer Security Incident Response capability, handling an
Incident along with co-ordination and information sharing. In addition, the appendices provide scenarios and
detailed templates and techniques.
See: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf

29/135
A number of different standards, acts, regulations etc. demand an appropriate approach to incident handling:
Payment Card Industry – Data Security Standard (PCI-DSS) – Requirement 10 demands that audit trails are in
place to help detect and investigate incidents, 11.1.2 requires testing of an incident response plan relating to the
detection of an unauthorized wireless access point, 12.5.3 requires documented incident response plans and
12.10 requires that the incident response plan is implemented with the remainder of 12.10 covering the
requirements for testing the plan, ensuring 24/7 response, provision of training, the inclusion of specific alerts and
the requirement for ongoing improvement of the process.
The Health Insurance Portability and Accountability Act requires the implementation of a security program which
includes effective incident management:
http://www.hhs.gov/ocr/privacy/hipaa/faq/securityrule/2002.html
The World Lottery Association – Security Control Standard (WLA-SCS) is a standard for lottery organizations and
includes alignment with ISO/IEC 27001 and the need for robust incident management.
Sarbanes Oxley (SOX) – Section 404 requires controls to detect and respond to frauds. A robust Incident
Management process is necessary to effectively meet these requirements.
The National Institute for Standards and Technology (NIST) – provides guidance implemented in federal
departments (and corporate organizations). NIST 800-61 provides comprehensive incident response
requirements.
The Organization for Economic Co-operation and Development (OECD) has developed ―Guidelines for the
Security of Information Systems and Networks: Towards a Culture of Security”. These guidelines target the
governments worldwide by emphasizing the importance of incident response. This document is currently
undergoing a revision.
See: http://www.oecd.org/sti/ieconomy/2002-security-guidelines-review.htm

30/135
ISO 20000 – Information technology – Service Management – Part 1 – Service management system
requirements includes requirements on Information Security Management and suitable incident response.
Many governments worldwide are implementing Cybersecurity strategies in an effort to manage risk and respond
to incidents. In some cases, this results in mandatory requirements for the public sector organizations, suppliers,
governments and organizations in general. See some examples below:
UK: https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/60961/uk-cyber-security-
strategy-final.pdf
US: http://www.whitehouse.gov/issues/foreign-policy/cybersecurity/national-initiative

31/135
Beginning of the 1990s
An industry in need expressed in terms of better practices and controls to support trade and government in
the implementation and improvement of information security;
Ministry of Commerce and Industry (United Kingdom) forms a working group which included directors with
experience in information security;
Publication of a collective work of advice on the management of information security.
1992
Guide of good practices of the industry (September) initially published as a British Standard Institute (BSI)
publication;
This guide was the basis for the British Standard: BS 7799-1.
1995
BS 7799-1:1995 published as a British standard.
1996 - 1997
Identification of a need to increase the level of confidence in the BS 7799 standard;
The industry request a certification programme for an ISMS.
1998
Launch of the ISMS certification model (Published as BS 7799-2:1998).
1999

Revision of BS 7799-1:1999 (updates and addition of new security controls):

New security controls: e-commerce, mobile IT, third-party agreements;
Suppression of specific references to United Kingdom.
BS 7799-2:1999 (Alignment of controls to BS7799-1).

32/135
2004
Launch of ISO/IEC TR 18044:2004 Information technology – Security techniques – Information security
incident management
2011
Launch of ISO/IEC 27035 Information technology — Security techniques — Information security incident
management
2012
Launch of NIST Special Publication 800-61
2013
Launch of the new ISO/IEC 27001/2:2013 standards
2016
Launch of ISO/IEC 27035-1:2016 - Information technology — Security techniques — Information security
incident management — Part 1: Principles of incident management
Launch of ISO/IEC 27035-2:2016 - Information technology — Security techniques — Information security
incident management — Part 2: Guidelines to plan and prepare for incident response

33/135
For each of the following statements, please determine if you think that they are true or false and justify your
answer:
1. Information Security Incident Management is more important now than 25 years ago.
2. Information Security Incident Management is only needed to handle breaches of personal or financial data.
3. It is possible to foresee risks and implement appropriate preventive controls, thus reduce the necessity for
an Information Security Incident Management.
4. Information security risk is primarily a matter of perception.
5. It is possible to be completely prepared for all incident types.
6. Information Security Incident Management is part of Business Continuity
7. Information Security Incident Management should be a key focus in the IT department.
8. The business culture indicates that being prepared for incidents is a secondary concern.
9. The implementation of Information Security Incident Management processes can actually create business
opportunities.
Duration of the exercise: 20 minutes
Comments: 15 minutes

34/135
35/135
This section will provide information that will help the candidate gain knowledge about information, assets and
information security. Particular attention will be paid to availability, confidentiality, integrity, vulnerability, threat,
and impact, whereby examples for each will be provided. Lastly, the candidate also will learn about security
objectives and controls and how they are classified.

36/135
ISO/IEC 27000, clause 3.35 Information system
Set of applications, services, information technology assets, or other information-handling components.
ISO/IEC 27001, Annex A.8 defines the objectives for the security control linked to the management of assets.
ISO/IEC 27001, Annex A.8 Asset Management
A.8.1 Responsibility for assets
Objective: To identify organizational assets and define appropriate protection responsibilities.
A.8.1.1 Inventory of assets
Control: Assets associated with information and information processing facilities shall be identified and an
inventory of these assets shall be drawn up and maintained.
A.8.1.2 Ownership of assets
Control: Assets maintained in the inventory shall be owned.
A.8.1.3 Acceptable use of assets
Control: Rules for the acceptable use of information and of assets associated with information and information
processing facilities shall be identified, documented and implemented.
A.8.1.4 Return of assets
Control: All employees and external party users shall return all of the organizational assets in their possession
upon termination of their employment, contract or agreement.

37/135
ISO/IEC 27002, clause 0.2 Information security requirements
It is essential that an organization identifies its security requirements. There are three main sources of security
requirements:
a. the assessment of risks to the organization, taking into account the organization’s overall business strategy
and objectives. Through a risk assessment, threats to assets are identified, vulnerability to and likelihood of
occurrence is evaluated and potential impact is estimated;
b. the legal, statutory, regulatory and contractual requirements that an organization, its trading partners,
contractors and service providers have to satisfy, and their socio-cultural environment;
c. the set of principles, objectives and business requirements for information handling, processing, storing,
communicating and archiving that an organization has developed to support its operations.
Resources employed in implementing controls need to be balanced against the business harm likely to result from
security issues in the absence of those controls. The results of a risk assessment will help guide and determine
the appropriate management action and priorities for managing information security risks and for implementing
controls selected to protect against these risks.
ISO/IEC 27005[11] provides information security risk management guidance, including advice on risk assessment,
risk treatment, risk acceptance, risk communication, risk monitoring and risk review.

38/135
Other definitions from ISO/IEC 27000:
3.6 Authenticity: Property that an entity is what it claims to be
3.23 Governance of information security: system by which an organization’s information security activities are
directed and controlled
3.26 Information need: insight necessary to manage objectives goals, risks and problems
3.27 Information processing facilities: any information processing system, service or infrastructure, or the
physical location housing it
3.29 Information security continuity: Processes and procedures for ensuring continued information security
operations
3.32 Information security incident management: Set of processes for detecting, reporting, assessing,
responding to, dealing with, and learning from information security incidents
3.34 Information sharing community: Group of organizations that agree to share information
Note 1 to entry: An organization can be an individual
3.35 Information system: Set of applications, services, information technology assets, or other information-
handling components
3.48 Non-repudiation: Ability to prove the occurrence of a claimed event or action and its originating entities
3.55 Reliability: Property of consistent intended behaviour and results

39/135
Confidentiality: Ensure that the information is only accessible to authorized individuals (individuals with a real
need).
For example, the personal data of salaried employees must only be accessible by the authorized Human
Resources Department personnel.
Several types of access control can ensure the confidentiality of information. Encryption is an example of such an
access control. It can be used to protect the confidentiality of information. Access controls can be applied at
different levels of an information security management system:
At the physical level (example: locks on doors, filing cabinets, safes, etc.)
At the logical level (example: access controls to information)
Integrity: Data must be complete and intact.
For example: Accounting data must be authentic (complete and exact). The accuracy of information is ensured by
avoiding unjustified alterations of such information.
Many devices manipulating data, including disk drives and other media as well as telecommunications systems,
contain devices for automatic data integrity verification. Data integrity controls are essential in operating systems,
software, and applications. They allow the avoidance of intentional or involuntary corruption of programs and
data.
Integrity controls must be included in the procedures. These contribute to the reduction in the risk of error, theft
and/or fraud. Data validation controls, user trainings, as well as certain controls at the operational level, are good
examples.
Integrity must be analyzed to:
Prevent someone with modification permits from making an error and modifying the data.
Prevent someone without modification permission from making any inaccurate changes.
Prevent any program or application that interacts directly with the "target" information from making any
changes.
Data that is previously stored, must remain unchanged during data transportation.

40/135
Data can experience changes due to:
Storage erosion
Natural or intentional errors
System damages

41/135
Availability: Information must be easily accessible by individuals who need it.
For example, data related to customers must be accessible in the marketing department.
In practice, availability of information requires a control system such as, for example, the backup of data, capacity
planning, procedures and criteria for approval of the systems, the incident management procedures, the
management of removable media, the information processing procedures, the maintenance and testing of
equipment, continuity concept procedures as well as the procedures to control the usage of systems.

42/135
Annex D of ISO/IEC 27005 provides a typology for classification of vulnerabilities which we could use in principle.
However, this list of vulnerabilities should be used with caution. This is not a complete list as new vulnerabilities
occur regularly due to, among other things, evolution and changes in technology.
One must use Annex D of ISO/IEC 27005 as a guide or reminder to help organize and structure the collection and
collation of relevant data on vulnerabilities rather than as a checklist to follow blindly.

43/135
ISO/IEC 27005, clause 8.2.3 (cont’d.)
A threat can arise from within or from outside the organization. Threats should be identified generically and by
type (e.g. unauthorized actions, physical damage, technical failures); then, where appropriate, individual threats
within the generic class identified. This means no threat is overlooked, including the unexpected, but the volume
of work required is limited.
By definition, a threat has the potential to harm assets such as information, processes, and systems and
therefore harm the organization. Threats are associated with the negative aspect of risk, and as such refer to
undesirable occurrences.
In interviews, a simple language should be used to facilitate the discussion on the threats. For example, one can
ask stakeholders for which events they wish to preserve the resources of the organization and provide for this
purpose a list of examples.

44/135
There are many other relevant terms to consider but clearly defining the difference between an information
security event and an information security incident is key.

45/135
Here is a list of several potential impacts (see ISO/IEC 27005, Annex B.2) that can affect either availability,
integrity, confidentiality or a combination of them:
1. Financial losses;
2. Loss of assets or their value;
3. Loss of customers and suppliers;
4. Lawsuits and penalties;
5. Loss of competitive advantage;
6. Loss of technological advantage;
7. Loss of efficiency or effectiveness;
8. Violation of the privacy of users or customers;
9. Service interruption;
10. Inability to provide service;
11. Loss of branding or reputation;
12. Disruption of operations;
13. Disruption of third party operations (suppliers, customers…);
14. Inability to fulfill legal obligations;
15. Inability to fulfill contractual obligations;
16. Endangering safety of staff and users.

46/135
BIA focus

Activities which have to be performed in order to deliver the key products and services which enable an
organization to meet its most important and time-sensitive objectives.
Critical activities are underpinned by resources such as people, premises, technology, information,
supplies and stakeholders.

47/135
RPO is the point in time to which an organization needs to recover its data for a particular application, put in other
terms, how much data loss can be tolerated. For instance, depending on the type and size of the company, the
data backups can be performed hourly, daily or maybe weekly. If the company performs daily backups, it implies
that a decision has been made to tolerate the loss of a week‘s worth of data.
RTO is the amount of time that elapses between the failure occurring and the application/data being recovered
and brought back online i.e. the acceptable amount of downtime.
A business should look at each of its applications in this way and decide what an acceptable RPO and RTO
should be across each of the individual applications. This profiling of applications then provides the basis for
making decisions around the technology.
Once there is an understanding of the recovery requirements for the various applications then the process of
mapping the most appropriate technology to achieve the required recovery profile can begin.
Different technologies will achieve different recovery profiles in terms of RPO and RTO. Typically, tape based
backup and recovery tend to deliver longer RPOs and RTOs and then as technologies such as disk based
backup, remote mirroring, replication and local and global clustering are introduced, the RPO and RTO will
reduce accordingly.
The diagram above highlights how different technology will deliver different RPO and RTO on an application:
Fora set of data saved on a backup tape, the organization iswilling to loseseven daysof data because the
RPO is 7 days.
If the data are used by a very important system, the objective is to restore them in a maximum of 12 hours
(RTO).

48/135
ISO/IEC 27000 - Definitions
3.57 Residual risk: Risk remaining after risk treatment.
Note 1 to entry: Residual risk can contain unidentified risk.
Note 2 to entry: Residual risk can also be referred to as ―retained risk‖.
3.61 Risk: Effect of uncertainty on objectives.
Note 1 to entry: An effect is a deviation from the expected — positive or negative.
Note 2 to entry: Uncertainty is the state, even partial, of deficiency of information related to, understanding
or knowledge of, an event, its consequence, or likelihood.
Note 3 to entry: Risk is often characterized by reference to potential ―events‖ and ―consequences‖
3.62 Risk acceptance: Informed decision to take a particular risk.
Note 1 to entry: Risk acceptance can occur without risk treatment or during the process of risk treatment.
Note 2 to entry: Accepted risks are subject to monitoring and review.
3.63 Risk analysis: Process to comprehend the nature of risk and to determine the level of risk.
Note 1 to entry: Risk analysis provides the basis for risk evaluation and decisions about risk treatment
Note 2 to entry: Risk analysis includes risk estimation.
3.64 Risk assessment: Overall process of risk identification, risk analysis and risk evaluation.
3.66 Risk criteria: terms of reference against which the significance of risk is evaluated.
Note 1 to entry: Risk criteria are based on organizational objectives, and external context and internal
context.
Note 2 to entry: Risk criteria can be derived from standards, laws, policies and other requirements.

49/135
1. Assets and controls can present vulnerabilities that can be exploited by threats.
2. It is the combination of threats and vulnerabilities that can increase the potential effect of the risk.
3. Controls allow the reduction of vulnerabilities. An organization has few alternatives to act against threats.
For example, controls can be implemented to provide protection against system intrusions, but it is difficult
for an organization to take action to reduce the number of hackers on the Internet.

50/135
51/135
This section will provide information that will help the candidate gain knowledge on incident management
definitions, examples, and the key processes of the ISO/IEC 27035 series.

52/135
When Information Security practitioners use the word incident or event, it often causes confusion in the IT Service
Management space. This is largely due to the fact that the IT Infrastructure Library (ITIL) defines events and
incidents in a generic IT sense. Information Security incidents and events are similar when considering the ITIL
definitions above but are a specialist subset of general incidents. In an ITIL compliant environment, Information
Security Management is a key requirement and Information Security Incident Management could be linked to the
wider ITIL incident management processes. The key point to consider is that due to their sensitivity, the details of
security incidents may need to be limited to certain people and handled in a manner commensurate with the
sensitivity.

53/135
Grupe accessed the company‘s network one last time and deleted essential files. He also removed the admin
accounts and changed the password on some others. He deleted the log files and before handing it in, wiped the
hard-disk of his laptop to cover his tracks. After some time, the network began to act erratically, and the IT staff
found out that they were locked out and could not restore the network. They eventually managed to gain access
to the system by rebooting it and hired an outside consulting firm to find out what went wrong. The firm was able
to retrieve the log files that and found out about Grupe‘s crime.

54/135
On September 7, 2017, Equifax announced that it had suffered a major data breach, in which around 143 million
consumers in the US, UK and some parts of Canada had their personal data compromised. The incident
occurred due to an exploit in the open source Apache Struts framework named CVE-201709805, which allowed
arbitrary code execution. This specific vulnerability was publicly announced on April 9, 2017 and a patch that
contained fix instructions was released immediately. Equifax failed to update their systems in a timely manner,
therefore at the time when the breach occurred, which was estimated to be around July, their system was still
unpatched.
What makes this data breach highly dangerous is not its size but the content of the leaked data. The leaked data
forms a complete profile of its customers, allowing for the perpetrators to use it for identity theft. Data like this
hold enormous value in the black market. The consequences of this breach are massive and will be long-lasting,
possibly for the decades to come.

55/135
56/135
57/135
The PECB Security Incident Management Framework is based on the principles of ISO/IEC 27035 series and
describes the steps through which an organization undertake in order to establish an effective Security Incident
Management Process along with the processes to be used in the event of an incident. It also covers how to
approach lessons learned and continuous improvement together with the overall on-going processes, which are
needed to support the Incident Management Framework even when not in use. This includes the need for
effective communication and overall testing, monitoring and review of the process.

58/135
ISO/IEC 27035-2 clause 4.3 highlights the importance of a clear and effective policy regarding Information
Security Incident Management. The policy should consider:
Management commitment: Senior management must support the initiatives stated in the policy and ensure that
all members of the organization understand the value and importance of an effective policy and associated
processes in this area. When an incident occurs, no one should be in any doubt about the importance of the
policy and should work in conformity to the requirements.
Definition of an Information Security incident: This should be clear and unambiguous. Any person in the
organization should be able to identify whether an event or set of events constitute an incident. Having such
clarity is vital for both accurate reporting but also effective response.
Roles and responsibilities: Everyone involved in the organization should clearly understand their roles and
position when it comes to identifying incidents, reporting incidents and responding to incidents.
Collection and preservation of records: During the reporting, response to and analysis of an incident, various
records will be generated. Making clear how the records should be, where the records should be kept, the format
and, most importantly, the security that shall be applied, should all be understood by everyone.
Training and awareness: In general, Information Security awareness is critical to the overall security posture of
an organization. A key part of that raising awareness process needs to include a clear description of what an
incident is and the importance of reporting the incident plus the reporting channel.
Reference to legal, regulatory and contractual requirements: Making sure that people involved in the Incident
Management understand the relevant laws and regulations is critical to having an effective Incident Management
process. Some laws/regulations require incidents to be addressed and reported within a set time frame. From a
contractual point of view, organizations may have requirements to report or handle incidents in certain time
frames dictated by customers.
This policy may be integrated into the overall information security policy or in an overall incident management
policy integrating various aspects such as environmental, health and safety incidents.

59/135
Important note:
Please note that the figure on the slide is explained in the following notes pages.

60/135
1. Detection and reporting

When an event related to information security is detected, the person responsible initiates the detection and
reporting process. This person should follow the procedures and use the report form of the information security
event as indicated in the information security management scheme to bring the information security event initially
to the attention of the operational support group and the management. So, it is essential that all personnel are
aware and have access to guidelines for reporting different types of possible information security events.
2. Initial assessment and decision
The member of the operations support group, who receives the report, should acknowledge the receipt by
completing the information security event report form, save the report in the database of information security
events/incidents and examine it.
This person should seek clarification from the person who produced the report related to the information security
event and collect all additional required and available information from the person who produced the report or any
other source.
Afterwards, the group's operational support person should do an evaluation to determine if the information
security event should be classified as information security incident or if it is a false alarm. If it is determined that
the information security event may be an information security incident and if the group's operational support has
the appropriate level of competence, further evaluation may be conducted. This can result in corrective actions:
for example, emergency protection controls are identified and returned to the competent people so that actions
can be taken.
3. Second evaluation and confirmation of an incident
The second evaluation and confirmation of the decision whether to close the incident event in the category of
information security or not, should be the responsibility of the CSIRT (Computer Security Incident Response
Team). If it is determined that the information security incident is real, then a member of the CSIRT, involving
colleagues if necessary, should do a more thorough evaluation. The aim is to confirm the nature of the
information security incident, how it was done - and what or who it might affect, the impact or potential impact of
the security incident on the business of the organization, an indication of whether the information security incident
is deemed significant or not (using the predetermined security grid of the organization).

61/135
4. Response
In most cases, the next activity of the CSIRT member will be to identify the immediate response actions to
address the information security problem: recording the details on the information security incident form and in
the information security events/incidents database and informing the appropriate persons or groups about the
required actions. This may result in emergency protection measures (e.g., isolating or halting an information
system, service and/or affected network, with the prior approval of the IT manager and/or the appropriate
business manager), and/or identification of protective controls and permanent additional reporting to the
appropriate person or group for action.
If not already done so, the seriousness of the security incident information should be determined using the
predetermined scale of severity of the organization, and if it is sufficiently important, members of the appropriate
senior management should be notified directly. While it is clear that a "crisis" situation should be declared, for
example, the director of business continuity should be notified for possible activation of the business continuity
plan; in addition, the CSIRT director and senior management should also be informed.
Once the CSIRT member has initiated the immediate responses and that the activities of forensic analysis and
communications are completed, a quick recommendation must be made on whether the information security
incident is under control. If necessary, the member may consult with colleagues, the CSIRT director and/or other
individuals or groups.
If confirmation is obtained that the information security incident is under control, then the CSIRT member should
provide all the answers, forensic analysis and subsequent communications required to close the information
security incident and restore normal operations of the affected information system.
Having determined that an information security incident is under control and that it should not be subject to any
"crisis" activities, then the member of the CSIRT should identify whether any additional responses and what
additional responses are required to address the information security problem. This could include the restoring of
affected information system(s), service(s) and/or network(s) to resume their normal operations. He/she should
then record the details related to the information security incident on the information security incident report form
and in the database of events/incidents of information security and notify those responsible to complete the
related actions. Once these actions have been completed successfully, the details should be recorded on the
information security incident report form and in the database of events/incidents of information security.
Afterwards, the information security incident should be closed and the appropriate personnel should be notified.

62/135
The term IRT is going to be used for Incident Response Team throughout the course. However there can be
other terms as seen in quotes below.
There are distinctions between ―Security teams", ―Internal CSIRT‖ and ―Coordinating CSIRT―:
In a security team, the formal responsibility of processing incident activities has been assigned to any
group or section of the organization. No CSIRTs (Computer Security Incident Response Team) has been
established; instead of CSIRTs, the available staff (typically system, network or security administrators) or
a local subsidiary handles security events ad hoc and sometimes, in case of an isolated incident, as part of
their global responsibilities or work assignments.
In an internal CSIRT, the responsibility for dealing with incidents is assigned to a designated group of
individuals.
In the coordinating CSIRT model, the CSIRT coordinates and facilitates the handling of incidents,
vulnerabilities and global information in a variety of internal and external organizations, which may include
other CSIRTs, provider organizations, security experts and even law enforcement agencies.
Source: Software Engineering Institute, Defining Incident Management Processes for CSIRTs: A Work in
Progress
Note on terminology
ISO/IEC 27035-1, clause 3.2 Incident Response Team IRT
Team of appropriately skilled and trusted members of the organization that handles incidents during their lifecycle
Note 1 to entry: CERT (Computer Emergency Response Team) and CSIRT (Computer Security Incident
Response Team) are commonly used terms for IRT.
In this course, the acronym CSIRT is also used for the internal team.

63/135
The IRT may choose to offer multiple services. The services offered by each IRT should be based on the
mission, purpose, and composition of the team. IRT services can be grouped into three categories:
1. Reactive services: These services are triggered by an event or request, such as a report of a
compromised host, wide-spreading malicious code, software vulnerability, or something that was identified
by an intrusion detection or logging system. Reactive services are the core component of IRT work.
2. Proactive services: These services provide assistance and information to help prepare, protect, and
secure constituent systems in anticipation of attacks, problems, or events. Performance of these services
will directly reduce the number of incidents in the future.
3. Security quality management services: These services augment existing and well-established services
that are independent of incident handling and traditionally performed by other areas of an organization
such as the IT, audit, or training departments. If the IRT performs or assists with these services, the IRT‘s
point of view and expertise can provide insight to help improve the overall security of the organization and
identify risks, threats, and system weaknesses. These services are generally proactive but contribute
indirectly to reducing the number of incidents.
Source: Software Engineering Institute, Handbook for Computer Security Incident Response Teams (CSIRTs)

64/135
During an incident, there may be many stakeholders with whom the IRT need to communicate. This can include
different internal teams and senior management. When developing an incident response process, careful
consideration should be given to each internal stakeholder in order to consider what we will communicate and at
what times. We need to ensure that the language, relevance, frequency and means of such communication are
sufficiently considered.
How will we handle questions from the media? When shall we report to our customer and how shall we report to
the customer (we may have certain contractual obligations to consider), do we need to bring in support from ISPs
or software vendors and what about law enforcement? Clearly, confidentiality needs to be considered when
working with ISPs and vendors since we certainly don‘t want to release confidential or sensitive information.
For Law Enforcement, understanding how to report but also who to report to in given circumstances is very
important. If possible, it is strongly recommended that an organization builds strong relationships with law
enforcement, whenever possible.

65/135
Once an information security incident is closed, it is important that the lessons learned related to the processing
of the information security incident are promptly identified and implemented. These lessons may include:
1. New requirements or changed requirements for safeguarding the information security. These safeguards
could be technical or non-technical (including physical). Based on the lessons learned, these controls could
include the need for urgent updating of material for information sessions to raise awareness of information
security (for users and other staff), and the revision and the instant release of guidelines and/or security
standards;
2. And/or changes to processes and procedures for managing incidents of information security, report forms
and database of events/incidents of information security.
Later in this activity, it is necessary to look beyond a single security incident information and check for trends that
might help identify the need for changes in approach to protection measures or changes.

66/135
Identification of security improvements
After one or more incidents have been resolved, new or changed controls can be identified as being required
during the review.
Recommendations and requirements for protective measures may be such that it is not feasible financially or at
the operational level to implement them immediately. In this case, they should appear in the long-term goals of
the organization.
For example, migration to a firewall and more robust security may not be financially feasible in the short term, but
it is necessary to take into account the long-term goals of the information security organization.
Identification of scheme improvements
After the incident has been resolved, the IRT manager or a nominee has to investigate what happened to
evaluate and therefore "quantify" the effectiveness of the overall response to information security incidents. Such
an analysis is to determine which parts of the ISIM plan have worked well and identify where improvements are
required.
An important aspect of the ―post-response‖ analysis is the reintroduction of the information and knowledge in the
ISIM scheme. If the incident is of sufficient severity it is important to plan a meeting with all parties concerned in
the short term after the resolution of the incident while the information is still fresh in memory. Some factors to
consider in this type of meeting include:
a. Did the procedures outlined in the information security incidents plan work as expected?
b. Are there any methods or procedures that would have helped in the detection of the incident?
c. Were any procedures or tools identified that would have been of assistance in the response?
d. Were there any procedures that would have aided in recovering information systems following an incident
identified?
e. Was the communication of the incident to all relevant parties effective throughout the detection, reporting
and response process?
The results of the meeting should be documented and any action agreed should be implemented appropriately.

67/135
Improvement of security:
General improvement of the effectiveness of information security;
Ability to be prepared to respond to a security event or incident.
Good governance:
Awareness and empowerment of personnel regarding information security;
Decrease of lawsuit risks against upper management in virtue of the ‗‗due care‘‘ and the ‗‗due diligence‘‘
principles;
The opportunity to identify the weaknesses of the ISMS and to provide corrections;
Increase the accountability of top management for information security.
Conformity:
To other ISO standards;
To OECD (Organization for Economic Co-operation and Development) principles;
To industry standards, example: PCI-DSS (Payment Card Industry Data Security Standard), Basel II (for
banking industry);
To national and regional laws.
Impact reduction:
Effective incident management can reduce the impact from a financial, legal and reputational perspective
when an incident occurs. A well-prepared and tested process will allow effective management of incidents
in a timely manner with the aim of limiting the effect on the organization.
Stakeholder assurance:
Satisfaction of customer and/or other stakeholders` requirements;
Consolidating confidence of customers, suppliers and partners of the organization;
Ability to provide evidence to win associated bids and tenders.

68/135
69/135
This section will provide information that will help the candidate to acquire knowledge on how to identify the
external and internal context of the organization, and how to determine its objectives and scope.

70/135
The PECB Security Incident Management Framework is based on the principles of ISO/IEC 27035-1 and
ISO/IEC 27035-2 and describes the steps through which an organization should undergo in order to establish an
effective Information Security Incident Management process along with the processes to be used in the event of
an incident occurring. It also covers how to approach lessons learned and continuous improvement along with
the overall on-going processes which are needed to support the Incident Management Framework even when
not in use. This includes the need for effective communication and overall testing, monitoring and review of the
process.

71/135
It is necessary to obtain an overview of the organization to understand the information security challenges of the
organization and the information security management inherent in that market segment. General information
about the organization concerned should be collected in order to better appreciate its mission, strategies, main
purpose and values. This helps to ensure consistency and alignment between the strategic objectives for
information security management and the organization's mission.

72/135
There are several models that have been developed to analyze and understand the strategic context of an
organization. Note that this step does not become a project itself. In most organizations, studies have been
conducted internally or by consulting firms on their strategic positioning. It should be enough to just collect these
studies, analyze them and interview some key stakeholders to ensure an adequate understanding of the
organization.
The following are some of the frequently used models:
SWOT Analysis (Strengths, Weaknesses, Opportunities, Threats):This model is used to conduct a thorough
analysis of an organization‘s strengths, weaknesses, opportunities and threats. The analysis is done for the
purpose of formulating policy options and determining where the organization should invest its resources (Take
advantage of opportunities? Reduce weaknesses? Face threats?).
STEP Analysis (Social, Technological, Economic, Political):The STEP analysis allows the organization to
analyze the market forces and opportunities in the four following areas: social, technological, economic and
political. Some authors have added two additional categories: environmental and legal.
Porter’s Five Forces Analysis: This approach analyzes the competitiveness level of organizations by employing
the five factors that influence the business environment within an industry. These five forces consist of the
intensity of rivalry among competitors, the bargaining power of customers, the threat of potential entrants in the
market, the bargaining power of suppliers, and threats of alternative products.

73/135
When analyzing the internal environment, it is necessary to identify the structures comprising the various bodies
and relations between them (hierarchical and functional). These include segregation of duties, responsibilities,
authority and communication within the organization that should be studied. The functions outsourced to
subcontractors should also be identified.
The structure of the organization may be of different types:
1. The divisional structure: Each division is under the authority of a division director responsible for
strategic, administrative and operational decisions within this unit.
2. The functional structure: Functional authority is responsible about the proceedings, the nature of work
and sometimes the decisions or planning of various activities/projects within different departments/units
(e.g., production, information technology, human resources, marketing, etc.).
Notes:
A division within the organization can be organized into functions and vice versa.
An organization has a matrix structure where the entire organization is based on the two structure types.
Whatever the structure, the following levels are distinguished:
1. The decision level (responsible for the policy and the strategies)
2. The steering level (responsible for the coordination and management activities)
3. The operational level (responsible for production and support activities)
The organizational chart is an excellent tool to get to understand the internal environment. It shows the structure
of the organization by using a scheme. This representation shows the links of subordination and delegation of
authority, but also dependencies. Even if the chart illustrates that no formal authority exists, based upon the links,
the information flows can be deduced.

74/135
Firstly, the Information Security Incident Management team must identify all stakeholders and their concerns
about information security. There should be a consensus with the stakeholders regarding their involvement
during the planning stage.
It is imperative to identify the stakeholders so that they can get involved in the ISIM process. The Information
Security Incident Management team will devote part of its time to sensitize stakeholders to understand the
process and explain how this process can ultimately help protect resources and reduce costs. Also, some people
involved in the project should be trained on the method chosen to do the risk assessment. In addition, there
should be time in the project to support stakeholders in the tasks that will be assigned to them (answering
questions, build relationships, present the progress of projects, etc.).

75/135
The security requirements for all organizations, small or large, are derived mainly from four sources:
1. Laws and Regulations: The new laws related to privacy issues, financial obligations and corporate
governance require firms to monitor their infrastructure more carefully and effectively than before. In the
absence of proactive actions, business executives may be exposed to prosecution (at a criminal or civil
level) for breach of fiduciary and legal responsibilities.
2. Standards: Organizations must comply with a set of international standards and codes of practice related
to their industry sector. Some of these can be implemented voluntarily.
3. Market: The market requirements include all contractual obligations that the organization has signed with
its stakeholders. A breach of contractual obligations may result in penalties (when stated in the contracts)
or civil suits for damages. Also, the market requirements are all implicit rules that an organization should
meet to do business. For example, although the organization has no contractual obligation to deliver its
products according to planning, it goes without saying that this is a commercial policy basis to meet the
scheduled delivery times.
4. Internal policies: Internal policies include all requirements defined inside the organization: internal policies
(human resources, information security, supply chain, etc.), ethical codes, work rules, etc. In case of
failure, we can consider that these are violations of internal policies without necessarily involving any legal
considerations.

76/135
The legal department/counsel must be involved in reviewing all proposed incident response plans and situations
where data sharing will take place between organizations. This is to ensure that the plans are both effective from
a legal perspective and do not put the organization at risk. Contractual considerations must also be covered here.
For example, if your organization is contractually bound to report an incident at a certain time, what does this
mean, who makes the decision and what are the contractual grounds.

77/135
Whilst it may be interesting to find the reason for an information security incident or prove a specific information
security concept, it must be considered that only the items in the scope may be tested at the agreed times using
the agreed techniques. The scope for the incident response activities must be formally documented and a letter
of authority and legal contract must be signed by the relevant person(s) with authority before the work
commences. N.B. This statement assumes the use of external resources if internal appropriate policies
are in place. There are several key reasons for this:
Investigatory or incident response work can involve further system downtime and outages and this must be
understood and agreed.
In some countries, conducting investigations and gathering evidence about the activities of individuals is
restricted by law. An unfair investigation (e.g., in a disciplinary case) could lead to the organization
suffering from legal action and many allegations.
From an insurance point of view, an external incident response practitioner should have adequate
professional indemnity cover. Often, this cover is only valid if activities are being performed within clear
formal boundaries.

78/135
 PECB Code of Ethics
PECB professionals will:

1. Show professionalism, accuracy, fairness, responsibility and independence in the duties they conduct.
2. Act at all times solely in the best interest of their employer, their clients, the public, and the profession by
acting in accordance with the professional standards and applicable techniques while performing
professional services.
3. Maintain their competency in their respective fields and strive to constantly improve their professional
skills.
4. Offer only professional services for which they are qualified to perform, and adequately inform clients and
consumers about the nature of proposed services, including any relevant concerns or risks.
5. Keep informed each employer or client that has any interest in the information being provided.
6. Treat with confidentiality the private and sensitive information acquired during professional and business
dealings from present and former employers, or client, unless they provide the consent to unveil such
information.
7. Comply with all laws and regulations of the jurisdictions where professional activities are conducted.
8. Respect the intellectual property and contributions of others.
9. Not intentionally communicate false or falsified information that may compromise the integrity of the
evaluation process of a candidate for a professional designation.
10. Not act in any manner that could compromise the reputation of PECB or its certification programs for
persons, and will fully cooperate on the inquiry following a claimed infringement of this Code of Ethics.

79/135
Integrity is a professional conduct that respects ethics. A code of conduct is a set of rights and obligations that
govern a profession, the conduct of those who exercise it, the relationship between them and their customers or
the public.
Ethics is a set of principles that constitutes a system of moral standards and ideals. These are values shared by
society. Beyond legal compliance, an incident response professional must be irreproachable.
It is difficult to gain trust and almost impossible to regain it in case of failure.
Fair Presentation
An incident response professional should report reliable and precise information.
The communication has to be truthful, accurate, objective, timely, clear and complete.

80/135
The objectives of a program or project information security incident management are the expressions of intent to
counter identified risks and/or to comply with organizational policies. Depending on its definition, an objective can
be a target system, its development environment or its operating environment. These objectives can then be
translated into various functions to be implemented.
Initially, it is necessary to establish the objectives of the Information Security Incident Management (ISMIM) with
various stakeholders. These are necessary to determine the scope of the Information Security Incident
Management program and must be validated at the highest level of the organization. Subsequently, for each
project envisaged, specific objectives should be identified, which will formalize all the elements necessary for
acceptance by the management. The implementation of the risk management system will be identified in a logic
of continual improvement.

81/135
The organization must define the scope and boundaries related to the Information Security Incident Management
process.
The ISIM process can be applied to the whole organization or to a subset defined in terms of:
1. Organizational units: department, office, project, branch, etc.
2. Business processes: sales management, procurement, hiring process, etc.
3. Location: headquarters, server room or any place geographically defined by a specific perimeter.
4. Assets: customer file, database, payroll, trademark, furniture, etc.
5. Technology: server, application, network, wireless internet, etc.
In a recently established organization, the introduction of the process can take several months, for example,
when introduced in an entity desiring an Information Security Incident Management. After implementing incident
management processes within a limited scope, the ISIM team can then gradually extend the scope to other
entities, and then adopt it across the organization. The scope of information security incident management should
be defined in a way that covers all the important assets and business processes of an organization.

82/135
83/135
This section will provide information that will help the candidate gain knowledge on how to draft an Information
Security Incident Management policy.

84/135
Any Information Security Incident Management policy should be part of the information security strategy for an
organization. It should also support the existing mission of its parent organization and be in line with already
existing policies and procedures.
An organization should implement an Information Security Incident Management policy that outlines:
Processes;
Responsible persons;
Authority and reporting lines (specifically the primary point of contact for reporting suspected incidents)
when an information security incident occurs;
Any awareness and training initiatives within the organization that are related to incident response.
The policy should be reviewed regularly to ensure it reflects the latest organizational structure, processes, and
technology that can affect incident response.

85/135
ISO/IEC 27001, clause 5.2
Top management shall establish an information security policy that:
a. is appropriate to the purpose of the organization;
b. includes information security objectives (see 6.2) or provides the framework for setting information security
objectives;
c. includes a commitment to satisfy applicable requirements related to information security; and
d. includes a commitment to continual improvement of the information security management system.
The information security policy shall:
be available as documented information;
be communicated within the organization; and
be available to interested parties, as appropriate.
ISO/IEC 27035-2, clause 4.1
Before the information security incident management policy is formulated, the organization should identify the
following regarding its information security incident management:
a. objectives
b. interested parties internally and externally
c. specific incident types and vulnerabilities that need to be highlighted
d. any specific roles that need to be highlighted
e. benefits to the whole organization and to its departments

86/135
After deciding on the standard model for the policy, the process of drafting the policy should be defined. Here are
the typical steps of the process of drafting a policy.
1. Appoint a responsible person: a person should be designated as responsible and empowered by
management to develop, review and evaluate the policy to be published.
2. Define the components of the policy: The team responsible for drafting the policy provides a list of all
topics to be addressed in the policy. As a minimum, the policy should cover the proposed subjects in
ISO/IEC 27035 standard series.
3. Draft the sections: The team responsible for drafting the policy compiles the different sections. We must
ensure that statements are written in simple but accurate language so that the policy is understood by all
parties affected by its publication. Also, the inclusion of operational specifications or references to specific
products in the policy must be avoided. The policy should address the "Why" and especially the "What"
and not the "How―. The ―How" will be detailed in the procedures.
4. Validation of contents and format: The person responsible for the policy has to validate the contents to
ensure that the policy complies with the requirements and other policies of the organization. For example,
it would be contradictory to publish a policy permitting the monitoring and screening of all employee
communication if an organizational policy, with respect to privacy provisions, prohibits these; or is in
violation of the laws of the country. Regarding the format, one must confirm that the policy meets the
documentation policy requirements regarding the life cycle management.
5. Validation by stakeholders: To ensure the support and understanding of the policy, it is common to
collect the comments of employees, managers and other stakeholders of the policy. The experience
demonstrates that the validation stage of a policy can be quite long depending on the size of the
organization, the organizational structure and diversity of involved stakeholders. The inclusion of these
elements has a direct impact on the time of validation that may represent a ratio of 1 to 6 times the time
taken for the development of the policy itself.

87/135
A successful Information Security Incident Management policy should be created and implemented as an
enterprise-wide process. To that end, all stakeholders or their representatives should be involved in the
development of the policy from the initial planning stages through the implementation of any process or response
team.
An organization should ensure that its ISIM policy is approved by a member of top management, with
commitment from all of top management.
An organized approach is essential for the acknowledgment of the ISIM .
Involved personnel should identify incidents, understand the information and the benefits of the approach
by the organization.
Management should approve the ISIM policy to establish a commitment to resourcing and preservation of
an incident response capability.
The ISIM policy should be made available to every employee and contractor and should also be addressed
in information security awareness briefings and training.

88/135
ISO/IEC 27035-2, clause 4.3 (cont’d)
An organization should ensure that its information security incident management policy content addresses, but is
not limited to, the following topics
a. The purpose, objectives and the scope (to whom it applies and under what circumstances) of the policy
b. Policy owner and review cycle
c. The importance of information security incident management to the organization and top management’s
commitment to it and the related plan documentation.
d. A definition of what a security incident is
e. A description of the type of security incidents or categories (or a reference to another document which
describes this in more depth)
f. A description of how incidents should be reported, including what to report, the mechanisms used for
reporting, where and to whom to report
g. A high-level overview or visualization of the incident management process flow (showing the basic steps for
handling a security incident) from detection, through reporting, information collection, analysis, response,
notification, escalation, and resolution.
h. A requirement for post information security incident resolution activities, including learning from and
improving the process, following the resolution of information security incidents.
i. If appropriate, also a summary of vulnerability reporting and handling (although this could be a separate
policy document).
j. Defined set of roles, responsibilities, and decision-making authority for each phase of the information
security incident management process and related activities (including vulnerability reporting and handling
if appropriate).
k. A reference to the document describing the event and incident classification, severity ratings (if used) and
related terms. The overview should either contain a description of what constitutes an incident or a
reference to the document where that is described.

89/135
90/135
These organization-level policies should refer explicitly to the Information Security Incident Management
policy and associated plans.
The organization-level policies should include the requirement that appropriate review mechanisms need
to be established.
These review mechanisms need to ensure that information -from the detection, monitoring and resolution
of information security incidents and from dealing with reported information security vulnerabilities- is used
as input to the process designed to maintain the continual effectiveness of the policies.

91/135
 Process description is a documented expression of a set of activities performed to achieve a given
purpose.
The process description provides an operational definition of the major components of a process. The
description specifies, in a complete, precise, and verifiable manner, the requirements, design, behavior, or
other characteristics of a process.
It also may include procedures for determining whether these provisions have been satisfied. Process
descriptions can be found at the activity, project, or organizational level.
Source: CMMI for Development, Version 1.2
Benefits of describing key processes
There are several benefits of describing and documenting any processes that are important to the organization.
It provides visibility into areas of quality, productivity, cost and schedule, it improves communication and
understanding and aids in the planning & execution of plans. In addition, it provides the ability to capture lessons
learned and helps facilitate the analysis/execution of organization-wide processes. Finally, it provides the basis
for training & skills assessment.
Source: SEI CERT

92/135
93/135
This section will provide information that will help the candidate gain knowledge on risk identification, analysis
and evaluation.

94/135
Based on the ISO 31000 framework, the ISO/IEC 27005 standard explains in detail how to conduct a risk
assessment and a risk treatment in the context of information security. This is the implementation of the continual
improvement cycle PDCA (Plan, Do, Check, Act) for risk management as it is used in all standards of
management systems. In this case, it can be easily connected to the corresponding clauses in the ISO/IEC 27001
on risk management (clauses 6.1.2 and 6.1.3), ultimately leading to the certification of the organization.
ISO/IEC 27005 Introduction
This document provides guidelines for information security risk management in an organization.
This document does not contain direct guidance on the implementation of the ISMS requirements given in
ISO/IEC 27001.
This document is relevant to managers and staff concerned with information security risk management within an
organization and, where appropriate, external parties supporting such activities.

95/135
The Information Security Risk Management process consists of context establishment (ISO/IEC 27005, clause
7), risk assessment (ISO/IEC 27005, clause 8), risk treatment (ISO/IEC 27005, clause 9), risk acceptance
(ISO/IEC 27005, clause 10), risk communication and consultation (ISO/IEC 27005, clause 11), and risk
monitoring and review (ISO/IEC 27005, clause 12).
As illustrated, the ISIM process can be iterative for risk assessment and/or risk treatment activities. If the risk
assessment provides sufficient evidence to actually determine the necessary actions to reduce the risk to an
acceptable level, it goes directly to the implementation of risk treatment options. If there is insufficient information
to determine the level of risk or the projected risk level if the treatment appears to be unacceptable, a new
iteration of the risk assessment will be conducted on some or all items of the application domain. Specifically, if
risk treatment is not satisfactory, and the context establishment is correct, a new iteration of risk treatment will be
conducted, otherwise, a new iteration of context establishment will be applied.
The effectiveness of treatment may depend in part on the accurate assessment of risk. It is possible that the
treatment may not lead directly to an acceptable level of residual risk. In this case, a new iteration of the risk
assessment should be undertaken.
Risk communication to the stakeholders of the organization and monitoring of risk are ongoing activities.

96/135
ISO 31000, clause 5 Framework
5.1 General
The purpose of the risk management framework is to assist the organization in integrating risk management into
significant activities and functions. The effectiveness of risk management will depend on its integration into the
governance of the organization, including decision-making. This requires support from stakeholders, particularly
top management.
Framework development encompasses integrating, designing, implementing, evaluating and improving risk
management across the organization.
The organization should evaluate its existing risk management practices and processes, evaluate any gaps and
address those gaps within the framework.
The components of the framework and the way in which they work together should be customized to the needs of
the organization.

97/135
ISO 31000, clause 6.4.2 Risk identification (cont’d)
The organization can use a range of techniques for identifying uncertainties that may affect one or more
objectives. The following factors, and the relationship between these factors, should be considered:
tangible and intangible sources of risk;
causes and events;
threats and opportunities;
vulnerabilities and capabilities;
changes in the external and internal context;
indicators of emerging risks;
the nature and value of assets and resources;
consequences and their impact on objectives;
limitations of knowledge and reliability of information;
time-related factors;
biases, assumptions and beliefs of those involved.

98/135
ISO 31000, clause 6.4.3 Risk analysis (cont’d)
Risk analysis should consider factors such as:
the likelihood of events and consequences;
the nature and magnitude of consequences;
complexity and connectivity;
time-related factors and volatility;
the effectiveness of existing controls;
sensitivity and confidence levels.
The risk analysis may be influenced by any divergence of opinions, biases, perceptions of risk and judgements.
Additional influences are the quality of the information used, the assumptions and exclusions made, any limitations
of the techniques and how they are executed. These influences should be considered, documented and
communicated to decision makers.
Highly uncertain events can be difficult to quantify. This can be an issue when analysing events with severe
consequences. In such cases, using a combination of techniques generally provides greater insight.
Risk analysis provides an input to risk evaluation, to decisions on whether risk needs to be treated and how, and
on the most appropriate risk treatment strategy and methods. The results provide insight for decisions, where
choices are being made, and the options involve different types and levels of risk.

99/135
ISO 31000, clause 6.4.4 Risk evaluation (cont’d)
Decisions should take account of the wider context and the actual and perceived consequences to external and
internal stakeholders.
The outcome of risk evaluation should be recorded, communicated and then validated at appropriate levels of the
organization.

100/135
101/135
This section will provide information that will help the candidate gain knowledge on the ISIM plan and its content,
processes and procedures involved in it, and how to handle confidential or sensitive information.

102/135
The main goal of incident management is to restore the service operation and minimize the impact of incidents
on business operations. Risk and business impact need to be clearly stated. The activities should be pre-planned
in order to:
Minimize the possibility of occurrences;
Reduce the impact.
Before drafting the plan, an alignment between the Response Plan and the organization‘s business plan must be
made, so that the most crucial operations can be identified and prioritized. The organization needs to pre-plan the
activities to be undertaken in order to minimize the possibility of the reoccurrence of incidents and minimize their
impact on the business operations.
Stages of an Incident Management Plan are:
1. Preparation: The organization develops an Incident Management Plan prior to the incident, including the
approach on how to handle the incident, how to set up the lines of communication, documentation,
ensuring the adequate equipment, etc.
2. Identification: Criteria to evaluate an event as incident must be established in advance. Considering that a
false alarm may sometimes appear as an incident, the identification phase is very important.
3. Containment: The aim is to limit the damage and prevent further damage.
4. Eradication: To eradicate the incident the organization must first find out the root cause and then eliminate
it.
5. Recovery: Trying to restore the services into production, ensuring no threat remains.
6. Lessons learned: The incident must be documented (e.g., an incident report) in order to be analyzed and
preventive actions to be taken.

103/135
The Incident Management Plan is a set of documented information on incident management activities and
procedures, such as the information security events and vulnerabilities, while the communication of them is a
vital part of the management. The plan stems from and is based on the ISIM policy.
The plan may include a high-level outline of the basic flow of incident management activities to provide structure
and pointers to the various detailed components of the plan. These components will provide step-by-step
instructions for incident handlers to follow, by using specific tools, following specific workflows or handling
specific types of incidents based on the situation.

104/135
ISO/IEC 27035-2, clause 6 Creating information security incident management plan
6.1 General
The information security incident management plan comes into effect whenever an information security event is
detected or information security vulnerability is reported.
Planning and preparation of the incident response plan should be undertaken by the process owner, with a clear
goal or set of goals for incident response within a defined scope based on the information security incident
management policy.

105/135
106/135
ISO/IEC 27035-2, clause 6.4 Information security incident management plan content (cont’d)
3. Guidance for deciding whether escalation is required during each relevant process, and to whom, and
associated procedures. Based on the guidance provided in the information security incident management plan,
anyone assessing an information security event, incident or vulnerability should know under which circumstances
it is necessary to escalate matters and to whom it should be escalated. In addition, there are unforeseen
circumstances when this may be necessary. For example, a minor information security incident could evolve to a
significant or a crisis situation if not handled properly or a minor information security incident not followed up in a
week could become a major information security incident.
4. Procedures to be followed to ensure that all information security incident management activities are properly
logged and that log analysis is conducted by designated personnel.
5. Procedures and mechanisms to ensure that the change control regime is maintained covering information
security event, incident and vulnerability tracking and information security report updates, and updates to the plan
itself.
6. Procedures for information security evidence analysis.

7. Procedures and guidance on using Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS),
ensuring that associated legal and regulatory aspects have been addressed. Guidance should include discussion
of the advantages and disadvantages of undertaking attacker surveillance activities. Further information on IDS is
contained in ISO/IEC 27039.
8. Guidance and procedures associated with the technical and organizational mechanisms that are established,
implemented and operated in order to prevent information security incident occurrences and to reduce their
likelihood, and to deal with information security incidents as they occur.
9. Material for the information security event, incident and vulnerability management awareness and training
program.
10. Procedures and specifications for the testing of the information security incident management plan.

11. The plan of organizational structure for information security incident management.

107/135
12. The terms of reference and responsibilities of the IRT as a whole, and of individual members.

13. Important contact information.

14. Procedures and guidance regarding information sharing as agreed with the organization’s public affairs office,
legal department and top management or relevant departments.

108/135
ISO/IEC 27035-2, clause 6.4 Information security incident management plan content (cont’d)
3. Reporting output or notification should be defined in the context of the organization, the incident response policy,
and assignment of technical and management roles. The format of reports and notification should match the
incident classification scale or a consistent related metric.
4. Detecting and reporting the occurrence of information security events (by human or automatic means).

5. Responding to incorrect use of the reporting process (potentially including taking action outside the scope of the
incident management plan).
6. Collecting the information on information security events.

7.Detecting and reporting on information security vulnerabilities.

8.Recording information gathered in the information security database.

109/135
ISO/IEC 27035-2, clause 6.4 Information security incident management plan content (cont’d)
3. If the incident planning process is to depend on automated information management and decision support
systems, the functions, implementation, and on-going operation of these systems should be defined. The incident
handling process owner should ensure an information security database is sufficiently defined prior to developing
the response processes that depend on it.
4. The PoC conducting assessments of information security events (including escalation as required), using the
information security event/incident classification scale (including determining the impacts of events based on the
affected assets/services) should decide whether events should be classified as information security incidents.
5. The IRT assessing information security events should confirm whether an event is an information security
incident or not. To do this, another assessment should be conducted using the information security event/incident
classification scale to confirm the details of the event (suspected incident) type and affected resource
(categorization). This should be followed by decisions being made on how the confirmed information security
incident should be dealt with, by whom and in what priority, as well as escalation levels.
6. Assessing information security vulnerabilities (that have not yet been exploited to cause information security
events and potential information security incidents), with decisions made on which need to be dealt with, by
whom, how and in what priority.
7. Fully recording all assessment results and related decisions in the information security database.

110/135
ISO/IEC 27035-2, clause 6.4 Information security incident management plan content (cont’d)
3. Review by the IRT to determine if the information security incident is under control,

i.if the incident is under control, instigate the required response, either immediately (in real-time or in near real-
time) or at a later time, and
ii.if the incident is not under control or it is going to have a severe impact on the organization’s core services,
instigate crisis activities through escalation to crisis handling function.
4. Defining a map of all internal and external functions and organizations that should be involved during the
management of an incident.
5. Containing and eradicating the information security incident as appropriate to mitigate or prevent the scope and
impact of the incident from increasing.
6. Conducting information security evidence analysis, as required.

7. Escalation, as required.

8. Ensuring that all involved activities are properly logged for later analysis.

9. Ensuring that electronic evidence is identified, collected/acquired and preserved.

10. Ensuring that the change control regime is maintained and thus that the information security database is kept
up-to-date.
11. Communicating the existence of the information security incident or any relevant details thereof to other
internal and external people or organizations.
12. Dealing with information security vulnerabilities.

13. Once the incident has been successfully dealt with, formally closing it and recording this in the information
security database.
14. Post-incident activity should include further analysis as required.

111/135
ISO/IEC 27035-2, clause 6.4 Information security incident management plan content (cont’d)
4. Reviewing how effective the processes, procedures, the reporting formats and/or the organizational structure
were in responding to assessing and recovering from each information security incident and dealing with
information security vulnerabilities, and on the basis of the lessons learned identifying and making improvements
to the information security incident management plan and its documentation.
5. Updating the information security database.

6. Communicating and sharing the results of review within a trusted community (if the organization so wishes).

112/135
ISO/IEC 27035-2, clause 6.7 Processes and procedures
NOTE: For brevity purposes, the term ―document‖ will be used to refer to both processes and procedures in this
text unless the distinction between a process and procedure is significant.
It is important to understand that not all documents need to be readily available either within the organization or to
the general public. For example, it is not necessary for all organizational personnel to understand the internal
operation of an IRT in order to interact with it. The IRT should ensure that available guidance, including
information resulting from information security incident analysis, is in readily available form, e.g. on the
organization’s intranet and/or public website, as and if appropriate. It may also be important to keep some details
of the information security incident management plan closely held to prevent an insider from tampering with the
investigation process. For example, if a bank employee who is embezzling funds is aware of some details how the
investigation is being done, he or she can be able to better hide their activities from investigators or otherwise
hamper the detection, investigation of and recovery from an information security incident.
The content of operating procedures depends on a number of criteria, especially related to the nature of known
potential information security events, incidents and vulnerabilities and the types of information system assets that
might be involved and their environment. Thus, an operating procedure could be related to a particular type of
incident or product (for example, firewalls, databases, operating systems, applications) or to a specific product.
Each operating procedure should clearly identify the steps to be undertaken and by whom. It should reflect
experience from external (for example, government and commercial IRTs or similar, and suppliers), as well as
from internal sources.
There should be operating procedures for dealing with types of information security events and incidents that are
already known, as well as vulnerabilities. There should also be operating procedures to be followed when an
identified information security event, incident or vulnerability is not of any known type. In this case, the following
should be addressed:
a. the reporting process for the handling of such exceptions;
b. guidance on the timing for getting approval from management in order to avoid any delay of response;
c. pre-authorized delegation of decision making without normal approval process.

113/135
114/135
ISO/IEC 27035-2. clause 6.8 (cont’d)
It is fundamental that the IRT is trusted by the whole organization and that external entities have confidence in it.
The trust within the organization is created by fiat and stems from the support given by the top management, i.e.
the trust is given. External entities that have to deal with the IRT (e.g. IRTs from other organizations) need to be
confident that the IRT will perform its job professionally, i.e. the trust should be earned.
The IRT can earn trust through transparency and mature processes. The IRT should work to educate users
(internal and external), explain how the IRT works, how it protects confidentiality of information collected and how
it manages security event, incident and vulnerability reports. The IRT should document and publicize provisions
that clearly illustrate the expectation of anonymity, or lack thereof, for persons or parties reporting a suspected
information security incident or vulnerability.
The IRT should be capable of efficiently satisfying the functional, financial, legal and political needs of the
organization and be able to exercise organizational discretion when managing information security incidents and
vulnerabilities. The function of the IRT should also be independently audited to confirm that all business
requirements are being satisfied effectively.
Further, a good way of achieving another aspect of independence is to separate the incident and vulnerability
reporting chain from operational line management and to make a top manager directly responsible for managing
incident and vulnerability responses. Finance of the capability should also be segregated to avoid undue
influence.

115/135
ISO/IEC 27035-2. clause 6.9 Handling confidential or sensitive information (cont’d)
An organization should ensure that the necessary processes and capabilities are established to anonymize
sensitive information when required (e.g. when leaving the protective domain of the IRT). If information security
events/incidents/vulnerabilities are logged via a generalized problem management system where it is not possible
to restrict who has access to it, sensitive details may have to be omitted. Give that the IRT would still have to have
access to the omitted information, this can lead to a situation where the IRT will maintain its own information
security database.
As outlined elsewhere in this part of ISO/IEC 27035, an organization should also ensure that the information
security incident management plan makes provision for controlling the communication of incidents and
vulnerabilities to external parties, including the media, business partners, customers, law enforcement
organizations, and the general public.

116/135
As a project manager, you must be prepared to solve issues that can hinder the implementation of an information
security incident management plan. Please identify issues that you consider as critical success factors for the
implementation phase of the Information Security Incident Management processes and describe why these are
important.

Duration of the exercise: 20 minutes

Comments: 15 minutes

117/135
118/135
This section will provide information that will help the candidate gain knowledge on how to establish an Incident
Response Team (IRT), how to assign the roles of each member and so on.

119/135
At some level, every member of an organization is a member of the IRT team, because every action they take
could potentially cause or avert an incident.
When building the IRT team, the organization might have to train the employees and help them get proper
training and become the experts that the organization needs. There are cases that organizations contract external
(third party) IRT teams.
Source: Dr. Michael E. Whitman & Herbert J. Mattord. Principles of Incident response and Disaster Recovery.
2011.

120/135
You will realize that in order to adequately address a cyber security incident, different skills are needed to take up
the different responsibilities and necessary roles of an efficient incident response.
Source: Cyber Security Incident Management Guide. Centre for Cyber Security Belgium & Cyber Security
Coalition.

121/135
ISO/IEC 27035-2, clause 7 Establishing an incident response team (IRT)
7.1 General (cont’d)
An IRT contributes to the reduction in physical and monetary damage, as well as the reduction of the damage to
the organization’s reputation that is sometimes associated with information security incidents. IRTs can be
structured differently depending on the organization size, its staff members and industry type.

122/135
 1. Collecting information from stakeholders: When establishing the Incident Response Team, the
organization needs to collect as much information as possible from the stakeholders. This information will
help in identifying what skills and abilities are required from the IRT in order to respond to information
security incidents/events. Even the definition of the organization and responsibilities of the IRT may differ
between the various communities of interest. Some typical skills that IRT members should have are:
Virus scanning, elimination and recovery
System administration
Network administration
Firewall administration
2. Incident Response Team structure: An IRT should be available for contact for anyone who discovers or
suspects that an incident involving the organization has occurred. One or more team members, depending
on the magnitude of the incident and availability or personnel, should then handle the incident. The incident
handlers analyze the incident data, determine the impact of the incident, and act appropriately to limit the
damage to the organization and restore normal services.
3. Incident Response Team services: The main focus of an IRT is performing incident response: however,
it is rare for a team to perform incident response only. In most organizations, the IR team work like
volunteer firefighters, going about their primary responsibilities until an incident arises. In some
organizations, the IR team is organized to provide IR services, which may significantly overlap with other
traditional information security tasks, but have an IR focus. By constantly working with IR-based tools and
technologies, the Incident Response team stays trained and focused on incidents and can better deal with
intrusions.
Source: Dr. Michael E. Whitman & Herbert J. Mattord. Principles of Incident response and Disaster Recovery.
2011.

123/135
ISO/IEC 27035-2, clause 7.2 (cont’d)
An IRT should have a defined constituency for which it is primarily responsible. Constituencies may be defined in
many different ways including (but not limited to) employees of an organization, being assigned a specific IP
address range, belonging to a specific autonomous system (AS) in IP routing, belonging to a specific domain (e.g.
example.org), having customers of a product, having customers of a commercial incident response service, or
covering the population of a region or country. Members may join the constituency voluntarily, as the result of
contractual agreement (e.g. the purchase of a service or product) or by legislation (e.g. the establishment of a
national CERT).
The characteristics and size of the constituency and the level of authority and control the IRT has over its
members, will affect the types of service the IRT can offer and the appropriate form of organization to
deliver it.
For example, IRTs may themselves do hands-on incident response (either in-house or as a contracted
service), they may coordinate the work of other IRTs, or they may provide information and assist individual
members on request (e.g. product IRTs).
Whatever services it offers, the IRT will require a response policy (defining what constitutes an incident,
what response(s) is/are required and what authority the IRT has to deliver it), a response process (defining
how the team will respond to those incidents to deliver that response), and operational capabilities to
implement that process.
Although the primary role of an IRT is to respond to incidents (whether detected by its own monitoring
systems, reported from within the constituency, or reported by external sources), many teams also
contribute a preventive role by improving security standards and practice within their constituencies, so as
to reduce the likelihood and/or severity of incidents. IRTs are also likely to have an administrative role, for
example, in reporting and managing their own policies, processes and resources.

124/135
ISO/IEC 27035-2, clause 7.3 IRT staff (cont’d)
In order to respond to various types of incidents, IRT members should possess technical knowledge and skills
such as the following:
current network security issues, including attacks, threats, malware, and vulnerabilities;
system administration security practices such as patch management, secure configuation, backup, and
disaster recovery;
cryptography (encryption and hash algorithms), digital signatures, current protocols such as SSL/TLS;
common network protocols such as ethernet (IEEE 802.3), WiFi (IEEE 802.11) IPv4, IPv6, ICMP, UDP,
TCP;
common network application protocols such as DNS, SMTP, HTTP(S);
digital evidence collection, reverse engineering;
computer science and programming concepts such as entropy, secure development, functional and object-
oriented programming, system architecture and memory layout.

125/135
126/135
This section aims to offer the candidate information regarding the relationships of the organization with its internal
and external parties.

127/135
128/135
 Their professional incident responders with their knowledge of possible threats and scenarios might reduce
the time for diagnosing the incident.
They work in a forensically sound way so that any evidence will be secured and documented according to
a legally valid chain of custody. This evidence can then be presented later on in court if that is needed.
They have experience of doing things in the right order and have tooling for recovering traces from RAM
memory, from virtual machines, from hard disks and from networks.
These experts will help you to identify the causes of the incident and will offer advice on how to contain,
eradicate and remediate the incident.
You can either contract and retain a cyber security incident response partner during the preparation phase,
or wait until an actual cyber security incident occurs. Bear in mind that establishing such a contract takes
time and effort. So if you are sure you will need external help, it might be better not to wait.
This way you will win precious time at the beginning of the cyber security incident. Several specialized
consulting firms for incident response services and law offices offer subscriptions that keep their incident
response capabilities on retainer for the subscriber. Furthermore most of these include training sessions
with your incident response team to facilitate cooperation between them when an incident happens.
Other parties like industry regulators, the Privacy Commission, Cert and law enforcement (police and
magistrates) might be of importance when you‘re confronted with a cyber security incident of criminal
nature or in case of a personal data leak. Some legislation even obliges you to inform these parties when
you have detected an incident of a specific nature.
Some legislation even obliges you to inform these parties when you have detected an incident of a specific
nature.
These parties can often help with information on the threat and with practical guidelines based on previous
incidents they have handled. Most of these investigations are covered by professional secrecy.
Bear in mind that the objective of law enforcement is to identify and catch the attacker. It is not their task to
get your business up and running again. It is also possible that the most effective way to catch the attacker
is not equal to the fastest way to get back to business as usual.
Source: Cyber Security Incident Management Guide. Centre for Cyber Security Belgium & Cyber Security
Coalition.

129/135
130/135
131/135
IMPORTANT: Internal communication is of crucial importance to the effective management of an
Information Security Incident.
Plans for internal communication should involve:
1. What to communicate?
2. Whom to communicate the information to, including a) instructions and support of outside spokesperson,
and b) communication to organization‘s internal users.
Internal communication:
Depending on the type and severity of the incident, the incident decision has to be made based on:
The need to know, and
The provided information.
It is advisable to have a documented procedure.

132/135
133/135
Page for Note Taking

134/135
Page for Note Taking

135/135