EXIN Information Security Management Professional

based on ISO/IEC 27001

Version 202306

Copyright © EXIN Holding B.V. 2023. All rights reserved.

EXIN® is a registered trademark.

No part of this publication may be reproduced, stored, utilized or transmitted in any form or by any means, electronic,
mechanical, or otherwise, without the prior written permission from EXIN.

002
Introduction to the Body of Knowledge

• These slides contain presentation material designed to prepare students for the EXIN Information Security Management Professional
based on ISO/IEC 27001 certification. You can also use this slide deck as the basis for accredited training.

• The material refers to all exam specifications and basic concepts. It covers the body of knowledge of the certification.

• A proper training requires examples of practical experience, deepening of exam specifications and basic concepts, exercises, elaborating
subjects of particular interest to the audience.

• In case of minimal training duration, candidates should study this Body of Knowledge (compare training duration with study load in
Preparation Guide).

• The order of the topics presented in this slide deck follows the order in the exam specifications.

• When you make use of this Body of Knowledge, your organization will still need to go through EXIN's standard accreditation procedure.
You can find the requirements for accreditation in the Accreditation Manual.

• Please note that this Body of Knowledge cannot be sold commercially. ATO’s are allowed to use these materials for the sole
purpose of developing their own full courseware to be used in EXIN accredited training. They may not create other
commercial products and services based on this file without permission from EXIN. When parts of it are used in another
context the source must be referenced and the EXIN copyright statement added.

003
EXIN Information Security Management based on ISO/IEC 27001
program

004
Course objectives and target audience

Course objectives Target audience

• This certification is intended for all security
• Information security perspectives professionals who are involved in the
(10%) implementation, evaluation and reporting of an
• Risk management information security program, including the
following roles:
(30%) • information security manager (ISM)
• Information security controls • information security officer (ISO)
(60%) • line manager
• process manager
• project manager with security
responsibilities.

005
Certification requirements

In order to become certified, a professional needs:

• Successful completion of the EXIN Information Security

Management Professional based on ISO/IEC 27001 exam.

• Accredited EXIN Information Security Management Professional

based on ISO/IEC 27001 training, including completion of the
practical assignments.

006
Exam details

• Examination type: multiple-choice questions

• Number of questions: 30

• Pass mark: 65% (20/30 questions)

• Open book: No

• Notes: No

• Electronic equipment/aides permitted:No

• Exam duration: 90 minutes

The Rules and Regulations for EXIN’s examinations apply to this exam.

007
Additional exam literature
B. ISO/IEC 27000:2020
Information technology — Security
techniques — Information security
management systems — Overview
and vocabulary
Switzerland, ISO/IEC, 2020
www.iso.org
C. ISO/IEC 27001:2022
Information security, cybersecurity
and privacy protection — Information
security management systems —
Requirements Switzerland, ISO/IEC,
2022
www.iso.org
D. ISO/IEC 27002:2022
Information security, cybersecurity
and privacy protection — Information
security controls Switzerland,
ISO/IEC, 2022
www.iso.org
E. ISO/IEC 27005:2022
Information security, cybersecurity
and privacy protection — Guidance
on managing information security
risks
Switzerland, ISO/IEC, 2022
www.iso.org
008
ISO/IEC 27001:2022 overview

ISO/IEC 27001 standard

The ISO/IEC 27001 standard represents the international

standard for the establishment of an Information
Security Management System (ISMS). The most recent
version was published in 2022 by the International
Organization for Standardization (ISO) and the
International Electrotechnical Committee (IEC). The ISO 27001:2022
standard is used world-wide by organizations that would
like to implement information security based on a global
standard.

09
 ISO/IEC 27001 structure
• 0 Introduction – General introduction to the standard and the wider ISO/IEC
27000 series of standards.
• 1 Scope – description of an ISMS generic requirements suitable for any size
and type of organization.
• 2 Normative references – description of other ISO standards that are required
to understand this standard.
• 3 Terms and definitions – description of the main terms and definitions used
by ISO/IEC 27001.
• 4 Context of the organization – description of how organizations should look
to their own context in order to define a good scope for the ISMS, to manage
the stakeholders' expectations and the main items and processes that must be
established, implemented, maintained and continually improved in the ISMS.
• 5 Leadership - description of the role and responsibilities from Top
Management regarding to the ISMS, as well as define the information security
main roles.
• 6 Planning - description of the actions that must be taken to identify, analyze
and plan to treat information risks. A description and definition of the
information security objectives must take place as well.
• 7 Support – description of the actions that must be taken to assign adequate
and competent resources, create and develop information security
awareness, prepare, publish and control the required documented processes,
policies and procedures.
• 8 Operation – description of detailed actions to assess and treat information
security risks, change management and documents (registers to facilitate
auditing activities).
• 9 Performance evaluation - description of the actions that must be taken to
monitor, measure, analyze and evaluate/audit/review the information
security controls, processes and management system, systematically
improving where necessary.
• 10 Improvement - description of the actions that must be taken to
continuously improve the ISMS based on audit findings, management
reviews, customers inputs, among others.
• Annex A Controls reference – description of the main information security
controls that must be adopted by the organizations. The selected and used
controls as well as the non-used ones must be described on the Statement of
Applicability (SoA) document.
010
ISO 27001 certification path (overview)

The ISMS implementation and certification can differ from organization to organization. However, these are the most common steps.

1 2 3 4 5 6
ISMS objectives
Obtain Define scope
and overall Information
management and context of Plan the project Risk assessment
management security policy
commitment the ISMS
system

7 8 9 10 11 12

Statement of External audit

Implement Management External audit
Applicability Internal audit stage two
controls review stage one
(SoA) (certification)

011
0. Introduction
Definition of the subject

Information security deals with…

The definition, implementation,

Safeguard the confidentiality,
1 maintenance, compliance and 3 integrity and availability (CIA)
evaluation of an ISMS
of information

2 Risk management, leading to a 4 The (manual and automated)

coherent set of controls information supply

013
This implies…

A management system such as

ISO/IEC 27001

A set of controls such as A focus on confidentiality,

ISO/IEC 27002 integrity and availability (CIA)

014
1. Information security
perspectives
Information security perspectives

customer (end user)

perspective on data
privacy

business service
perspective provider/supplier
of information responsibilities in
security security assurance

016
1.1 Business interest of
information security
The business perspective

Information has become the most critical asset for many organizations.

Protecting this asset from loss, tampering, and disclosure is vital.

Controls should be put in place at a level that is appropriate to the
value of the information or asset.

Information is everywhere, even outside the organization’s perimeter.

This fact makes protection difficult but also more necessary;
information security is not limited only to the IT field.
business
Custodians of information need to show that they are trustworthy;
governance and compliance are crucial. perspective
of information
International respected standards and best security practices such as security
the ISO 2700x series help to understand how to deal with the above
(also when using suppliers).

018
The business perspective

Laws and regulations force

organizations to comply with data
protection and intellectual property
best practices.

Stories of incidents travel fast. Since information is everywhere,

Damage to reputation can be information security and awareness
outside your control which makes of risks needs everyone’s attention.
it essential to focus on prevention.

Monitoring, logging, and a pro-

active organization are key
elements. Immediate detection of Information security needs to be
incidents and incident management embedded in the organization.
are crucial processes.

Customers and even suppliers

demand transparency and
019
compliance.
1.2 Customer (end user)
perspective on governance
Customer (end user) perspective on governance

Customers demand 24/7 business continuity of operations.

Due to the open marketplace customers can take their business customer (end user)
elsewhere. perspective on
governance
Concerns surrounding privacy are still very strong. Although the use
of social media, and the selling out of personal privacy as a result,
indicate that this is highly contextual.

Customers have become very vocal when their privacy is breached.

Any security incidents therefore get a lot of media attention.

Customers place trust in organizations that are transparent in the way

they deal with risks.

021
Customer (end user) perspective on governance
In B2B environments the chain of
trust requires compliance and
governance.

End users receive almost no training.

Information security training is mostly Security is often regarded as an
lacking. End users do not perceive optional add-on instead of an
security risks in the same way that embedded design requirement.
professionals do.

Stakeholders are clueless as to

what proof they require to decide
that information security risks are
022
managed.
1.3 Service provider/supplier
responsibilities in security
assurance
Service provider/supplier security assurance responsibility

Providers need to show due diligence regarding information security.

The usage of best practice standards prevails.

Incident, change, and continuity management are key processes.

Information security performance needs to become a part of the service

level agreement (SLA) management processes.
service
Active monitoring and vulnerability management need more attention. provider/supplier
responsibilities in
Transparency is key but difficult to maintain in a shared service security assurance
environment.

024
Service provider/supplier security assurance responsibility
Service providers need to
understand their customers’
business and requirements.

IT service management and

information security need to be Suppliers are not always
implemented using best-practice transparent about security risks
standards. SMART performance inherent within the solutions they
indicators are key. provide. Third-party assessment of
the risks is vital.

Perimeter security is still important but

data security even more so. This requires a
different mindset and products/solutions.
025
2. Risk management
Risk management subjects

Risk assessment

Selection of mitigating
controls/strategies 2 3 Residual risk

027
2.1. Risk management
principles
Risk assessment

Risk assessment answers a number of questions

What (information) assets should be protected?

Why do these assets need to be protected?

What are the risks?

What are the priorities in dealing with these risks?

What are the options to deal with these risks?

029
Steps in risk assessment processes

1 Assets Risks 3

• Determine which assets are in scope of the assessment • Define a formula to calculate the magnitude of risks

• Determine who the owners of the assets are • Define the risk appetite of the owner(s)

• Discuss the threats to these assets with the owners • Find options to mitigate unacceptable risk(s)

2 Threats Controls 4
• Decide who the threat agents are • Implement controls
• Get expert opinions on vulnerabilities of these assets • Understand and mitigate the new risks of the controls
• Get expert opinions on likelihood that the threats will occur • Accept any residual risks and repeat all of the above
• Get expert opinions on the impact if/when the threats occur
• Have a brainstorm with representatives of all stakeholders

030
Risk management generic workflow

value
Owners wish to minimize

impose
to reduce
Controls

that may
that may be possess
reduced by

Vulnerabilities
may be aware of

leading to

that
Threat agents exploit Risk

give
rise to that increase to

Threats to Assets

031
wish to abuse and/or may damage
Risk management according to ISO/IEC 27001:2022

Significance of risk
Risk Analysis Risk Evaluation

Information Identify sources Compare estimate

Risk criteria Next risk
Estimate risk against criteria
Risk Acceptance
Yes

Risk assessment
No

Risk Treatment
(information
security controls)

Risk management

ISO/IEC 27001 explicitly refers to and aligns with

ISO 31000 – Risk management – Principles and guidelines 032
Risk assessment – attention points

• Produce a Business Impact Analysis first to determine where a risk assessment is required.

• Implement a baseline on the risks. However, risk mitigation controls must be implemented only when required.

• Discussing risks that have not (yet) occurred needs an open mind.

• Analyzing risks can be facilitated by a specialist but requires a multi-disciplinary approach with members of each business
function.

• There are many tools available, but tools can only assist the process; not perform it!

• The risk assessment will provide the direction as to which controls must be implemented to tackle the risks that are being faced
by the organization. This is a must when designing an enterprise-wide information security program.

• The best way to achieve a good level of effectiveness in security governance is to perform a periodic risk assessment as part of
a risk management program.

• The organization will not bring the number of risks down to zero. However, stakeholders must be informed regarding to the
residual risks and accept them in agreement with the organization’s risk appetite.

033
Business impact analysis (BIA)

Only deals with the impact of an

Must be performed in cooperation
event such as the loss of, damage to,
with the business owner(s).
or disclosure of information.

BIA
In business terms, i.e. monetary loss, Does not analyze assets, threats,
damage to reputation, legal vulnerabilities, probabilities etc.;
consequences etc. only the impact of events.

Enables an organization to pinpoint Acts as a filter to determine which

those processes where security is activities require a risk assessment
important. and which do not.

034
Baseline principle

• Implement a limited set of controls for assets that are part of the scope.

• Be able to explain and justify why it is sufficient to implement only those specific
controls on those assets (tool: business impact analysis).

• Do a risk assessment on all the other assets and implement extra controls only where
required.

• Organizational objectives, operational constraints as well as applicable legislation and

regulation always need to be accounted for when implementing risk controls.

• Represents the way to start setting the information security controls for the organization.

035
2.2.1 Assessing the risks -
Guidance
Determine which assets are in scope of the assessment

• Purpose:
Determine which assets will be assessed during the next steps.

• How:
The business impact analysis (BIA) will have made clear what processes
result in the highest impact if loss, damage, or disclosure occurs. Assets
within these processes are people, systems, applications, operating
systems, buildings/rooms, utilities etc.

• Guidelines:
Draft the list of assets but keep a high level of abstraction and try to
group assets where possible.

037
Determine who the owners of these assets are

• Purpose:
Only the owners can clearly discuss the value of assets.

Asset ownership • How:

The business impact analysis should, for the most part, have already clarified
who the owners are.

• Guidelines:
Determining the owners of shared assets (such as network, email infrastructure,
internet access) can be tricky. When this is the case, the owner will be the
manager responsible for (delegated) maintenance of these assets.

038
Discuss the threats to the assets with these owners

• Purpose:
Determine which threats are applicable to the assets within scope. Only those
threats need to be analyzed in the next steps.

• How:
Standard lists of threats do exist, but whether the list is complete should be
discussed with the owner.

• Guidelines:
Be as complete as possible, do not filter out threats at this point. Try to compile
a list of inherent threats, not the threats for which there are residual risks at this
moment. For instance, do not exclude the threat of data loss because back-ups
are already made.

039
Decide who the threat agents are

• Purpose:
Knowing your enemy enables you to better determine which vulnerabilities
there are and the probability of threats occurring.

• How:
Discuss who might be interested in attacking your organization and the means
these adversaries have to their disposal.

• Guidelines:
Adversaries can be employees, criminals, hackers (of every kind), competitors,
states, terrorists etc.

040
Get expert opinions on vulnerabilities of the assets

• Purpose:
Enable those present during the risk assessment workshop to have enough
detailed information to make informed decisions.

Vulnerability 1 • How:
Vulnerability 2 Interviews with experts about information security aspects that are relevant to
…. the assets in scope. This can include technical experts and facility managers but
also local government, police, fire brigade etc.

• Guidelines:
The obtained data needs to be judged as to whether there is high, medium, or
low vulnerability. Try to be exhaustive. Talk to as many experts as possible
within scope and budget.

041
Get expert opinions on the likelihood that threats will occur

• Purpose:
Enable those present during the risk assessment workshop to have enough
detailed information to make informed decisions.

Probability 1 • How:
Probability 2 Interviews with experts about information security aspects relevant to the assets
…. in scope. This can include technical experts and facility managers but also local
government, police, fire brigade etc. Also get publicly available information
(where available) from incidents in the past both within and outside of the
organization.

• Guidelines:
The obtained data needs to be judged as to whether there is high, medium, or
low likelihood and impact. Try to be exhaustive. Talk to as many experts as
possible within scope and budget.

042
Define the impact for all threats when they occur

• Purpose:
Enable those present during the risk assessment workshop to have enough
detailed information to make informed decisions.

• How:
For every threat, discuss with experts what the maximum impact would be
if/when the threat occurs.

• Guidelines:
It is difficult to consider the impact on the organization when a threat has never
occurred. Consider monetary losses, legal problems, loss of business,
advantages it would give a competitor, loss of image etc. If possible, classify all
possible losses in monetary terms.

043
Define a formula to calculate risk

• Purpose:
Bring all information about a threat together in one quantitative or qualitative
parameter which will enable deciding whether the risk is above or below the
acceptable risk level.

• How:
• Quantitative: When only numbers are used to calculate the risk.
• Qualitative: When using classes of risk, for instance LL (low likelihood,
medium impact) or quantify (VL=1, L=2, M=3, H=4, VH=5) and then
multiply (L*M = 1*3 = 3) or use a different formula (most accepted risk
methodology).

• Guidelines:
Be careful when quantifying risks not to lose the distinction between for
instance L*M=1*3 and M*L=3*1 (both are 3).

044
Define the risk appetite of the owner(s)

• Purpose:
Determine the level above which a risk is unacceptable (i.e. should be mitigated
where possible).

• How:
For each threat, or all threats in one go, have the process owner decide which
level of risk is unacceptable.

• Guidelines:
Also take an outside view. What would customers/suppliers find acceptable?
What would legal entities consider acceptable?

045
Remarks

Example:

• Imagine two houses next to a chemical factory. An explosion at the factory causes fires in the

? ? ? surroundings. Both houses are equally likely (probability) to catch fire as a result of the
? explosion in that factory.
Probability
? ? • But, if one of the houses is made from wood and the other is made from concrete, the wooden
? ? Vulnerability house is much more vulnerable if there is a fire. Since vulnerability is difficult to determine,
limit the number of classes to (for instance) only high or low vulnerability.
? ? ? ?
The distinction between probability
and vulnerability is not always clear.

Concrete house Wooden house

046
Remarks
Risk assessment needs to be part of the scope of every project. Usually, a simple identification and rating mechanism for the threats and risks
specifically related to the project is sufficient.

Before doing a risk assessment, an organization will need to reach consensus on classes for probability, vulnerability and impacts.
For instance: Impact:
high: could lead to bankruptcy
medium: impacts the bottom line
low: no impact

Vulnerability: Probability:
high: when it happens there is a big high: it can happen any day
impact medium: could happen yearly
low: when it happens there will be low: will never happen
minor impact

047
2.2.2 Controlling the risks
Risk treatment in ISO/IEC 27001:2022

• Select risk treatment options

• Determine the needed controls

• Compare the selected controls to ISO/IEC 27001:2022 Annex A

• Create a Statement of Applicability (SoA) indicating which controls from Annex

A match the controls

• Create a plan to treat risks

• Obtain the risk owners’ approvals to treat the risks and their acceptance of
residual risk

049
Find ways to mitigate unacceptable risk(s)

• Purpose:
Select the risks for which mitigating controls are required.

• How:
Decide whether a risk can be avoided, transferred to another party, accepted or
whether it needs mitigation. Or maybe the risk is already mitigated by a control.

• Guidelines:
For example, avoidance of the risk means cancelling the business process in
question or moving the organization to an area with a lower/other risk profile.
Transferring a risk can be done by insuring against it. Both avoidance and
transferring tend to be exceptions. This tends to lead to discussions to decide
whether a risk can be accepted or needs mitigation. Sometimes risks are already
covered, for example Escrow arrangements to protect software code.

050
Implementing controls

• Purpose:
Where there are risks that cannot be accepted, controls need to be selected and
implemented with the aim of lowering probability, vulnerability and/or impact.

• How:
Controls should always follow from the risk assessment. For inspiration, a
standard baseline best-practice set of controls such as ISO/IEC 27002 can be
used to select those controls that mitigate the risk.

• Guidelines:
Whether controls mitigate a risk requires expertise in technical, legal,
procedural, physical/facility aspects. Ensure the expert view on all these aspects
is available.

051
Remarks

Use the available controls in ISO/IEC 27001 (Annex A) and ISO/IEC 27002 for further guidance or inspiration for risk mitigation activities

A.5 Information security

policies

Organisation of
A.6 information security

Human resource
A.7 security

A.8 Asset management

...
052
Statement of Applicability (SoA)

• The SoA is a document that must be produced as a result of the risk assessment
process.

• The document can be a matrix, by listing the used information security controls (to
mitigate and/or minimize the risks), the treatment options, and often also the
person(s) accountable for them.

• This document is required during auditing activities to provide an overview of SoA

which controls were implemented as part of the ISMS scope.
• Internal audit: The internal audit will be performed by the internal auditors of
the organization. They also have the responsibility of checking the
compliance of the organization (according to the ISMS scope) with the
information security policy.
• External audit: The external audit will be performed by an independent third
party. They will also assess the documentation, processes and policies. This
includes the SoA.

053
2.3. Residual risks
Understand and mitigate the new risks of the controls

• Purpose:
Determine whether the controls that have been selected to mitigate the
unacceptable risks introduce new risks themselves.

• How:
Discuss the implications of the selected controls with suitable experts. Decide
on mitigation strategies if new risks are found.

• Guidelines:
An example might be key management. Physical locks or electronic keys
(passwords/certificates) introduce all sorts of new problems (key management,
key loss, revoking keys etc.) that need to be understood and mitigated.

055
Accept any residual risks and repeat

• Purpose:
Residual Formally accept the residual risks and embed this process.
risk
acceptance
• How:
Have the organization’s management document the fact that residual risks do
exist but that these can or should be accepted. Embed this risk management
process within the management system, perhaps based on ISO/IEC 27001 or
even ISO 9001 (quality) or ISO/IEC 20000 (service management).

• Guidelines:
This risk management process should be linked to the incident management
process and the change management process. This guarantees that new threats
will be considered and mitigated when required.

056
PDCA

Control

• ISO/IEC 27001 and other standards for management systems

Control (ISO 9001 and COBIT for instance) describe information
Plan Do security risk management in terms of the plan-do-check-act
(Deming) cycle.

• Think thoroughly about what is required taking into account

policy, risk assessment and management (e.g. plan). Then
implement what is required (procedures, controls etc.) and
measure performance (e.g. do) and periodically – as often as

Act Check required to assure risks are mitigated – audit/review it all (e.g.
check). Lastly all possible improvements should again be
considered (e.g. act) and lead to new plans.

• Information security often adds up the Control function on the

PDCA model.

057
3. Information security controls
Strategies for controls

Information security can only be improved by implementing controls , i.e. the Plan-activities of the PDCA cycle are the most important
ones. Nevertheless, implementing the right controls is crucial and testing whether these actually work (i.e. mitigate risk) is even more
important.

Plan Do • Therefore, there are a number of options (strategies) for information

security improvement:

• Focus on ‘plan’ (describing the planned controls);

• Focus on ‘do’;

Act Check • Focus on ‘check/act’ (continuous improvement).

059
A good mix of controls

• Mitigates the relevant CIA aspects

• On all three hierarchical levels

• Takes into account both logical (ICT) as well as physical protection

• Is embedded and documented

• Important remarks:

• Top management reviews the ISMS on a regular basis. Input is the performance of
the ISMS. Output is decisions on improvement and change.

• The commitment of management and tactical control are the most important aspects.

• Operational controls actually improve security.

• If a risk can be mitigated by a physical control this is preferred above logical

(physical controls can be audited a lot more easily).

• If a risk can be mitigated by a logical control this is preferred above procedural

(people make mistakes, a logical control then acts as a safety net).

060
Protecting confidentiality
• Preventing leakage of confidential
information relies on preventing access to the
information. When this fails, or cannot be
guaranteed (on public networks for instance),
encryption is required.
• Preventing access to information means user
identification and authorization is critical.
Subsequent access should be based on access
control lists (ACL) that describe what kind of
access the user has; read, write, execute,
create, delete etc.
• A good access control covers the three
Group R W
categories: technical controls, programs, and
policies.
DL_SALES
DL_OPS • Encryption of information comes down to
scrambling the information in such a way
that legitimate users can easily descramble it
DL_ADM but an adversary cannot. This requires some
sort of digital key and a one-way decryption
method that will not allow descrambling data
without the key.
061
ISO/IEC 27002:2022

• This standard contains 93 controls.

ISO/IEC
27002:2022 • Grouped into 4 themes:
• People (8 controls)
• Physical (14 controls)
• Technological (34 controls)
• Organizational (37 controls)

• Each control has a number of attributes in five

categories:
• Control type
• InfoSec properties
• Cybersecurity concepts
• Operational capabilities
• Security domains
062
 Attributes in controls

Control type Information security Cybersecurity Operational Security domains

• Preventive properties concepts capabilities • Governance_and_
• Governance
• Detective • Confidentiality • Identify • Asset_management Ecosystem
• Corrective • Integrity • Protect • Information_protection • Protection
• Human_resource_security
• Availability • Detect • Physical_security • Defense
• Respond • System_and_network_securi • Resilience
ty
• Recover • Application_security
• Secure_configuration
• Identity_and_access_manag
ement
• Threat_and_vulnerability_m
anagement
• Continuity
• Supplier_relationships_secu
rity,
• Legal_and_Compliance
• Information_security_event_
management
• Information_security_assura
nce

063
ISO/IEC 27002 themes

ISO/IEC
27002:2022

5. Organizational controls
6. People controls
7. Physical controls
8. Technological controls

064
Organizational controls

Organizational Organizational

5.1 Policies for information security 5.19 Information security in supplier relationships
5.2 Information security roles and responsibilities 5.20 Addressing information security within supplier agreements
5.3 Segregation of duties 5.21 Managing information security in the ICT supply chain
5.4 Management responsibilities 5.22 Monitoring, review and change management of supplier services
5.5 Contact with authorities 5.23 Information security for use of cloud services
5.6 Contact with special interest groups 5.24 Information security incident management planning and preparation
5.7 Threat intelligence 5.25 Assessment and decision on information security events
5.8 Information security in project management 5.26 Response to information security incidents
5.9 Inventory of information and other associated assets 5.27 Learning from information security incidents
5.10 Acceptable use of information and other associated assets 5.28 Collection of evidence
5.11 Return of assets 5.29 Information security during disruption
5.12 Classification of information 5.30 ICT readiness for business continuity
5.13 Labelling of information 5.31 Legal, statutory, regulatory and contractual requirements
5.14 Information transfer 5.32 Intellectual property rights
5.15 Access control 5.33 Protection of records
5.16 Identity management 5.34 Privacy and protection of PII
5.17 Authentication information 5.35 Independent review of information security
5.18 Access rights 5.36 Compliance with policies, rules and standards for information security
5.37 Documented operating procedures

065
People controls

People

6.1 Screening
6.2 Terms and conditions of employment
6.3 Information security awareness, education and training
6.4 Disciplinary process
6.5 Responsibilities after termination or change of employment
6.6 Confidentiality or non-disclosure agreements
6.7 Remote working
6.8 Information security event reporting

066
Physical controls

Physical

7.1 Physical security perimeters

7.2 Physical entry
7.3 Securing offices, rooms and facilities
7.4 Physical security monitoring
7.5 Protecting against physical and environmental threats
7.6 Working in secure areas
7.7 Clear desk and clear screen
7.8 Equipment siting and protection
7.9 Security of assets off-premises
7.10 Storage media
7.11 Supporting utilities
7.12 Cabling security
7.13 Equipment maintenance
7.14 Secure disposal or re-use of equipment

067
Technological controls

Technological Technological
8.1 User endpoint devices 8.18 Use of privileged utility programs
8.2 Privileged access rights 8.19 Installation of software on operational systems
8.3 Information access restriction
8.20 Networks security
8.4 Access to source code
8.5 Secure authentication 8.21 Security of network services
8.6 Capacity management 8.22 Segregation of networks
8.7 Protection against malware 8.23 Web filtering
8.8 Management of technical vulnerabilities 8.24 Use of cryptography
8.9 Configuration management
8.25 Secure development life cycle
8.10 Information deletion
8.11 Data masking 8.26 Application security requirements
8.12 Data leakage prevention 8.27 Secure system architecture and engineering principles
8.13 Information back-up 8.28 Secure coding
8.14 Redundancy of information processing facilities 8.29 Security testing in development and acceptance
8.15 Logging
8.30 Outsourced development
8.16 Monitoring activities
8.17 Clock synchronization 8.31 Separation of development, test and production environments
8.32 Change management
8.33 Test information
8.34 Protection of information systems during audit testing

068
3.1. Organizational controls
Examples of organizational controls

Policies for information security Classification of information

A document that helps all employees to understand why Procedures for the classification of types of information
5.1 information security is important and what their role is. 5.12
and correct handling of these various types.

Threat intelligence Documented operating procedures

5.7 Describes the security organization, confidentiality 5.37 All day-to-day procedures for information management,
agreements and how to deal with relevant parties. procedures for separation of duties and development,
test and operation.

5.19 Information security in supplier relationships

5.9 - Asset management
Procedures for the inventory, ownership and use of - Identification of risks when dealing with external parties
5.11 (suppliers, customers etc.) and including these in
assets. 5.21
contracts.

Note: not all ISO/IEC 27002 controls are included; this list is not exhaustive, the numbers refer to ISO/IEC 27002:2022. 070
5.1 Policies for information security

Information security policy

and its review process

071
5.37 Documented operating procedures

Internal
Public
…

Information security policy Management commitment Asset management Change management Separation of duties
and its review process including classification of procedures
assets/information

Access control program & Incident management Identification of applicable Protection of intellectual Protection of personal
policy and its review procedures legislation property rights information
process

072
Procedure and process (definition from ISO 9001)

Procedure Process

Specified way to carry out an activity or a A set of interrelated or interacting activities

process. Procedures can be documented or not. which transforms inputs to outputs.
When a procedure is documented, the term “written
procedure” or “documented procedure” is frequently
used. The document that contains a procedure can be
called a procedure document.

A B C

073
5.12 Classification of information

Scope Asset owners

• Only secure what is required (according to the ISMS’ • Let the asset owners classify information based on the
scope). impact of loss, damage and/or disclosure.

• Consider: How to consistently add a label to

printed documents, for instance to a
printed e-mail message?

Labelling Internal Controls/Policy

public
…

• Add a corresponding label to the information, for
instance: highly confidential, confidential, or public.
• Classified documents can only be accessed
by persons cleared for that level or higher.
• Have rules to deal with these labels, for instance
confidential information should be encrypted or
transported by registered mail.

074
5.7 Threat intelligence

Threat intelligence should be

Operati- • Relevant
Strategic Tactical
onal • Insightful
• Contextual
• Actionable
Threat intelligence program
1. Create a plan
2. Know who needs the information Sources of threat intelligence
3. Involve the right people - Verizon Data Breach Investigation Report
4. Implement the right tools, techniques and procedures - CrowdStrike Global Threat Report
5. Understand the difference between threat data and - Hardware and software vendors
threat intelligence
6. Integrate with your organization’s information security
program
7. Communicate

075
5.9, 5.10, 5.11 Asset management

5.9 Inventory of information and other associated assets

Asset
5.10 Acceptable use of information and other associated assets Management DB

5.11 Return of assets

Acceptable Use
Policy

Return

076
5.19-5.21 Information security in supplier management

Suppliers come in various forms 5.19 Information security in supplier relationships

• Software (desktop, server, database, network) 5.20 Addressing information security within supplier
• Hardware (desktop, server, network) agreements
• Facilities (air conditioning, buildings, physical security) 5.21 Managing information security in the ICT supply chain
• Business process outsourcing (BPO)

Level of access to information

Low High

Supplier Contractual
T&Cs Agreement

077
 Continuity/availability
Information security deals with the triad.
ISO/IEC 27002 control 5.29 is called
“Information security during disruption” and
deals with aspects of business continuity
management (BCM).
The BCM process within an organization is
of course much broader than just
information security incident management.
Integrity
Confidentiality
From an information security perspective, the
term continuity should be interpreted as:
• continuity of security when an organization faces
a business continuity problem;
• availability of security systems, procedures and
services during normal operation.
Availability
078
Business continuity planning
Periodic exercise
Any BCP should be exercised periodically. It
should lead to fully restore the services within the
recovery time objective (RTO) and recovery point
objective (RPO) requirements. All personnel
involved should be knowledgeable in their roles
and activities.
Organizational change
Any change to the organization should lead to
changes to the BCP. This requires a strong
interface with any change management process
within the organization.
079
Continuity controls

5.29 Information security during disruption 5.30 ICT readiness for business continuity
This is the main control related to how to protect This control focuses on the redundancy of
information security during disruptive events ICT services, such as servers, network and
when a business continuity plan is invoked. applications.

Note: not all ISO/IEC 27002 controls are included; this list is not exhaustive, the numbers refer to ISO/IEC 27002:2022.
080
ICT business continuity planning

A disaster recovery plan must cover both RTO and RPO:

When a severe incident has led to substantial damage to
information processing and related services, there is one
important constraint: time!
RTO specifies the duration of time and
RTO a service level within which a service
must be restored after a disaster or
disruption.

The maximum allowable downtime (if longer the RPO is the maximum amount of data
organization will not be able to recover) should have
been translated into recovery time objective (RTO) and
recovery point objective (RPO).
RPO that might be lost from a service due
to a disruption.

081
ICT business continuity planning

RPO heavily depends on the business risks an organization faces when

transactions are lost. It dictates the service level target required.

Examples of RPOs and required IT infrastructure:

1 – 2 days: daily back- 1 – 2 minutes: mirrored

up using network or disks
cloud replication

082
Guidance for information back-up and restore
• It should be understood, at every level within the organization,
that ‘back-up’ is not a problem.
• The problem is being able to restore all relevant information
whatever the threat to data loss is, under all circumstances,
within the required timeframe.
• When it is properly understood that ‘restore’ is the problem, it
will be clear that ‘back-up’ is only part of the solution.
• For proper restore a large number of other requirements exist,
such as:
• Understand what the timeframe for restore is.
• Understand the order in which systems should be
restored.
• Availability of systems to restore on.
• Personnel knowledgeable in restore activities.
• Software required to do the restore.
• Restore procedures describing the activities required.
• Test procedures after a restore to decide whether
production can restart.
083
 ICT business continuity planning

dictates whether cold standby, hot standby or mirrored data processing is

RTO required. Since time is the only constraint, RTOs expressed in hours dictate
that all activities detecting, escalating and mitigating the incident are
documented and sufficiently trained.

The document describing this is the business During a business continuity incident the
continuity plan (BCP) or IT continuity plan. personnel involved in solving the situation
might be different than during normal
operation. This requires that the BCP describes
critical activities in large detail.
Drafting a BCP is done by assembling knowledgeable
experts who during normal operation are responsible for ICT
or business processes. They define the actions, lead times
and required facilities/services to be able to perform those
actions. Subsequently these actions are put into a Gantt
chart.

084
Guidance for procedures
Incident management procedures
These describe how incidents are managed,
i.e. escalation paths, who is responsible, how
incidents are resolved, who should be
informed and how the organization learns
from incidents.
Change management procedures
These describe how (ICT) changes are
defined, how risks are mitigated, who
approves and how changes are controlled.
Continuity management procedures
These describe the actions, responsibilities
and escalation paths of major incidents (that
might lead to a crisis situation) that are
required to keep the organization from failing
in business-in-unusual circumstances.
085
3.2. Physical controls
Examples of physical controls

Public area Restricted area

7.1 Physical security perimeters 7.2 Physical entry

Dividing the physical area(s) into zones and Locks, keys, electronic entry systems
clearly marking these zones. controlled by keys, badges, biometrics etc.

Note: not all ISO/IEC 27002 controls are included; this list is not exhaustive, the numbers refer to ISO/IEC 27002:2022.
087
Examples of physical controls

7.6 Working in secure areas
Procedures that describe the conditions for
working in protected areas. For instance
specifying that in such areas nobody may
work alone.
7.11 Supporting utilities
Protection against loss of utilities (cooling,
power, gas, water). Describes the need for
uninterruptible power supplies and no-break
systems.
7.14 Secure disposal or re-use of
equipment
Procedures and technical tooling for the
secure disposal of media (paper, disks)
containing classified information.

Note: not all ISO/IEC 27002 controls are included; this list is not exhaustive, the numbers refer to ISO27002:2022.
088
7.1 Perimeter protection

Some examples of perimeter protection

Landscaping Fences Gates

Bollards Perimeter IDS CCTV

089
7.2 Physical access control & biometrics

Access control Biometrics

Identification (who are you) Biometrics

• Someone professes to have a certain identity • False negative (type I)

• Uses user ID, badge or biometrics • False positive (type II)

Authentication (what rights do you have)

• Something you have (badge, key…)

• Something you know (pin, password…)
• Something you are (fingerprint, iris scan…)

Authorization (what rights do you have)

• Based on the identity and access control lists

(ACL) your access will be controlled

090
Guidance for physical controls
Check legislation when
surveillance cameras and other
privacy sensitive equipment is to
be installed.
Access rights management needs a
tight interface with the human
resource department when personnel
is hired, fired or when someone’s
position within the organization
changes.
General entry
Operations
Datacenter
Zoning helps to decide which
parts of the organization need
strict physical entry controls.
For example a policy for a
loading/unloading area.
Physical controls are often
managed by the organization’s
facilities management
department. To optimize these
controls for the protection of
information the security
officer/manager, the ICT
manager and the facility
manager should closely work
together on this subject.
091
Guidance for physical controls
IT systems are very vulnerable to
electrical power problems. A back-
up power supply (uninterruptible
power supply – UPS – for short
outages and no-break systems –
generators – for longer outages) is
always required.
Building management systems –
controlling power, lighting,
access, temperature etc. – are
computer systems themselves.
These need the same protection
as other computer systems
within the organization.
A thorough environmental risk
assessment should dictate what
kind of physical entry controls
are required.
Physical barriers should not
obstruct personnel leaving the
premises in case of an
emergency.
092
3.3. People controls
Examples of people controls

6.1 Screening
Procedures for the screening of personnel in those positions
where special risks could occur, for instance in financial
positions or in positions where confidentiality requirements
are high. In case of fraud to investigate the employee’s
workstation might be the only legal possibility.
6.3 Information security awareness, education, and
training
Procedures and all activities the organization takes to train
employees in information security in general and the
organization’s policies in particular.

6.6 Confidentiality or non-disclosure agreements 6.8 Information security event reporting

Clarifies the legal responsibilities of personnel for the Clarifies the legal responsibilities of personnel for the
protection of information confidentiality. protection of information confidentiality.

Note: not all ISO/IEC 27002 controls are included; this list is not exhaustive, the numbers refer to ISO/IEC 27002:2022.
094
Awareness, training

• Aspects:
Information security
• Knowledge (understanding the rules)
• Attitude (willingness to cooperate)
• Behavior (obeying the rules)

• The awareness program must be established in alignment with the target group and led by
the information security management.
• The level of awareness of the target group should be measured. The actual mindset of
employees towards information security can for example be observed in a walkabout after
office hours.
• Behavioral change will only happen when the target group has obtained all required
knowledge and understands why security controls are required.
• Tools: class-based training, e-learning, one-to-one talks, discussion, gaming.

095
Social engineering

Most humans are willing to help. Adversaries
use this to their advantage by building trust
with an employee. After gaining their trust,
the adversary uses the employee to obtain
information that helps them to get access to
the organization’s assets.
With the success of social media an
enormous amount of personal information is
publicly available. Employees should
understand and follow company policies
what they can and cannot disclose on social
media about the organization they work for.

Employees should be trained to identify social engineering and know how to identify who may have
access to what asset(s).

096
Guidance for people controls

System System Business

administrator administrator analyst

Special care should be given to those
functions where high risks occur.
Especially in situations where access
privileges are granted. If needed, duties
should be separated to reduce risk. For
instance administrators should only be
allowed to use admin rights when another
administrator is present (“four-eye
principle”).
Defining roles and responsibilities is of
the utmost importance. It is also vital to
make sure that employees understand
their responsibilities and any that
disciplinary steps are taken if they abuse
them.
All access rights should be reviewed
periodically, especially when employees
change roles within the organization. This
requires action from the HR department
and the relevant managers.

097
3.4. Technological controls
Examples of technological controls

8.8 Separation of development, test and production

environments
8.7 Protection against malware
System development needs to be done without risking
Malware is abundant. Antivirus software and procedures for
disrupting a production environment and impacting users.
prevention are mandatory.
The development and test environments should therefore be
separate from the production environment.
8.15 Logging
Especially high-risk activities should be logged to media 8.19 Installation of software on operational systems
were an adversary has no access to. This facilitates detection End users may be able to download software from the
of incidents. Logging also facilitates demonstrating the Internet which contains malware or other security
effectiveness of security controls. vulnerabilities. The use of software should be controlled to
prevent vulnerabilities to be introduced.

8.20-8.22 Networks security, security of network services,

segregation of networks 8.24 Use of cryptography
A layered security approach means that the organization’s The use of electronic keys and certificates should be
network must be divided into zones with special attention to controlled.
those zones that have external connections.

Note: not all ISO/IEC 27002 controls are included; this list is not exhaustive, the numbers refer to ISO/IEC 27002:2022.
99
8.15 Logging

Event management
• Collects information from systems, applications and network elements
• Correlates this information to determine if there is an incident, such as an outage or a security incident
• Is, in part, dependent on logging of events on the systems themselves (syslogs) or on logging servers

Information security events that should be logged

• Unauthorized access attempts
• Changes to configuration or data
• Privileged access attempts
• Creation, modification or deletion of user IDs
• Alarms generated by the system

Not all events lead to an incident, but all events should be analyzed to verify if an incident actually took place.

All logs should be protected to preserve their confidentiality, integrity and availability in order to analyze the information in them.

100
8.19 Installation of software on operational systems

End users may be able to install software on their PCs themselves. This brings with it a high risk, because this software cannot be
controlled and may contain malware or other threats.

Best Practices to prevent issues with software installations

• Only authorized administrators may install software.
• Software needs to be verified and tested for vulnerabilities before use.
• Use a configuration management database (CMDB) to verify what software at what versions is installed on the systems.
• Use an automated patch management system to install vendor patches as soon as they are released.

101
8.24 Use of cryptography

Cryptography aims to achieve

• Confidentiality
• Integrity
• Non-repudiation
• Authentication

The use of cryptography requires

• A policy covering the principles for protecting information
• A link to data classification and what classification needs encryption
• The need for encryption on specific vulnerable devices, such as cell phones, USB sticks,
etc.
• Encryption standards to use, including key length, key management, algorithms, etc.

102
Symmetric encryption

A B

cleartext ciphertext cleartext

f1() f2()

Key Key

103
Symmetric encryption

• Symmetric because both parties use the same key.

• An example of the mathematics used is the Data Encryption Standard (DES).

It uses a 56-bit key.

• DES is considered insecure (the key can be found within minutes by

employing brute-force techniques), it has been replaced by AES (Advanced
Encryption Standard).

• Symmetric encryption is fast and therefore used often.

• The problem, however, is key management. When a lot of parties need to

communicate with each other, the secured distribution of keys becomes a
problem.

104
Asymmetric encryption

A B

cleartext ciphertext cleartext

f1() f2()

Certificate Authority (CA)

manages private and public
keys of A and B
Keys: Keys:
Private-A, Public-B Public-A, Private-B

105
Asymmetric encryption

• Every party generates two keys: a private key that needs to be kept secret and a public key that
everyone may know.

• When A needs to send a confidential message to B, she uses a mathematical formula that encrypts
the message using her private key and B’s public key.

• When B receives the message, he can decrypt the message using his private key and A’s public
key.

• A separate entity, the certificate authority (CA), acts as an intermediate responsible for delivering
the public key of someone to everyone that asks for it.

• For this to work there are a number of pre-requisites, such as:

• The CA should make sure that the public key someone asks for indeed belongs to the party
that generated it.

• The mathematics involved should 100% guarantee that without the private keys no one can
decipher messages of the one that used the corresponding public key to cipher.

• An attention point must be given, in case the certificate authority (CA) is hacked, fake certificates
can be hacked and/or all certificates can be made invalid.

106
Digital signatures

• A private key is a unique identifier, thus it can be used as an electronic signature.

• Together with hash functions they can be used to prove identity and/or integrity.

• A generates a hash of a document and encrypts (“signs”) that document and its
hash using her private key and sends the results to B.

• B decrypts the document and hash using A’s public key and reruns the hashing
function. If the result on the decrypted document matches the decrypted hash
that A sent, the document can only have originated from A.

• Of course this only works when A keeps her private key secret and there is
definite proof that she “owns” her public key. This is again arranged using
Certificate Authorities (CA).

107
8.20-8.22 Networks security

E-mail server DNS Webserver

DMZ Mainframe

Internet
Router Firewall Router IDS

LAN

Home office

Firewall Antivirus Server Servers Clients

Development

Servers Workstations Printers

108
Infrastructural components – firewall types

Packet filtering firewall Stateful firewall Application layer firewall

These act by inspecting the "packets" which These record all connections passing through it and These can "understand" certain applications and
transfer between computers on the Internet. If a determine whether a packet is the start of a new protocols (such as File Transfer Protocol (FTP),
packet matches the packet filter's set of rules, the connection, a part of an existing connection, or not Domain Name System (DNS), or Hypertext
packet filter will drop or reject it. part of any connection. Though static rules are still Transfer Protocol (HTTP)). This is useful as it is
used, these rules can now contain connection state able to detect if an unwanted protocol is attempting
This type of packet filtering pays no attention to as one of their test criteria. to bypass the firewall on an allowed port, or detect
whether a packet is part of an existing stream of if a protocol is being abused in any harmful way.
traffic. It filters each packet based only on
information contained in the packet header (most
commonly using a combination of the packet's
source and destination address, its protocol, and,
for TCP and UDP traffic, the port number).

109
8.7 Protection against malware

• Malware comes in a variety of types; they damage data and/or applications or steal information.

• Systems (either hardware or software based) that detect malicious code rely on signatures that represent
previously found code of the malware or detect the malicious behavior of the malware itself.

• Unfortunately, these systems generate false-positives and accurately fail to detect all known malware.
Malware
• Note that ISO/IEC 27002 uses the more general term ‘malware’. This also denotes for instance hidden
backdoors and logical bombs that can (sometimes!) only be detected by humans when doing a code review of
bespoke software.

• A lot of malware nowadays is transferred via USB sticks but mostly by visiting infected websites.

110
8.31 Separation of development, test and production environments

Test environment Production environment

Authorization controls

• Tests environments should be controlled via authorization controls in order to protect the production environment’s integrity.

• By implementing this control an authorization must be made every time that data are being moved from the production to test and from the
test to the environment.

• This will increase not only the integrity of the data, but also guarantees that transferred data are aligned with the information security policy
of the organization.

111
Service Oriented Architecture (SOA)

There are two major roles within SOA:

Service Oriented Architecture (SOA) is an architectural approach in which applications make use of
services available in the network . In a service oriented architecture, a number of services communicate with each other, in Service provider: The service provider is the
one of two ways: through passing data or through two or more services coordinating an activity. maintainer of the service and the organization
that makes available one or more services for
The main SOA characteristics are: business value, strategic goals, intrinsic inter-operability, shared services, flexibility and others to use. To advertise services, the
evolutionary refinement provider can publish them in a registry,
together with a service contract that specifies
the nature of the service, how to use it, the
requirements for the service, and the fees
charged.

Service consumer: The service consumer

Service response can locate the service metadata in the registry
and develop the required client components
to bind and use the service.
Service provider Service consumer

Service request

112
Service Oriented Architecture (SOA) and information security

• When it comes down to information security, some aspects must be taken into consideration.

• Information security architecture follows information security strategy.

• It is important that when designing services or infrastructure based on SOA, the information
security team are involved in the project.

• The definition of which security services will be provided, and in which architecture, must be
defined to better align the information security requirements and the service for the customers.

113
Open-design architecture

• Open-design architecture advocates that establishing a single, consistent, clearly defined control
catalog provides an excellent means to simplify requirements from numerous standards,
governance frameworks, legislation, and regulations.

• Using OSA (Open Security Architect) patterns provides a fast start, improves the quality of the
solution that must be deployed, and reduces overall effort.

• Commonly, open-design architectures are tested a lot, which improves the security of the services.

Architectural principles

Simplicity over flexibility Usability over restriction Defense in depth

Implementation principles

Open design Secure coding practices Black box and white box testing

Operations and configuration principles

Complete mediation Least privilege Audit trails

114
Common Criteria

• Since firewalls and other access granting equipment are the gate-keepers to the information assets
of the organization, independent certification is required.

• ISO/IEC 15408, or “common criteria”, “… is a framework in which computer system users can
specify their security functional and assurance requirements, vendors can then implement and/or
make claims about the security attributes of their products, and testing laboratories can evaluate the
products to determine if they actually meet the claims”.

• When a security product has been tested against ISO/IEC 15408, it will be assigned an Evaluation
Assurance Level (EAL). When users determine their assurance requirements, they can then decide
ISO/IEC 15408 to install only equipment with the corresponding EAL’s.

• Assurance levels range from 1 (basic) to 7 (most stringent).

115
Thank you

Questions?

116
Contact EXIN

www.exin.com