IISP Knowledge Framework v1.0 - 2017-August

IISP Knowledge Framework
Version 1.0 | August 2017
Non-Commercial - No Derivatives (BY-NC-ND) license.

2017 Copyright © The Institute of Information Security Professionals. All rights reserved. The Institute of Information Security Professionals®,
IISP®, A.Inst.ISP™, M.Inst.ISP®, F.Inst.ISP™ and various IISP graphic logos are trademarks owned by The Institute of Information Security
Professionals and may be used only with express permission of the Institute.
IISP Knowledge Framework Version 1.0 August 2017 Page 1 of 195

Contents
1. Introduction ....................................................................................................................................... 6
1.1. Purpose ........................................................................................................................................ 6
1.2. Structure ...................................................................................................................................... 8
1.3. How to Use the Knowledge Framework ...................................................................................... 9
2. Knowledge Areas ............................................................................................................................. 11
2.1. Goals and Principles ................................................................................................................... 11
2.2. Threat, Vulnerability, Risk Assessment and Management ........................................................ 12
2.2.1. Risk Management .............................................................................................................. 12
2.2.2. Threat Modelling ................................................................................................................ 18
2.2.3. Vulnerability Assessment/Management and Penetration Testing .................................... 21
2.2.4. Threat Intelligence ............................................................................................................. 24
2.2.5. Topical References ............................................................................................................. 24
2.3. Governance and Information Security Management ................................................................ 27
2.3.1. Governance ........................................................................................................................ 27
2.3.2. Information Security Management.................................................................................... 28
2.4. Security Architecture and Controls ............................................................................................ 32
2.4.1. Type of Controls ................................................................................................................. 32
2.4.2. Security Architecture ......................................................................................................... 33
2.4.3. Design Patterns .................................................................................................................. 34
2.4.4. Security Design Principles .................................................................................................. 35
2.4.5. Physical Controls ................................................................................................................ 36
2.4.6. Procedural Controls ........................................................................................................... 37
2.4.7. Personnel Controls ............................................................................................................. 37
2.4.8. Cloud Computing ............................................................................................................... 37
2.4.9. Internet of Things ............................................................................................................... 43
2.4.10. Industrial Control Systems ................................................................................................. 45
2.4.11. Cryptography...................................................................................................................... 46
2.4.12. Technical Controls .............................................................................................................. 52
2.5. Information Security Framework ............................................................................................... 64
2.5.1. Legislation .......................................................................................................................... 65

2.5.2. Regulations......................................................................................................................... 71
2.5.3. Policies ............................................................................................................................... 73
2.5.4. Standards ........................................................................................................................... 82
2.5.5. Guidelines .......................................................................................................................... 84
2.5.6. Procedures ......................................................................................................................... 85
2.5.7. Security Awareness ............................................................................................................ 85
2.5.8. Security Strategies ............................................................................................................. 87
2.6. Security Lifecycle ........................................................................................................................ 91
2.6.1. Security Development Lifecycle ......................................................................................... 91
2.6.2. Secure Coding .................................................................................................................... 91
2.6.3. Testing ................................................................................................................................ 92
2.6.4. Hardening ........................................................................................................................... 92
2.6.5. Independent Assurance ..................................................................................................... 93
2.6.6. Deployment and Release Management ............................................................................ 95
2.6.7. Patch Management ............................................................................................................ 96
2.6.8. Change Management ......................................................................................................... 98
2.6.9. Data Security Lifecycle ....................................................................................................... 98
2.6.10. Topical References ........................................................................................................... 100
2.7. Operational Compliance .......................................................................................................... 103
2.7.1. Auditing ............................................................................................................................ 103
2.7.2. Compliance Monitoring ................................................................................................... 104
2.7.3. Protective Monitoring ...................................................................................................... 105
2.7.4. Incident Management...................................................................................................... 107
2.7.5. Topical References ........................................................................................................... 109
3. Knowledge Levels .......................................................................................................................... 111
4. Common Terms ............................................................................................................................. 144
5. Abbreviations and Acronyms......................................................................................................... 180
6. Skill Areas to Knowledge Areas...................................................................................................... 193


Table of Figures
Figure 1 - Skills Framework, Knowledge Frame and Cyber Security Body of Knowledge Relationship ....... 7
Figure 2 - Structure of the Knowledge Framework...................................................................................... 8
Figure 3 - Risk Wheel.................................................................................................................................. 14
Figure 4 - Gartner's Predict, Prevent, Detect, Respond Framework ......................................................... 15
Figure 5 - Risk Treatment Options ............................................................................................................. 17
Figure 6 - Risk Management Overview ...................................................................................................... 18
Figure 7 - Attack Tree ................................................................................................................................. 19
Figure 8 - Data Flow Diagram..................................................................................................................... 21
Figure 9 - Information Security Governance.............................................................................................. 27
Figure 10 - Information Security Management System ............................................................................. 29
Figure 11 - Types of Security Controls ....................................................................................................... 33
Figure 12 - SABSA Layers ............................................................................................................................ 34
Figure 13 - Cloud Subscribers and Providers ............................................................................................. 38
Figure 14 - Cloud Actors ............................................................................................................................. 38
Figure 15 – Cloud Service Models and Levels of Control and Abstraction ................................................ 40
Figure 16 – SaaS, PaaS and IaaS Layers ...................................................................................................... 40
Figure 17 – Shared Responsibility Model for AWS Infrastructure Services ............................................... 41
Figure 18 – Encryption and Decryption ..................................................................................................... 47
Figure 19 - Symmetric Cryptography ......................................................................................................... 48
Figure 20 - Asymmetric Cryptography ....................................................................................................... 48
Figure 21 - Asymmetric Cryptography used for Encryption....................................................................... 49
Figure 22 - Asymmetric Cryptography used for Key Distribution .............................................................. 49
Figure 23 - Hash Function .......................................................................................................................... 50
Figure 24 - Digital Signature ....................................................................................................................... 51
Figure 25 - Intrusion Prevention System.................................................................................................... 56
Figure 26 - Typical Firewall Architecture ................................................................................................... 60
Figure 27 - Information Security Framework ............................................................................................. 64
Figure 28 - Security Awareness .................................................................................................................. 86
Figure 29 - Vulnerability and Patch Management ..................................................................................... 97
Figure 30 - Data Security Lifecycle ............................................................................................................. 99
Figure 31 - Compliance and Protective Monitoring ................................................................................. 103
Figure 32 - Security Operations Centre.................................................................................................... 106
Figure 33 - Incident Management and Risk ............................................................................................. 107
Figure 34 - Phases of Incident Management ........................................................................................... 108
Figure 35 - IISP Skills Framework ............................................................................................................. 111


Copyrights and Trade Marks
Permission to reproduce extracts from British Standards is granted by BSI. British Standards can be
obtained in PDF or hard copy formats from the BSI online shop: www.bsigroup.com/Shop or by
contacting BSI Customer Services for hardcopies only: Tel: +44 (0)20 8996 9001, Email:
cservices@bsigroup.com.
The name "OASIS", the OASIS corporate logos, and the names and common abbreviations of OASIS
specifications are trademarks of the OASIS consortium.
Oxford University Press is a department of Oxford. Oxford is a registered trade mark of Oxford
University Press in the UK and in certain other countries.
CSA’s trademarks and service marks include, without limitation, Cloud Security Alliance; CSA; Certificate
of Cloud Security Knowledge; CCSK; CSA Security, Trust and Assurance Registry; CSA STAR, and any
associated logos.
OpenID® is a trade mark (registered in numerous countries) of the OpenID Foundation.
CREST (GB) Limited, CREST and the CREST logos are trade marks of CREST.
Tiger Scheme is a trademark at Tiger Scheme Ltd.
Qualified Security Assessor (QSA) is a trade mark of PCI Security Standards Council.
The Predict, Prevent, Detect, Respond Framework is copyrighted by Gartner, Inc.


1. Introduction
1.1. Purpose
This document contains the IISP Knowledge Framework. It builds upon the IISP Skills Framework version
2.1. It contains in detail the knowledge that a practitioner should have at Levels 1 and 2
The definitions of these two levels are as follows:
Level 1: (Knowledge) Basic knowledge of principles/follow good user practice
Has acquired and can demonstrate basic knowledge associated with the skill, e.g. through training
or self-tuition.
Level 2: (Knowledge and Understanding) Knowledge and Understanding of basic

principles
Understands the skill and its application.
Knowledge
Has acquired and can demonstrate the basic knowledge associated with the skill, for example has
attended a training course or completed an academic module in the skill. Understands how the
skill should be applied.
Practice
Can explain the principles of the skill and how it should be applied. This might include experience
of applying the skill to basic tasks in a training or academic environment, for example through
participation in syndicate exercises, undertaking practical exercises in using the skill, and/or
passing a test or examination. Should be aware of recent developments in the skill.
The objectives of the Knowledge Framework are to:

1. To define the knowledge at Levels 1 and 2 required by professionals in Cyber Security and
Information Security.
2. To assist IISP interviewers and assessors understanding the requirements of knowledge and
understanding for each of the Security Disciplines.
3. To provide a topical access to the “Cyber Security Body of Knowledge” for Levels 1 and 2. (see
Figure 1)
4. To promote a consistent view of Cyber Security and Information Security.
5. To provide a foundation for curriculum development, course accreditation and for individual
professional certification. In particular to define the knowledge required to pass a Level 1
examination.
6. To inform organisations and managers deciding which competencies and skills that practising Cyber
Security and Information Security professionals should possess in various roles ranging from
apprentice to expert.


Figure 1 captures two of the primary purposes of the Knowledge Framework, namely to:
• Expand upon the IISP Skills Framework.
• Provide topical access to the “Cyber Security Body Knowledge”.
Topical
Access
Expands External Bodies
Skills Knowledge of Knowledge,
Framework Framework Standards etc
Cyber Security
Body of Knowledge
Figure 1 - Skills Framework, Knowledge Frame and Cyber Security Body of Knowledge Relationship
“Topical access” in this sense means providing access to up to date information of immediate relevance,
interest, or importance which expands upon the information contained in the Knowledge Framework.
Level 1 and Level 2 information is contained within the Knowledge Framework, whilst Level 3 and above
knowledge is contained in the “Cyber Security Body of Knowledge” (CyBOK). The CyBOK should be
considered as a logical construct. It contains all the standards, laws, regulations, papers and other
reference material that the Knowledge Framework provides topical access to.


1.2. Structure
The IISP Knowledge Framework consist of four sections divided into two parts. The first part contains
two sections, namely:
• Knowledge Areas – provides an overview to each Knowledge Area and then topical references to
external documents and standards. Each Knowledge Area is then sub-divided into sub-areas.
• Knowledge Levels – provides an overview of each of the Skill Areas and then defines the knowledge
and practices required for levels 1 and 2.
The second part of the Knowledge Framework contains references, namely
• Common Terms – definitions of a wide range of common terms used in Cyber and Information
Security. When a common term is used in the Knowledge Area and Knowledge Levels sections it is
hyperlinked to this section.
• Abbreviations and Acronyms - a list of abbreviations and acronyms used in the document.
Figure 2 shows the structure of the Knowledge Framework in diagrammatic form.
Part 1
Topical
Access
External Bodies
of Knowledge,
Standards etc
Knowledge Areas
Cyber Security
Hyperlinks Body of Knowledge
Knowledge Levels
Part 2
Common
Terms
Abbrevs / Acronyms
Figure 2 - Structure of the Knowledge Framework
In addition the document contains a mind map showing how the Skill Areas in the IISP Skills Framework
map to the Knowledge Areas.


1.3. How to Use the Knowledge Framework
The Knowledge Framework can be used in a number of different ways.
Firstly it can be used as a reference work. For example, if you want to look up a definition or understand
what a particular Skill Area entails.
Secondly it can be used as a book, particularly for those new to the field of Cyber and Information
Security. In this case the Knowledge Areas section can be read from start to finish, with the reader
referring out to the common terms section as necessary.
Finally it can be used as a means of looking up standards, laws, regulations etc. relevant to either a
Knowledge Area or a Skill Area.


Part 1:
Knowledge Framework


2. Knowledge Areas
2.1. Goals and Principles

The primary goal of cyber and information security is to preserve the confidentiality, integrity, and
availability of information and information systems. If there is a significant failure in one or more of
them the result could be a loss of reputation, privacy, life and financial loss.
The principles behind an organisation’s Information Security Management System (ISMS) should be to
design, implement, and maintain a coherent set of policies, processes, and controls that keep the risks
associated with its information assets at a tolerable level whilst managing the cost and inconvenience.
The goals of cyber and information security are to:
• Understand the current risk appetite of the enterprise with respect to cyber and information
security.
• Understand the security threats and potential consequences and damage to information,
information systems, devices, and individuals.
• Create and follow policies and procedures that keep cyber and information risks, consequences and
damage at or below a tolerable level.
• Create, securely deploy and maintain suitable controls to minimise risks and vulnerabilities to
reduce the threat potential and business impact.
• Effectively and efficiently detect and deal with cyber and information security incidents.
Cyber Security is designed to protect networks, computers, programs and data from external attack in
cyberspace. Cyber Security can be considered to be a specialism inside Information Security.
Information security is protecting the data wherever it is held whether by the data owner or by a
contracted third party.
The following Knowledge Areas examine these goals in more detail:
• Threat, Vulnerability, Risk Assessment and Management.
• Governance and Information Security Management
• Security Architecture and Controls.
• Information Security Framework.
• Security Lifecycle.
• Operational Compliance.
Each one has topical resources and standards to look at for more information. In a few situations it has
not been possible to provide suitable topical references.


2.2. Threat, Vulnerability, Risk Assessment and Management
In this section we look at a number of disciplines that are concerned with looking at potential and real
risks to an information system. We will examine the following:
• Risk management.
• Threat modelling.
• Vulnerability Assessment/Management and Penetration Testing.
• Threat Intelligence.
2.2.1. Risk Management

In this section we examine risk assessment and risk management. Before we do this we need to define
“CIA”.
CIA stands for confidentiality, integrity, and availability. These are known as the three tenets or
cornerstones of information security objectives. Virtually all practices within the field of cyber and
information security are designed to uphold these three properties. CIA is also known as the CIA triad.
Confidentiality ensures that the information is not disclosed to unauthorised persons or processes. The
concept of confidentiality attempts to prevent the intentional or unintentional unauthorised disclosure
of information. Loss of confidentiality can occur in many ways, such as through the intentional release
of private company information or accidental misclassification of information leading to inappropriate
handling. Restricting access to information to those who have a need-to-know is good practice and is
based on the principle of confidentiality.
The next tenet we shall look at is integrity. This means that information is only useful if it is complete
and accurate. Maintaining the integrity of information is often critical to any information system.
The concept of integrity seeks to ensure that:
• Modifications are not made to data by unauthorised personnel or processes.
• The data is internally and externally consistent.
• It is accurate and complete over its entire life-cycle.
The final tenet we shall look at is availability. The concept of availability ensures the reliable and timely
access to data or computing resources by appropriate personnel. In other words, availability seeks to
ensure that information systems are up and running when they are needed. Many attacks, such as
denial of service attacks, are deliberately triggered to make a system difficult or impossible to use
resulting in a business impact.
Whilst most people think of cyber and information security as consisting of a combination of
confidentiality, integrity and availability it is also important to know that there are some other
characteristics that are considered important. Non-repudiation is the presentation of non-forgeable
evidence that a message was sent or received. If messages or transactions can be disputed then
important identity actions can be challenged and jeopardised. Normally, proof is determined by a third-
party. Therefore, neither the sender nor the receiver can dispute the action.
Accountability is the property that ensures that the actions of an entity can be traced solely to that
entity. Accountability ensures that all operations carried out by individuals, systems or processes can be
identified and can be traced that entity.
Authenticity is the property of being genuine and being able to be verified and trusted. This pertains to
a number of different types of entities including: software, messages, transmissions and individuals.


Reliability is the property of leading to consistent intended behaviour and results.
As stated above we are concerned about risks to assets. What is an asset? There are many different
types of assets, for example: information assets; software, such as a computer program; physical, such
as computer; services; people; and intangibles, such as reputation and image. An information asset is a
body of information, defined and managed as a single unit so it can be understood, shared, protected
and exploited effectively.
A threat is something that may occur that causes some unwanted consequence or has some business
impact. Threat is a potential violation of security. This violation need not actually occur. The fact that
the violation might occur makes it a threat. It is important to protect against threats and be prepared
for the actual violation. A threat agent is the originator and/or initiator of deliberate or accidental man-
made threats.
A vulnerability is a weakness of an asset or control that can be exploited by a threat. The presence of a
vulnerability does not cause harm in itself as there needs to be a threat present to exploit it.
Vulnerabilities may be identified in any aspect of an information system or organisation, such as
processes and procedures, physical environment, information system configuration, hardware, software
or communications equipment. The successful exploitation of a vulnerability by a threat agent will result
in the compromise of confidentiality, integrity or availability of an asset. This compromise will have a
consequence, usually referred to as a business impact. A business impact is by definition the
consequence that the compromise has on the operations or efficiency of the organisation or on
customers or citizens.
Information risk can be thought of as the likelihood that a threat will exploit a vulnerability leading to a
business impact.
The relationship between all these terms can be found in Figure 3.


Figure 3 - Risk Wheel
As an example of how the risk wheel works for a zero-day vulnerability:

A threat could exploit a zero-day vulnerability which could expose assets leading to a loss of
confidentiality, integrity or availability which could cause a business impact.
Another approach for looking at cyber and information security is to use Gartner’s Predict, Prevent,
Detect, Respond (PPDR) Framework. It can be very useful as a tool to communicate an organisation’s
strategy and approach to security in easy-to-understand, outcome-focused terms.- Gartner's Predict,
Prevent, Detect, Respond Framework. Figure 4 illustrates the four steps of the framework. We will cover
all the points raised in this figure later on in the document. However, the first step, PREDICT, is the topic
covered in this Knowledge Area. : It requires an organisation to know their risks.


PREDICT PREVENT
Understand your risk Prevent or deter attacks
Know your attack surface Minimize attack surface
Predict most likely attacks Patch and update software
Good user behaviours
RESPOND DETECT
Rapidly address incidents Recognise incidents and threats
Mitigate the damage Monitor key areas and activities
Analyse and learn
Figure 4 - Gartner's Predict, Prevent, Detect, Respond Framework
The overall process of analysing and managing risks is called risk management. The first part of risk
management is called risk assessment. Risk assessment itself is then subdivided into three activities, as
follows:
• Risk identification.
• Risk analysis.
• Risk evaluation.
The purpose of risk identification is to determine what could happen to cause a potential loss, and to
gain insight into how, where and why the loss might happen. Risk identification involves identifying
assets, threats, existing controls, vulnerabilities and business impacts. Threat intelligence can be used to
inform on the threats and vulnerabilities to a system.
The risk identification stage is also sometimes referred to as a business impact analysis (BIA). A BIA
always commences with an understanding of what the organisation’s key assets are. These could
include such things as people, property, systems and information, and each will have some form of
value to the business.
The BIA will then examine the impact of a threat taking place on each of the key assets identified. The
impact can be measured objectively in purely numerical terms such as money or number of customers,
or can be measured more subjectively as high, medium or low. Apart from financial impacts, other
consequences may be on reputation, ability to provide customer service, or the ability to meet legal or
regulatory requirements. It is important that the asset owner within the business is involved in the BIA
as it is they who will have the best view of the asset’s value.
The next stage is risk analysis. This is the process to comprehend the nature of risk and to determine the
level of risk and provides the basis for risk evaluation and decisions about risk treatment. This analysis
takes into account impacts on the assets and the likelihood of threats. Risk analysis may be undertaken
in varying degrees of detail depending on the criticality of assets, extent of known vulnerabilities, and
prior incidents involving in the organisation. A risk analysis methodology may be qualitative or
quantitative, or a combination of these, depending on the circumstances. The output of the risk analysis
process is a list of risks with assigned levels of risk, using either a qualitative or quantitative method.
The final stage of risk assessment is risk evaluation. This is the process of comparing the results of risk
analysis with risk criteria to determine whether the risk is acceptable or tolerable. At this stage the
analysis can indicate which risks are within an organisation’s risk appetite or which requires treatment
to lower the level of level of risk so it is tolerable (known as risk tolerance).


The final stage in the risk management process is risk treatment. When it comes to risk treatment, it
should be obvious that those risks that have the highest impact, and are high likelihood events, should
be dealt with first – assuming they are outside an organisation’s risk appetite.
Security controls can be used to treat risks. In treating risks one could potentially do one of the
following:
• Reduce, or modify the risk.
• Accept, or retain the risk.
• Avoid the risk.
• Share the risk with someone else.
We will look at these in more detail.
The first approach is called risk reduction, although the latest standards now use the term risk
modification. The aim here is to lessen the likelihood, impacts, or both, associated with a risk. This is
usually performed by using controls.
The second approach is called risk retention or risk acceptance. Having performed a risk assessment, an
appropriately authorised manager or director in an organisation could just accept the risk. This assumes
the risk is within the organisation’s risk appetite.
The next approach is risk avoidance. This means taking a set of actions that removes the threat of a
certain risk occurring at all.
The final approach is risk sharing. A risk could be shared with, or transferred to, another party that can
more effectively manage that particular risk, depending on the risk evaluation. Sharing can be done by
insurance that will support the consequences, or by subcontracting a partner whose role will be to
monitor the information system and take immediate actions to stop an attack before it makes a defined
level of damage.
Many organisation produce a Remediation Action Plan (sometimes referred to as a Risk Treatment Plan)
to record risks and how they are treated. This includes details such as:
• Level of risk.
• Impact and likelihood of the risk.
• Controls used to treat the risk and level of risk after treatment.
• Name of authorised Individual who accepted the risk if not completely treated.
Note that a Remediation Action Plan need not just contain output from a risk assessment but could also
contain entries from:
• Vulnerability assessments.
• Non-compliance with policies and standards.
• An information security incident.
• Internal or external audit reports.
Figure 5 summarises the risk treatment options.


Figure 5 - Risk Treatment Options
Figure 6 provides an overview of risk management as described above. This type of figure can be found
in two ISO standards, ISO/IEC 27005 and ISO 31000.
Context Establishment is where an organisation articulates its objectives, defines the external and
internal parameters to be taken into account when managing risk, and sets the scope and risk criteria
for the remaining processes, such as risk assessment and risk treatment. During the Context
Establishment phase, all information about the organisation relevant to the information security risk
management context is established. This involves setting the basic criteria necessary such as:
• Risk evaluation criteria.
• Impact criteria.
• Risk acceptance criteria.
It is also used to define the scope and boundaries such as:
• Defining relevant assets.
• Articulating business objectives.
• Setting out the business processes in scope.
• Listing the legal and regulatory requirements applicable to the organisation.
• Interfaces to other organisation, for example were information is exchanged.
Context Establishment should also be used to define and set-up an appropriate governance structure.


Figure 6 - Risk Management Overview
They are a number of risk management methodologies and methods. Those in widespread use are
provided in the topical references section.
Either ISO/IEC 27005 or ISO 31000 can be used to perform risk management in a business continuity
context. Business Continuity Management (BCM) is focused on keeping an organisation working in the
face of disruptive events. Risk management for BCM is therefore focused on dealing with events that
have a major impact on the organisation. While risk management will consider all threats, BCM risk
management focuses on impacts and on developing a Business Continuity Plan (BCP) to deliver a more
resilient organisation. Many of the Business Continuity threats to an organisation, whether external or,
internal, have similar impacts. For example, a flu pandemic, industrial disputes, transport network
disruption or terrorist action will all have the same impact, namely a loss of people available to work.
The severity of the impact will differ depending on the duration of the disruption. A business continuity
risk assessment should also take into account environmental threats such as flooding and power
outage.
ISO 22301 is the standard that helps organisations put business continuity plans in place to protect
them, and help them recover from, disruptive incidents when they happen. It also helps identify
potential threats to a business and to build the capacity to deal with unforeseen events. We will talk
more about business continuity in the sections on policies, standards, procedures and incident
management.
2.2.2. Threat Modelling

Threat modelling is an approach for analysing the security of a system, whether it is the network, the
infrastructure or the applications. It is a structured approach that enables you to identify and address


security risks and vulnerabilities, and then define the controls to prevent, or mitigate the effects of,
threats to the system. Threat intelligence can inform threat modelling activities by identifying new
vulnerabilities and threat agents. Note that threat modelling can be used in conjunction with risk
management – or performed separately.
Threat models are sometimes referred to as threat scenarios. A threat scenario is an illustration where
one or more threat actors can mount one or more attacks in an attempt to compromise an identified
asset by exploiting both vulnerabilities and inadequate controls.
We will look at two common techniques. The first threat modelling approach to look at referred is
attack trees. Attack trees are produced through methodical analysis of a security system. Bruce Schneier
defines them as follows:
“Attack trees provide a formal, methodical way of describing the security of systems, based on
varying attacks.”
Figure 7 illustrates an attack tree. The attacks are represented with a treelike structure that starts with a
root node. In this case it is marked as “Gain Access to System”. The root node has one or more child
conditions that must be true for an attacker to exploit a threat. In turn, any of these child conditions
may have one or more children of their own. Attack trees are quite easy to construct and offer an
overview on the attacks that might be made to a system.
Gain Access to
System
Man in The
Denial of Service Eavesdropping Spoofing Invalid Flow
Middle Attack
IP address Spoof ARP Poisoning

DHCP Snooping Mis-routing
Obtain Authn MAC Address Switch Mis- Obtain Authn
Credentials Spoof configuration Credentials
DHCP Starvation
Obtain PM
WAN Spoof
Obtain PM MAC Flooding Information
Information
DNS Spoof
Figure 7 - Attack Tree
Attack trees can be quite sophisticated. For instance one could add annotations to each node including
whether a particular attack is possible/impossible or expensive/inexpensive. You can also use Boolean
algebra. For instance, you could use OR nodes where a successful attack is possible if any of its child
nodes occur, or if you have AND nodes the attack is possible only if all child nodes occur.
The next technique we will look at is called STRIDE which has been produced by Microsoft. It is
supported by the Microsoft SDL Threat Modeling Tool, which we will talk about shortly. STRIDE is
actually a threat classification scheme. STRIDE is an acronym for the following:
• Spoofing – using someone else’s credentials to gain access to otherwise inaccessible assets.
• Tampering – changing data to mount an attack.
• Repudiation – occurs when a user denies performing an action, but the target of the action has no
way to prove otherwise.
• Information disclosure – the disclosure of information to a user who does not have permission to


see it.
• Denial of service – reducing the ability of valid users to access resources.
• Elevation of privilege – occurs when an unprivileged user gains privileged status.
The SDL Threat Modeling Tool allows an analyst to model a representation of the software or
components of a system and the data flows between them based on the STRIDE classification scheme.
The resulting threat model allows for potential design vulnerabilities to be discovered and potential
threats to the information assets in the system.
Microsoft Threat Modeling Tool allows you to:
• Create Data Flow Diagrams (DFDs) for products or services and show interactions between different
types of entities.
• Analyse Data Flow Diagrams to automatically generate a set of potential threats based on the
STRIDE threat classification.
• Suggest potential mitigations to vulnerabilities in the design.
• Produce reports on the identified and mitigated threats.
• Define trust boundaries.
A trust boundary is used to separate different levels of trust and reliability. A good example of a trust
boundary for web applications is the demarcation between the user’s browser/computer and the
application interface, which resides on a server somewhere on the Internet. Data flow across trust
boundaries is particularly important because code that is passed data from outside its own trust
boundary should assume that the data is malicious and perform thorough validation of the data.
Figure 8 shows a simple DFD diagram produced using the tool. It is a representation of a mobile app
store.


Figure 8 - Data Flow Diagram
2.2.3. Vulnerability Assessment/Management and Penetration Testing

Vulnerability assessment is the process of identifying vulnerabilities within a system. This could be a
software system, a physical system or even a mechanical system, and the testing can be targeted to
focus on components that might be technical, physical or even administrative in their nature. Typically a
vulnerability assessment does not try and break into a system – unlike penetration testing. Vulnerability
assessment is where tools are used to scan a system or network for a list of known vulnerabilities, such
as system misconfiguration, outdated software, or a lack of patching. These tests can be performed
either on a pre-production system or a production system. It should be noted that a penetration test,
and to a lesser extent a vulnerability assessment, could cause a system to crash or become non-
operational. Hence, care should be taken when testing critical operational systems.
A vulnerability assessment tool can be used to test the capability of a system’s or network’s security and
discover points of weakness. These tools do not provide direct protection or security for a system or
network but instead they gather and report information. Vulnerability assessment tools typically can be
used to test:
• Hosts.
• Networks.


• Applications.
• Web services.
Outputs of risk assessments and threat modelling can be used to help focus a vulnerability assessment.
A penetration test simulates the actions of an external or an internal attacker that aims to breach the
information security of the organisation. This could potentially include trying to obtain information or
attempting to leave messages or malware in a specific location. Using many tools and techniques, the
penetration tester attempts to exploit critical systems and gain access to sensitive data. These tests can
also look at trying to subvert or break physical or procedural controls, for example gaining unauthorised
access to a data centre.
It is usual to agree a scope of the vulnerability assessment or penetration test. A scoping document
normally includes:
• Components within scope: the systems, servers, applications, devices and components that should
be included within the test.
• Components out of scope: those components that should not be included within the test.
• Configuration of components: the network infrastructure and IP addresses of those systems,
servers, applications, devices and components that are within scope.
• Approach: the location of tests. Whether the tester can exploit any identified vulnerabilities.
Specific time slots (during or out of business hours).
• Specific tests: any specific areas of concern that the organisation may have should be identified for
inclusion.
• Report contents: any specific requirements that the company may have for the way that the final
report is structured, and the format in which the results are to be presented.
• Timescales: the timescales in terms of when and how long the testing should take. This will also
define how soon after the testing is complete the final report should be delivered.
Interpreting and analysing a report is a skilled job. It is not unusual to find false positives or false
negatives described in a report.
A wide selection of tools are available to the vulnerability and penetration tester. However, many
testers use the collection of tools known as Kali Linux.
There are a number of methodologies that exist for performing vulnerability assessments or penetration
tests. Some of them are listed in the topical references section.
Vulnerability assessments and penetration testing could be performed by internal or external teams.
External teams are sometimes referred to as Red Teams, with an internal teams being referred to as
Blue Team.
Some organisations have a bug bounty program in particular those that have web sites or offer “web
services”, for instance Facebook, Google and Microsoft. From a cyber security perspective a bug bounty
program is where an individual can receive recognition and compensation for reporting exploits and
vulnerabilities. Individuals that participate in such a program are typically external to the organisation
offering the bounty.
OWASP publishes the OWASP Top Ten. It is an awareness document for web application security and
represents a broad consensus about what the most critical web application security flaws are.


The OWASP Top 10 2013 lists the top 10 flaws, i.e. vulnerabilities, as being:
• A1-Injection.
• A2-Broken Authentication and Session Management.
• A3-Cross-Site Scripting (XSS).
• A4-Insecure Direct Object References.
• A5-Security Misconfiguration.
• A6-Sensitive Data Exposure.
• A7-Missing Function Level Access Control.
• A8-Cross-Site Request Forgery (CSRF).
• A9-Using Components with Known Vulnerabilities
• A10-Unvalidated Redirects and Forwards.
A new OWASP Top Ten list will be published by the end of 2017.
There are three common techniques used to define and record vulnerabilities, they are:
• Common Vulnerabilities and Exposures (CVE)

• Common Vulnerability Scoring System (CVSS)
• Common Weaknesses Enumeration (CWE)
All three are widely used by product vendors and security researchers.
The National Vulnerability Database (NVD) is a U.S. government repository of standards based
vulnerability management data. This data enables automation of vulnerability management, security
measurement, and compliance. NVD includes databases of security checklists, security related software
flaws, misconfigurations, product names, and impact metrics. Each product vulnerability is identified
with a CVE value and CVSS scores.
Vulnerability management is a comprehensive approach to the development of a system of practices
and processes designed to identify, analyse and address vulnerabilities in hardware or software. It is
specifically designed to proactively mitigate or prevent the exploitation of vulnerabilities which exist in a
system or organisation.
Vulnerability management usually involves the following:
• Planned and regular vulnerability assessments.
• Review and actioning relevant CERT alerts.
• Obtaining and reviewing product vendor reports on vulnerabilities and updates.
• Engaging with operational teams to trigger appropriate patching of software.
• Engaging with architectural teams to implement new technical controls.
• Using threat intelligence to establish new vulnerabilities.
Commercial tools exist to assist organisations in performing vulnerability management.


2.2.4. Threat Intelligence
Threat intelligence is threat information that has been aggregated, transformed and analysed, to
provide the necessary context for decision-making processes - in particular to inform risk management,
threat modelling and vulnerability management activities. The principle behind threat intelligence is to
provide the ability to recognise and act upon indicators of attack and compromise scenarios in a timely
manner.
Effective threat intelligence involves comprehensive, continuous collection and analysis of the right data
sources, from both inside and outside an organisation. Threat assessments should be sought from:
• The theatre of operations, e.g. geographic information.
• The specific industry or business domain.
• The IT environment, for example specific threats to the use of cloud technologies.
Threat information can be collected from a number sources, including:
• Open Source Intelligence (OSINT) from sources such as websites, blogs, forums, breach databases
and exploit databases (e.g. the Web-Hacking-Incident-Database – WHID).
• In the UK a number of WARP (Warning, Advice and Reporting Point) communities have been
created. A WARP is a community-based service where members can receive and share up-to-date
advice on information security threats, incidents and solutions.
• The US Department of Homeland Security (DHS) Office of Cybersecurity and Communications,
National Cybersecurity and Communications Integration Center, and US-CERT are leading efforts to
automate and structure operational cybersecurity information sharing techniques across the globe:
Exchange of threat information from partners using Trusted Automated Exchange of Indicator
Information (TAXII) and Structured Threat Information Expression (STIX).
• External Data Feeds such as commercial phishing feeds, produce vendor updates, spam analytics
and CERT/Government alerts.
• Partner and supply chain data, sharing threat intelligence reports with partners in a supply chain.
• SIEM Information, evaluated events from SIEM analysis and exploration in particular looking for
anomalous user activity.
A number of products and service exist in assisting organisations to obtain and process threat
intelligence.
2.2.5. Topical References

Risk Management and Terminology
Name Description and Location
ISO/IEC 27000:2014 Information technology — Security techniques — Information security
management systems — Overview and vocabulary.
ISO or BSI web site.
ISO/IEC 27005:2011 Information technology — Security techniques — Information security risk
management
ISO 22301 ISO 22301:2012. Societal security -- Business continuity management
systems --- Requirements.
ISO 31000:2009 Risk management – Principles and guidelines


ISO Guide 73:2009 Risk management — Vocabulary.
Information Risk Management David Sutton. BCS.
– A practitioner’s guide ISBN 978-1-78017-265-1
IRAM2 Information Risk Analysis Methodology (IRAM) produced by the ISF
https://www.securityforum.org/products-services/risk-manager
OCTAVE Allegro Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE)
methodology. Produced by the SEI
http://www.cert.org/resilience/products-services/octave/index.cfm
Risk IT Produced by ISACA.

http://www.isaca.org/knowledge-center/risk-it-it-risk-
management/pages/default.aspx
NIST SP 800-30 NIST Special Publication 800-30. Guide for Conducting Risk Assessments.
(September 2012)
http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-
30r1.pdf
The Open FAIT™ Body of The Open FAIT™ Body of Knowledge – A Pocket Guide: A Taxonomy and
Knowledge Method for Risk Analysis. Published by The Open Group. (2014)
ISBN 978 94 018 0018
Threat Modelling
Attack Trees https://www.schneier.com/academic/archives/1999/12/attack_trees.html.
Threat Modelling: Designing for Adam Shostack. John Wily & sons, Inc.
Security. ISBN 978-1-118-80999-0
Microsoft SDL Threat Modeling https://www.microsoft.com/en-us/sdl/adopt/threatmodeling.aspx
Tool
Threat Intelligence
MWR InfoSecurity Threat Intelligence: Collecting, Analysing, Evaluating. Paper produced with
the support of CPNI and CERT-UK
TAXII and STIX Information Sharing Specifications for Cybersecurity.
https://www.us-cert.gov/Information-Sharing-Specifications-Cybersecurity
WARP https://www.ncsc.gov.uk/articles/what-warp
and
https://www.warp.gov.uk/about-us/
Vulnerability Assessment/Management and Penetration Testing

Penetration Testing Execution http://www.pentest-standard.org/
Standard


PCI DSS Information Supplement: Penetration Testing Guidance
https://www.pcisecuritystandards.org/documents/Penetration_Testing_Guid
ance_March_2015.pdf
OSSTMM Open Source Security Testing Methodology Manual

http://www.isecom.org/research/osstmm.html
Kali Linux https://www.kali.org/
OWASP Testing Guide https://www.owasp.org/images/1/19/OTGv4.pdf
OWASP Top 10 https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

CVSS Common Vulnerability Scoring System
https://www.first.org/cvss
CVE Common Vulnerabilities and Exposures
http://cve.mitre.org
NVD National Vulnerability Database
https://nvd.nist.gov


2.3. Governance and Information Security Management
2.3.1. Governance
Corporate governance refers to the mechanisms, processes and relationships by which organisation are
controlled and directed. Governance structures identify the rights and responsibilities among different
participants in the organisation, such as the board of directors, managers, shareholders, creditors,
auditors, regulators, and other stakeholders. It also includes the rules and procedures for making
decisions in corporate affairs. Information security governance is similar but it is the system by which an
organisation directs and controls information security. It should not be confused with information
security management, which we will cover next. Information security management is concerned with
making decisions to mitigate risks; information security governance is primarily concerned with who is
authorised to make decisions. Information security governance specifies the accountability framework
and provides oversight to ensure that risks are adequately mitigated, while information security
management ensures that security controls are implemented to mitigate risks.
Information security governance is the foundation of an Information Security Management System
(ISMS) as it provides both strategic and operational frameworks. It needs to make sure that its
objectives and strategies align with business objectives and strategies.
Information Security Governance must be viewed as being an integral part of the organisation’s wider
governance structures and mechanisms, such as IT, business continuity, risk management and financial
planning. In particular it must be seen as linking into overall corporate governance, as shown in Figure 9.
Figure 9 - Information Security Governance
ISO/IEC 27014 was published in 2013 and provides guidance on the concepts and principles for the
governance of information security. The standard provides:
“guidance on concepts and principles for the governance of information security, by which
organisations can evaluate, direct, monitor and communicate the information security related
activities within the organisation” and is “applicable to all types and sizes of organisations”.
From ISO/IEC 27014, the principles of information security governance are to:
• Establish organisational wide information security.
• Adopt a risk based approach.
• Set the direction of investment decisions.
• Ensure conformance with internal and external requirements.


• Foster a security-positive environment.
• Review performance in relation to business outcomes.
One of the key aspects of information security governance is the establishment of a governance
structure. At the top of this should be a governing body – as ISO/IEC 27014 calls it. This is either a single
person or group of people who are accountable for the performance and conformance of the
organisation to the principles and objectives stated above. This this could be the CISO, the board of
directors, or a named director on the board. The governing body is usually also responsible for:
• Ensuring that adequate resources are provided so that security objectives and strategies can be
met.
• Defining and approving an organisation wide security policy or set of security policies.
• Defining and approving the risk management approach adopted by the organisation.
• Defining the organisation’s risk appetite.
• Establishment of an Information Security Management System.
• Defining the roles and responsibilities of persons and any committees within the governance
structure.
• Defining within the governance structure who can accept risks and at what level, in particular
who should accept a risk if it is above the organisation’s risk appetite and can’t be mitigated.
The governing body is ultimately accountable for an organisation’s decision and performance of the
organisation from an information security perspective. The key focus of it is to ensure the organisation’s
approach to information security is efficient, effective, acceptable and in line with business objectives
and strategies giving due regard to stakeholder expectations. Stakeholders could include shareholders,
board of directors, regulators etc.
2.3.2. Information Security Management

If information security is concerned with protecting the confidentiality, integrity and availability of
information, then information security management is the means by which this can be achieved. The
standard ISO/IEC 27001 describes a way to manage information security, by creating an Information
Security Management System (ISMS). This is a combination of security governance, processes, policies
and security controls which all work together within a risk management environment. The objective of
an ISMS is to manage risk effectively and to demonstrate that you are doing so.
It is important to know that risk management is not about “fixing an issue” but it is about recognising a
risk and applying sufficient controls to reduce, that is mitigate, a risk to a manageable level. That level is
defined by the risk appetite and sets the level at which a degree of risk is manageable and therefore
acceptable and beyond which further mitigation would not be cost effective.
Figure 10 illustrates the steps to establish and maintain an ISMS according to the 2013 version of
ISO/IEC 27001.


Figure 10 - Information Security Management System
In summary the steps in ISO/IEC 27001 are:

• Define ISMS Scope: The first step is to define and document the ISMS scope and the context within
which it will be established. This will need to take into account a number of factors including the
required boundary of the ISMS, legal and regulatory requirements, interested parties in the ISMS
and any internal and external issues. An ISMS might only cover part of a business or a sub-set of the
IT infrastructure.
• Establish Governance: Governance structures, processes and roles and responsibilities need to be
defined and documented. Linkages to other governance structures and processes should also be
defined. Refer to the previous section and ISO/IEC 27014 on how this should be set up. ISO/IEC
27001 describes this as demonstrating leadership and commitment.
• Establish Security Policy: The governing body establishes an information security policy. This should

include the security objectives of the organisation.
• Risk Context Establish and Risk Assessment: The next step is to establish the risk management
context and then go onto to perform a risk assessment as we described in a previous section. This
should use the processes and principles described in ISO/IEC 27005.
• Risk Treatment: Having established the risks they need to be treated and suitable security controls
implemented to mitigate the identified risks. Those that can’t be mitigated need to be placed on a
risk treatment plan and a process invoked to allow risks to be treated according to severity and level
of risk.
• Statement of Applicability: ISO/IEC 27001 requires a Statement of Applicability (SoA) to be
produced. The SoA contains the necessary controls and justifies their inclusion, whether they are
implemented or not. It should justify why controls are excluded. ISO/IEC 27001 in Annex A contains
the controls most organisations are expected to implement. ISO/IEC 27002 provides a more detailed
explanation of the controls specified in Annex A.
• Operation: ISO/IEC 27001 then goes on to specify the requirement for supporting and operating the
ISMS – in particular as regards its maintenance and continual improvement. Particular emphasis is
made as regards to:
o Suitable training and education.
o Security awareness.
o Documentation control.
o Control of planned changes and reviewing of unintended changes.
o On-going risk assessment at planned intervals or when significant changes are planned.
o Maintenance of a risk treatment plan.
• Monitoring & Improvement: Finally ISO/IEC 27001 requires the organisation to monitor
performance of the ISMS, including potentially performing internal audits. The governing body
should review the ISMS at planned intervals to ensure its continuing suitability, adequacy and
effectiveness. Establishment of an ISMS is not a single one off process. Rather it must be viewed as a
continual improvement process. When a nonconformity occurs the organisation shall take actions
to control and correct it. If necessary they should make changes to the ISMS. All this should be
documented.
The exact steps and terminology for the above you will need to refer to ISO/IEC 27001.
To be effective an ISMS must
• Have the continuous, visible support and commitment of the organisation’s top management.
• Be managed centrally, based on a common strategy and policy across the entire organisation. We
will talk about strategies in section 2.5.8.
• Be an integral part of the overall management of the organisation.
• Have security objectives and activities based on business objectives and requirements.
• Be based on continuous training and awareness of staff.
• Be a never ending process.
It is possible for an organisation to be certified against the ISO/IEC 27001 standard. There are a number
of accredited certification bodies that exist across the world. In some countries, the bodies that verify
conformity of an ISMS are called "certification bodies", while in others they are commonly referred to as
"registration bodies". Certification audits are usually conducted by ISO/IEC 27001 Lead Auditors.
ISO/IEC 27001 certification usually involves a three-stage external audit process.
• Stage 1: is a preliminary, informal review of the ISMS, for example checking the existence and
completeness of key documentation such as the organisation's information security policy,
Statement of Applicability (SoA) and Risk Treatment Plan (RTP). This stage allows the ISO/IEC 27001
Lead Auditor and other team members to become familiar with the ISMS.

• Stage 2: This is a more detailed and formal compliance audit, independently testing the ISMS
against the requirements specified in ISO/IEC 27001 and that the security controls have been
implemented. The auditors will seek evidence to confirm that the management system has been
properly designed and implemented, and is in fact in operation (for example by confirming that
appropriate governance has been established to oversee the ISMS). Passing this stage results in the
ISMS being certified compliant with ISO/IEC 27001.
• Ongoing: This involves follow-up reviews or audits to confirm that the organisation remains in
compliance with the ISO/IEC 27001 standard. Certification maintenance requires periodic re-
assessment audits to confirm that the ISMS continues to operate as specified and intended. These
should happen at least annually.
Some organisations do not want to be certified against ISO/IEC 27001 but still implement an ISMS.
Furthermore many of these use employee auditors to verify their compliance with the standard.
It is also important that an ISMS covers supplier, that is third party, relationships. In particular
coordination and oversight of information security aspects of supplier relationships should be identified
and documented. ISO/IEC 27002 contains a number of security controls and implementation guidance
you should consider. It is important that applicable legislation, regulations, policies and standards are
flowed down to suppliers usually in the form of contractual terms and conditions. Any contract with a
supplier should also enable regular monitoring, reviewing and auditing of the service delivery.

Governance
ISO/IEC 27014 ISO/IEC 27014:2013 Information technology — Security techniques —
Governance of information security. Part of the ISO/IEC 27000 family of
standards
Information Security Management

ISO/IEC 27001 ISO/IEC 27001:2013. Information technology — Security techniques —
Information security management systems —Requirements. Part of the
ISO/IEC 27000 family of standards.
Information security management systems — Code of practice for
information security controls. Part of the ISO/IEC 27000 family of standards.


2.4. Security Architecture and Controls
2.4.1. Type of Controls

Security controls can be of four different types:
• Physical security controls: these are means to control physical access to information. Examples are,
physical access systems, such as guards on doors and gates, physical intrusion detection systems,
alarms, gates and CCTV.
• Procedural security controls: these are policies and procedures put into place to define and guide
staff. For example, procedures might dictate how documents should be classified or hard disk drives
destroyed.
• Personnel security controls: everything needed to ensure that all personnel who have access to
sensitive information have the required authority as well as appropriate clearances. These controls
are used to confirm a person’s background and provide assurance of necessary trustworthiness.
Personnel security controls are primarily concerned with policing the insider threat which can be
reduced by appropriate selection, training and controls, or detected and responded to through
control of behavioural patterns and motivation of individuals.
• Technical security controls (also called logical controls): devices, protocols and other technology-
based measures used to protect the confidentiality, integrity and availability of information.
Examples are: firewalls and antivirus software.
Physical, procedural and personnel security controls are sometimes referred to as administrative
controls.
We will provide more details concerning these controls later on in this section.
Security controls can also can classified based on what they do. The classification scheme we shall use in
this document is as follows:
• Preventive controls.
• Deterrent controls.
• Detective controls.
• Corrective controls.
Preventive controls attempt to prevent security incidents and the associated business impacts before
they occur. Preventive controls try to prevent security violations and also can enforce access control.
Like other controls preventive controls may be physical, procedural or technical. Guards on a door or
requiring users to logon to a system are examples of preventive controls.
Deterrent controls reduce the likelihood of an attack. They are intended to discourage potential
attackers and attempt to discourage someone from taking a specific action. Examples of deterrent
controls include notices of monitoring as well as having a security policy stating consequences for
employees if it is violated.
Detective controls are in place to identify security violations or provide information about violations as
part of an investigation. Detective controls discover attacks and trigger preventive or corrective
controls. Detective controls include protective monitoring, file integrity monitoring, and audit logs.
Corrective controls reduce the impact of a successful attack and hence try to correct the situation after
a security incident has occurred. Upgrading an operating system to the latest version after a successful
attack is an example of a technical corrective control.
Figure 11 shows the relationship between these four classes of security controls and threats and
impacts.


Figure 11 - Types of Security Controls
We will look at different types of physical, procedural and technical controls later on in this section.
However, first we will look at architectural aspects of designing security controls into a system and
organisation.
2.4.2. Security Architecture

Security architecture addresses potential risks involved in a certain scenario or environment and assists
the security architect in specifying when and where to apply security controls. In a security architecture,
the security design principles are defined and the placement of security controls are generally
documented. The security controls serve the purpose of maintaining the system’s security properties
such as confidentiality, integrity and availability. We shall look at some of the key security design
principles later on in this section.
A security architecture comprises a layered view of various elements. The layers used will depend on
the methodology being used. There are two types of architecture that the IISP Skills Framework
references:
• Enterprise Security Architecture (also referred to as Enterprise Information Security Architecture
(EISA).
• Technical Security Architecture.
An Enterprise Security Architecture (ESA) is business driven and describes the relationship between
procedural and technical solutions to support the aims of a business. Hence it covers both policy and
procedural controls as well as the technical controls. An Enterprise Security Architecture must also be
risk driven. It represents a cohesive design that helps the different pieces of a security organisation and
infrastructure work well together.
A technical security architecture focuses just on the technical controls of a system. Therefore, it can be
considered as a subset of an Enterprise Security Architecture. Not all organisations use ESA
methodologies.
An example of the layers in an ESA is provided in Figure 12. This example is from SABSA.

Figure 12 - SABSA Layers
The SABSA model is layered, with the top layer, Contextual Security Architecture, being the business
requirements definition stage. At each lower layer a new level of abstraction and detail is developed,
going through the definition of the conceptual security architecture, logical services architecture,
physical security architecture and finally at the lowest layer, the selection of technologies and products
specified in the component security architecture.
Another ESA of note is The Open Group Architecture Framework (TOGAF). This is actually a framework
for enterprise architecture that provides an approach for designing, planning, implementing, and
governing. What The Open Group did, as of version 9.1, is define how security fitted into the TOGAF
methodology. As with SABSA it is business and risk driven.
Both SABSA and TOGAF are very prescriptive, however, with the benefit of usually providing repeatable
designs.
Note that a Technical Security Architecture will typically include three sub-architectures, namely:
• Infrastructure security architecture.
• Network security architecture.
• Application security architecture.
2.4.3. Design Patterns

A design pattern is the re-usable form of a solution to a design problem. The term design pattern was
originally used by building architects, who abstracted common design patterns in architecture and
formalised a way of describing the patterns in a pattern language. This approach was then adopted by
the IT community. Initially it was applied to programming but then has spread out to be used in a
number of different areas.


A design pattern describes a generic solution to a design problem, something that is required time and
time again. There are a number of different types of design pattern that are used by architects,
including the following:
• Design.
• Programming.
• Process.
• Architectural.
The type of design patterns we are concerned within this section are architectural design patterns of a
security nature. Neither SABSA nor TOGAF address the architectural design patterns problem. The Open
Group has published a book called Open Enterprise Security Architecture (O-ESA). O-ESA introduces the
notion of design patterns with the explanation of a number of conceptual and logical security
architectures for particular areas of an IT system. It also describes a number of security services.
Of note is also the Open Secure Architecture organisation (OSA). OSA is a not for profit organisation.
Although not very active they have published a number of design patterns and their web site is well
worth a visit.
2.4.4. Security Design Principles

To improve software development processes and the resultant applications a book entitled Building
Secure Software was published in 2002. In it were ten guiding principles described that help software
developers produce more secure software. Whilst these principles are targeted at writing software
many of them can be applied at the architectural level including for infrastructure, network and
application architectures. In addition some of the principles also pertain to procedural and physical
controls.
In this document we will cover some of the more important ones and a few additional ones we would
like you to be aware of.
Secure the weakest link. Attackers usually target parts of a system that are likely to break. Therefore,
the level of security in a system is determined by its weakest components. In order to improve system
security, weaknesses and vulnerabilities must be identified and strengthened until the risk of security
incidents can be considered acceptable. For example an unpatched operating system; a weak set of
rules implemented in a firewall.
Practice defence in depth. Layering multiple security controls in a system can reduce the chance of a
successful attack. Incorporating layered security controls requires an attacker to circumvent each
control in turn, to gain access to information. The layered controls do not all have to be technical, they
can include procedural and physical controls. For example you would not just rely on a firewall to
protect a web site from external attackers. You would also implement additional controls such as
antivirus software, content inspection and intrusion detection. On a workstation you would implement
endpoint protection.
Fail securely. Security flaws are often inherent to system failures. Unfortunately, failures cannot be
avoided completely in complex systems. Thus, it is even more important to plan failure modes and
assure that a system’s security is not compromised when a failure occurs.
Follow the principle of least privilege. This principle states that every entity in a system should be
granted only the minimum set of permissions or privileges needed to perform its designated tasks.
Some programmers, due to laziness, violate this principle and have their application running with full
system privileges. If the application is then hacked the whole system can then be compromised.


Compartmentalise. The principle of compartmentalisation aims for a similar goal as the principle of
least privilege. It tries to minimise the damage an attacker can cause. It recommends segmenting a
system into several components or networks that can be protected independently. Therefore, a security
breach in one component should not affect other parts of the system.
Another design principle you should take note of is called Segregation of Duties or Separation of
Duties. It is concept of requiring more than one person to complete a task. This design principle is a key
concept of internal controls, particularly in financial and accounting systems. It is also frequently used
when designing an administration model in order to prevent having all powerful system administrators.
The final design principle we would like to mention is the minimisation principle. This principle says do
not execute any software, applications, or services that are not required. Basically do not install any
software you are not using. If this is not possible then just disable it. Adherence to this principle is that it
not only it improves security but usually also improves performance, saves storage space, and is good
system administration practice in general. The primary security benefit is that it reduces the attack
surface of the system. All software has bugs in it. The more lines of code you are executing the more
bugs and vulnerabilities will be present. Note that the primary security benefit is counterbalanced by
increased complexity in implementation adding steps to the build and configuration and tailored design
to specific servers and functionality for example. The overhead of this increased complexity may
outweigh the security benefits in terms of cost and time.
2.4.5. Physical Controls

Many people in the information security field do not think as much about physical security as they
should do.
Physical security controls can be defined as the measures taken to ensure the safety and material
existence of something or someone against theft, espionage, sabotage, or harm. It is the first step in the
layered approach of information security we talked about previously. If it is non-existent or weak then
information security will fail. This could range from intruders gaining access to a data centre or intruder
being able to walk around unchallenged in an office. Physical security is usually the first line of defence
against environmental risks and unpredictable human behaviour.
Even physical security experts do not always have a holistic view of physical security. There are so many
components and variables to understand, people have to specialise in specific fields, such as secure
facility construction, data centre implementation, fire protection, IDS and CCTV implementation and
personnel emergency response. Each has its own focus and skill set, but for an organisation to have a
solid physical security program, all of these areas must be understood and addressed.
Physical controls one may need to consider include:
• Perimeter security including fences, controlled gates and spot or flood lighting.
• Security guards and dogs.
• Security gates/barriers into buildings
• Access cards and ID badges.
• Motion detectors.
• Intruder alarms.
• Fire protection.
• CCTV.
• Lockable doors controlling access to secure rooms.
• Secure disposal of papers, removable media and disk drives.
• Heating, ventilation and air conditioning (HVAC).
• Anti-tamper/handling devices.

2.4.6. Procedural Controls
Procedural security controls cover the rules, regulations and policies that an organisation puts in place
to help mitigate risks. As opposed to other controls, procedural controls rely on users to follow rules or
perform certain steps that are not necessarily enforced by technical or physical means.
Security Operating Procedures (SOPs or SyOPs) are a set of security procedures that are usually used to
implement a particular policy which a user or an administrator must follow.
We will cover policies and procedures in section 2.5.
2.4.7. Personnel Controls

Personnel security controls is a system of policies and procedures which are used to mitigate the risk of
staff and other “insiders” from exploiting their legitimate access to assets for unauthorised purposes.
Typical controls include:
• Pre-employment checks on employees.
• Clearances for staff who require access to sensitive information.
• Security awareness.
• Training for specific roles and functions.
• Implementation of separation of duties to reduce the potential of fraud.
2.4.8. Cloud Computing

Before we look at specific technical controls we need to look at three specific architectural
environments. These environments have their own taxonomy, although many of the security controls
described in this section are relevant to them.
The first environment we will look at is Cloud computing. As stated in NIST SP 800-145:
"Cloud computing is a model for enabling convenient, on-demand network access to a shared
pool of configurable computing resources (e.g., networks, servers, storage, applications, and
services) that can be rapidly provisioned and released with minimal management effort or
service provider interaction.”
A Cloud consumer (often referred to as a Subscriber) is the entity that consumes services provided by a
Cloud Provider. A Subscriber can take many forms, including:
• A user working at a PC.
• A server within the Subscriber’s IT infrastructure – the organisation might have outsourced their
messaging infrastructure to a Cloud Provider.
• A cloud can have a single tenant, known as a Private Cloud, or it can have multiple tenants. If there
are multiple tenants then it is either a Community Cloud or a Public Cloud.
Figure 13 illustrates the relationship between Cloud Subscribers and Cloud Providers.


Figure 13 - Cloud Subscribers and Providers
In the NIST Cloud Computing Reference Architecture (Special Publication 500-292) it defines five actors.
They include the Cloud Consumer and the Cloud Provider together with three others. They are:
• Cloud Broker: A Cloud Broker acts as an intermediary between the consumer of cloud services and
Cloud Providers. It negotiates relationships between Cloud Providers and Cloud Consumers. A Cloud
Consumer may request cloud services from a Cloud Provider directly or via a Cloud Broker. A Cloud
Broker may create a new service by combining multiple services, potentially from different Cloud
Providers, or by enhancing an existing service.
• Cloud Auditor: A Cloud Auditor is a party that can perform an independent examination of cloud
services, information system operations, performance and security of the cloud implementation.
Audits are performed to verify conformance to standards through review of evidence. The audit
may involve interactions with both the Cloud Consumer and the Cloud Provider. For security
auditing, a Cloud Auditor can make an assessment of the security controls in the information system
to determine the extent to which the controls are implemented correctly, operating as intended,
and producing the desired outcome with respect to the security requirements for the system. The
security auditing could also include the verification of the compliance with regulation and security
policy
• Cloud Carrier: A Cloud Carrier acts as an intermediary that provides connectivity and transport of
cloud services between Cloud Consumers and Cloud Providers.
Figure 14 illustrates the interrelationships between the actors defined in the NIST reference
architecture.
Figure 14 - Cloud Actors


Cloud Brokers play an increasingly important role in cloud adoption. The Cloud Access Security Broker
(CASB) is a term defined by the analysts Gartner and is used to refer to a special type of Cloud Broker. A
CASB provides security enforcement between a customer and a Cloud Provider. The term is interpreted
in different ways across the cloud industry although CASB functionality often includes:
• Looking for unusual activity, malware, and Data Loss Protection (DLP) violations. Hence they analyse
traffic patterns to identify compromised accounts and malicious usage.
• Monitor cloud service APIs and assess activities. They can enforce differing levels of data access and
cloud service functionality based on the user’s device, location, and operating system.
• Encrypt structured and unstructured data. They enable encryption of data being uploaded to a
cloud service and decryption of data already in a cloud service.
• Aid investigation of suspicious users and incidents.
Cloud computing services are usually grouped into service models, representing different logical layers
in the service stack. The service models are as follows:
• Software as a Service (SaaS): The provision of software over a network rather than being loaded
directly onto a local computer. In this case, applications are exposed as a service running on a cloud
infrastructure, usually as a web-based application. The consumer of the service does not manage or
control the underlying cloud infrastructure, including network, servers, operating systems, storage
or even individual application capabilities. Examples of SaaS applications include SalesForce CRM,
Google Apps and Microsoft Office 365.
• Platform as a Service (PaaS): The provision of computing platforms that create the environment for
other software to run on, such as, operating systems over a network rather than being loaded
directly onto a local computer. The consumer of the service doesn’t manage or control the
underlying infrastructure, including, network, servers, operating systems or storage, but has control
over the deployed applications and possibly configuration settings for the application-hosting
environment. Examples include Amazon Simple Storage Service (S3), Microsoft’s Azure Storage and
Force.com.
• Infrastructure as a Service (IaaS): The provision of access to a computer infrastructure, for example,
data storage or processing capability, over a network that is used to complement local platform
resources. The consumer using the service does not manage or control the underlying cloud
infrastructure but has control over operating systems, storage and deployed applications; and
possibly, limited control of selected networking components. An example is Amazon’s Elastic
Compute Cloud (EC2).
At the bottom of the stack is the data centre, where the physical hardware resides. As can be seen in
Figure 15, the level of abstraction and level of control changes as you go up or down the stack.


Software as a Service (SaaS)
Level of Abstraction
Level of Control
Platform as a Service (PaaS)
Infrastructure as a Service (IaaS)
Data Centre (Hardware Layer)
Figure 15 – Cloud Service Models and Levels of Control and Abstraction
Obviously Figure 15 is a simplification with Figure 16 showing a more detailed representation. This
figure illustrates the components within each service model and the types of services offered to the
Cloud Consumers.
SaaS
Presentation Presentation
Modality Platform
APIs
Applications
Data Metdata Content

PaaS
Integration & Middleware Integration & Middleware
IaaS
APIs APIs APIs
Core Connectivity & Core Connectivity & Core Connectivity &

Delivery Delivery Delivery
Abstraction Abstraction Abstraction
Hardware Hardware Hardware
Figure 16 – SaaS, PaaS and IaaS Layers
Depending on the service model, and the Cloud Provider, will dictate who is responsible for what part of
the service. This gives rise to an important concept called the shared responsibility model. Typically, a
Cloud Provider vendor will define their shared responsibility model for a given type of service and
service model. Public cloud adoption requires an organisation to evaluate how security operational and
assurance processes are applied and validated when cloud services are being consumed. The shared
responsibility model requires organisations to fully understand “who does what” in relation to security
operations. Often Cloud Providers supply technology but the customer retains operational
responsibility, although this depends on the service model being used. In a shared responsibility model
one needs to consider who is responsible for the following:


• Data protection and classification.
• Encryption of data and transmissions.
• Endpoint protection.
• Identity and access management.
• Application level control.
• Business continuity management, data backup and recovery
• Networking and associated security.
• Host infrastructure.
• Patching.
A number of Cloud Providers have published their shared responsibility model for a given service. Figure
17 shows a simplified version of the shared responsibility model for Amazon Web Services (AWS) for
their IaaS offering.
Customer Data
Customer IAM
Platform & Application Management
Managed by
Operating System, Network & Firewall Configuration AWS Customers
Client-Side Data
Encryption & Data Server-Side Network Traffic
Integrity Encryption Protection
Authentication
AWS IAM
Managed by
Compute Storage Databases Networking Amazon Web
Services
Figure 17 – Shared Responsibility Model for AWS Infrastructure Services
The Cloud Security Alliance (CSA) is a not-for-profit organisation with a mission to “promote the use of
best practices for providing security assurance within Cloud Computing, and to provide education on
the uses of Cloud Computing to help secure all other forms of computing”. Whilst it was established in
the US it has a number of chapters around the world, including the UK. Their seminal work is the
“Security Guidance for Critical Areas of Focus in Cloud Computing - Foundational best practices for
securing cloud computing”. The document’s intent is to establish a stable, secure baseline for cloud
operations. It describes a set of practices the CSA has put together in 14 domains involved in governing
or operating the cloud, namely:
• Cloud Computing Architectural Framework.
• Governance and Enterprise Risk Management.
• Contracts and Electronic Discovery.
• Compliance and Audit Management.
• Information Management and Data Security.
• Interoperability and Portability.
• Traditional Security, Business Continuity, and Disaster Recovery.

• Data Centre Operations.
• Incident Response.
• Application Security.
• Encryption and Key Management.
• Identity, Entitlement, and Access Management.
• Virtualisation.
• Security as a Service.
As you can see we have covered, or will cover, many of these topics in respect of traditional IT
environments.
The CSA have also published the document “The Treacherous 12 Cloud Computing Top Threats in 2016”.
In this report, CSA experts identified the following 12 critical issues to cloud security (ranked in order of
severity):
• Data Breaches. Incidents in which sensitive, protected or confidential information is released,
viewed, stolen or used by an individual who is not authorised to do so.
• Weak Identity, Credential and Access Management. Lack of scalable identity access management
systems, failure to use multifactor authentication, weak password use, and a lack of ongoing
automated rotation of cryptographic keys, passwords and certificates.
• Insecure Interfaces and APIs. The security and availability of general cloud services is dependent on
the security of a number of basic APIs. Provisioning, management, orchestration and monitoring of
cloud services are all performed with these interfaces. Any vulnerabilities in these APIs would be
quickly exposed.
• System Vulnerabilities. Vulnerabilities within the components of the operating system, system
libraries and application tools put the security of all services offered by a Cloud Provider and
Subscriber’s data at risk.
• Account Hijacking. Attack methods such as phishing, fraud and exploitation of software
vulnerabilities can have a major impact on cloud services.
• Malicious Insiders. A malicious insider, such as a system administrator, can access potentially
sensitive information. From IaaS to PaaS and SaaS, a malicious insider can have increasing levels of
access to more critical systems and eventually to data. Systems that depend solely on the Cloud
Provider security are at greater risk.
• Advanced Persistent Threats. Once in place, APTs can move laterally through data centre networks
and potentially impact multiple tenants.
• Data Loss. Data stored in the cloud can be lost for reasons other than malicious attacks. An
accidental deletion by the Cloud Provider, or worse, a physical catastrophe such as a fire or
earthquake, can lead to the permanent loss of customer data unless the Cloud Provider or Cloud
Consumer takes adequate measures to back up data. The burden of avoiding data loss does not fall
solely on the Cloud Provider’s shoulders. If a Cloud Consumer encrypts their data before uploading
it to the cloud but loses the encryption key, the data will be lost as well.
• Insufficient Due Diligence. Developing a roadmap and checklist for due diligence when evaluating
technologies and Cloud Providers is essential for a successful implementation and operation. An
organisation that rushes to adopt cloud technologies and choose Cloud Providers without
performing due diligence exposes itself to a myriad of commercial, financial, technical, legal and
compliance risks that jeopardise its success.
• Abuse and Nefarious Use of Cloud Services. Poorly secured cloud service deployments, free cloud
service trials and fraudulent account sign-ups via payment instrument fraud expose cloud
computing models such as IaaS, PaaS and SaaS to malicious attacks.
• Denial of Service. Cloud Providers are not immune from DoS or DDoS attacks. By forcing the
targeted cloud service to consume inordinate amounts of finite system resources such as processor

power, memory, disk space or network bandwidth, the attacker(s) causes an intolerable system
slowdown.
• Shared Technology Issues. Cloud Providers deliver their services scalably by sharing infrastructure,
platforms or applications. Cloud technology divides the “as a Service” offering without substantially
changing the off the-shelf hardware/software, sometimes at the expense of security. This can lead
to shared technology vulnerabilities that can potentially be exploited in all delivery models.
As explained above when selecting a Cloud Provider performing appropriate due diligence is extremely
important. The CSA guidance describes above provides a lot of important information in this area. Some
of the more significant factors you should take into account are:
• Accreditation: Does the Cloud Provider have any form of security certification or accreditation for
its services? For example, whether they are a member of the CSA, if so, are involved in the CSA
Security, Trust & Assurance Registry (STAR) scheme?
• Tenant Separation: Remember that an organisation’s information is its most important asset, so
you need to ensure that an organisation’s data is not inadvertently shared with any other tenant.
You need to determine the Cloud Provider’s data separation procedures and techniques and decide
if you consider them strong enough. If the data is highly sensitive and separation is vital, especially
in a multi-tenanted cloud, then potentially consider encryption both on the network and on data
residing on virtual disks.
• Location of Data Centers: From a data protection perspective, you need to know where information
is stored in the cloud. One of the ways that Cloud Providers keep their costs down is by locating
their datacentres in countries where labour, electricity and other overheads are low. Hence, a Cloud
Provider could be storing information anywhere in the world.
• Supply Chain: You need to establish whether a Cloud Provider has a layered supply chain. Perhaps
an organisation proposes to contract with a SaaS Cloud Provider, however, in turn they use an IaaS
provider for their infrastructure. You need to establish all the locations of all the equipment, right
down to the physical assets.
• Audit: Do you have the right to audit their operations?
• Exit Strategy: Should you wish to leave a Cloud Provider will they be able to support your exit
strategy. If you do leave their service, determine what assurance measures exist to ensure all your
data has been securely deleted.
Whilst we have talked about SaaS, IaaS and PaaS as the service models of note – there is also the
emergence of the concept of XaaS. XaaS is a collective term used to refer to as "anything as a service" or
"everything as a service." Examples of XaaS services include:
• Ransomware as a Service (RaaS).
• Storage as a Service (SaaS).
• Network as a Service (NaaS).
• Monitoring as a Service (MaaS).
2.4.9. Internet of Things

The Internet of Things (IoT) is a system of interrelated computing devices, physical devices, vehicles,
buildings, sensors and actuators that are networked together – and are internet reachable.
The growth of network-connected devices and systems mean that the Internet of Things creates
immense opportunities and benefits to society. However, it does create substantial risks. Many
manufacturers of IoT devices have a poor understanding of cyber security. IoT devices are frequently
sold and installed with a considerable number of vulnerabilities.


Recognising these problems the IoT Security Foundation (IoTSF) has been created. Its mission statement
is:
Our mission is to help secure the Internet of Things, in order to aid its adoption and maximise its
benefits. To do this we will promote knowledge and clear best practice in appropriate security to
those who specify, make and use IoT products and systems.
So far the IoTSF have produced two documents of importance:
• IoT Security Compliance Framework.
• Establishing Principles for Internet of Things Security.
The compliance framework is a comprehensive checklist to guide an organisation through the IoT
security assurance process. The principles document contains a number of principles to follow when
designing, building or operating IoT devices. Many of these principles, and associated security controls,
are also relevant to traditional IT systems and indeed are described in this document. Below are a
selection of the
• Be designed with security, appropriate to the threat and device capability, in mind from the
outset. Hence security should not be retrofitted at a later date.
• Offer appropriate protection for all potential attack surfaces (e.g. device, network, server,
cloud etc.). As well as the device itself, sensitive data may be exposed in other connected
systems. Consider how the security of the data will be maintained throughout the whole
network, include transmission.
• Ensure identifiers are removed or anonymised where necessary. Exposure of sensitive personal
identifiers may allow collection analysis of private data by unauthorised devices.
• Manage encryption keys securely. Consider the lifecycle of encryption keys, from provisioning
through to decommissioning and/or revocation of the device.
• Defences against hacking are designed in from the outset. Considering potential attacks during
the design stage will ensure the device’s security functionality is built on solid foundations and
reduces the risk of serious security architecture issues emerging later in development.
• Development processes incorporate secure coding standards, penetration testing etc.
Practices such as these reduce the risks of unintentional vulnerabilities occurring in the product
and help to identify and fix potential issues.
• The vendor update and management process follows best security practice. Security
patches/updates should be applied in a timely fashion without impacting the functionality of
the device. Only authenticated sources are able to provide security updates or patches.
• Provide a secure method to transfer ownership of the device to another user. This will allow
both the old and new users to verify that the transfer of ownership has succeeded and that any
sensitive data will be handled appropriately after handover
OWASP have also published a Top 10 for IoT devices. This is a list of what OWASP consider to be the top
10 threats to IoT. They make the point that it is just not about the device, application or network. There
are many attacks surfaces involved. In summary the OWASP Top 10 for IoT are:
• Insecure Web Interface: External or internal attacker obtains credentials to gain access to the web
interface.
• Insufficient Authentication/Authorization: Attacker uses weak passwords, insecure password reset
or poorly protected credentials to gain access to the device.
• Insecure Network Services: Device is liable to buffer overflow attacks; uses insecure network

services or exposes unnecessary communication ports.
• Lack of Transport Encryption: The device does not protect communication with other devices or
servers, whether this is a local network (e.g. over Wi-Fi) or to servers over the internet.
• Privacy Concerns: The device collects personal or sensitive data and this is not properly protected.
• Insecure Cloud Interface: Insufficient authentication or transport encryption when using cloud
services.
• Insecure Mobile Interface: Insufficient authentication or transport encryption when using the
mobile interface.
• Insufficient Security Configurability: The user of a device has limited or no ability to change the
security configuration – for example to introduce stronger controls.
• Insecure Software/Firmware: Device cannot update its software or firmware. Device contains
hardcoded sensitive data, such as credentials.
• Poor Physical Security: Attackers use vectors such as USB ports to gain access to the device.
2.4.10. Industrial Control Systems

With the successful 2010 STUXNET attack against Iran’s nuclear enrichment facilities, the industrial
control community has woken up to the realisation that targeted attacks against industrial control
systems (ICS) are no longer a theoretical risk. A number of organisations have been talking about ICS
security a lot longer than this, some being prompted into action because of the 9/11 attacks. Given that
national infrastructure (such as power, water and energy) depend on industrial control systems for their
safe and reliable operation, this has prompted a significant effort in quantifying and managing the
potential risk to these industrial processes from cyber-attacks.
ICS is a generic term and is used to refer to real-time industrial process control systems used to centrally
monitor and control remote or local industrial equipment such as motors, valves, pumps and relays,
robotics, etc. ICS systems can be used to control and monitor a very wide range of applications such as
chemical plant processes, oil and gas pipelines, electrical generation and transmission equipment,
manufacturing facilities, water purification and distribution, etc. ICS also includes building management
systems (BMS), which control and monitor a building’s mechanical and electrical equipment such as
ventilation, lighting, power systems, fire and smoke monitoring and security systems.
SCADA (supervisory control and data acquisition) systems typically refer to ICS systems that control
processes distributed over large distances, such as those controlling pipelines and power transmission;
for many purposes the terms ICS and SCADA are used interchangeably.
Initially, ICS had little resemblance to traditional IT systems because they were isolated systems running
proprietary control protocols using specialised hardware and software. Widely available, low-cost
Internet Protocol (IP) devices are now replacing or being added to existing proprietary network
solutions, and control room graphical display systems now typically run on Windows; both factors
increase the possibility of ICS being susceptible to traditional cyber security vulnerabilities and incidents.
Improving the security of ICS system is constrained by a number of other factors such as:
• Logistics of updating antivirus software and patching operating systems.
• The undesirable impacts of installing un-tested patches and updates on the operation of industrial
control systems.
• The shortage of ICS engineers capable of understanding security issues.
• The shortage of security experts who understand control and process plan.
• The variety of proprietary control system platforms and communications protocols.
• The expected operational lifetime of ICS can be well over 20 years while Windows-based IT systems
have a much shorter lifetime, more like 5 years. Consequently some ICS systems may run on

operating systems or hardware which are at or beyond their formal end of serviceable life.
The IEC 62443 series of standards has been jointly developed by the IEC and the International Society of
Automation committee number 99 (ISA99). The aim of the standards is to “address the need to design
cybersecurity robustness and resilience” in ICS systems. The IEC 62443 series build upon established
standards for general purpose information system, for example the ISO/IEC 27000 family. The IEC 62443
series is still being developed although some parts have been published.
The US Department of Energy has published a 21-step guide to improving SCADA security. A summary of
some of the key points are as follows:
• Segmentation: Establish a network protection strategy based on the principle of segmentation and
defence-in-depth. Don’t use “flat network” where all ICS components can communicate with each
other without control. Identify systems that serve critical functions, or contain sensitive
information, and implement additional levels of protection where necessary.
• Disconnect Unnecessary Connections: Identify all connections to ICS systems and disconnect any
unnecessary connections to the ICS network.
• Harden ICS servers: Harden servers by removing or disabling unnecessary services and only permit
known services, or applications, into and out of the ICS system. Evaluate and strengthen the security
of any remaining connections in and out of the ICS network.
• Establish a Perimeter: Establish strong controls over any data coming into the system either over a
communications channel or on media, such as a USB memory stick.
• Malware Protection: Consider AV scanning and content controls.
• Maintenance Program: Design the system so that components can be taken offline for
maintenance, including patching. Establish effective configuration management processes.
• Intrusion Detection Systems: Implement internal and external intrusion detection systems and
establish 24x7 protective monitoring, especially focusing on communication between components
that normally don’t talk to each other. Implement file integrity monitoring to monitor the integrity
of operating system configuration files and applications.
Some other security controls that must be considered for ICS include:
• Staff training and awareness in security for operators control engineers, process control
superintendents and plant managers.
• Firewall management.
• Controls on file transfer, not only via firewalls rules but should include file transfers using USB sticks.
• Strongly-authenticated remote access, especially for management functions.
• Backup and recovery tests.
• A practised incident response plan.
Many of the above controls we will discuss in the following sections and indeed are just as relevant to
traditional IT system as to ICS systems.
2.4.11. Cryptography
Before we look at the technical controls we would like to introduce you to cryptography. As many
technical controls are based on cryptography it is important you have some understanding of this
subject.
Cryptography is the science of applying a complex mathematical operation to some data, whether it is a
message or data being transmitted or residing on a disk. Cryptography means literally hidden or secret
writing. It involves changing normal information into another form that hides it and makes it secret.
Cryptanalysis means literally untying something hidden. It involves recovering information that has been
hidden by someone else using cryptography.

Cryptography has its own terminology and language, which we will introduce you to. Ciphers are
cryptographic algorithms that takes plaintext and converts it to unintelligible ciphertext. Although the
term plaintext is used in cryptography this does not mean it refers to just plain text. It refers to any data
or information whether it is plain text, documents, drawings, web pages, image files – in fact any type of
content.
The process of converting plaintext to ciphertext is called encryption. The reverse process of converting
ciphertext back to plaintext is referred to as decryption.
Figure 18 shows these two operations in diagrammatic form.
Figure 18 – Encryption and Decryption
As we go on and explain different forms of cryptography it is useful to define two standard actors used
in describing cryptographic mechanisms. If you ever talk about cryptographic mechanisms it is usual to
refer to the processes using the following actors:
• Alice: she is an end user or computer without malicious intentions. She is one of the main users of
the cryptographic services being explained.
• Bob: he is Alice’s friend and also a main user of the cryptographic services. Like Alice, Bob does not
have any malicious intentions.
There are two forms of encryption and decryption you should be aware of. They are called symmetric
and asymmetric cryptography and use two different types of algorithms. Both these types of algorithms
use cryptographic keys.
In symmetric cryptography cryptographic keys are just very large randomly generated numbers. These
are called symmetric keys. The size of the key is specified in bits. The key space defines all possible
values used to construct a cryptographic key. The larger the key space the better. In the case of a 64-bit
key, the key space is 2 to the power of 64 (264). In other words, the number of possible values of the
key, i.e. the key space, is 18,446,744,073,709,600,000. Different symmetric algorithms support different
key sizes. In most environments it is recommended that you use keys with a minimum size of 128 bits
(i.e. a key space of 2128).
With this system, the symmetric algorithm transforms the plaintext message into ciphertext. This
transformation involves the symmetric key, being available only to legitimate senders and receivers of
the message. To reverse the process the ciphertext is fed into the symmetric algorithm together with
the symmetric key to recover the plaintext. This process is shown in Figure 19.


Figure 19 - Symmetric Cryptography
The strength of the protection in symmetric cryptography lies in the secrecy of the keys and NOT in the
algorithm. This is because most modern commonly used algorithms are in the public domain and freely
available to implement. It is therefore assumed that attackers have knowledge of the algorithm. The
most widely used symmetric algorithms are:
• Advanced Encryption Standard (AES). AES was originally adopted by the U.S. government and is
now used worldwide. AES supports three different key sizes: 128, 192 and 256 bits.
• Data Encryption Standard (DES). A cipher defined and endorsed by the U.S. government in 1977 as
an official standard. The key size of DES is 56 bits in length. Because of the small size of the key, this
algorithm is now considered insecure for many applications and should not be used.
• Triple DES (3DES). A technique for improving the security of DES is triple encryption, that is,
encrypting each message using three different DES keys. In general, Triple-DES, (with three
independent keys), has a key size of 168 bits (three 56-bit DES keys), but due to a cryptographic
weakness in this approach, the effective security it provides is only 112 bits.
Asymmetric cryptography requires the user to be provided with two keys, namely a public key and a
private key. As the public name implies, this is the key that is provided to the world, whilst the private
key is kept by the owner in a safe location. Figure 20 shows the processing of asymmetric cryptography.
In this type of cryptography one of the keys is used, via the asymmetric algorithm, to create the
ciphertext. To recover the original plaintext from the ciphertext then the other key is used. Asymmetric
cryptography is often referred to as Public Key Cryptography.
Figure 20 - Asymmetric Cryptography
The private key and public key have a mathematical relationship with each other and are generated at
the same time. They are generated using a trapdoor one-way function. This means it is easy to compute

yet hard to reverse. Hence possessing one of the keys will not allow another party to generate the other
key.
Asymmetric algorithms have some very useful properties, the fact that the keys are always in pairs, one
is kept very secret whilst the other is made available to the world. This means they can be used for
different purposes. The first use case is shown below in Figure 21. In this case the Alice obtains Bob’s
public key. She then uses this to encrypt some data before sending onto Bob. Once Bob receives the
ciphertext he then decrypts it using his private key. As Bob is the only one in possession of the private
key he is the only one that can decrypt the ciphertext. This is an example of asymmetric cryptography
being used for encryption. This technique is also used widely for key distribution. We will talk more
about this shortly.
Figure 21 - Asymmetric Cryptography used for Encryption
The second use case is shown in Figure 22. In this case Alice uses her private key to encrypt some data
and then send the ciphertext to Bob. Bob obtains Alice’s public key and uses this to decrypt the received
ciphertext from Alice. The two key points about this are:
• Anyone provided with Alice’s public key can decrypt the data.
• Anyone that successfully decrypted the message from Alice can be sure it came from her – as she
was the only entity processing her private key.
Figure 22 - Asymmetric Cryptography used for Key Distribution
This property of asymmetric algorithms is not actually used for encrypting data but usually used for
creating and verifying digital signatures as well as distributing symmetric keys. We will talk more about
digital signatures shortly.
The most widely used asymmetric algorithms are:

• Rivest, Shamir, Adleman (RSA). RSA is a public key cryptography algorithm used for both encryption
and digital signatures. It is the most widely used asymmetric algorithm. RSA keys are typically 1024
to 2048 bits in length, although some implementations use 4096-bit keys.
• Diffie-Hellman (DH). DH is used primarily for key distribution and key management, in particular for
TLS.
• Elliptical curve cryptography (ECC). ECC is a public key encryption technique based on elliptic curve
theory that can be used to create faster, smaller, and more efficient cryptographic keys.
Symmetric algorithms are considerably faster than asymmetric algorithms. The speed difference is such
that asymmetric algorithms are never used for bulk encryption. Symmetric algorithms are used for data
encryption whilst asymmetric algorithms are used to support key distribution and digital signatures.
One of the challenges of symmetric cryptography is how keys are distributed to all the end points. If you
only have Alice and Bob communicating then that is easy. All Alice needs to do is to provide Bob with
her symmetric key – perhaps using a memory stick. (Remember that symmetric keys need to be kept
secret – so a simple email of the symmetric key is not really feasible). Unfortunately if there are many
parties that need to communicate with each other then this does not scale. Hence there is a key
distribution problem. This is where asymmetric algorithms are used. They are the basis of how a Public
Key Infrastructure (PKI) is built. A PKI is used to distribute public keys in the form of public key certificate
(and just usually referred to as a certificate or as a X.509 certificate). Certificates are just basically
digitally signed public keys. Certificates are intended to be made public and shared.
The full lifecycle management of cryptographic keys is known as key management. This includes:
• Key generation.
• Key distribution and exchange.
• Key storage.
• Key destruction and replacement.
It is a key element of any cryptographic system and often difficult to achieve securely.
Before we get onto the final subject of digital signatures in this section we need to introduce another
type of algorithm called a cryptographic hash function – usually just referred to as a hash function. Hash
functions produce hash values. A hash value is a numeric value of a fixed length that uniquely identifies
data. A hash function is a mathematical function, which works in one direction, for converting messages
or data of varying length into a fixed numerical output value. For example, if you had a dozen Microsoft
Word documents, each of varying length, then running the hash function against them would produce a
unique hash value for each one. Hashes are also used to obscure data such as passwords. We cover this
more in section 0.
The length of the resulting hash value depends on the cryptographic algorithm used. In modern
cryptographic systems, you will also see hashes referred to as digests or message digests.
The following figure shows the purpose of a hash function.
Figure 23 - Hash Function


The basic properties of a cryptographic hash function are as follows:
• Hash functions are one-way functions that do not use keys.
• The input can be of any length, the output has a fixed length.
• Hash functions are used to build other cryptographic primitives, such as digital signatures.
• A collision-free hash function is one for which it is computationally infeasible to find any two
messages such that their hash values are the same.
The most widely used cryptographic hash functions are:
• MD5 (Message Digest 5): It produces a 128-bit hash value and is widely used. However, it has
recently been shown that MD5 is not collision resistant, therefore, it is not recommended for use in
applications like TLS or digital signatures.
• SHA (Secure Hash Algorithm): SHA-1 is a 160-bit cryptographic hash function and is widely used and
supported. In 2005 it was found that attacks on SHA-1 were possible, which suggested that SHA-1
might not be secure enough for certain applications, in particular digital signatures. To address this
problem, NIST specified SHA-2. SHA-2 defines four hash functions namely: SHA-224, SHA-256, SHA-
384 and SHA-512, with the number indicating the size of the hash value (in bits).
Finally in this section of cryptography let us look at digital signatures. A digital signature is where a
signer, Alice, digitally signs a message or some data in such a way that another party can verify that the
message was signed by Alice, and only Alice. Digital signatures use public key cryptography to provide
this capability. Figure 24 illustrates the production of a digital signature. The process involves taking the
input message and running it through a cryptographic hash function to produce a hash value. The hash
value is then encrypted using the signer’s private key and a suitable asymmetric algorithm. Therefore, in
effect, a digital signature is just an encrypted hash value.
Figure 24 - Digital Signature
To verify the digital signature the recipient decrypts the digital signature with the sender’ public key
(e.g. Alice) and verifies that the hash value received matches what they expected. This is achieved by
independently calculating the hash over the received data and comparing that with the value of the
hash just received.


2.4.12. Technical Controls
We will now go through some of the more important technical controls you should be aware of. To aid
this we have grouped the controls into a number of categories. They are
• Access Control.
• Auditing and Alerting.
• Content Control.
• Cryptographic Services.
• Detection.
• Identification and Authentication.
• Security Management.
• Trusted Communications.
We will now go through of these categories and technical controls and describe some of the key ones
you should have some level of understanding about.
Access Control
There are a number of different types of access control. Broadly access control concerns controlling
access to data or applications so that only authorised entities have access. Hence, the access is based on
business and security requirements. Authorisation policies define what an individual identity or group
may access, access controls are the methods used to enforce such policies. Identities are established
during Identification and Authentication.
Discretionary Access Control (DAC) is restricting access to objects based on the identity of subjects
and/or groups of subjects to which they belong. The controls are discretionary in the sense that a
subject with a certain access permission is capable of passing that permission on to any other subject.
DAC is commonly implemented in operating systems.
Access Control Lists are a form of DAC where a list of permissions is attached to an object. It specifies
which users or system processes (i.e. subjects) are granted access to objects, as well as what operations
are allowed on given objects.
Role Based Access Control (RBAC) is a method of controlling access to data or applications based on the
roles of individual users. A role is essentially a collection of permissions, and all users receive
permissions only through the roles to which they are assigned, or through roles they inherit through a
hierarchy of roles. RBAC can be used to enforce the Separation of Duties principle.
Attribute-Based Access Control (ABAC) in a system whereby access rights are granted to users through
the use of policies which combine attributes together. The access right can be based on many different
type of attributes including:
• User: e.g. name, organisation, role, nationality.
• Object: e.g. name, file type, author, date of creation.
• Environment: e.g. time of day, IP address of request.
Sometimes ABAC is referred to as Policy Based Access Control (PBAC).
Application Control is used to block or restrict unauthorised applications from executing on an endpoint.
The Application Control service maintains a list of authorised applications that the user is permitted to
execute. If the user attempts to download an unauthorised application they will not be able to execute
it. This facility is also known as application whitelisting.
Device Control protects against data loss by monitoring and controlling data transfers from PCs to
removable storage devices such as USB drives. It allows administrators to define the specific types of


devices that certain users or groups of users can use, potentially specifying the actual specified time
periods they can access the device. Device Control also allows you to set restriction rules on reading and
writing to devices.
A similar facility to Device Control is Port Control This protects against data loss by monitoring and
controlling access to device ports on a user workstation.
Auditing and Alerting

Auditing and alerting involve:
• The collection of audit information.
• The analysis of audit information.
• Alerting when defined events occur.
Audit information needs to be collected from all components of a system, including operating systems,
workstations, servers, mobile devices, network components and applications. Most applications also
generate accounting information and it’s important this is collected.
This process is called audit logging and the audit information is stored in one or more audit logs.
For most components you can configure exactly what is collected and this should be based on the
auditing policy of the organisation. The policy should cover what information should be collected for
each type of event. For instance, if you want to collect logon events, you probably want to record the
time of the logon and the workstation where it was generated.
A typical information system will have many different types of logs, including:
• Operating systems logs.
• Security logs.
• Networking logs.
• Application logs.
In a large IT infrastructure managing multiple audit logs can be very difficult. This is why many
organisations often implement a centralised audit collection service. Audit collection products are
known as Security Information and Event Management (SIEM) systems. SIEM is an approach to security
management that seeks to provide a holistic view of an organisation’s information security and is
primarily used for incident detection and analysis.
SIEM systems can be used centralise the storage and interpretation of audit logs and allows near real-
time analysis which enables security personnel to take defensive actions more quickly. It collects data
into a central repository for trend analysis and provides automated reporting for compliance and
centralised reporting. SIEM systems provide quicker identification, analysis and recovery of security
incidents. You can configure a SIEM to trigger alerts given defined security events or group of security
events. We cover SIEM systems in more detail in the protective monitoring section.
It is vital to have a system wide accurate time source across the infrastructure, as this will allow
correlation of security events between different systems.
Content Control
The purpose of content control is to block content entering or leaving an organisation where that
content does not conform to the corporate policy. This is sometimes referred to as content inspection.
The policy could be in place for many reasons, some of which might include:


• Preventing malware entering into an organisation or user’s system.
• Detecting spam and phishing attacks and blocking them.
• Preventing sensitive information leaving an organisation.
The last point is commonly referred to as Data Loss Prevention (DLP).
Antivirus software is used detect and remove computer viruses and other types of malware. The most
common technique that antivirus software uses to detect malware is using virus signatures. A virus
signature is a unique fingerprint that a virus has. However, this method is not foolproof and it is possible
to create virus payloads that bypass detection. It is also possible that false positive alerts are raised
when antivirus software reports it has found malware in software that is actually safe to import or
execute.
Polymorphic malware is difficult to detect using traditional signature based anti-virus software.
On workstations antivirus software usually detects malware on an attempt to execute software.
However, some products can be configured also to detect malware on copying software from
removable media onto a hard disk drive.
In most organisations antivirus software is placed at the boundaries of an organisation, such as on mail
servers, as well as on internal servers and workstations.
Boundaries devices, such as firewalls, can support both include web filtering and mail filtering in order
to control both incoming and outgoing content and web requests.
Web filtering can be configured to block pages that include copyright infringement material,
pornographic content, social networks and web email. Downloads of executable programs can be
prevented. It can also be used to block specific web sites based on a blacklist basis or permit only
specific web sites based on a whitelist.
Mail filtering includes the ability to launch one of more antivirus software programs to scan incoming
email and its attachments. Analysis of the contents of an email, and the subject line, allows detection,
alerting and rejection of spam.
Deep Content Inspection is an advanced form of mail filtering and web filtering. It examines the
contents of information to verify it is actually what it says it is. For instance is the attachment really a
MS Word document.
Cryptographic Services
There is a large number of security controls based on cryptography. Many of these are of a comms
nature and we will cover them in the Trusted Communications section. In this section we will look at a
few other security controls based on cryptography.
The first one we will look at is the Public Key Infrastructure, which we covered in the cryptography
section. In its purest sense a PKI is used to securely generate and distribute public keys in the form of
public key certificates. The public keys in the certificates can then be used by applications or services to
support cryptographic based controls – such as Virtual Private Networks or secure email. Organisations
can build their own PKIs and there are also a number of public PKIs – many of which are used to secure
public web sites with TLS. We will cover TLS in the Trusted Communications section.
Digital signature services are used to digitally sign a message, document or other information object.
The service is also then used to verify the digital signature. Signature services are typically used in
conjunction with a PKI. You will very rarely find digital signature services by themselves, rather they are
components of a larger offering, such as a service offering digitally signed contracts or other legal

documents and secure email. Secure email usually supports both encryption of the messages as well as
digital signatures supporting authentication and non-repudiation.
The final cryptographic services we’ll look at are disk and file encryption. This protection provides
encryption of data at rest. Full disk encryption (FDE) secures all data stored on hard disks automatically
and transparently, including swap files and hidden files that may contain confidential data, without any
user intervention. File level encryption protects only specific files that are manually encrypted and
generally depends on the user to perform some action to ensure that files are encrypted before storage.
Full disk encryption is usually considered to be more secure than File level encryption. Some products
also support encryption at the field level.
Encryption can also be useful in protecting data on disks or tapes held in off-site locations. We will cover
encryption when used in cloud services later in this section.
Detection
Detection security controls are designed to detect and possibly block or prevent abnormal behaviour.
Intrusion detection systems are designed to identify that an intrusion has been attempted, is occurring,
or has occurred and possibly respond. However, Intrusion prevention system are designed to identify
and then actually block the attack. There are four variants of these systems:
• Network Intrusion Detection System (NIDS). These products attempt to identify unauthorised, illicit,
and anomalous behaviour based solely on network traffic as the traffic traverses a NIDS sensor. A
NIDS, using either a network tap, span port, or hub collects IP packets that traverse a given network.
Using the captured data, the NIDS system processes and flags, and optionally reports or alerts, any
suspicious traffic. The role of a NIDS is passive, only gathering, identifying, logging and alerting.
• Network Intrusion Prevention System (NIPS). Very similar to a NIDS except this device actually
blocks any traffic it believes to be suspicious. Most network products of this type can be configured
to operate in either NIDS or NIPS mode.
• Host Intrusion Detection System (HIDS). These products attempts to identify unauthorised, illicit,
and anomalous behaviour on a specific device, whether it is a server or workstation. HIDS generally
involves an agent installed on each system, monitoring and alerting on local OS and application
activity. The installed agent uses a combination of signatures, rules, and heuristics to identify
unauthorised activity. Like a NIDS, the role of a HIDS is passive, only gathering, identifying, logging,
and alerting.
• Host Intrusion Prevention System (HIPS). Similar to a HIDS except they can be configured to block
activity. Most products in this space can operate in either HIDS or HIPS mode, and usually on a rule
by rule basis.
Placement of sensors is important in enterprise architectures. NIDS/NIPS products are not able to
properly inspect traffic if it is encrypted. For instance don’t place a sensor between web clients and SSL
accelerators; instead place the sensor after the accelerators where the traffic is decrypted.
NIDS/NIPS can also be placed in networks in two different types of location. The first type of location is
by attaching the sensor to a spanning port of a network switch. All traffic coming in and out of the
network switch is copied over to the span port. Hence the sensor can view all traffic on the network
switch. When operating like this the device can only operate in NIDS mode. It is unable to block traffic.
The other location is when it is placed in-line. This means that all network traffic must go through the
device. Hence the devices can operate in NIPS mode (and NIDS if configured to do so) as it is now able
to block traffic if it so wishes. Figure 25 illustrates this point.


Internet
Span Port
NIDS Sensor
Firewall
Server Server
Firewall
In-line NIDS/NIPS
Sensor
Workstation Workstation Workstation
Figure 25 - Intrusion Prevention System
Implementation of an IDS/IPS is not without its problems and requires a highly skilled and trained team
to manage it effectively. Initially, when first installed, you will see many false positives and false
negatives, both of which require skilled tuning. Hence you could see normal behaviour falsely triggering
an alert (false positives) or situations when alerts should have been raised but were not detected (false
negatives). It will take some time to bed down an IPS until it is effective.
File integrity monitoring is a security control that that validates the integrity of operating system and
application software files. It does this by comparing the current file state and a known, good baseline.
Should a file change due to virus activity or corruption, the file will no longer match the recorded
integrity information of the original file. Hence it alerts you, and/or an administrator, to changes in
critical system files, application programs, configuration files, and content files.
Identification and Authentication

In this section on identification and authentication we are covering user authentication. Network
authentication is covered in the trusted communication section.
The most common form of user authentication is where you identify yourself with a username (also
sometimes called user-ID) and also provide a password. The evidence provided by a user in the process
of user authentication is called a credential. Credentials can be passwords, tokens, public-key
certificates or biometrics.
There are a number of secondary security controls concerning the use of passwords. They are:
• Password strength. A facility to control how resistant a password is to brute force or password
guessing attacks.
• Password reset. A mechanism that allows a user, help desk operator or administrator to reset the
user’s password to a new value.

• Password aging. A technique used by system administrators to defend against weak passwords
within an organisation. Password aging means that after a specified period, the user is prompted to
create a new password. The theory behind this is that if a user is forced to change his password
periodically, a cracked password is only useful to an intruder for a limited amount of time.
• Limited logins: Many systems and applications limit the number of logins a user can perform before
they are locked out. If this occurs then many systems allow a password reset. Limiting the number
of logins reduces the threat of password guessing attacks.
When a system is verifying a user’s password it does not actually compare against a plaintext copy of
the password in a password file. Instead passwords are usually stored as hash values – usually with a
salt value. The salt is used to increase the password space. When a system receives a password from a
user it creates the hash value and then compares that with the hash value stored in the password file.
Password files must be protected. Should an attacker be able to exfiltrate the password file from an
organisation they will be able to launch a brute force attack. All they do is create a hash value of a
guessed password and compare to the hash values stored in the password file. Related to this is a
dictionary attack. There are many utilities that exist to assist an attacker in performing both brute force
attacks and dictionary attacks. This is why it is extremely important to use good password strength.
It is possible to use other techniques other than passwords to undertake user authentication. Some of
these other approaches can be combined with password authentication. This is termed multi-factor
authentication. There are three factors that can be used for authentication: Something only known to
the user, such as a password or PIN; Something that is part of the user, such as a fingerprint, retina scan
or another biometric measurement; or something that belongs to the user, such as a card, token or a
key. Multifactor authentication is when more that factor is used to authenticate a user
One approach, although not that common, is to use public key certificates. In this technique the user’s
private key and the corresponding public key (in the form of a public key certificate) is held on the
workstation or mobile device. The private key and public key is then used to authenticate to the remote
web site or service. As only the user should be in possession of the private key then the remote web site
can be assured it is that person attempting to authenticate to it.
Another approach is to use tokens, such as smart cards or other types of token. It is quite common now
for financial institutions to require the use of either a bank card or a token to gain access to on-line
accounts.
Although quite rare, except for authentication to a device, biometrics- such as fingerprints can be used.
It should be noted that even if a user was to have a very strong password it does not prevent them from
being subject to a phishing attack. Typically a phishing attack is carried out by email spoofing and often
directs users to enter personal information, such as a password, at a malicious fake website.
Associated with user authentication is identity management. Identity management (IDM or IdM)
concerns the processes and policies involved in managing the lifecycle of identities along with
associated attributes of the identity. The lifecycle of an identity usually involves the following steps:
• Registration: This is the process of obtaining identity information from an entity (usually a person)
and placing it in an identity store or identity register. This includes creation of an identifier and
gathering attributes, including credentials such as a password.
• Verification: Part of the registration process is to verify the identity information provided.
• Enrolment: Typically this refers to either the capture of biometric data or that the identity is
enrolled into one or more applications.
• Authentication: This phase is when the identity can be used to perform functions such as user
authentication.
• Maintenance: Attributes will need to be updated and changed, for instance performing a password

reset.
• Suspension: Accounts will need to be suspended or deleted (and potentially reactivated). It is
important that an organisation either deletes or suspends an account when a person leaves.
Identity and access management (IAM) combines identity management and access management.
Access management is the process of granting authorised users the right to use an application or
service. Hence it is related to the access control security controls we previously described. Identity and
access management is particularly used to refer to products that manage and control access to web
sites and applications.
Federated identity is a means by where person's identity and associated attributes are stored across
multiple distinct identity management systems. Single sign-on (SSO) systems allow a single user
authentication process across multiple IT systems or even organisations. SSO within a federated identity
management means that identities are federated across different identity management systems,
potentially in different organisations or domains. Technologies used for federated identity include
Security Assertion Markup Language (SAML), OAuth and OpenID.
Security Management
Whilst Security Management is a wide field, in this section we are going to go through a few of the
security controls that support security management. We will cover the following areas:
• Centralised configuration management.
• Secure network management.
• Software distribution.
By centralised configuration management we mean having a centralised facilities that allow
administrators to configure software products residing on clients, mobile devices and servers. The most
common product in this area is Microsoft’s Active Directory (AD). A key function of AD is its ability to
configure the policy of all attached workstations and servers using group policy objects (GPOs). Other
products exist that permit this functionality whether it is for mobile devices, other operating system or
Linux systems. A key point about this facility is that if it is compromised your whole system is exposed.
Hence it is important that if you do have a centralised configured management system that it is very
secure and you strictly control access to it.
Secure network management, as the name suggests is all about managing a network securely. Like the
centralised configuration management it is vital that it is very secure. For instance changing firewall
rules to allow an organisation to be completely open to the internet would not be a good thing!
Network management is a key component of an organisation’s overall administration structure. Some
good practices that should be considered, especially for large organisations with complex networks, are
as follows:
• Establishment of a network management centre (NMC) that monitors the status of the network –
potentially operating 24x7. NMC is also known as a Network Operations Centre (NOC).
• NMC monitors the status of the network, looking for outages and problems. It also monitors
configuration changes, such as an attacker trying to reconfigure your devices. Maintenance of a
baseline of what configurations should be installed on network devices, such as firewalls and
network routers.
• Documenting the network architecture and topology, including configuration information.
• Having a governance structure, with associated processes and procedures for changes to firewall
rules.
Software distribution concerns obtaining the software from a vendor, including updates, all the way to
distributing it to all the endpoints. Again it is important that this facility is secure. You do not want to

distribute software that has been tampered with or is bogus. All software should be obtained from
authenticated websites from trusted suppliers and the software authenticity proven. For instance,
validating the specified hash value of a downloaded file. Any software obtained should be run through
with an antivirus software product. Finally the software should be tested in a preproduction or testing
environment. We cover more about this is the Security Lifecycle section as well as patch management.
It is common to separate out management traffic from data traffic flows by using either separate
physical networks or logical networks using Virtual LAN (VLAN) technology.
Trusted Communications
The purpose of security controls within trusted communications is to:
• Control the flow of information around a network, including into and out of an organisation.
• Provide a secure communications channel between two endpoints.
This is a very wide subject so in this document we cannot go through all the technologies and protocols
that might be of interest.
The flow of information around networks is primarily controlled by network routers and firewalls. Most
network routers and all firewalls support packet filtering. Packet filtering devices allows only those IP
packets to pass, which are allowed as per the device policy. Each IP packet passing through is inspected
and then the device decides to pass it or not. Network switches are networking devices that connect
devices together on a computer network by using packet switching to receive, process, and forward
data to the destination device. They do not perform routing and they do not usually support packet
filtering (although there are some exceptions).
There are two types of packet filtering:
• Stateless packet filtering
• Stateful packet filtering
Stateless packet filtering is where the information about the passing IP packets is not remembered by
the device. This type of device is not very smart and can be fooled very easily by the hackers. These are
especially dangerous for UDP type of IP packets. The reason is that, the allow/deny decisions are taken
on a packet by packet basis and these are not related to the previous allowed/denied packets. Stateless
packet filtering is implemented by network routers. Although stateless packet filtering implemented by
network routers is not a very strong security control this control is still very useful in following the
security design principle of compartmentalise. It allows a network architect to segment networks into
different security domains.
If the device remembers the information about the previously passed IP packets, then this type of
filtering is called stateful packet filtering with the device monitoring IP packets over a period of time and
examining both incoming and outgoing packets. Outgoing packets that request specific types of
incoming packets are tracked and only those incoming packets constituting a proper response are
allowed through the device. This is the technique most firewalls implement.
There are two other firewall types should be aware of. They first is called an application firewall. These
work at a higher level than packet filtering as they understand the application traffic passing through
them. For instance, they would follow and understand web or email traffic. Since the firewall does a lot
more than simple packet filtering, the throughput is not as good. This type of firewall is considered
more secure.
The second type is called a Web Application Firewall (WAF). WAFs are designed to be placed on servers
and are able to filter the content of specific web applications. By inspecting HTTP traffic, it can prevent


attacks stemming from web application security flaws, such as SQL injection, and Cross-Site Scripting
(XSS).
Firewalls tend to be used as perimeter devices – also known as boundary devices. Hence they are
typically placed to protect an internal network from internet threats. However, they can also be used to
provide security between different security domains within an organisation. There are a many different
design patterns that can used to define how firewalls should be used as a boundary device. Figure 26
illustrates one such architecture.
Figure 26 - Typical Firewall Architecture
This architecture has the following characteristics:

• It uses a Demilitarised Zone (DMZ). This is a small network inserted as a neutral zone between an
organisation’s internal network and the Internet. The DMZ contains an external web server and a
mail server.
• It has two firewalls, an outer and an inner firewall. These two firewalls are configured to allow
through only defined TCP applications (e.g. mail and web)
• The outer firewall routes incoming HTTP traffic to the external web server which is hosted in the
DMZ. It also controls what traffic can come from the internal network, via the inner firewall, and
what traffic can be sent/received from the DMZ.
• The inner firewall controls what traffic is permitted into and out of the internal network.
The next security control we will talk about is Transport Layer Security (TLS). TLS and its predecessor,
Secure Sockets Layer (SSL), both frequently referred to as "SSL", are cryptographic protocols used to
carry application traffic, such as HTTP. It can, however, carry other types of application traffic too, such
as email.
The security controls that TLS and SSL provide are as follows:


• Authentication. In a HTTP scenario the web server authenticates itself to the web browser. It does
this by using the web site’s public key certificate. It is possible to configure TLS so that in addition
the web browser authenticates itself to the website, but this is rare. This is called client
authentication. The combination of server authentication and client authentication is referred to as
mutual authentication.
• Encryption. During the authentication phase an encryption algorithm is agreed and an encryption
key set up. All traffic is then encrypted.
• Integrity. Besides providing an encryption service, TLS provides integrity, hence, any attempts to
modify, delete or insert data will be detected.
One of the interesting properties of TLS is that the client and server negotiate the cryptographic
algorithms it uses – including for encryption. Depending on the configuration of the server it is possible
to negotiate extremely weak ciphers. Hence, always check what algorithms have been configured to
use. The collection of cryptographic algorithms using in a connection is termed a cipher suite.
TLS can also be used to create Virtual Private Networks (VPNs). VPNs can be used in two main ways:
• Site to site communication – whether this is within an organisation of with a partner organisation.
• Remote access from a client device to a server.
The other technology used frequently in implementing VPNs is called Internet Protocol Security (IPsec).
IPsec is an extension to the TCP/IP family of protocols. IPsec supports source authentication, data
integrity and confidentiality using a wide range of cryptographic algorithms and public key certificates.
The final topic we will talk about in the trusted communications section is that of secure messaging. This
refers not just person to person e-mail but also communication between two processes – such as web
services. Like TLS, secure messaging supports the same three security services, namely:
• Confidentiality.
• Integrity.
• Authentication.
However, depending on the technology a non-repudiation service is also available.
There are four main technologies used for secure messaging. They are:
• S/MIME (Secure Multipurpose Internet Mail Extensions). A standard for the encryption and signing
of MIME data. S/MIME functionality is built into the majority of modern email software products,
including Microsoft Outlook. S/MIME also provides a non-repudiation service.
• PGP (Pretty Good Privacy). Email clients can be obtained that implement the PGP suite of algorithms
and protocols defined originally by Phil Zimmerman. PGP also provides a non-repudiation service
using digital signatures.
• TLS can be used to protect web services traffic. It is also used to protect traffic from a web email
client to a mail server. TLS replaces Secure Sockets Layer (SSL). The latest version of TLS is version
1.2. SSL and TLS 1.0 should not be used as they both have known weaknesses.
• WS-Security is a suite of standards from OASIS that define how to protect SOAP messages in web
services.


Security Architecture
SABSA Sherwood, Clark and Lynas. Enterprise Security Architecture A Business-
Driven Approach. CMP Books. Published 2005. ISBN 978-1-57820-318-4.
See also http://www.sabsa.org/
TOGAF The Open Group Architecture Framework.
See https://www.opengroup.org/togaf/
Design Patterns
OSA Open Security Architecture
http://www.opensecurityarchitecture.org/cms
O-ESA Open Enterprise Security Architecture (O-ESA) – A Framework and Template
for Policy-Driven Security. The Open Group, 2011. ISBN 978-90-8753-672-5.
Security Design Principles

Building Secure Software John Viega and Gary McGraw. Building Secure Software - How to Avoid
Security Problems the Right Way. Addison-Wesley. Published 2001
ISBN 978-0321774958
Cryptography
Everyday Cryptography Keith M Martin. Everyday Cryptography. Oxford University Press. Published
2012. ISBN 978-0-19-969559-1
NIST SP 800-175A NIST Special Publication 800-175A. Guideline for Using Cryptographic
Standards in the Federal Government: Directives, Mandates and Policies
(August 2016).
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175A.pdf
NIST SP 800-175B NIST Special Publication 800-175A. Guideline for Using Cryptographic
Standards in the Federal Government: Cryptographic Mechanisms (August
2016).
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175B.pdf
Physical, Procedural and Technical Controls

ISO/IEC 27002:2005 ISO/IEC 27002:2005. Information technology — Security techniques — Code
of practice for information security controls.
ISO/IEC 27035 ISO/IEC 27033-1:2009. Information technology — Security techniques —
Network security —Part 1: Overview and concepts.
ISO/IEC 24760 ISO/IEC 24760-1:2011 Information technology -- Security techniques -- A
framework for identity management -- Part 1: Terminology and concepts.


Cloud Computing
CSA Guide Cloud Security Alliance. Security Guidance For Critical Areas Of Focus In Cloud
Computing V3.0 (2011)
https://downloads.cloudsecurityalliance.org/assets/research/security-
guidance/csaguide.v3.0.pdf
Treacherous 12 Cloud Cloud Security Alliance. The Treacherous 12 Cloud Computing Top Threats in
Computing Top Threats 2016.
https://downloads.cloudsecurityalliance.org/assets/research/top-
threats/Treacherous-12_Cloud-Computing_Top-Threats.pdf
NIST Special Publication 800- NIST Special Publication 800-145. The NIST Definition of Cloud Computing
145 (September 2011)
http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-
145.pdf
NIST Special Publication 500- NIST Special Publication 500-292. NIST Cloud Computing Reference
292 Architecture. (September 2011)
https://www.nist.gov/publications/nist-cloud-computing-reference-
architecture?pub_id=909505
Internet of Things
IoT Security Foundation IoT Security Foundation Guidelines
https://iotsecurityfoundation.org/best-practice-guidelines/
OWASP IoT OWASP Internet of Things Project.
https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project
Industrial Control Systems

ISA99 ISA99, Industrial Automation and Control Systems Security.
https://www.isa.org/isa99/
IEC 62443 ISA/IEC-62443

https://webstore.iec.ch/
21 Steps 21 Steps to Improve Cyber Security of SCADA Networks. US Department of
Energy.
https://energy.gov/sites/prod/files/oeprod/DocumentsandMedia/21_Steps_-
_SCADA.pdf
NIST SP 800-82 NIST Special Publication 800-82 Revision 2 Guide to Industrial Control
Systems (ICS) Security. May 2015
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r2.pdf


2.5. Information Security Framework
This section covers the basics of what you need to know about legislation, regulations, policies,
standards, procedures, and guidelines, and provides some examples to illustrate the principles. Taken
all together this defines the Information Security Framework of an organisation. The Information
Security Framework may well be based on an ISMS such as ISO/IEC 27001 or COBIT.
Policies, standards, procedures, and guidelines are influenced by relevant legislation, for example the
Data Protection Act in the UK. Depending on the industry the organisation may also need to be
compliant with one more regulations. Contracts between organisations may also call up legislation and
regulations that sub-contractors must adhere with.
The relationship between these various artefacts are shown in Figure 27.
Figure 27 - Information Security Framework
In summary the various components are:
• Legislation: A particular bill or act of parliament.

• Regulations: Regulations are enforced usually by a regulatory agency formed or mandated to carry
out the purpose or provisions of a legislation.
• Policies: long-term, high-level management statements on how the organisation is to be run and
managed from an information security perspective. Policies reflect an organisation's goals,
objectives, culture and are intended for broad audiences. From a legal and compliance perspective,
an information security policy is often viewed as a commitment from senior management to protect
information. A policy is frequently a requirement to satisfy regulations or legislation, such as those
relating to privacy and finance. They also are mandatory and are applicable to everyone, including
employees, contractors and temporary staff. Policies drive standards, procedures and technical
controls.


• Standards: a collection of system-specific or procedural-specific requirements that must be met by
everyone and are typically low-level. Standards can be directed to a broad audience or limited to
specific groups or individuals, for instance development staff. Standards help to ensure security
consistency across an organisation and usually contain technical controls relating to the
implementation of specific technology, hardware or software. An example is a hardening standard
for Microsoft Windows desktops. Standards can be developed by organisations, e.g. “corporate
standards”, or they can be are adopted from a recognised standards producing organisation such as
ISO, NIST, OWASP or OASIS.
• Guidelines: A collection of system specific or procedural specific "suggestions" for best practice.
They are not requirements to be met, but are strongly recommended. They could consist of
additional recommended controls that support a standard.
• Procedures: Procedures are specific instructions, typically ordered tasks, for performing some
function or action. Procedures are mandatory.
• Security Awareness: A process for educating employees about information security defining the
level of security required by the organisation and individual security responsibilities. A security
awareness program should educate employees about corporate policies and procedures. It should
also define the required behaviours of staff and sets the required security culture.
Note that these terms are not used consistently in some organisations. For instance some organisations
will refer to policy whereas what the document is describing is a procedure. As a high level example for
remote access:
• The policy says you must use encryption.

• The standard which protocols and cipher suites must be used.
• The procedure describes how the user obtains their remote access credentials.
We will now go into each of these in more detail in the following sections.
2.5.1. Legislation
In this section we go through primary legislation that affects information security within the UK. Many
countries have similar laws. It’s not possible in this document to through all the legislation, or
regulations, that might impact a given organisation or industry. Good sources include:
• http://www.legislation.gov.uk/. This contains details all of the Acts and regulations passed by the
UK parliament.
• http://eur-lex.europa.eu. EUR-Lex is an official website of European Union law and other public
documents of the European Union (EU)
Data Protection Act
The Data Protection Act 1998 (DPA) controls how personal data is used by organisations, businesses or
the government. The DPA defines eight data protection principles, which apply in various contexts, to
ensure that information is processed lawfully. In summary the eight principles are:
• Principle 1: Personal data shall be processed fairly and lawfully.
• Principle 2: Personal data shall be used for limited, specifically stated purposes.
• Principle 3: Personal data shall be adequate, relevant and not excessive in relation to the purpose or
purposes for which they are processed.
• Principle 4: Personal data shall be accurate and, where necessary, kept up to date.
• Principle 5: Personal data shall be kept for no longer than is absolutely necessary.
• Principle 6: Personal data shall be handled according to people’s data protection rights
• Principle 7: Appropriate technical and organisational measures shall be taken against unauthorised


or unlawful processing of personal data and against accidental loss or destruction of, or damage to,
personal data.
• Principle 8: Personal data shall not transferred outside the European Economic Area without
adequate protection.
The DPA also defines sensitive personal data. Sensitive personal data has stronger legal protection
under the Act. In summary sensitive personal data is personal data that includes any of the following
information pertaining to a data subject:
• Racial or ethnic background.
• Political opinions.
• Religious beliefs.
• Whether they are a member of a trade union.
• Physical or mental health or condition.
• Sexual health.
• Criminal records.
The DPA protects the rights of individuals whom the personal data is about. The data subject is the
individual whom particular personal data is about. The DPA does this by placing duties on those who
decide how and why such personal data is processed. These are known as data controllers. The data
controller determines the purposes for which and the manner in which any personal data are, or are to
be, processed. Data controllers will usually be organisations, but can be individuals. Data controllers
must ensure that any processing of personal data for which they are responsible complies with the Act.
Failure to do so risks enforcement action, even prosecution, and compensation claims from individuals.
The DPA also defines data processors. This means any person or organisation who processes the data on
behalf of the data controller. Data processors are not directly subject to the DPA. However, most data
processors, if not all, are data controllers in their own right.
The DPA requires every data controller who is processing personal data to register with the Information
Commissioner’s Office (ICO), unless they are exempt. The ICO is responsible for regulating compliance
with the DPA. Organisations or individuals who only process personal data for domestic or recreational
reasons are exempt from registering. However, it is important to note that exempt organisations or
individuals must still adhere to the principles of the DPA.
The ICO has always stated that when processing personal data it has been good practice to adopt a
privacy by design approach and to carry out a Privacy Impact Assessment (PIA) as part of this. With the
introduction of the General Data Protection Regulation (GDPR) it is now a legal requirement to do this in
certain situations – although the GDPR call this a data protection impact assessment (DPIA). We will go
through the GDPR in the next section.
The DPA also provides the data subject with the right to see a copy of the information an organisation
holds about them. This right is commonly referred to as a subject access request. However, the right of
access goes further than this, and an individual who makes a written request, and pays a fee, is entitled
to be:
• Told whether any personal data is being processed.
• Given a description of the personal data, the reasons it is being processed, and whether it will be
given to any other organisations or people.
• Given a copy of the information comprising the data; and given details of the source of the data
(where this is available).
The ICO has several ways of taking action to change the behaviour of anyone who breaches the DPA.
They include criminal prosecution, non-criminal enforcement and audit. The Information Commissioner
can also serve a monetary penalty notice imposing a fine of up to £500,000.

Computer Misuse Act
The Computer Misuse Act 1990 (CMA) is designed to protect computers against malicious attacks and
theft of information. Prior to 1990, there was no legislation in place to tackle the problems caused by
hacking. The CMA was introduced to add three new offences that criminals can be prosecuted under.
These are:
• Unauthorised access to a computer.
• Unauthorised access with intent to facilitate further offences.
• Unauthorised acts with intent to impair, or with recklessness as to impairing, the operation of a
computer.
The misuse of computers can include the following activities:
• Hacking of computer systems (in terms of illegally accessing someone’s systems).
• Unauthorised interception of communications.
• Production and use of malware.
• Interference with computer systems that could lead to a denial of service.
• Computer related fraud and forgery.
• Infringement of copyrights.
• Downloading and sharing of illegal material, such as pornography or bootleg films.
• Trafficking in stolen informational goods, such as credit card numbers, bank details, email
addresses, passwords, digital signatures and encryption keys.
Since the CMA was introduced it has been constantly updated.
Many systems implement a “splash screen” on logging on to a system warning the person that they
need to be authorised to access the system; if not they could be infringing the CMA. It is also very
common to quote the CMA in the organisation’s acceptable use policy.
The penalties of breaking the CMA range from fines to imprisonment.
Regulation of Investigatory Powers Act
The Regulation of Investigatory Powers Act 2000 (RIPA) regulates the manner in which certain public
bodies may conduct surveillance and access a person's electronic communications. It governs the use of
covert techniques by public authorities. It requires that when public authorities, such as the police or
government departments, need to use covert techniques to obtain private information about someone,
they do it in a way that is necessary, proportionate, and compatible with human rights. The Act covers
the following:
• Intercepting communications, such as the content of telephone calls, emails or letters.
• Acquiring communications data: the ‘who, when and where’ of communications, such as a
telephone billing or subscriber details.
• Conducting covert surveillance, either in private premises or vehicles (intrusive surveillance) or in
public places (directed surveillance).
• The use of covert human intelligence sources, such as informants or undercover officers.
• Access to electronic data protected by encryption or passwords
Investigatory Powers Act
The Investigatory Powers Act 2016 brings together and updates existing laws including RIPA. It has
introduced new powers, and updated existing ones, for UK intelligence agencies and law enforcement
to carry out targeted interception of communications, bulk collection of communications data, and bulk
interception of communications.


This is a new Act of Parliament and hence some of its provisions may not be in place for some time.
Some of the provisions of the Act include:
• Creation of an Investigatory Powers Commission (IPC) to oversee the use of all investigatory powers.
• A “double-lock” for the most intrusive powers, so that warrants issued by a Secretary of State will
also require the approval of a senior judge.
• New protections for journalistic and legally privileged material, and a requirement for judicial
authorisation for acquisition of communications data that identify journalists’ sources.
• Creation of a new criminal offence for unlawfully accessing internet data.
• Requires communication service providers (CSPs) to retain UK internet users' "Internet connection
records" – which websites were visited but not the particular pages and not the full browsing
history – for one year.
Freedom of Information Act
The Freedom of Information Act 2000 (FOI) came into force on 1 January 2005 and provides the public
with a general right of access to official information held by public bodies in England, Wales and
Northern Ireland. The Information Commissioner’s Office oversees the operation of the Act. In principle,
the freedom of information act applies to all "public authorities" within the United Kingdom, a full list of
public authorities for the purposes of the Act is included in Schedule 1. However, some public
authorities such as the intelligence services are exempt from the Act.
On receipt of a freedom of information request a public authority has two corresponding duties:
• A duty to inform a member of the public whether or not it holds the information requested
• If it does hold that information, to communicate it to the person making that request.
However, there are numerous exemptions. Some of these are absolute bars to disclosure; some are
qualified, which means the public authority has to decide whether the public interest in disclosing the
relevant information outweighs the public interest in maintaining the exemption. An applicant for
information who considers that a request has been wrongly rejected may apply to the Information
Commissioner, who has the power to order disclosure.
The Freedom of Information (Scotland) Act 2002 is the responsibility of the Scottish Information
Commissioner.
The Copyright, Designs and Patents Act 1990
The Copyright, Designs and Patents Act 1990 exists to provide protection for the owners of Intellectual
Property Rights (IPR). The Act defines and regulates ownership of rights in intellectual property and
generally provides the owner with a right to prevent others using it unless they have permission or a
licence. These works can be written documents, recordings and include computer software that is
considered a literary work. The objective of the Act is to protect the right of a copyright author in his
work and at the same time allow others to access that work. The Act maintains this balance by
establishing time limits for the author’s control over a particular work. The Act states that “the owner of
the copyright has the exclusive right to copy the work”. This means it is illegal to copy original works
without the copyright owner’s permission. With regard to software, the copyright owner is the software
developer/publisher.
Organisations must be aware of this Act and comply with the licensing requirements of software they
use. Unauthorised installation of copyrighted software is likely to breach the terms of licence and could
potentially result in criminal prosecution. In addition corporate web pages where information is
published should be checked for infringement of the Act and that any necessary permissions or
acknowledgements have been given.


Copyright infringement that may be criminal offences under the Act may attract an unlimited fine and
up to 10 years imprisonment.
Human Rights Act
The Human Rights Act 1998 (HRA) puts the rights set out in the 1953 European Convention on Human
Rights into UK law. Article 8, relating to privacy, is of most relevance to information security. The HRA
provides for
• The right to respect for private life, family life, one’s home and correspondence.
• That there shall be no interference by a public authority with the exercise of this right, except if it is
in accordance with the law, for a legitimate social purpose, or for the protection of the rights and
freedoms of others
Hence personal data is protected by the HRA as part of an individual’s right to respect for a private life.
This right is also embedded within the Data Protection Act.
The HRA can also have an impact on physical security, for instance, placement of CCTV.
Companies Act 2006
The Companies Act 2006 states that directors have a legal responsibility to promote the success of their
companies, and to exercise independent judgement, reasonable care, skills and diligence. Directors who
fail to manage security risk appropriately may infringe their legal duties to promote the success of the
company and to exercise reasonable care, skill and diligence. Therefore, this has a direct bearing on how
an organisation defines its governance.
The Companies Act states that private companies must keep their company accounting records for
three years from the date on which they are made, and public companies must keep them for six years.
This requirement can therefore be included in a review, retention and disposal policy and information
classification policy to ensure the necessary documents and information are kept secure with controlled
access for the legally required period of time. We will be talking about these types of policies in section
2.5.3.
Sarbanes Oxley Act
The Sarbanes Oxley Act 2002, usually referred to as “SOX” was introduced by US Congress following the
high profile collapse of US corporate giants Enron and WorldCom. Both organisations had massively
overstated their profits because of corruption within the boardroom. SOX is also known as the "Public
Company Accounting Reform and Investor Protection Act" or the "Corporate and Auditing
Accountability and Responsibility Act".
SOX compliance is important to UK businesses with listings in a US stock exchange.
Under SOX boardroom directors also have a responsibility to ensure that IT systems follow SOX
compliance rules to ensure transparent accounting and audit reporting. From an information security
perspective the key points of the Act are:
• The signing officers are responsible for internal controls and have evaluated these internal controls
within the previous ninety days and have reported on their findings.
• A list of all deficiencies in the internal controls and information on any fraud that involves
employees who are involved with internal activities.
• Any significant changes in internal controls or related factors that could have a negative impact on
the internal controls.
• Assess both the design and operating effectiveness of selected internal controls related to
significant accounts and relevant assertions, in the context of material misstatement risks.


• Understand the flow of transactions, including IT aspects, sufficient to identify points at which a
misstatement could arise.
• Evaluate controls designed to prevent or detect fraud, including management override of controls.
Penalties of fines and/or up to 20 years imprisonment can be imposed for altering, destroying,
mutilating, concealing, falsifying records, documents or tangible objects with the intent to obstruct,
impede or influence a legal investigation.
Gramm-Leach-Bliley Act
This US federal Act is also known as the Financial Modernization Act of 1999. The Act includes provisions
to protect consumers' personal financial information held by financial institutions.
Financial institutions, banks, securities firms, insurance companies, as well as companies providing
financial products and services to consumers, including lending, are covered by the Act. Any UK
company with subsidiaries in the US offering these type of services will be covered.
There are three principal parts to the privacy requirements within the Act:
• Financial Privacy Rule: Requires financial institutions to give customers privacy notices that explain
its information collection and sharing practices. In turn, customers have the right to limit some
sharing of their information. Financial institutions and other companies that receive personal
financial information from a financial institution may be limited in their ability to use that
information.
• The Safeguards Rule: Requires all financial institutions to design, implement and maintain
safeguards to protect the confidentiality and integrity of personal consumer information.
• Pretexting provisions: Protect consumers from individuals and companies that obtain their personal
financial information under false pretences, including fraudulent statements and impersonation.
NIS Directive
On July 6, 2016, The European Parliament set into policy the Directive on Security of Network and
Information Systems (the NIS Directive). EU countries have until 9 May 2018 to implement the NIS
Directive into their national laws. The UK government has confirmed that it will be implementing the
NIS Directive regardless of Brexit. The NIS Directive aims to ensure that critical IT infrastructure in key
sectors are secure from cybersecurity threats. The NIS Directive will apply to:
• Companies within critical sectors. For example, banking, health care, energy and transport.
• Digital service providers. For example, online marketplaces, search engines and cloud services.
Organisations covered by the NIS Directive are accountable for reporting significant security incidents to
Computer Security Incident Response Teams.
Each EU Member State needs to adopt a national strategy on the security of network and information
systems defining the strategic objectives and appropriate policy and regulatory measures with a view to
achieving and maintaining a high level of security of network and information systems and covering at
least the above sectors.
Other aspects of the directive include:
• Designation of one or more national competent authorities on the security of network and
information systems for the defined sectors.
• The creation of a EU-wide Co Cooperation Group. This group is to support and facilitate strategic
cooperation and the exchange of information among the EU Member States.
• A network of the national CSIRTs is to be established.


2.5.2. Regulations
Information Commissioner’s Office
Compliance with the Data Protection Act is regulated and enforced by an independent authority, the
Information Commissioner's Office, which maintains guidance relating to the Act.
Compliance with the DPA is a very specific specialism. Hence, if you are not very familiar with the Act
then please obtain specialist advice.
General Data Protection Regulation
The General Data Protection Regulation (GDPR) (Regulation (EU) 2016/679) is a regulation by which the
European Parliament, the Council and the European Commission intend to strengthen and unify data
protection for individuals within the European Union. It also addresses export of personal data outside
the EU.
The regulation was adopted on 27 April 2016. It comes into effect on 25 May 2018 after a two-year
transition. The GDPR will also apply in the UK from 25 May 2018. The UK government has confirmed
that the UK’s decision to leave the EU will not affect the commencement of the GDPR.
Many of the GDPR’s main concepts and principles are much the same as those in the current DPA. If an
organisation is complying properly with the current DPA then most of the approach to compliance will
remain the same under the GDPR and can be the starting point to build from. However, there are new
elements and significant enhancements. They include:
• The regulation applies if the data controller, data processor or the data subject is based in the EU.
• Most organisations will need to appoint a Data Protection Officer (DPO) to take responsibility for
data protection compliance. This person should have expert knowledge of data protection law and
practices and should assist the data controller or data processor to monitor internal compliance
with the GDPR. In the UK monitoring of DPOs will be the responsibility of the ICO rather than the
Board of Directors of the organisation that employs the DPO.
• Where processing operations are likely to result in a high risk to the rights and freedoms of data
subjects, the data controller should be responsible for the carrying-out a Data Protection Impact
Assessment.
• The data subject has the right to request erasure of personal data related to them on any one of a
number of grounds.
• Privacy settings must be set at a high level by default in applications.
• Increased fines. Depending on the infringement the fine could be up to 20 million Euros, or up to 4%
of the annual worldwide turnover. Hence, the ICO will be able to fine organisations this increased
amount compared to the previous £500,000.
Privacy and Electronic Communications Regulations
The Privacy and Electronic Communications Regulations (PECR) sit alongside the Data Protection Act.
They give people specific privacy rights in relation to electronic communications.
There are specific rules on:
• Marketing calls, emails, texts and faxes.
• Cookies (and similar technologies)
• Keeping communications services secure.
• Customer privacy as regards traffic and location data, itemised billing, line identification, and
directory listings.
The PECR has been amended a number of times since becoming into force in 2003.


One of the amendments concerned the use of cookies. Cookies, or similar technologies, that track
information about people accessing a website or other electronic service must not be used unless the
web site (or similar):
• Tells people the cookies are there.
• Explains what the cookies are doing and why.
• Gets the person’s consent to store a cookie on their device (e.g. mobile phone, PDA, PC etc).
The PECR also requires service providers to take appropriate technical and organisational measures to
safeguard the security of their service. For example:
• Ensure that personal data can be accessed only by authorised personnel for legally authorised
purposes.
• Protect personal data stored or transmitted against accidental or unlawful destruction, accidental
loss or alteration, and unauthorised or unlawful storage, processing, access or disclosure.
• Ensure the implementation of a security policy with respect to the processing of personal data.
Compliance with the PECR is regulated and enforced by the Information Commissioner's Office. The ICO
will take enforcement action against organisations that persistently ignore their obligations under the
PECR. The ICO has several ways of taking action to change the behaviour of anyone who breaches the
PECR. They include criminal prosecution, non-criminal enforcement and audit. The Information
Commissioner can also serve a monetary penalty notice imposing a fine of up to £500,000.
Investigatory Powers Commission
The use of all investigatory powers under the Investigatory Powers Act will be overseen by the
Investigatory Powers Commission (IPC). The IPC will be headed by the Investigatory Powers
Commissioner. The IPC will be supported by a number of Judicial Commissioners to help the IPC
perform their extensive range of functions. The Commissioners will be supported by a team of specialist
technical inspectors who can fully question and hold to account those using investigatory powers.
Payment Card Industry Data Security Standard
PCI DSS is the Payment Card Industry Data Security Standard. It is a worldwide standard that was set up
to help businesses process card payments securely and reduce card fraud. The way it does this is
through controls surrounding the storage, transmission and processing of cardholder data that
businesses handle. Merchants, service providers and acquiring banks must be compliant with PCI DSS.
PCI DSS is also intended to protect sensitive authentication data, including the CVV. PCI DSS includes
requirements for security management, policies, procedures, network architecture, software design and
other critical protective measures.
PCI DSS has 12 high level requirements, which have not changed significantly since the inception of the
standard. They are:
1. Install and maintain a firewall configuration to protect cardholder data.
2. Do not use vendor-supplied defaults for system passwords and other security parameters.
3. Protect stored cardholder data.
4. Encrypt transmission of cardholder data across open, public networks.
5. Protect all systems against malware and regularly update anti-virus software or programs.
6. Develop and maintain secure systems and applications.
7. Restrict access to cardholder data by business need-to-know.
8. Identify and authenticate access to system components.
9. Restrict physical access to cardholder data.

10. Track and monitor all access to network resources and cardholder data.
11. Regularly test security systems and processes.
12. Maintain a policy that addresses information security for all personnel.
These high level requirements are then broken down to sub-requirements and guidance on how
compliance should be tested.
Compliance with PCI DSS is not a UK or a US federal law. However, the laws of some US states refer to
PCI DSS. Organisations may be liable for non-compliance fines if they do not work towards compliance.
Ultimately the issuing bank, that is the financial institution that has issued the card, could be forced to
terminate the relationship, which will prevent the merchant from accepting payments by card.
How compliance is validated depends on the size of the organisation and how many card transactions
are processed. This ranges from using an external assessor to having internal assessors to undertake a
self-assessment.
2.5.3. Policies
According to ISO/IEC 27000:2016 a policy is:
Intentions and direction of an organisation as formally expressed by its top management
In effect a security policy establishes what must be done to protect information whether it is stored on
a computer is on paper. A well written policy contains sufficient definition of “what” to do so that the
“how” can be identified and measured or evaluated. A policy needs management commitment,
supporting procedures and an appropriate technical framework within which it can be implemented. It
is important that there is a means by which compliance can be checked and a visible statement on the
consequences of the policy being violated.
There are two broad approaches to documenting policy:

• A single monolithic policy document is produced. Frequently a document of this type runs to many
hundreds of pages.
• A single high-level policy document is produced with a number of subservient policy documents
covering specific areas.
Either approach is acceptable. As we go through this section we will assume that separate individual
policy documents are produced – but there is nothing stopping an organisation collapsing them into a
single document.
This is not intended to be an exhaustive list. Rather it should indicate to the reader the types of policies
requires as well as an indication of what should be in them. Not all organisations will need to produce
all of the policies we have described in this section, it will depend on their specific environment. In
addition there may be some policies not listed here that an organisation feels they need to produce.
Each policy should include details of whatever authority supports the policy such as the Board, the
organisation’ CEO, the Head of HR, the CIO etc. Each policy should have a set of objectives and the
statements within a policy should be unambiguous, concise and establish intent.
We will first describe the top level information security policy and then go to describe the subservient
ones – in alphabetic order. For the subservient policies we will outline the primary purpose of the policy
and then go on to provide a few typical clauses you might have in that type of policy. Many of the
policies we will describe below are outlined in ISO/IEC 27002.


Information Security Policy
The high-level information security policy will usually cover the following points:
• The scope of the policy – is it covering all parts of the organisation or just one part.
• The governance arrangements within the organisation and who is responsible for what. Clear roles
and responsibilities should be defined. Someone on the board should be appointed as having overall
responsibility for cyber and information security.
• The security goals of the organisations, for example:
 Ensure compliance with current legislation, regulations and guidelines (these should be
stated where practical).
 Comply with requirements for confidentiality, integrity and availability for employees and
other users.
 Establish controls for protecting the organisation’s information and information systems
against theft, abuse and other forms of harm and loss.
 Implementation of all applicable ISO/IEC 27002 security controls.
• How risk is managed and the risk management methodology used within the organisation.
Acceptable Use Policy
Purpose:
Outlines the acceptable use of information, electronic and computing devices, and network
resources to conduct business or interact with internal or external networks and business
systems. These rules are in place to protect the employee and the organisation.
Inappropriate use exposes an organisation to risks including malware attacks, compromise
of network systems and services, and legal issues.
Typical Clauses:
 Under no circumstances is an employee authorised to engage in any activity that is illegal
under UK or international law while utilising the organisation’s owned resources.
 It is strictly prohibited to introduce into the network any malicious programs (e.g., viruses,
worms, Trojan Horses).
 Port scanning or security scanning is expressly prohibited unless prior notification is
obtained.
 It is forbidden to send unsolicited email messages, including the sending of "junk mail" or
other advertising material to individuals who did not specifically request such material.
 Downloading of indecent material from the internet is strictly forbidden.
 You must not send emails containing potentially offensive material.
Anti-virus Policy
Purpose:
 Anti-virus software must be installed by default on all systems including servers, desktops,
laptops and mobile devices. Failure to install anti-virus software increases the risks not just
to the data and user information held on a machine, but also to those hosted on all other
machines across the network.
Typical Clauses:
 All systems built and / or hosted by third parties that are used by the organisation must run
anti-virus software.
 Anti-virus software must be maintained and virus-signatures updated on a regular basis.
 The organisation may monitor any system attached to the network for anti-virus software

and may deny any systems access to the network without up-to-date virus signatures.
Asset Management Policy
Purpose:
 Describes the policy required to provide assurance that all assets have been accounted for,
thereby ensuring that these assets can be protected with the appropriate information
security controls.
Typical Clauses:
 All assets shall be clearly identified and an inventory of all important assets drawn up and
maintained.
 All assets associated with information processing facilities shall be owned by a designated
part of the organisation.
 The information security manager retains the right to audit any information asset at any
time.
Auditing and Logging Policy
Purpose:
Auditing and logging of systems will be carried out in order to help protect the safety of the
organisation, and in order to preserve the confidentiality, integrity and availability of the
data held in information systems. It will also assist the organisation in detecting and
investigating inappropriate behaviour according to the acceptable use policy.
Typical Clauses:
 Logs are kept securely and will only be accessed by authorised members of the IT
department.
 Audit logs recording user activities, exceptions and information security events shall be
produced and kept for an agreed period to assist in future investigations and access control
monitoring. The audit events that must be logged is contained in the Auditing and Logging
Standard.
 System administrator and system operator activities shall be logged.
Business Continuity Policy
Purpose:
 This policy enables the organisation to proactively identify and plan to minimise the impact
of risks that could affect its objectives, operations and infrastructure. BCM provides the
capability to ensure continuity of operations, together with support from its staff, following
any disruptive event.
Typical Clauses:
 Each department within the organisation shall have its own Business Continuity Plan and it
shall be written according to the Business Continuity Plan Standard.
 Each Business Continuity Plan shall be approved by the board.
 Each Business Continuity Plan shall be tested yearly unless an exemption is approved by the
board.
Bring Your Own Device (BYOD) Policy
Purpose:
 Defines the acceptable use by employees whilst using their own devices for accessing,
viewing, modifying and deleting an organisation’s data and accessing its systems and

applications.
Typical Clauses:
 Use the device security features, such as a PIN, Password/Passphrase and automatic lock to
help protect the device when not in use.
 Keep the device software patched and up to date, for example using Windows Update or
Software Update services.
 You must use and activate and use encryption services and anti-virus protection.
Clear Desk and Clear Screen Policy
Purpose:
 Establishes the minimum requirements for maintaining a “clear desk” and “clear screen”–
where sensitive/critical information is secure in locked areas or is out of sight. A clear desk
and clear screen policy is a control specified in ISO/IEC 27002.
Typical Clauses:
 Sensitive or critical business information should be locked away (ideally in a safe or cabinet
or other forms of security furniture) when not required, especially when the office is
vacated.
 Workstations should be left logged off or protected with a screen and keyboard locking
mechanism controlled by a password, token or similar when unattended.
 Media containing sensitive or classified information should be removed from printers
immediately.
Data Protection Policy
Purpose:
This policy aims to detail how the meets its legal obligations concerning confidentiality and
information security standards. The requirements within the policy are primarily based
upon the Data Protection Act 1998 that is the key piece of legislation covering security and
confidentiality of personal data.
Typical Clauses:
 The Data Protection Officer is responsible for maintaining compliance with this policy.
 The Data Protection Officer must annually notify the Information Commissioner’s Office
about the organisation’s use of personal information.
 Before any new system goes live it must undertake a Privacy Impact Assessment which must
be approved by the Data Protection Officer.
 All information relating to identifiable individuals must be kept secure at all times. The
organisation will ensure there are adequate procedures in place to protect against
unauthorised processing of information and against accidental loss, destruction and damage
to this information.
 If person identifiable information records need to be transported in any media such as
magnetic tape, floppy disc or manual paper records, this should be carried out to maintain
strict security and confidentiality of this information. Only reliable transport couriers should
be used at all times.
Disposal Policy
Purpose:
 The IT Asset Disposal Policy is concerned with managing the secure disposal of IT equipment
assets which are owned by the organisation and are no longer required.

Typical Clauses:
 Cross cut shredders and confidential waste containers must be used to dispose of hardcopy
sensitive information, CDs, floppy disks etc. which are no longer needed.
 Any IT assets leaving premises must comply with licences and copyright law. The IT
department must ensure that all licensed software or operating systems are removed.
 IT Equipment that stores sensitive data, including personal data, which is no longer needed
or has reached “end of life”, must be securely deleted according to the Data Deletion
Standard.
Encrypted Authentication Policy
Purpose:
Unencrypted methods of authentication are a major threat to the security of user
credentials, and consequently to the confidentiality, integrity and availability of information.
This policy defines how authentication data must be protected.
Typical Clauses:
 All user authentication, for example the input of a username and password in order to gain
access to a system or application, must be protected, whilst being transmitted, by an
encrypted protocol, in order to ensure that username and password details are not passed
in plaintext.
 Passwords must not be stored on a system in plaintext. They must be suitably protected and
stored in a hashed form.
 By default, applications requiring user authentication should use the encrypted version of
protocols.
 Known weak encryption algorithms and vulnerable protocols must not be used in new
implementations. These include, but are not restricted to the use of DES and RC4.
Incident Management Policy
Purpose:
To ensure a consistent and effective approach to the management of information security
incidents, including communication on security events and weaknesses. Enables the
efficient and effective management of information security incidents by providing a
definition of an information security incident and establishing a structure for the reporting
and management of such incidents.
Typical Clauses:
 All staff shall be made aware of the procedure for reporting information security incidents
and their responsibility to report such incidents.
 All information security incidents shall be reported promptly to the Service Desk in
accordance with the Information Security Incident Reporting Procedure.
 New risks identified as a result of an information security incident shall be assigned to the
relevant risk owner and unacceptable risks shall be mitigated promptly in accordance with
the risk management processes.
Information Classification Policy
Purpose:
 Information should be classified according to an appropriate level of confidentiality,
integrity and availability. Refer to the Information Classification Standard for details. The
policy should also cover how information is handled at a given classification.

Typical Clauses:
 Staff with particular responsibilities for creating documents are responsible for ensuring the
classification attached to a document is appropriate.
 All users must handle information appropriately and in accordance with its classification
level.
Information Sharing Policy
Purpose:
Information sharing, in the context of this policy, means the disclosure of personal data
from one or more organisations to a third party organisation. This policy lays down the
requirements for information sharing with external organisations.
Typical Clauses:
 When information needs to be shared, sharing must comply with the law, guidance and
best practice.
 A sharing agreement shall be set up when personal data needs to be exchanged with a third
party. The Data Protection Officer must approve each sharing agreement.
 Only the minimum information necessary for the purpose will be shared and only when a
sharing agreement explicitly permits it.
Monitoring Policy
Purpose:
 There are circumstances where we may monitor or record communications, or examine
material stored on systems. This document sets out the policy in respect of such activity.
Under RIPA, unlawful interception of communications on the computer network may lead
to criminal proceedings against an individual operating without authority; unlawful
interception may also lead to civil action. RIPA, however, allows for legitimate interceptions
of communications by organisations on their private computer and telecommunications
networks - in other words, they provide 'lawful authority.
Typical Clauses:
 Routine monitoring for operational reasons may only be authorised by written
authorisation from the Head of Security.
 The Information Security Board will oversee monitoring. All results of monitoring user
communications or stored data must be reported to the chair of the Information Security
Board as soon as the monitoring is completed.
Password Policy
Purpose:
 It is important to ensure that end users and administrators use complex passwords that are
difficult to guess or crack. They also need to be changed on a regular basis. The policy
covers the frequency and conditions for change.
Typical Clauses:
 Password need to be at least 8 characters long, contain at least one uppercase letter and at
least one lower case letter, contain at least one number or punctuation character
 Passwords for standard users must be changed at least once per year.
 Passwords of administrators will need to be changed every 90 days.
 All users will receive an email 30 days before expiry, and regularly thereafter, reminding


them of the required password change.
 Failure to change a password within the defined duration will lead to the account becoming
disabled.


Patch Management Policy
Purpose:
Unpatched systems and applications are often a source of compromise, adversely affecting
the confidentiality, integrity and availability of data. It is important that all systems and
applications must be updated to the latest patch release.
Typical Clauses:
 Patching of systems will be centrally managed wherever possible, unless there are clear
business reasons for patching to be performed locally.
 The most recent security patches must be installed on the system as soon as practical, the
only exception being when immediate application would interfere with business
requirements.
 Systems, devices and applications must be updated within 30 days of any release of a patch
that fixes CVSS-defined ‘High’ vulnerabilities.
 All patches must be tested before being released into the production system unless Board
approval has been obtained.
PCI DSS Compliance Policy
Purpose:
 This policy provides essential information for everyone tasked with handling credit and
debit cards, cardholder data and the systems processing such data. It is designed to ensure
the organisation can meet the standards required by the Payment Card Industry’s Data
Security Standard (PCI-DSS), in order to be able to process card payments.
Typical Clauses:
 System users shall not send cardholder data via end-user messaging technologies such as, e-
mail, instant messaging or chat without using an approved encryption solution.
 Users shall not store cardholder data on local hard drives, floppy disks, or other external or
mobile media.
 Any documents containing cardholder data must be securely locked away when not in use.
 The CVV should be handled with great care and should never be written down or stored
anywhere, whether on a piece of paper, a form or in a spreadsheet.
Remote Access Policy
Purpose:
 The purpose of this policy is to define rules and requirements for connecting to the
organisation’s network from any host. These rules and requirements are designed to
minimise the potential exposure from damage which may result from unauthorised use of
resources. Damage include the loss of sensitive or company confidential data, intellectual
property, damage to public image, damage to critical internal systems, and fines or other
financial liabilities incurred as a result of those losses.
Typical Clauses:
 Secure remote access must be strictly controlled with encryption (i.e., Virtual Private
Networks (VPNs)) and strong passwords. The VPN technology used must be company
approved. Refer to the Remote Access Standard.
 Authorised users shall protect their login and password, even from family members.
 Remote access to system administrator functions is not permitted.
 Please refer to the Remote Access and Mobile Working Guidelines document.

Review, Retention and Disposal Policy
Purpose:
 Important records and documents of the organisation must be protected from loss,
destruction and falsification. Some records may need to be retained securely to meet
statutory or regulatory requirements as well as to support essential business activities. The
retention period of each class of information is contained in the retention schedule.
Typical Clauses:
 There must be a valid and justifiable reason for retaining records past the retention period.
 Personal data must be deleted when it is no longer needed – unless there are legal reasons
to retain it. Advice must be sought from the Data Protection Officer in these cases.
Security Incident Policy
Purpose:
IT systems and network compromises can cause significant damage to an organisation's
resources and harm to its reputation through attacks on other systems and networks via
compromised systems. The purpose of this policy is to ensure that all information security
incidents that occur, or are suspected of having occurred, are handled in a structured and
consistent manner.
Typical Clauses:
 Information security incidents must be properly reported and handled by appropriate
authorised personnel.
 Information security incidents must be properly recorded and documented with all
evidence being gathered, recorded and maintained in a form that will withstand internal
and external scrutiny.
 If a user believes an information security incident has occurred they must report it using the
Incident Handling Procedure.
 If a weaknesses in a procedure or policy is identified then this must be addressed.
Starters and Leavers Policy
Purpose:
The purpose of this policy is to prevent unauthorised access to information systems. The
policy describes the registration and de-registration process for all information systems and
services. This policy applies especially to new starters, leavers and those moving job or
responsibility. This policy should also read in conjunction with the HR policy to verify a new
starter’s qualifications, references and right to work in this country.
Typical Clauses:
 Before being granted access to any system a starter must have signed and acknowledged
the acceptable use policy.
 As soon as practicable after an individual leaves employment, all their system logons must
be revoked and accounts suspended. It is the responsibility of HR to inform the IT
department if an individual leaves employment.
 Any lapsed or unwanted logons, which are identified, will be disabled immediately and will
be deleted unless positively reconfirmed.
 Should an individual change job or responsibility then their privileges must be reviewed and
those that are not required removed. It is the responsibility of the IT department to do this.


Training and Awareness Policy
Purpose:
 This policy specifies an information security awareness and training program to inform and
motivate all staff and temporary workers regarding their information security obligations.
Typical Clauses:
 The Security Manager has overall responsibility for maintaining awareness of confidentiality
and security issues for all staff.
 Security awareness and training should commence as soon as practical after a worker
(employee or temporary staff) joins the organisation.
 Workers must receive annual security awareness training.
Vulnerability Assessments Policy
Purpose:
 Vulnerability management is an essential component of any information security program
and the process of vulnerability assessment is vital to effective vulnerability management.
Vulnerability assessment provides visibility into the vulnerability of assets deployed in the
organisation’s network. Vulnerability assessment consists of scanning to identify networked
assets, determine potential vulnerabilities and assess potential vulnerabilities. This policy
defines who can perform vulnerability assessments and how often then can occur.
Typical Clauses:
 Only individuals authorised by the Security Manager can perform vulnerability assessments.
No other user can perform vulnerability assessments or download tools that permit them to
be performed.
 Only authorised vulnerability assessment tools can be used. The list of authorised tools is
maintained by the Security Manager.
 Vulnerability assessments should be performed overnight and occur every month.
2.5.4. Standards
An organisation will refer to a number of external security standards, or if they are not appropriate,
develop their own. In this section we will give you an idea of a few of the security standards that a
typical organisation may require. Different business communities and sectors may well have different
types of standards. For instance there are different standards in the defence, public sector, health, retail
and finance sectors.
Some of these standards we referred to in the previous section. As with the policies section, the
description of the standards are not meant to be complete, but rather are intended to give you an idea
on some of the topics they address. Many of these standards will have an associated procedure
containing specific instructions for performing some function or action in order to be compliant with the
standard.
Audit and Logging Standard
This standard defines what audit events are logged and when. For instance you may require that
applications log access to every single record in a database when it contains personal data – and this
would include both read and write access. Some other examples are:
• User authentication and authorisation such as user login and logout
• Grant, modify, or revoke privileges, including adding a new user or group, changing user privilege
levels, changing file permissions, changing database object permissions.

• Changing firewall rules.
• User password changes.
• System, network, or services configuration changes, including installation of software patches and
updates, or other installed software changes.
• Application process start-up, shutdown, or restart.
Business Continuity Standard
As we described in the previous section we would expect in large organisations to have a business
continuity plan for each department. This standard would describe what is required in each plan.
A standard would cover things like:
• Need to appointment a Business Continuity Coordinator for each department.
• Structure and contents of a business continuity plan.
• Need to conduct a business impact analysis to identify time-sensitive or critical business functions
and processes and the resources that support them. Then identify and document a plan to recover
critical business functions and processes.
• Arrangements to make staff aware of plans, their roles in them and ensure they are trained
appropriately.
• Business continuity plans are subject to regular reviews, audits and exercises.
Data Deletion Standard
Before IT equipment (especial disk drives and USB memory sticks) can be disposed of, or reused, data
and potentially software will need to be deleted. Using normal deletion functions in an operating
system does not really delete the data – they just release the disk space for future use. Special tools
have to be used to really delete data. This standard should describe what tools are used to delete data
depending on the type of IT equipment and its information classification.
If data is very sensitive then the equipment may have to be destroyed. For disk drives this could mean
degaussing them and then physically destroying them. Refer to NIST Special Publication 800-88 for more
details.
Hardening Standards
We will cover hardening (i.e. secure configuration) in section 2.6.4. In summary an organisation needs
to have a number of standards that describe how operating systems, applications, devices (especially
printers and mobile devices) etc. are configured so they are secure. Some of these standards could be
obtained from external sources and others developed in-house by the organisation. Refer to the topical
references in section 2.6.10 for a list of potential sources of hardening advice.
Information Classification Standard
Different types of information require different security controls depending upon their sensitivity. The
Information Classification Standard is designed to provide information owners with guidance on how to
classify information assets.
The standard should define how many classification levels (sometimes referred to as sensitivity levels)
and what they mean. The standard should be quite clear so that a document creator can easily decide
what classification level should assigned to the information asset they are creating. The classification
level then defines what handling is required as well as the protection. For instance should the document
be locked away in a safe when not used? Should access be limited to it on a need-to-know basis? Can
the document be made public – or should it be considered as confidential to the organisation? All these
points, and more, needs to be addressed in the standard.


Remote Access Standard.
The purpose of this standard is to establish usage and documentation requirements for remote access
methods used in the organisation. Firewalls will be used to restrict remote access to only approved VPN
products. The standard will need to document:
• The permitted cipher suites used by the approved VPN products.
• What audit events the audit logs contain concerning remote access connections.
• What information systems and services the remote users may access, and the methods used to
enforce those restrictions.
Risk Management Standard
Most organisations will need to adopt a risk assessment and risk management standard. Note that
ISO/IEC 27005 does not prescribe a particular standard – rather it is a methodology and doesn't specify,
recommend or even name any specific risk management method. Hence, if you want to develop an in-
house risk management standard based on ISO/IEC 27005 you will have document your own method.
Secure Coding Standards
We will cover secure coding standards in section 2.6.2. There are many external secure coding
standards that exist and some are listed in the topical reference in section 2.6.10. However, for some
more obscure languages there may not be any authoritative secure coding standards. In that case you
may need to produce you own. What an organisation’s overall secure coding standard should do is
make it clear what internal and external secure coding standards developers should use.
What some organisations have done is to produce an overarching document that describes their overall
approach to hardening and secure coding and then listing the appropriate standards their organisation
use.
2.5.5. Guidelines
As we said earlier a guideline is a collection of system specific or procedural specific "suggestions" for
best practice. They are not requirements to be met, but are strongly recommended. Guidelines can
provide advice, direction and best practice in instances where it is difficult to define a policy or
procedure. Organisations can produce just a few or as many as feel they want to. Typical titles of
guidelines are provided below. You should be able to work out what most of them are intended to do:
• Information classification guidelines.
• Using encryption to protect your data.
• Guideline for Virus Protection.
• Guidance on Backing-up Data
• Electronic Mail guidelines.
• Use of USB memory sticks.
• Remote Access guidance.
• Spam, Phishing and Spear Phishing emails.
• Data Protection Act guidance.
• Sharing Data with External Organisations guidance.
• Guidelines when working from home.
• Travelling aboard.
• Guidance on Social Media and Social Networking
This list is not supposed to be exhaustive by any means but it should give you an idea of the type of
guidelines or guidance an organisation could have.


2.5.6. Procedures
A procedure is a set of detailing working instructions that describes what, when and how and by whom
something should be done. Procedures are mandatory and they usually support polices and standards.
Below are a few examples that typically exist in an organisation. Many of these we have already
mentioned. For each of them we have supplied a short explanation.
• Business continuity procedure: In large organisations you may have a number of these procedures,
perhaps one for each department. They will contain a step by step description that in the event of a
business disruption the organisation can continue to undertake its prioritised activities. For instance
it will name the individuals to contact should a particular event occur.
• Incident reporting procedure: This procedure will describe how to identify and report an
information security incident. It would normally describe the form to use and how to submit it.
• Incident handling procedure: This would be used by the CSIRT. It would describe how they handle
different types of information security incidents. This includes recovery from the incident as well as
lessons learned.
• New Employee procedure. This will describe the steps for on-boarding a new employee. For
instance creating a new user account, getting them to sign the acceptable user policy and receive
security awareness training.
• Password reset procedure: Users frequently forget their passwords. This procedure would describe
how a user’s password can be reset to a new value. If only the help desk can do this it would need
to explain how they validate the user’s identity.
• Subject access request procedure: This procedure would describe the steps the organisation would
go through on receiving a subject access request from the public. It would include who should
handle the request in the organisation, who communicates with the individual and who approves
the response. It would also need to state the timescales.
• Termination of Employment procedure: On termination of employment their user account(s) – and
there could many! - should be disabled and all their IT assets returned.
2.5.7. Security Awareness

Effective information security begins and ends with security awareness and appropriate training for
members of staff with responsibility for information security related functions. A comprehensive
information security program not only focuses on physical and technical security practices and methods,
but also on the human aspects of security threats and common methods employed by malicious parties
to take advantage of those without security awareness and training. It is also an ongoing process of
learning that is meaningful to recipients, and delivers measurable benefits to the organisation and
provides lasting behavioural change. It also defines the type of security culture an organisation desires.
A security awareness programme is not just about training but also requires monitoring effectiveness
regarding employee’s security understanding and behaviour. Security awareness is a means to ensure
that staff understand their environment and the tools they have to secure it, and is all about
encouraging the appropriate levels of behaviour.
A good security awareness program should educate employees about corporate policies and procedures
for working with IT. Employees should receive information about who to contact if they discover a
security threat and be taught that data is an extremely valuable corporate asset.
Awareness comes in many forms including during induction as well as an ongoing regime through the
use of all sorts of media and messages. For example, plasma displays, formal presentations, videos,
quizzes and posters. Training is just one potential channel you can use to improve security awareness.


The first task when developing a security awareness program is to recognise that different roles require
different levels of awareness and potentially training. So the first thing to do is to group individuals
according to their roles or job functions within the organisation. Then you can determine the level of
risk to the organisation should that individual be compromised in some manner. Figure 28 depicts how
the depth of awareness should increase as the level of risk associated with different roles.
So for instance system administrators should have in-depth security awareness – whilst most personnel
would only receive general security awareness.
Figure 28 - Security Awareness
The overall objectives of a security awareness program should be to:

• Communicate risks and vulnerabilities facing the organisation.
• Communicate company objectives regarding security and enterprise risk.
• Communicate company policies and procedures.
• Communicate organisation roles and responsibilities.
• Provide resources and tools for deeper knowledge.
• Provide a mechanism for on-going communication on issues related to risks and vulnerabilities.
• Deliver behavioural change.
Typically a general security awareness course will take between one to two hours. This should be
delivered to new employees, and temporary staff, as soon as possible from when they started
employment. It is also recommended that refresher courses are held every year.
The training can be instructor led or using self-paced, computer based. It is also common for employees
to pass an exam as well.
Security awareness is not just about training courses, but should also include:
• Posters reminding staff of the risks and their duties
• Regular security newsletter on security matters
• Lunchtime briefing sessions on specialised topics.
A security awareness course could address the following topics.
• What is Information Security?
• Key Concepts: confidentiality, integrity, availability, threat, vulnerability, risk and control.
• Governance within the organisation defining key security roles and responsibilities.
• Legislation landscape. Covering legislation and regulations that are pertinent to the organisation
(e.g. DPA, PECR, and PCI DSS). State consequences of non-compliance.

• Threats to the organisation: DDoS, viruses, worms, Trojan horses, phishing, spear phishing, spam,
pharming, ransomware and social engineering. Avoiding malicious software.
• Where to find policies and procedures.
• Policy and guidelines on information classification and the correct handling of information.
• Handling of printed output and its destruction (e.g. shredding for sensitive data). Threats of
dumpster diving.
• Policy and password usage and management – including password strength, frequency of changes,
and protection. Process for password reset.
• Email policy and guidance: handling unknown e-mail/attachments.
• Web usage – appropriate usage versus prohibited; monitoring of user activity.
• Security incident procedure – contact whom? “What do I do?”
• Policy and procedures on the use of encryption and the transmission of sensitive/confidential
information over the Internet.
• Laptop security while travelling – addressing both physical and information security issues.
• Policies and procedures concerning working at home.
• Policy, procedures and guidance on deleting data and destroying disks and IT assets.
• Visitor control and physical access to spaces – discuss applicable physical security policy and
procedures, e.g., challenge strangers, report unusual activity.
• Clear Desk and Clear Screen Policy – discuss use of screensavers, restricting visitors’ view of
information on a screen to prevent shoulder surfing.
2.5.8. Security Strategies

We have mentioned strategies a number of times in this section, but what is a strategy? The Oxford
English Dictionary defines a strategy as:
A plan designed to achieve a particular long-term overall aim.
A strategy defines how you move from where you are now to where you want to be. It contains a plan
of action designed to achieve a specific goal or series of goals within an organisational framework and
will normally cover the following elements:
• Mission and vision.
• Objectives.
• Policies and plans to execute the vision
• Allocation of resources to implement those policies and plans.
Organisations develop and maintain strategic plans for most of the activities they carry out – not just for
security. It is important that any security strategy is aligned with other corporate strategies.
A security strategy is an important document which details the series of steps necessary for an
organisation to identify, remediate and manage risks while staying compliant with applicable legislation
and regulations. A security strategy should be aligned with an Information Security Management System
(ISMS) as it provides both strategic and operational frameworks in particular as regards governance.
A security strategy can provide business improvement if executed correctly and can also assist in
innovation. A good example of a security strategy can be found in the topical references.


Legislation
Data Protection Act Data Protection Act 1998
http://www.legislation.gov.uk/UKPGA/1998/29/contents
Computer Misuse Act Computer Misuse Act 1990

http://www.legislation.gov.uk/ukpga/1990/18/contents
Regulation of Investigatory Regulation of Investigatory Powers Act 2000

Powers Act http://www.legislation.gov.uk/ukpga/2000/23/contents
Investigatory Powers Act Investigatory Powers Act 2016

http://www.legislation.gov.uk/ukpga/2016/25/contents/enacted
Freedom of Information Act Freedom of Information Act 2000

Copyright, Designs and Patents Copyright, Designs and Patents Act 1988
Act http://www.legislation.gov.uk/ukpga/1988/48/contents
Human Rights Act Human Rights Act 1998

Companies Act Companies Act 2006

Sarbanes Oxley Act Sarbanes Oxley Act 2002

https://www.gpo.gov/fdsys/pkg/PLAW-107publ204/content-detail.html
Gramm-Leach-Bliley Act Gramm-Leach-Bliley Act 1999

https://www.congress.gov/bill/106th-congress/senate-bill/00900
NIS Directive DIRECTIVE (EU) 2016/1148 OF THE EUROPEAN PARLIAMENT AND OF THE
COUNCIL of 6 July 2016 concerning measures for a high common level of
security of network and information systems across the Union
http://eur-lex.europa.eu/legal-
content/EN/TXT/PDF/?uri=CELEX:32016L1148&rid=1


Regulations
Information Commissioner’s https://ico.org.uk/
Office
Privacy and Electronic The Privacy and Electronic Communications (EC Directive) Regulations 2003
Communications Regulations http://www.legislation.gov.uk/uksi/2003/2426/contents/made
The Privacy and Electronic Communications (EC Directive) (Amendment)
Regulations 2004
http://www.legislation.gov.uk/uksi/2004/1039/contents/made
Regulations 2015
Regulations 2016
The Privacy and Electronic Communications (EC Directive) (Amendment) (No.
2) Regulations 2016
General Data Protection The General Data Protection Regulation (GDPR) (Regulation (EU) 2016/679)
Regulation http://eur-lex.europa.eu/legal-
content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN
PCI-DSS The PCI Security Standards Council

https://www.pcisecuritystandards.org/pci_security/
Policies
Information security management systems —Code of practice for
Standards
NIST Special Publication 800-88 Guidelines for Media Sanitization
Revision 1 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r1.pdf
Guidelines
Information security management systems —Code of practice for


Procedures
NONE
Security Awareness
PCI DSS guidance Best Practices for Implementing a Security Awareness Program
https://www.pcisecuritystandards.org/documents/PCI_DSS_V1.0_Best_Pract
ices_for_Implementing_Security_Awareness_Program.pdf
NIST Special Publication 800-50 Building an Information Technology Security Awareness and Training
Program
http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-50.pdf
Strategies
NCSC NATIONAL CYBER SECURITY STRATEGY 2016-2021
https://www.gov.uk/government/uploads/system/uploads/attachment_data
/file/567242/national_cyber_security_strategy_2016.pdf


2.6. Security Lifecycle
In this section we are going to look at the full lifecycle of a system from its initial development, its
deployment and then finally then its maintenance.
2.6.1. Security Development Lifecycle

The first notable Security Development Lifecycle (SDL) methodology was published by Microsoft. The
Microsoft SDL is a software development process that helps developers build more secure software and
address security compliance requirements. Microsoft use it to develop most of their support. In the
topical references section we point out to the original book on the subject as well as the Microsoft web
site that hosts the current material and tools for the SDL.
OWASP have also published a type of security development lifecycle. This is called the Application
Security Verification Standard (ASVS).
Many of the security points raised in the Microsoft and OWASP documentation are covered in this
section.
2.6.2. Secure Coding

We covered many of the security design principles in a previous section. However, it is worthwhile
emphasising some of these again whilst introducing a few new ones specifically for secure coding.
• Validate Input. Validate input from all untrusted data sources – in particular user input. Proper
input validation can eliminate many software vulnerabilities. Attacks such as SQL Injection, Cross
Site Scripting are all as a result of failing to properly validate user input. In general be suspicious of
all external data coming into the program, including command line arguments, network interfaces,
environmental variables, and user controlled files.
• Heed Compiler Warnings. Compile code using the highest warning level available for the compilers
in use and eliminate warnings by modifying the code. Use static and dynamic analysis tools to
detect and eliminate additional security flaws.
• Adhere to the Principle of Least Privilege. Every process should execute with the least set of
privileges necessary to complete the job. Any elevated permission should be held for a minimum
time. This approach reduces the opportunities an attacker has to execute arbitrary code with
elevated privileges. Usually programmers are being lazy if they need their application to run with
privileges.
• Sanitise Data Sent to Other Systems. Sanitise all data passed to complex subsystems such as
command shells and relational databases. Attackers may be able to invoke unused functionality in
these components through the use of SQL, command, or other injection attacks.
• Look for Buffer Overflows. Many of the vulnerabilities in products, in particular operating systems,
is due to poor handling of buffers. This is known as a buffer overflow attack. A buffer overflow
attack is frequently used to obtain elevated privileges. If this occurs then the attacker can quite
easily take over a system. Programmers need to be extremely diligent in looking for and preventing
buffer overflow situations. Similar to buffer overflows programmers should also look for integer
overflows.
• Adopt a Secure Coding Standard. Apply a secure coding standard for the target development
language and platform. The topical references section provides two resources that will prove
invaluable to development teams.
It is also common to have code auditing performed either by another member of the team or an
external specialist. Backdoors in programs can only usually be found by this method.


When looking to develop and build trusted software, which you could argue most needs to be, also
consider looking at BS PAS 754:2014. This is a British Standards Institution (BSI) software Publicly
Available Specification (PAS). PAS 754 defines the overall principles for effective software
trustworthiness, and includes technical, physical, cultural and behavioural measures. It also define how
to have effective leadership and governance. The specification looks defines five aspects of software
trustworthiness:
• Safety.
• Reliability.
• Availability.
• Resilience.
• Security.
Work on PAS 754 has been led by the Trustworthy Software Foundation.
2.6.3. Testing
All software and applications must be tested. In section 2.2.3 we looked at vulnerability assessments
and penetration testing performed by specialised teams – potentially from external organisation. This
section is looking at the type of testing that the development teams could (or should!) be performing.
These tests are usually performed on a development or pre-production system, whereas vulnerability
assessments and penetration tests are frequently performed on a production system (although they can
also be undertaken on a pre-production system).
All development teams will do some testing usually of a functional nature – usually referred to as
functional testing. The problem with only doing this type of testing it that it only tests positive results –
referred to as positive testing. Testing must also be performed for erroneous and bad input – for
instance trying to inject code into a field that should only contain numeric values. This is termed
negative testing. In particular the testers in the development teams should be looking for SQL injection,
cross-site scripting and buffer overflow vulnerabilities.
Developers should also look at using static code analysis and fuzzing tools. Fuzzing is a software testing
technique, often automated or semi-automated, that involves providing invalid, unexpected, or random
data to the inputs of a program. The program is then monitored for exceptions such as crashes. Whilst
this is a specialist area most development staff should have no problem in using such tools.
OWASP have published the OWASP Testing Guide which is a very valuable resource for anyone involved
in developing and testing web applications.
2.6.4. Hardening
Hardening is also known as secure configuration and sometimes as lockdown. It is the secure
configuration of an operating system, device, service or an application to remove vulnerabilities that are
present in a standard build. Many products are sold in a form that is either insecure or allows attackers
easy access. Some products are sold already hardened – at least to some degree.
The basic principles of hardening is as follows:
• Reduce the attack surface of systems. This means not installing unnecessary components of
operating systems or applications. This is conform to the security design principle of minimisation
we mentioned previously.
• Changing default passwords to ones that have good password strength.
• Delete or disable unnecessary user accounts.
• Renaming of privileged accounts from their default name, e.g. “root”.

• Reducing the amount of information that helps an attacker to launch an attack. For instance
removing the default landing page for web servers. You do not want an attacker to establish exactly
the version of software running – as that might indicate the vulnerabilities in the system
• Limit the privileges assigned to applications and do not – unless absolutely necessary – allow them
to run with superuser privileges.
• If possible do not have a single all powerful superuser account and have multiple administrators
with different sets of privileges. This is to conform to the security design principle of separation of
duties.
• Make sure the systems and applications are patched and up to date.
• Turn off or disable all communication ports and protocols that are not required.
• If external communication is required use the appropriate secure version of the protocol, for
instance using HTTPS rather than HTTP.
• If TLS is used then make sure strong cipher suites are configured to be used.
• Remove all unnecessary network shares.
• Remove all development tools from production systems such as compilers.
Good sources of hardening advice for various products can be found in the topical references section.
However, many large organisations will already have specialised secure builds for operating systems
they use internally.
Hardening is usually performed during the development process and will be applied when applications
and systems are deployed in pre-production and production environments.
2.6.5. Independent Assurance

In this section we are going to look at how you can gain assurance of security functionality and
resistance to threats for both products and services. We will cover three type of assurance gained from
independent sources, namely:
• Product Assurance.
• System Assurance.
• Cryptographic Assurance.
Product Assurance
The first type of assurance we shall look at is primarily designed for security products.
The first one is called the Common Criteria and is specified in ISO/IEC 15408. It defines a framework for
evaluating security features and capabilities of security products. However, it can also be used to assess
systems. Once completed, it provides assurance to buyers that the process of specification,
implementation and evaluation for any certified security product was conducted in a thorough and
standard manner. Products can only be evaluated by competent and independent licensed laboratories
so as to determine the fulfilment of particular security properties. The certification of the security
properties of an evaluated product can be issued by a number of Certificate Authorizing Schemes, with
this certification being based on the result of their evaluation. Nearly 20 countries have Certificate
Authorizing Schemes including the UK and the US. Certificates issued by any participants in this scheme
will be recognised by all the other participants.
The security properties of a product are specified in its Security Target. The product under evaluation is
termed the Target of Evaluation (TOE). A Security Target specifies:
• A description of the TOE.
• The threats the TOE is designed to counter.
• The TOE security objectives.

• Security functional requirements.
• Security assurance requirements.
The security assurance requirements are typically given as a number 1 through 7 called an Evaluation
Assurance Level (EAL). An EAL indicates the depth and rigor of the security evaluation, usually in the
form of supporting documentation and testing, that the product meets the security functional
requirements. The highest level of assurance is EAL7 – although not many projects are evaluated at that
level. Most products are evaluated at EAL2, EAL3 or EAL4
A Security Target always describes a specific TOE whereas a Protection Profile (PP) is intended to
describe a TOE type (e.g. firewalls). The same PP may therefore be used as a template for many
different Security Targets to be used in different evaluations. A PP describes the general requirements
for a TOE type, and is therefore typically written by a user or vendor community seeking to come to a
consensus on the requirements for a given TOE type.
The Commercial Product Assurance (CPA) scheme is run by the UK’s National Cyber Security Centre
(NCSC). It is designed to be more lightweight than the Common Criteria. Although administered by NCSC
CPA is not just for cryptography based products but other types as well. It includes a number of
different product types. NCSC has worked with industry to produce security characteristics for the
different product types. Security characteristics documents are very similar to Common Criteria
Protection Profiles. CPA products are evaluated by independent NCSC-approved CPA Test Labs. The
scheme is designed to provide assurances that a product functions as claimed by the manufacturer.
Product assurance applies to a specific version of a product and can take a long time to complete such
that often a later, and unassured, product is on the market by the time the assurance process is
complete.
System Assurance
Independent assurance of a system can be gained in a number of ways. We have already talked about
penetration testing and vulnerability assessments in section 2.2.3. One thing you must do is establish
whether the testers have suitable accreditations and qualifications. Some of the schemes of note are:
• CREST.
• Tigerscheme.
• CHECK.
• Cyber Scheme.
Although rare it is possible to use the Common Criteria to evaluate systems.
HMG organisations in the UK can also make use of the CTAS service. A number of organisations are
accredited by NCSC to perform CTAS evaluations. Each CTAS evaluation is tailored to provide the
assurances required by the user organisation to better understand the environment under evaluation.
Examples of evaluation activities the CTAS evaluation team many undertake include:
• Document Review: Review of evaluation deliverables (e.g. security architecture, design, test
evidence, development procedures, operational guidance and operational procedures).
• Audit: Audit of development, delivery, installation and/or operational procedures.
• Analysis: Cryptographic analysis and/or source code review; vulnerability analysis.
• Test: Security functional and penetration tests.
The UK government has also promoted the Cyber Essentials and Cyber Essentials Plus assurance
scheme. This scheme is targeted at organisations and the systems they run. In Cyber Essentials
organisations self-assess their systems, and this assessment is independently verified. In Cyber
Essentials Plus systems are independently tested. Annual recertification is required.


The Cyber Essentials certification process includes a self-assessment questionnaire (SAQ), which is
independently assessed, and an external vulnerability scan is run. Cyber Essentials Plus certification
includes all of the assessments for the Cyber Essentials certification but includes an additional internal
scan and an on-site assessment.
The five main technical controls are the schemes are:
• Boundary firewalls and internet gateways.
• Secure configuration.
• Access control.
• Malware protection.
• Patch management.
Cryptographic Assurance
There are two schemes that are of importance as regards cryptography based products. The first one is
usually referred to as FIPS 140 or FIPS 140-2 and is produced by NIST. However, its full title is “Federal
Information Processing Standards Publication – Security Requirements for Cryptographic Modules.”
Although initially created to evaluate products aimed at the US government marketplace it has seen
worldwide adoption and in particular for products target at the financial sector.
FIPS-140-2 is on its third revision (and hence the “2”!). It has a number of associated annexes and these
are updated more frequently than the main body of the standard.
The standard specifies security requirements for the design and implementation of cryptographic
modules for protecting information and cryptographic keys and certificates whether it is stored in
hardware, firmware or software. The reason the standard refers to cryptographic modules is that
products certified against FIPS 140-2 can be self-contained modules (such as VPN devices), software
libraries, smart cards or plugin cryptographic PC cards. FIPS 140-2 defines the cryptographic algorithms
that can be used in implementation. These algorithms are specified in the annexes.
The Cryptographic Module Validation Program (CMVP) is responsible for maintaining the FIPS 140-2
standard ensuring that certified modules comply with it. The testing is undertaken by accredited
laboratories and CMVP ensures that the testing performed by a laboratory has been carried out
correctly.
FIPS 140-2 imposes requirements in eleven different areas including design assurance, self-tests and
physical security. FIPS 140-2 defines four levels of security, simply named Level 1 to Level 4. Level 1 is
the lowest while Level 4 is the most stringent. The requirements for each of the levels is specified in the
standard. The level of a product for a given application or use case scenario is not specified in the
standard. It is down to the user organisation or community to specify what is required for a given usage.
Very few cryptographic modules are certified at Level 4.
NIST maintains a list of cryptographic modules that have been validated. The URL for the list can been
found in the topical reference section.
The CESG Assisted Products Service, known more simply as CAPS, is a scheme run by NCSC. It is only for
what is called high grade cryptography protecting the most sensitive information of HMG.
As we mentioned above cryptographic products can also be evaluated under the CPA scheme.
2.6.6. Deployment and Release Management

Release Management is a discipline that encompasses managing, planning, designing, building,
configuring, testing and scheduling of hardware and software releases through different stages and
environments until they are deployed into production.

Whilst this very much a function of the IT department, there are a few things that security should be
concerned about. The following is some guidance you should consider in following:
• All software should be tested before being deployed – including patches (as we will look at in the
next section).
• All major releases should undergo a vulnerability assessment – if not all releases!
• Administrators of the production systems should not have access to the pre-production systems.
Therefore, you should have separate administration staff for production and pre-production.
• Development and test staff should not have administrator or privileged user access to the
production system – unless it is highly controlled.
• Live data from the production system containing personal data should not be installed on either the
testing or pre-production systems. Exceptionally this can be allowed assuming the data is highly
sanitised. This is one of the security controls in ISO/IEC 27002.
Many organisations in the UK use practices developed by ITIL for IT Service Management (ITSM). The
ITIL best practices are currently detailed within five core publications, namely:
• ITIL Service Strategy
• ITIL Service Design
• ITIL Service Transition
• ITIL Service Operation
• ITIL Continual Service Improvement.
The best practices cover the entire service management lifecycle, beginning with the identification of
customer needs and drivers of IT requirements, through to the design and implementation of the
service and finally, the monitoring and improvement phase of the service. If ITIL is used then any
security processes you use will have to operate within an ITIL environment.
2.6.7. Patch Management

We covered vulnerability management in section 2.2.3. One of the outputs of the vulnerability
management process is deciding what patches to apply. The process of applying patches is termed
patch management. The main objective of a patch and vulnerability management process is to detect
vulnerabilities and then patch them in a timely fashion.
There is not a clear distinction between vulnerability management and patch management. However, in
Figure 29 we have tried to indicate one way of thinking about the differences in terms of the overall
process.


Figure 29 - Vulnerability and Patch Management
The process starts by identifying vulnerabilities and patches issued by all the vendors used in the system
as well from other sources such as CERTs. The first thing to do is to establish whether the vulnerabilities
are in products within your system. For instance Oracle issue Critical Patch Updates, Security Alerts on a
regular basis. However, this is for all their products. You may determine that some of the products are
not used in your system.
Assuming it is identified that the vulnerability affects your system, then first you need to establish
whether a work around is available. If there is then the associated patches can be applied when the next
routine schedule maintenance occurs. If a work around is not available then a determination needs to
be made as to how high a risk the vulnerability is. If it a high risk then you may want to patch
immediately. If it is not high risk then again it can wait until the next scheduled maintenance. Many
organisations use the CVSS scoring system to determine the level of risk of the vulnerability. As part of
the initial triage you also need to establish if it is viable threat. For example, you would need to establish
if it is worth the effort of addressing a risk from an external attack to a stand-alone system).
Once patches are applied then this needs to be documented.
Whilst this is an overview there are some complexities to it. Before patching any application, device or
operating system you should test it. You really don’t want to deploy an updated application without
testing. For the routine scheduled maintenance then you can factor in that testing does need to be
performed in a pre-production environment. For high risk patches it is more complicated. If the release
procedure indicates that the system requires 3 or 4 days of testing before it can be moved to production
what do you do? It maybe you need to have an emergency procedure such that if it is a critical patch
then it needs to be deployed straight away without testing. This is obviously high risk and it is
recommended that the business signs this off – as a potential business impact is that the system may
crash. If it is not quite so critical then the organisation may be comfortable with taking several days of
testing before deploying into production. If the system needs to be taken off-line for a significant period
of time to apply patches, such as an hour or more, then the business needs to be consulted. It may be

that they have some critical business activity being undertaken which means they cannot afford to have
the system down for any period of time.
This process requires documentation and should form part of the change management process. We will
talk about this in the next section
The following issues should be considered when created a patch management process.
• Testing: As stated above, updated components should be tested before deploying into production.
However, this is not always possible. It could be that the pre-production environment doesn’t quite
match the production environment or it does not have access to live data. The key point is that you
need to minimise risk before deployment – so whatever testing can be performed should be
performed.
• Back-up: A data backup of the existing live system should be captured before patching of the
production system.
• Rollback: A contingency plan should be developed in the event of a failure in applying the patch.
Hence a recovery point should be taken before deploying the patches. If a failure does occur then
the system can be rolled back.
• Level of Risk: Don’t forget to patch medium and low vulnerabilities on a regular basis as well.
• Vendor Patches: Do not patch production systems directly from vendor sites. Always download the
patches and use anti-virus software to check for malware before applying them to software in the
pre-production environment. When patches are downloaded you should compare the hash value
calculated on the file(s) against the hash value published on the vendor’s web site.
NIST Special Publication 800-40 contains a good review of the technologies and techniques available to
an enterprise for applying patches.
2.6.8. Change Management

Change management is vital to every stage of the patch management process. As with all system
modifications, patches and updates must be performed and tracked through the change management
system. It is highly unlikely that an enterprise-scale patch management program can be successful
without proper integration with the change management system and organisation. What is also key is
that “security” should be involved in the change management process. The objective of change
management is to ensure that standardised methods and procedures are used for efficient and prompt
handling of all changes to control the IT infrastructure including applications.
In many organisation a Change Advisory Board (CAB) or sometimes called a Change Control Board (CCB)
is formed. This board is usually made up of representatives from all areas within the IT organisation, the
business, and third parties such as suppliers. Their aim is to prioritise and schedule changes. It is
important that a security representative is on this board.
Change management is covered extensively within ITIL.
2.6.9. Data Security Lifecycle

Organisations cannot protect what they do not know about; we need to understand where our data is,
always. Understanding where enterprise data resides, and the path it takes between systems, is
imperative to comply with legal and regulatory requirements but also to ensure that appropriate
controls are being deployed. The “Data Security Lifecycle” (DSL) was created by Securosis and version
2.0 is available online. The DSL is also referred to by the Cloud Security Alliance in their guidance.
The DSL is comprised of six phases which cover data from creations to destruction. Figure 30 illustrates
the lifecycle.

Create
 Destroy
Store
Archive Use
Share
Figure 30 - Data Security Lifecycle
The six phases are:

• Create: Creation of new digital content, or the updating of existing content.
• Store: Storage of the digital data to some sort of storage repository, and typically occurs nearly
simultaneously with creation.
• Use: Data is viewed, processed, or otherwise used in some sort of activity.
• Share: Information is made accessible to others, such as between users, to customers, and to
partners.
• Archive: Data leaves active use and enters long-term storage.
• Destroy: Data is permanently destroyed using physical or digital means.
The original model assumed an on-premise architecture. The 2.0 version has been extended to take into
account cloud environments and considers the impact of where the data is located and who has access.
The addition of looking at location information was made as organisations are commonly leveraging
cloud services for backup, DR and testing facilities.
Any organisation can benefit from asking the questions which are outlined in the DSL:
• Where are the potential locations for my data?
• What are the lifecycles and controls in each of those locations?
Once data residency has been established, it is important that we understand who is accessing the data
and from where. Completing this activity successfully will satisfy many of legal and regulatory
requirements which are frequently cited at as being an inhibitor to public cloud adoption. Two
important questions to ask are:
• Who accesses the data?
• How can the data be accessed, from what devices and over what channels
Answering all these questions will enable an organisation to complete a privacy impact assessment.


Security Development Lifecycle

Microsoft SDL https://www.microsoft.com/en-us/sdl/
The Security Development The Security Development Lifecycle: SDL: A Process for Developing Demonstrably
Lifecycle: More Secure Software (Developer Best Practices). Michael Howard, Steve Lipner.
ISBN 978-07356-2214-2
OWASP ASVS The OWASP Application Security Verification Standard.
https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verific
ation_Standard_Project
Secure Coding
SEI CERT Coding Standards https://www.securecoding.cert.org/confluence/display/seccode/SEI+CERT+Coding
+Standards
Contains standards for C, C++, Java, Perl and Android.
OWASP Secure Coding https://www.owasp.org/index.php/Secure_Coding_Cheat_Sheet
PAS 754 British Standard PAS 754:2014. Software Trustworthiness. Governance and
management. Specification.
http://shop.bsigroup.com/ProductDetail?pid=000000000030284608
Testing
OWASP Testing Guide https://www.owasp.org/index.php/OWASP_Testing_Project
Hardening
National Cyber Security Guidance.
Centre (NCSC) https://www.ncsc.gov.uk/guidance
National Institute of NIST Special Publication (SP-800) series
Standards and Technology http://csrc.nist.gov/publications/PubsSPs.html
(NIST)
Center for Internet CIS Security Benchmarks
Security (CIS) https://benchmarks.cisecurity.org/
Department of Defence Security Technical Implementation Guides (STIGs)
(DoD) http://iase.disa.mil/stigs/Pages/index.aspx

Independent Assurance
ISO/IEC 15408 ISO/IEC 15408-1:2009. Information technology -- Security techniques -- Evaluation
criteria for IT security -- Part 1: Introduction and general model.
ISO/IEC 15408-2:2008. Information technology -- Security techniques -- Evaluation
criteria for IT security -- Part 2: Security functional components.
ISO/IEC 15408-3:2008. Information technology -- Security techniques -- Evaluation
criteria for IT security -- Part 3: Security assurance components
CC Certified Products List https://www.commoncriteriaportal.org/products/
CPA Commercial Product Assurance scheme run by NCSC.
https://www.ncsc.gov.uk/document/cpa-scheme-library
CPA Security Security Characteristics published by NCSC.
Characteristics. https://www.ncsc.gov.uk/document/security-characteristics-collection
CPA Certified Products https://www.ncsc.gov.uk/index/certified-

product?f[0]=field_assurance_scheme%3A226&f[1]=field_assurance_status%3AAs
sured
CTAS CTAS Principles and Methodology.
https://www.ncsc.gov.uk/documents/ctas-principles-and-methodology
Cyber Essentials https://www.cyberaware.gov.uk/cyberessentials/
FIPS 140-2 Federal Information Processing Standards Publication - Security Requirements For
Cryptographic Modules (issue 2) May 25, 2001. Published by NIST
http://csrc.nist.gov/groups/STM/cmvp/standards.html#02
Validated FIPS 140-1 and Published by NIST.
FIPS 140-2 Cryptographic http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm
Modules
CAPS https://www.ncsc.gov.uk/articles/information-about-caps
Deployment and Release Management

ITIL https://www.axelos.com/best-practice-solutions/itil/what-is-itil
Patch Management
NIST SP 800-40 NIST Special Publication 800-40 Revision 3. Guide to Enterprise Patch
Management Technologies. July 2013
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r3.pdf
Change Management
ITIL https://www.axelos.com/best-practice-solutions/itil/what-is-itil

Data Security Lifecycle
Data Security Lifecycle Data Security Lifecycle 2.0.
https://www.securosis.com/blog/data-security-lifecycle-2.0

2.7. Operational Compliance
In this section we are going to look at various types of techniques that organisations can implement and
invoke to establish whether their ISMS is being effectively and efficiently operated and managed, whilst
complying with relevant legal, statutory and regulations. Relevant regulations and legislation will define
what policies and security controls should be implemented within the ISMS. Independent audits can
establish whether the business and the corresponding ISMS is compliant.
Compliance monitoring allows an organisation to monitor the security controls and associated policies,
especially those that have been defined by the relevant regulatory framework or legal requirements.
Protective monitoring allows an organisation to monitor the system as well as the technical controls.
Any non-compliance detected can be fed into the compliance monitoring process. Both compliance
monitoring and protective monitoring may detect security events – in which case they will be handled
by the incident management process.
Figure 31 illustrates the inter-relationship between these techniques.
Figure 31 - Compliance and Protective Monitoring
2.7.1. Auditing
In ISO/IEC 27000 audit is defined as:
“Systematic, independent and documented process for obtaining audit evidence and evaluating
it objectively to determine the extent to which the audit criteria are fulfilled.”

There are actually two types of audit – an internal audit and an external audit. However, in both cases
they need to be performed by independent teams. Many organisations have internal audit teams
although usually they are not focused just on security. In fact security is just a small part of what they
perform.
Audits are performed to ascertain the validity and reliability of information; also to provide an
assessment of a system's security controls. The goal of an audit is to express an opinion of the
organisation or system in question. It is very similar to going through a checklist of security controls and
management processes to establish that they have been implemented and are effective. Usually the
audit teams will audit a system or organisation against a standard, such as ISO/IEC 27001. The standards
do not have to purely about security. For instance the Sarbanes–Oxley Act in the US requires
compliance audits. This US Act protect shareholders and the general public from accounting errors and
fraudulent practices in the enterprise, as well as improve the accuracy of corporate disclosures. Whilst
compliance audits for the Sarbanes–Oxley Act are mainly concerning with accounting and financial
statements it does require the auditors to look at security controls. A compliance audit is sometimes
referred to as a compliance gap analysis.
ISO/IEC 27001 does require compliant organisations to conduct internal audits at planned intervals to
provide information on whether the information security management system conforms to the
organisation’s own requirements for its ISMS; and it has been effectively implemented and maintained.
More details on ISO/IEC 27001 audits and certifications can be found in section 2.3.2. The processes and
requirements for performing ISO/IEC 27001 audits or certifications can be found in ISO/IEC 27006.
The Payment Card Industry Data Security Standard (PCI DSS) requires validation of compliance annually.
This is usually performed by an external Qualified Security Assessor (QSA) or by an Internal Security
Assessor (ISA) that creates a Report on Compliance (ROC) for organisations handling large volumes of
credit card transactions. For organisation handling small volumes it is possible to submit a Self-
Assessment Questionnaire (SAQ).
Many organisations audit their third party suppliers. For instance, cloud service providers. The
standards they use could be ones their have devised themselves, a particular industry standard or based
on standards such as ISO/IEC 27001 or the Payment Card Industry Data Security Standard.
2.7.2. Compliance Monitoring

Compliance monitoring defines and implements processes to verify on-going conformance to security
and regulatory requirements. This is accomplished through undertaking security compliance checks
against technical, physical, procedural and personnel controls using appropriate methodologies and
technologies. As we will describe in the next section protective monitoring can assist in this. The
objective of compliance monitoring is fundamentally operational. It is assessing whether all activities
are carried out in compliance with the relevant regulatory requirements with appropriate policy and
procedures in place and being adhered to.
The organisation’s business and country will dictate the legislation and regulations they should, and in
many cases must, adhere to. We covered many of these in section 2.5.
If an organisation is subject to a compliance scheme, it means the business is bound, usually by contract
or law, to follow rules set by external bodies. Failure to adhere to a compliance program can have
severe consequences, specifically
• Withdrawal or suspension of a business service.
• Externally defined remediation programs.
• Substantial fines.
• Investigation.
• In extreme cases, criminal liability (potentially against individuals rather than just the organisation).
Organisations often discover that adhering to a compliance scheme does generate a number of
benefits, including:
• Reducing the risk of security incidents, saving costs associated with incident response.
• Protecting reputation, when risks are managed more effectively.
• Improving incident response.
• Providing evidence of good governance and risk management.
The compliance monitoring function provides an on-going oversight on the implementation of the
organisation’s policies and security controls. Compliance monitoring is often a combination of manual
checklists as well as IT controls. An example of a manual checklist is looking at the recent new
employees to establish whether they had an employment check, received induction training and signed
an acceptable use policy.
A SIEM platform (which will be discussed in the next section) can also be leveraged for monitoring.
Compliance helps the organisation reduce risk, and the monitoring process can uncover gaps, but
ultimately it is the compliance owner that is accountable for signoff.
Compliance monitoring ensures that evidence is produced demonstrating the effective implementation
of policies, procedures, and controls. It is essential that evidence be collected in a consistent and
comprehensible fashion. If certification is a requirement for the organisation, such as against ISO/IEC
27001, then this documentation can support the certification process.
2.7.3. Protective Monitoring

Protective monitoring enables the efficient, automatic monitoring, alerting and reporting of system
changes and significant system events. It is really a management function, supported by systems and
technology allowing an organisation to monitor how information systems are used, misused or
compromised. One of the key things it is does is to provide an organisation with situational awareness
ensuring the organisation is provided with a near real-time feed of information regarding the status of
systems. In order to support protective monitoring most large organisations have implemented a
Security Operations Centre (SOC). A SOC collates all appropriate audit event information from the
system and works with the CSIRT to create a comprehensive infrastructure for managing security
operations including support for incident management. For large organisations the SOC would be
manned 24x7. In smaller organisations that cannot afford to set-up and maintain a 24/7 SOC some
service providers do provide an outsourced capability.
All audit events generated by PCs, PDAs, servers, applications, firewalls, IDS and network devices, such
as routers and switches, would be directed in real-time into the SOC. Figure 32 illustrates this point.

Figure 32 - Security Operations Centre
Typically the SOC would use a Security Information and Event Management (SIEM) platform to provide
real-time analysis of the collected audit events. SIEMs can also be used to assist in post-event forensic
investigations.
Most SIEM platforms combine log management with a powerful analytics engine. The analytics engine
can run complex rules and advanced correlations against incoming event data. Therefore, they can
detect patterns of behaviour that may be undetectable by boundary devices or on single end user
devices. It can also look for events that have been detected across multiple devices, which may signal an
emerging threat.
A SIEM can be used to look for the following:
• Detection of a brute force attack.
• Detection of malware activity.
• Detection of suspicious user behaviour
• Suspicious device behaviour
• Unauthorised system changes
As an example of one of the rules you could configure can be found below when the SIEM is looking for
repeating login attempts:
Goal: Early warning for brute force attacks and password guessing.
Trigger: Alert on 5 or more failed logins in 1 minute on a single user identifier.
Event Sources: Active Directory, Unix/Linux hosts, applications, network switches,
network routers, firewalls.
Most regulatory guidelines require some form of audit event collection and log management function.
SIEMs provide a mechanism to rapidly and easily deploy an audit event collection infrastructure that
directly supports this requirement, and allows instant access to recent audit data, as well as archived log
data. A SIEM can be used to produce reports of various types, including for management. Hence a SIEM
assists in performing compliance monitoring.
Many large organisation also have a Network Operations Centre (NOC). A NOC is used to manage a
network as well as monitoring its health.
2.7.4. Incident Management
All organisations have to deal with information security incidents – no matter how perfect the security
controls or security awareness programs. Information security incidents come as network attacks from
hackers, virus outbreaks or simply from someone not following procedures. The impact of such an
incident might be a confidentiality breach or maybe a denial of service attack. There may be no harm
done, but an incident can still serve the purpose of highlighting a lack of security awareness or a flaw in
the implementation of security controls.
Information security incident management is concerned with the processes for detecting, reporting,
assessing, responding to, dealing with, and learning from information security incidents. An information
security event could be reported by a member of staff or it could have been detected by protective
monitoring.
Figure 33 shows information security incidents in the context of the risk wheel we showed in the
previous risk management section. A threat exploits vulnerabilities in information systems causing the
occurrence of information security events and thus potentially causing information security incidents to
information assets exposed by the vulnerabilities. Information security incidents compromise the
operations of an organisation.
Figure 33 - Incident Management and Risk
Objectives of incident management should be as follows:

• Information security events are detected and dealt with efficiently. A process should be in place to
decide whether a particular information security event should be classified as an information
security incident.
• Information security incidents are assessed and responded to in the most appropriate and efficient
manner.
• Adverse effects of information security incidents on the organisation and its operations are
minimised by appropriate use of security controls as part of incident response.
• Appropriate links with crisis management and business continuity management should be
established as necessary.
• Security vulnerabilities are assessed and dealt with appropriately to prevent or reduce information
security incidents.
• Lessons are learnt quickly from information security incidents, vulnerabilities and their
management. This feedback mechanism is intended to increase the chances of preventing future
information security incidents from occurring, improve the implementation and use of security
controls, and improve the overall information security incident management plan.
ISO/IEC 27035 defines that there are five distinct phases in incident management, as shown in the
following figure:
Figure 34 - Phases of Incident Management
In more detail the five phases consist of:

• Plan and Prepare: Development of an incident management policy and plan. Creation of Forensics
Readiness Plan. Creation of a Computer Security Incident Response Team. Develop relationships
with internal and external organisations. Create and hold security awareness briefings and training.
Create incident reporting form and related process. Testing of incident management plan.
• Detection and Reporting: Detection and alerting of anomalous, suspicious or malicious activity (as
described in the prevision section on protective monitoring). Collection of threat intelligence.
Detect and report occurrence of an information security event or existence of a vulnerability.
Preservation of digital evidence and it is gathered as required and stored securely.
• Assessment and Decision: Determine whether the information security event should be classified as
an information security incident. Collect all required information about the information security
incident.
• Responses: Allocate duties to appropriate personnel to help respond to the information security
incident – including any resulting information security investigation. Escalate through the
organisation as required. Call in digital forensics experts as necessary depending on the security
incident – potentially from law enforcement. Share details of the incident with other external
parties as required – including with WARP or other CSIRTs. All information pertaining to the incident
should be stored.
• Lessons Learnt: Identify lessons learnt from information security incident and vulnerabilities. Make
improvements to security controls implementation as required. Review how effective existing
processes and procedures are and update if necessary. Update incident management plan if
required
The incident reporting form should be designed as a pro-forma and it should contain all the relevant
information needed to successfully investigate, assess and close down the incident. Many organisations
have the reporting form, the incident management policy and plan on their intranet. The incident report
should contain a succinct summary of exactly what the security incident was and what its effects were,
following the typical: who, what, where, when and how, principle.

Forensics concerns the gathering of digital evidence that could be used in a court of law, employment
tribunal or similar. A key concept in digital forensics (or any form of forensics) is the continuity of
evidence, which is sometimes referred to as chain of custody. Continuity of evidence ensures that there
is a witnessed, written record of all of the individuals who maintained unbroken control over items of
physical or digital evidence. A key principle of gathering digital evidence is that no action should change
data held on a computer or storage media which may subsequently be relied upon in court. For hard
disk drives this means taking a secure copy of the original disk drive that potentially holds digital
evidence that could be used in a court proceeding.
Digital Forensics support is not required for every incident. However, until you start an assessment of an
incident it is not always apparent. To undertake a forensics investigation is a specialist skill – with few
organisations having an in-house capability. During the Plan and Prepare phase this should be taken
into account and ideally a Forensics Readiness Plan created. Part of the plan would be who to contact
externally if you need to access forensics expertise.
Auditing
Requirements for bodies providing audit and certification of information
security management systems.
PCI DSS Payment Card Industry (PCI). Data Security Standard Requirements and
Security Assessment Procedures.
Compliance Monitoring
PCI DSS Payment Card Industry (PCI). Data Security Standard Requirements and
Security Assessment Procedures.
COBIT Control Objectives for Information and Related Technologies
https://www.isaca.org/COBIT/Pages/default.aspx
SOX The Sarbanes–Oxley Act of 2002, also known as the "Public Company
Accounting Reform and Investor Protection Act" and "Corporate and Auditing
Accountability, Responsibility, and Transparency Act"
https://www.gpo.gov/fdsys/pkg/PLAW-107publ204/pdf/PLAW-
107publ204.pdf
Protective Monitoring
NONE

Incident Management
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

3. Knowledge Levels
In this section we take the principles stated in the IISP Skills Framework plus the requirements for Level
1 and Level 2 and then expand upon the requirements for knowledge and understanding.
In the following pages we provide a table for each Skill Area within each Security Discipline in the IISP
Skills Framework with each table containing:
• A restatement of the principle of the Skill Area.

• The level 1 and level 2 definitions for that Skill Area taken from the IISP Skills Framework.
• An expansion of the level 1 and level 2 definitions in particular defining what a person should be
able to explain or describe at that level.
You can find the definitions for the various terms in the Common Terms section using the hyperlinks.
Figure 35 summaries the Security Disciplines within the IISP Framework, with each Security Discipline
being divided into one or more of Skill Areas.
Figure 35 - IISP Skills Framework

Security Disciple Information Security Governance and Management
Skill Area Governance Ref: A1
Directs, oversees, designs. Implements or operates within the set of multi-disciplinary structures, policies,
procedures, processes and controls implemented to manage Cyber and Information Security at an Enterprise
level, supporting an organisation's immediate and future regulatory, legal, risk, environmental and operational
requirements and ensuring compliance with those requirements
Level 1 Level 2
Can describe the principles of Information Security Can explain the basic principles of Information Security
Governance. Governance and how it applies within an organisation.
Can list the potential impacts that occur where poor
Information Governance has been observed.
They shall be able to describe: They shall be able to explain:
• The importance of governance structures. • Approaches for establishing and monitoring good
• Information governance within an organisation governance within an organisation.
and key bodies and membership. • The importance of Board level support and
responsibilities.
• Key governance legislation/regulation e.g. UK
Companies Act.
• Statutory, regulatory and advisory requirements.
• The potential business impact of poor information
governance.

Skill Area Policy & Standards Ref: A2
Directs, develops or maintains organisational Cyber and Information Security policies, standards and processes
using recognised standards (e.g. the ISO/IEC 27000 family, the Security Policy Framework) where appropriate.
Applies recognised Cyber and Information Security standards and policies within an organisation, programme,
project or operation.
Level 1 Level 2
Can describe the main policies and standards relevant Can explain the main concepts of the main
to the Information Security discipline and/or Information Security policies and standards. This might
organisation. include experience of applying knowledge of
Information Security policies and standards in a
training or academic environment, for example
through participation in syndicate exercises,
undertaking practical exercises, and/or passing a test
or examination.
They shall be able to list: They shall be able to explain:

• Security policies in use by a typical organisation. • In detail some of a typical organisation’s policies
• Key internal and external security standards and procedures - and their purpose.
relevant to an organisation e.g. ISO/IEC 27000 • The role of any standards adopted by an
family. organisation e.g. ISO/IEC 27000 family.
The difference between standards, policies, guidelines
and procedures.

Skill Area Information Security Ref: A3
Strategy
Directs, develops or maintains plans and processes to manage Cyber and Information Security risks
appropriately and effectively, whilst complying with legal, statutory, contractual, and business requirements.
Level 1 Level 2
Can describe the purpose of Information Security Can explain the basic principles of Information Security
strategies and how they can benefit the business. Strategy and how it applies within an organisation.
They shall be able to name one security strategy in an They shall be able to explain the purpose of security
organisation. strategies and potential business benefits.
They shall be able to describe the purpose of a They shall be able to explain the different elements in
security strategy. a typical strategy.
They shall be able to explain the business benefits of
one strategy.
They shall be able to explain the factors influencing
the development of a strategy.

Skill Area Innovation & Business Ref: A4
Improvement
Recognises potential strategic application of Cyber and Information Security and initiates investigation and
development of innovative methods of protecting information assets, to the benefit of the organisation and the
interface between business and information security.
Exploits opportunities for introducing more effective secure business and operational processes.
Level 1 Level 2
Can list the potential impacts of poor Information Can explain how good Cyber and Information Security
Security and the business benefits of Information strategies and processes can benefit the business, and
Security. provide examples.
They shall be able to recognise potential impact on a They shall be able to explain the business benefits of
business due to poor information security. improving information security and provide several
examples.
They shall be able to explain how implementing an
ISMS can provide business improvement.
They shall be able to explain how a security strategy
could benefit a business.

Skill Area Behavioural Change Ref: A5
Identifies Cyber and Information Security awareness, training and culture management needs in line with
security strategy, business needs and strategic direction, and gains management commitment and resources to
support these needs.
Manages the development or delivery of Cyber and Information Security awareness and training, behavioural
analysis programmes and/or security culture management programmes, applying analysis of human factors as
appropriate.
Level 1 Level 2
Recognises the role of Information Security awareness Can explain the concepts of Information Security
and training, and can list the benefits of behavioural awareness and security culture management and give
analysis and security culture management in examples of good practice.
maintaining good IS.
They shall be able to list several security policies that They shall be able to explain security awareness
all users should be aware of. training that should be present in a typical
They shall be able to list several examples of where organisation.
poor security awareness caused a business impact They shall be able to explain to non-IS staff the
They shall be able to describe security weaknesses in a importance of security awareness and the potential
typical organisation. impacts to the business.
They shall be able to explain different techniques for
delivering and measuring behavioural change.

Skill Area Legal & Regulatory Ref: A6
Environment and
Compliance
Understands the legal and regulatory environment within which the business operates.
Ensures that Information Security Governance arrangements are appropriate.
Ensures that the organisation complies with legal and regulatory requirements.
Level 1 Level 2
Can describe the major legislative and regulatory Can explain the principal requirements of major
instruments relevant to Information Security (e.g. Data legislation and regulations relevant to Information
Protection Act, privacy, healthcare, ISO/IEC 27000 Security, and those legal and regulatory instruments
family) and legislation and regulation relevant to own relevant to own work.
work.
They shall be able to list the major applicable They shall be able to explain:
legislation and regulations affecting an example • In reasonable detail all of the applicable
organisation and describe their overall purpose. legislation and regulation pertinent to an
They shall be able to name or describe who in an organisation.
organisation they should go to consult about
• The consequences of non-compliance with major
legislation and regulation.
legislation and regulation.
They should be able to explain when an organisation is
non-compliant with major legislation and regulation.
They shall be able to explain how legislation or
regulations could influence governance arrangements
within an organisation.

Skill Area Third Party Management Ref: A7
Identifies and advises on the technical, physical, personnel and procedural risks associated with third party
relationships, including systems development and maintenance, outsourced service providers and business
partners.
Assesses the level of confidence that third party Cyber and Information Security capabilities/services operate as
defined.
Level 1 Level 2
Recognises the need for organisations to manage the Can explain the main security issues associated with
Information Security of third parties and can describe third party relationships and how these can be
the impacts of failure to do so. managed effectively.
They shall be able to describe the consequences to an They shall be able to explain the relevant legislation
organisation of failing to manage third parties and regulations that third parties must comply with –
effectively. and why.
They shall be able to list the relevant legislation and They shall be able to explain the relevant polices and
regulations that third parties must comply with. standards that third parties must comply with – and
They shall be able to list the relevant polices and why.
standards that third parties should comply with. They shall be able to summarise the relevant
contractual terms and conditions of an Information
Security nature in third party contracts in their
business area.

Security Disciple Threat Assessment and Information Risk Management
Skill Area Threat Intelligence and Ref: B1
Assessment, and Threat
Modelling
Assesses and validates information on current and potential Cyber and Information Security threats to the
business, analysing trends and highlighting information security issues relevant to the organisation, including
Security Analytics for Big Data.
Processes, collates and exploits data, taking into account its relevance and reliability to develop and maintain
‘situational awareness’.
Predicts and prioritises threats to an organisation and their methods of attack.
Analyses the significance and implication of processed intelligence to identify significant trends, potential threat
agents and their capabilities.
Predicts and prioritises threats to an organisation and their methods of attack.
Uses human factor analysis in the assessment of threats.
Uses threat intelligence to develop attack trees.
Prepares and disseminates intelligence reports providing threat indicators and warnings.
Level 1 Level 2
Can describe the concepts and principles of threat Can explain the principles of threat intelligence,
intelligence, modelling and assessment. modelling and assessment. This might include
experience of applying threat intelligence, modelling
and assessment principles in a training or academic
environment, for example through participation in
syndicate exercises, undertaking practical exercises,
and/or passing a test or examination.
They shall be able to describe the purpose of threat They shall be able to describe different types of threat
modelling. models. – including attack trees.
They shall be able to describe the concept of a threat They shall be able to describe a number of threats to
and a threat agent. an organisation.
They shall be able to describe a number of threat
agents to an organisation.
They shall be able to explain the role of threat
intelligence and threat modelling in undertaking risk
assessments.

Skill Area Risk Assessment Ref: B2
Identifies and assesses information assets; uses this information and relevant threat assessments, business
impacts, business benefits and costs to conduct risk assessments and identify potential vulnerabilities.
Level 1 Level 2
Can describe the concepts and principles of risk Can explain the principles of risk assessment. This
assessment. might include experience of applying risk assessment
principles in a training or academic environment, for
example through participation in syndicate exercises,
or examination.
They shall be able to describe risk components such They shall be able to explain in detail at least one risk
as: information risk, asset, threat agent, vulnerability, assessment methodology.
impact and likelihood. They shall be to explain sources of threat to an
They shall be able to list at least one risk management organisation.
methodology. They shall be able to explain the role of threat
They shall be able to list sources of information on intelligence and threat modelling in undertaking risk
threats and vulnerabilities. assessments.
They shall be able explain different types of
vulnerabilities within a typical organisation

Skill Area Information Risk Ref: B3
Management
Develops Cyber and Information Security risk management strategies and controls, taking into account business
needs and risk assessments, and balancing technical, physical, procedural and personnel controls.
Level 1 Level 2
Can describe the concepts and principles of Can explain the principles of risk management. This
Information Security risk management. might include experience of applying risk management
principles in a training or academic environment, for
example through participation in syndicate exercises,
or examination.
They shall be able to list different types of controls to They shall be able to explain in detail one risk
manage risks. management methodology and the associated
They shall be able to describe the difference between processes.
technical, physical, procedural and personnel controls. They shall be able to explain the following terms and
They shall be able to describe the difference between their relationship:
risk assessment and risk treatment. • Residual Risk.
They shall be able to name at least one risk • Risk Acceptance.
management methodology. • Risk Avoidance.
• Risk Retention.
• Risk Sharing.
• Risk Tolerance.
• Risk Appetite.
They shall be able to explain different types of
controls to mitigate risks

Security Disciple Implementing Secure Systems
Skill Area Enterprise Security Ref: C1
Architecture
Working with Enterprise Architects, takes customer security requirements and assists in the development of an
Enterprise Security Architecture.
Interprets relevant security policies and threat/risk profiles into secure architectural solutions that mitigate the
risks and conform to legislation and relate to business needs.
Applies common architectural frameworks (e.g. TOGAF, SABSA).
Presents security architecture solutions as a view within broader IT architectures.
Maintains awareness of the security advantages and vulnerabilities of common products and technologies.
Designs robust and fault-tolerant security mechanisms and components appropriate to the perceived risks.
Develops and implements appropriate methodologies, templates, patterns and frameworks.
Level 1 Level 2
Can describe the concept of an enterprise Information Can explain the concept of an enterprise Information
Security architecture and how it can be used to reduce Security architecture, how it relates to business needs
information risk. and how it can be used to reduce information risk. This
might include experience of applying these concepts in
a training or academic environment, for example
or examination.
Can describe how an enterprise security architecture They shall be able to explain at least one common
can relate to business needs. architectural framework and provide pros and cons of
They shall be able to name at least one common that framework.
architectural framework. They shall be able to describe at least one design
They shall be able to name at least one design pattern and explain the business benefits.
pattern. They shall be able to explain how legislation,
regulations and policies can influence an Enterprise
Security Architecture.

Skill Area Technical Security Ref: C2
Architecture
Contributes to the development of Computer, Network and Storage Security Architecture, incorporating
hosting, infrastructure applications and cloud based solutions as covered by the role of Chief Security Architect.
Interprets relevant security policies and threat/risk profiles into secure architectural solutions that mitigate the
risks and conform to legislation and relate to business needs.
Presents security architecture solutions as a view within broader IT architectures.
Applies security architecture principles to networks, IT systems, Control Systems (e.g. SCADA, ICS),
infrastructures and products.
Devises standard solutions that address requirements delivering specific security functionality whether for a
business solution or for a product.
Maintains awareness of the security advantages and vulnerabilities of common products and technologies.
Designs robust and fault-tolerant security mechanisms and components appropriate to the perceived risks.
Uses appropriate methodologies and frameworks.
Level 1 Level 2
Can describe the principles of a technical security Can explain the principles of a computer system,
architecture and how these can be used to reduce network or storage security architecture and how
information risk. these can be used to reduce information risk. This
might include experience of applying these concepts in
or examination.
They shall be able to list a number of different They shall be able to explain a wide range of different
technical security controls and describe their purpose. technical security techniques, mechanisms and
They shall be able to name several important security technologies, including:
design principles. • Access control.
They shall be able to recognise the importance of • Auditing and alerting.
secure configuration and hardening and their role in • Content control.
building secure systems.
• Cryptography.
• Detection.
• Identification and Authentication.
• Security Management.
• Trusted communications.
They shall be able to explain at least one design
pattern.
They shall be able to explain a number of different
security design principles such as:
• Defence in depth.
• Compartmentalise.
• Least Privilege.
• Separation of Duties.
• Secure the Weakest Link.
• Fail Securely.
• Principle of Least Privilege.
• Minimisation.
They shall be able to explain the purpose of secure
configuration and hardening and their role in building
secure systems.

Skill Area Secure Development Ref: C3
Implements secure systems, products and components using an appropriate methodology.
Defines and/or implements secure development standards and practices including, where relevant, formal
methods.
Selects and/or implements appropriate test strategies.
Defines and/or implements appropriate secure change and fault management processes.
Verifies that a developed component, product or system meets its security criteria (requirements and/or policy,
standards & procedures).
Specifies and/or implements processes that maintain the required level of security of a component, product, or
system through its lifecycle.
Manages a system or component through a formal security assessment.
Level 1 Level 2
Recognises the benefits of addressing security during Can explain the benefits of addressing security during
system development and can list some of the tools, system development.
products and practices that contribute to secure Can describe some of the tools, products and practices
development. that contribute to secure development.
They shall be able to list the typical stages of a They shall be able to explain the Security
Security Development Lifecycle and the role of Development Lifecycle used within an organisation.
security within each stage: They shall be able to explain the tools in use and their
• Requirements. role in the Security Development Lifecycle.
• Design. They shall be able to explain the purpose of secure
• Implementation. coding standards.
They shall be able to explain the purpose of different
• Verification.
type of testing such as functional testing, static code
• Release.
analysis and fuzzing.
They shall be able to describe the benefits of
They shall be able to describe the personnel,
introducing security early into the development
procedural, physical, and technical security necessary
lifecycle.
for a secure development site.
They shall be able to name who in an organisation
they should go to consult about secure development
and/or what development practices are in place.
They shall be able to list a number of secure coding
standards used by an organisation.
They shall be able to describe different type of testing
such as functional testing, static code analysis and
fuzzing

Security Disciple Assurance, Audit, Compliance and Testing
Skill Area Internal and Statutory Ref: D1
Audit
Verifies that information systems and processes meet the security criteria (requirements or policy, standards
and procedures).
Assesses the business benefits of security controls.
Level 1 Level 2
Can describe the requirements for and basic principles Can explain the main principles and processes involved
involved in conducting security audits of information in conducting an audit. This might include experience
systems. of applying these principles in a training or academic
They shall be able to describe the overall process of an They shall be able to explain in detail the process of an
audit. audit.
They shall be able to list a number of standards that They shall be able to explain how an audit can test
audits can be performed against. compliance with policy, standards, procedures and
controls.
They shall be able to explain an auditing standard (e.g.
ISO/IEC 27001)

Skill Area Compliance Monitoring Ref: D2
and Controls Testing
Defines and implements processes to verify on-going conformance to security and/or regulatory requirements.
Carries out security compliance checks in accordance with an appropriate methodology.
This Skill covers compliance checks and tests against technical, physical, procedural and personnel controls.
Level 1 Level 2
Can describe the benefits of compliance monitoring Can explain the main principles and processes involved
and list the common compliance monitoring in conducting a compliance monitoring exercise. This
standards, e.g. ISO/IEC 27001, PCI/DSS, IAMM. might include experience of applying these principles
in a training or academic environment, for example
or examination.
They shall be able to name at least one standard in They shall be able to explain in detail at least one
this area and what business areas they would be common standard in this area.
typically be applied to. They shall be able to describe how compliance
They shall be able to describe the benefits of monitoring could be achieved against different
compliance monitoring. controls.

Skill Area Security Evaluation and Ref: D3
Functionality Testing
Contributes to the security evaluation or testing of software.
Evaluates security software by analysing the design documentation and code to identify potential vulnerabilities
and testing to ascertain whether these are exploitable.
Tests the security functionality of systems or applications for correctness in line with security policies, standards
and procedures, and advises on corrective measures.
Applies recognised evaluation/testing methodologies, tools and techniques, developing new ones where
appropriate.
Assesses the robustness of a system, product or technology.
Applies commonly accepted governance practices and standards when testing in an operational environment.
Level 1 Level 2
Can describe the principal concepts of security Can explain the principal concepts of security
evaluation and functional testing to support evaluation or functional testing and how these are
Information Security. applied in practice. This might include experience of
applying these concepts in a training or academic
Recognises that security testing cannot guarantee They shall be able to explain the typical structure of a
security. security test plan.
They shall be able to describe the difference between They shall be able to explain a number of tools in use
white box and black box testing. by an organisation.
They shall be able to recognise the difference They shall be able to explain the purpose of a number
between positive and negative testing. of independent assurance schemes.
They shall be able to recognise the difference
between testing application functionality, code,
vulnerability assessments and penetration testing.
They shall be able to describe the purpose of
independent assurance.
They shall be able to name at least one independent
assurance scheme.

Skill Area Penetration Testing Ref: D4
Contributes to the scoping and conduct of vulnerability assessments and tests for public domain vulnerabilities
and assessment of the potential for exploitation, where appropriate by conducting exploits. Reports potential
issues and mitigation options.
Contributes to the review and interpretation of reports. Co-ordinates and manages Remediation Action Plan
(RAP) responses
This skill covers, but is not limited to, penetration testing against networks and infrastructures, web
applications, mobile devices and control systems.
Level 1 Level 2
Can describe the principles of penetration testing and Can explain the principles, the main components of an
list the common types of penetration test – e.g. infrastructure penetration test and the high level
infrastructure, web applications, etc. Recognises the processes involved. This might include recognised
difference between a vulnerability assessment and a training in infrastructure penetration testing involving
penetration test practical exercises in using these skills.
They shall be able to recognise the difference They shall be able to explain the structure and content
between testing application functionality, code, of a typical scoping document.
vulnerability assessments and penetration testing. They shall be able to explain the structure and content
They shall be able to describe the main stages of a of a typical Remediation Action Plan.
test, e.g. scope, test, report, fix, re-test. They shall be able to describe the functionality of
They shall be able to name a few of the more common several testing tools and explain what type of tools
testing tools (e.g. nmap/Zenmap, Nessus, Metasploit, would be used in what situation.
Burp Suite).

Security Disciple Operational Security Management
Skill Area Secure Operations Ref: E1
Management
Establishes processes for maintaining the security of information throughout its existence including establishing
and maintaining Security Operating Procedures in accordance with security policies, standards and procedures.
Coordinates penetration and other testing on information processes.
Assesses and responds to new technical, physical, personnel or procedural vulnerabilities. Engages with the
Change Management process to ensure that vulnerabilities are mediated.
Manages the implementation of information security programmes, and co-ordinates security activities across
the organisation
Level 1 Level 2
Recognises the need for secure management of Understands and can explain the main processes for
Information Systems and can list some of the types of managing the security of information systems. This
incident which could occur is this is not done. might include experience of applying these concepts in
or examination.
They shall be able to describe the potential for They shall be able to explain most of the security
security incidents if systems and processes are not operating procedures within an organisation and
managed securely. explain their purpose.
They shall be able to name several security operating They shall be able to explain what a typical security
procedures within an organisation and summarise operating procedure looks like.
their purpose. They shall be able to explain the common causes of
They shall be able to describe the process of reporting security incidents and how security operating
security incidents within an organisation. procedures help to mitigate these risks.
They shall be able to describe the purpose of patch They shall be able to explain the purpose of
management, change management and vulnerability management.
deployment/release management. They shall be able to explain the role of vulnerability
assessments and penetration testing in maintaining
the security of a system.
They shall be able to explain patch management,
change management and deployment/release
management processes.

Security Disciple Operational Security Management
Skill Area Secure Operations & Ref: E2
Service Delivery
Securely configures and maintains information, control and communications equipments in accordance with
relevant security policies, standards and guidelines. This includes the configuration of Information Security
devices (e.g. firewalls) and protective monitoring tools (e.g. SIEM).
Implements security policy (e.g. patching policies) and Security Operating Procedures in respect of system
and/or network management.
Undertakes routine technical vulnerability assessments.
Maintains security records and documentation in accordance with Security Operating Procedures.
Administers logical and physical user access rights.
Monitors processes for violations of relevant security policies (e.g. acceptable use, security, etc.).
Level 1 Level 2
Recognises the need for information systems and Can explain the main principles of secure configuration
services to be operated securely and can list some of of security components and devices, including firewalls
the main policies and practices involved in achieving and protective monitoring tools (e.g. SIEM). This might
this. include experience of applying these principles in a
training or academic environment, for example
or examination.
They shall be able to name who in an organisation They shall be able to list most of the standards in the
they should go to consult about secure configuration organisation for secure configuration of systems and
of various systems and devices. devices.
They shall be able to name a few of the more common They shall be able to explain the principles of secure
vulnerability assessment tools (e.g. nmap/Zenmap, configuration.
Nessus). They shall be able to explain the purpose and
They shall be able to describe what a typical principles of protective monitoring.
organisation’s patching policy would look like. They shall be able to explain the functionality of
They shall be able to describe what a typical several vulnerability assessment tools.
organisation’s antivirus signature update policy would They shall be able to explain an organisation’s
look like. patching policy.
They shall be able to recognise non-compliance of They shall be able to explain the antivirus signature
most security policies. update policy.
They shall be able to explain why non-compliance of a
particular security policy has occurred.
They shall able to explain the difference between
network routers, network switches and stateful
firewalls.

Security Disciple Incident Management, Investigation and Digital Forensics
Skill Area Intrusion Detection and Ref: F1
Analysis
Monitors network and system activity to identify potential intrusion or other anomalous behaviour. Analyses
the information and initiates an appropriate response, escalating as necessary.
Uses security analytics, including the outputs from intelligence analysis, predictive research and root cause
analysis in order to search for and detect potential breaches or identify recognised indicators and warnings.
Monitors, collates and filters external vulnerability reports for organisational relevance, ensuring that relevant
vulnerabilities are rectified through formal change processes.
Ensures that disclosure processes are put in place to restrict the knowledge of new vulnerabilities until
appropriate remediation or mitigation is available.
Produces warning material in a manner that is both timely and intelligible to the target audience(s).
Level 1 Level 2
Recognises the need for intrusion detection and Can explain the basic principles involved in monitoring
analysis to maintain Information Security and can network and system activity for anomalous behaviour
describe the difference between Intrusion prevention and how the results can be used. This might include
and intrusion detection. experience of applying these principles in a training or
academic environment, for example through
participation in syndicate exercises, undertaking
practical exercises, and/or passing a test or
examination.
They shall be able to explain a number of sources of
vulnerability reports relevant to an organisation.
They shall be able to list several sources of external They shall be able to interpret external vulnerability
vulnerability reports relevant to an organisation. reports and establish whether they are relevant to the
They shall be able to name who in an organisation organisation.
they should go to consult about a new vulnerability. They shall be able to explain the process for reporting
They shall be able to describe the process for a new vulnerability.
identifying, analysing and reporting potential They shall be able to explain how anomalous network
intrusions. or system activity could be detected using protective
They shall be able to describe protective monitoring. monitoring.
They shall be able to explain the process of creating
warning material and how it should be tailored for the
target audience.
They shall be able to explain the difference between
NIDS, NIPS, HIDS and HIPS.

Skill Area Incident Management, Ref: F2
Incident Investigation and
Response
Engages with the overall organisation Incident Management process to ensure that Information Security
incidents are handled appropriately.
Defines and implements processes and procedures for detecting and investigating Information Security
incidents.
Establishes and maintains a Computer Security Emergency Response Team or similar to deal with Information
Security incidents.
Working within the legal constraints imposed by the jurisdictions in which an organisation operates, carries out
an investigation into a security incident using all relevant sources of information.
Assesses the need for Forensic activity, and coordinates the activities of specialist Forensic personnel within the
overall response activities, engaging with the relevant organisational processes to ensure that Forensic services
are deployed appropriately.
Provides a full Information Security investigation capability where third parties, managed service providers, etc.
are involved.
Co-ordinates the response to an Information Security incident.
Level 1 Level 2
Recognises the benefits of managing Information Can explain the basic principles of incident
Security incidents and can describe the basic principles management, investigation and response. Can explain
of incident management, investigation and response. how incident management can operate effectively,
benefiting the organisation.
Understands the need to preserve evidence to support
any investigation and can explain the basic principles
involved.
Can describe how incident management can operate They shall be able to explain in detail the incident
effectively, benefiting the organisation. reporting process.
Understands the need to preserve evidence to They shall be able to explain the processes,
support any investigation. procedures, methods, tools and techniques used to
They shall be able to describe what is meant by an conduct incident management activities within the
information security incident. organisation.
They shall be able to describe what is meant by an They shall be able to explain the processes,
information security investigation. procedures, methods, tools and techniques used to
They shall be able to describe potential business conduct investigations.
impacts of security incidents upon confidentiality, They shall be able to explain the role of digital
integrity, availability and reputation in their forensics in conducting investigations.
organisation.
They shall be able to describe the main stages of
incident management, e.g. e.g. identify, contain,
cleanse, recovery, close.
They shall be able to name who in their organisation
they should report to if a security incident occurs, e.g.
Computer Security Emergency Response Team.

Skill Area Forensics Ref: F3
Secures the scene and captures evidence in accordance with legal guidelines and in the most effective manner
to minimise disruption to the business and maintaining evidential weight, using specialist equipments as
appropriate.
Analyses the evidence to identify breaches of policy, regulation or law, including the presence of malware.
Presents evidence as appropriate, acting as an expert witness if necessary.
Level 1 Level 2
Can describe the basic principles of digital forensics Can explain the basic principles of digital forensics,
and recognises the capability of forensics to support including the principles and processes surrounding
investigations. securing and analysing evidence. This might include
experience of applying these principles in a training or
academic environment, for example through
participation in syndicate exercises, undertaking
practical exercises, and/or passing a test or
examination.
They shall be able to describe what information can They shall be able to explain examples of information
be collected to support forensic examination. recoverable through forensics.
They shall be able to list possible sources of digital They shall be able to explain the term “Continuity of
forensic information. Evidence”.
They shall be able to describe the requirements to They shall be able to explain the processes,
preserve forensic evidence. procedures, methods, tools and techniques used to
They shall be able to name who in an organisation conduct forensic examinations.
they should go to arrange for a forensics examination. They shall be able to explain relevant legislation and
guidance, e.g. Data Protection Act (DPA), Regulation
of Investigatory Powers Act (RIPA).
They shall be able to explain the purpose of a
Forensics Readiness Plan.

Security Disciple Business Resilience
Skill Area Business Continuity and Ref: H1
Disaster Recovery
Planning
Contributes to defining the need for, and the development of, Business Continuity Management (BCM) and
Disaster Recovery (DR) Plans, Processes or Functions.
Level 1 Level 2
Recognises the importance of Business Continuity & Can explain and give examples of how Business
Disaster Recovery Planning to Information Security, Continuity and Disaster Recovery Planning contributes
and can list some of the potential consequences if to Information Security.
these aspects are not properly considered.
They shall be able to describe how business continuity They shall be able to explain why business continuity
planning contributes to information security and disaster recovery plans should be tested.
objectives. They shall be able to explain the: types of
They shall be able recognise the difference between IT/technology disaster scenarios that may impact an
business continuity and disaster recovery. organisation.
They shall be able to describe a number of different They shall be able to explain the different types of
business continuity threats to an organisation. disruptive events that may impact an organisation.
They shall be able to name the ISO standards relevant They shall be able to explain the structure and
to business continuity. (e.g. ISO 22301). contents of a typical business continuity policy and
They shall be able to describe the contents of a typical business continuity standard.
business continuity policy and business continuity
standard.

Skill Area Business Continuity and Ref: H2
Disaster Recovery
Management
Contributes to the implementation, operation and maintenance of BC and DR Processes or Functions.
Level 1 Level 2
Recognises the importance of Business Continuity & Can explain and give examples of how Business
Disaster Recovery management to Information Continuity and Disaster Recovery management
Security, and can list some of the potential contributes to Information Security.
consequences if these aspects are not properly
considered.
They shall be able to describe the business continuity They shall be able to explain why business continuity
management lifecycle. and disaster recovery plans should be tested.
They shall be able recognise the difference between They shall be able to explain disaster recovery options
business continuity and disaster recovery. to meet the business needs to restore individual
They shall be able to name the ISO standards relevant IT/technology systems, services and assets.
to business continuity. They shall be able to explain the business continuity
management lifecycle.
They shall be able to explain the processes in a typical
business continuity plan.

Skill Area Cyber Resilience Ref: H3
Contributes to the development and implementation processes to anticipate, recognise and defend against
changing Cyber and Information risk environments which threaten business stability, and the development and
implementation of plans to introduce an holistic culture of Information Security across an organisation aimed at
identifying and reacting promptly and effectively to incidents.
Level 1 Level 2
Can describe the principles and benefits of cyber Can explain and give examples of how Cyber Resilience
resilience. contributes to Information Security.
They shall be able to describe the different They shall be able to explain a wide number of
components of cyber resilience. potential cyber risks pertinent to their organisation.
They shall be able to describe a number of potential They shall be able to explain how the following areas
cyber risks pertinent to their organisation. contribute to making an organisation resilient against
cyber attacks:
• Threat Intelligence.
• Various technical controls.
• Security Awareness.
• Business Continuity Management.
• Incident management.

Security Disciple Information Security Research
Skill Area Research Ref: I1
Conducts original investigation in order to gain knowledge and understanding relating to Information Security.
Defines research goals and generates original and worthwhile ideas in Information Security.
Writes or presents papers, either internally or externally, on the results of research.
Contributes to the development of the employing organisation’s Information Security research policy and
participates in or supervises the work of Information Security research functions.
Develops new or improved models or theories of Information Security.
Develops new cryptographic algorithms.
Level 1 Level 2
Recognises the different types of Information Security Can describe and give examples on how research has
research within own sector. improved information security.
Can name at least one significant research paper that Can explain the role of at least one significant
contributed to information security. research paper that contributed to information
Can name at least one significant research activity that security.
contributed to information security. Can explain at least one significant research activity
that contributed to information security.

Security Disciple Information Security Research
Skill Area Applied Research Ref: I2
Vulnerability Research and Discovery, leading to the development of exploits, reverse engineering and
researching mitigation bypasses.
Cryptographic research leading to the assessment of existing algorithms.
In the Information Security field, uses existing knowledge in experimental development to produce new or
substantially improved devices, products and processes.
Level 1 Level 2
Recognises the value of applied research in Understands the principles of applied research in
Information Security. Information Security and might have undertaken some
directed practical examples in a training environment.
Can list some examples of applied research in Can explain the principles and processes of conducting
information security applied research.

Security Disciple Management, Leadership, Business and Communications
Skill Area Management, Leadership Ref: J1
and Influence
Works effectively in teams, either as a member or leader.
Encourages and supports others to meet objectives and to develop as Information Security professionals.
Is a leader on Information Security issues, either locally or across an organisation.
Provides technical leadership in a professional field, either within an organisation or across an industry sector.
Level 1 Level 2
Works cooperatively and professionally with others. Has received recognised training in management
and/or leadership.
Recognises that others could be impacted by their Can explain why it is important to openly celebrate
own behaviour. success and recognise accomplishments.
Recognises that others many have different values Can explain why it is important to empower
and views and is sensitive to this. colleagues by giving them the information and
Recognises that it is important to encourage and authority needed to complete tasks.
support team spirit and morale, helping work to be Can explain why it is important to provide support and
enjoyable and stimulating for all feedback to encourage and develop colleagues

Skill Area Business Skills Ref: J2
Understands local or corporate business aims and uses this knowledge to maximise the cost-effectiveness of
Information Security.
Contributes to the development of cost-effective corporate Information Security strategy; takes action to
achieve greater corporate efficiency in line with strategic aims.
Takes reasoned decisions on Information Security based on business aims and influences.
Level 1 Level 2
Understands local objectives and organisational aims Understands and supports organisational aims, and
and how own job supports them. any regulations and laws that govern own
organisation.
Works in a cost effective manner.
Recognises that they need to monitor progress against Can explain why it is important to work in a cost-
objectives. effective manner.
Recognises that they need to demonstrate a self- Can summarise the business skills they are required to
motivated attitude. possess:
• Delivering
• Managing Customer Relationships.
• Time management and planning.
• Effective decision making

Skill Area Communication and Ref: J3
Knowledge Sharing
Communicates information clearly and in a manner relevant to the target audience.
Influences senior management.
Shares knowledge on Information Security.
Negotiates effectively on Information Security issues.
Level 1 Level 2
Understands and interprets instructions effectively. Has clear written and verbal communication skills.
Communicates effectively with colleagues. Shares information and knowledge with others.
Can describe the required skills in this area: Can explain different techniques and styles of sharing
• Accurate and clear communication. information (documents, slides, presentations, wikis
• Writing in clear plain English. etc.).
• Listen and learn effectively from others. Can explain why it is important to produce work to a
• Constructive criticism. high standard, with well-reasoned arguments and
• Importance of sharing information as necessary. clear conclusions.
Can explain why it is important to encourage and
make useful contributions to open debate or complex
discussions.

Security Disciple Contributions to the Information Security Profession and Professional
Development
Skill Area Contributions to the Ref: K1
Community
Undertakes activity to broaden awareness and knowledge of Information Security issues, including the risks
from social media use, in the wider community – e.g. moderating sessions at schools, community centres, etc.
Level 1 Level 2
Recognises the need to educate the community on N/A
Information Security issues.
Recognises the need to educate family and wider N/A

community on information and cyber risks.

Development
Skill Area Contributions to the IS Ref: K2
Profession
Undertakes voluntary roles within industry forums or professional bodies.
Presents sessions on Information Security, either within the organisation or at conferences.
Level 1 Level 2
Recognises the value of Information Security Can describe the main Information Security
professional bodies and industry forums. professional bodies and industry forums.
They shall be able to name several Information

Security professional bodies and industry forums.

Development
Skill Area Professional Development Ref: K3
Takes appropriate and timely action to develop and maintain personal Information Security knowledge and
expertise.
Level 1 Level 2
Recognises the value of continued professional Has professional or academic accreditations to
development to the Information Security profession. support areas of expertise.
Can list some of the industry training, certification and
accreditation bodies.
For example has one of the following qualifications:

• CCP.
• CISMP.
• CISA.
• CISSP
• CISM.
• CRISC.

Part 2
References
Part 2: References

4. Common Terms
The following table contains a number of common terms and abbreviations used in the IISP Knowledge
Framework. Wherever possible an authoritative source has been used to obtain the definition – which is
contained in the right hand column of the table.
As there are many sources for definitions it has been decided that the following priority will be used.
• ISO/IEC 27000 family.
• ISO Guide 73.
• Other ISO Standards.
• OWASP.
• NISTIR 7298.
• NIST Special Publication 800-145 - The NIST Definition of Cloud Computing.
• NIST Special Publication 800-146 - Cloud Computing Synopsis and Recommendations.
• Oxford English Dictionary.
Where an authoritative definition cannot be found from the above list IISP has provided a definition.
Term Definition Source
Acceptable Use An Acceptable Use Policy (AUP) is a set of rules applied by the
Policy owner of an information system, which restrict the ways in it may
be used and sets guidelines as to how it should be used. Typically
users sign-up and accept the AUP or their employment contracts
make it mandatory to conform.
Access Control Means to ensure that access to assets is authorized and restricted ISO/IEC 27000:2016
based on business and security requirements.
Access Control A list of permissions attached to an object. It specifies which users
List or system processes (i.e. subjects) are granted access to objects, as
well as what operations are allowed on given objects.
Access Access management is the process of granting authorised users the
Management right to use a service, while preventing access to non-authorised
users. Access management can also be referred to as rights
management.
Accountability The security goal that generates the requirement for actions of an NISTIR 7298
entity to be traced uniquely to that entity. This supports non-
repudiation, deterrence, fault isolation, intrusion detection and
prevention, and after-action recovery and legal action.
Advanced A targeted attack against a specific entity that tries to avoid
Persistent detection and steal information over a period of time. Usually, the
Threat attacker behind the APT will use several pieces of malware and
security technologies to build up an attack.
Adware Adware refers to any piece of software or application that displays
advertisements, usually through pop-up or pop-under windows.
While they may be disruptive to some users, adware are not
inherently malicious.
Alert “Instant” indication that an information system and network may be ISO/IEC 27033-1:2009
under attack, or in danger because of accident, failure or human
error.
Algorithm A process or set of rules to be followed in calculations or other Oxford English
problem-solving operations. Dictionary
Antivirus A program that will prevent, detect and remediate certain types of
Software malware infection on individual computing devices and IT systems.

Anything as a Anything as a Service (XaaS) is a collective term used to refer to "X
Service as a service” where “X” stands for the service being offered, for
example ransomware!
Application Application control blocks or restricts unauthorised applications
Control from executing and hence only permits those that are approved to
execute. Also known as application whitelisting.
Application A type of firewall that follows and understands the application
Firewall protocols traversing it and can deny/allow traffic based on the
inspection of the application protocol.
Asset A useful or valuable thing or person Oxford English
Dictionary
A major application, general support system, high impact program, NISTIR 7298
physical plant, mission critical system, personnel, equipment, or a
logically related group of systems.
Assurance A positive declaration intended to give confidence; a promise. Oxford English
Dictionary
See Information Assurance.

Asymmetric An algorithm used for encryption and decryption where keys come
Algorithm in pairs. Normally the keys are interchangeable, in the sense that if
key A encrypts a message, then key B can decrypt it, and if key B
encrypts a message, then key A can decrypt it.
Attack Attempt to destroy, expose, alter, disable, steal or gain ISO/IEC 27000:2016
unauthorized access to or make unauthorized use
of an asset
Attack Surface The total sum of the vulnerabilities in a given device, application,
system or network.
Attack Tree Conceptual diagrams showing how an asset, or target, might be
attacked. They are multi-levelled diagrams consisting of one root,
leaves, and children. From the bottom up, child nodes are
conditions which must be satisfied to make the direct parent node
true; when the root is satisfied, the attack is complete.
Attribute-Based Access control based on attributes associated with and about NISTIR 7298
Access Control subjects, objects, targets, initiators, resources, or the environment.
An access control rule set defines the combination of attributes
under which an access may take place.
Audit Systematic, independent and documented process for obtaining ISO/IEC 27000:2016
audit evidence and evaluating it objectively to determine the extent
to which the audit criteria are fulfilled.
Audit Event Any significant occurrence in the system, program or application
that requires to be reported with the event being added into an
audit log.
Audit Log Chronological record of information documenting important events
or stages in a business or IT process, such as the system security log,
typically configured to record successful and failed logons, etc.
Sometimes referred to as an event log or audit trail.
Audit Logging Recording of data on information security events for the purpose of ISO/IEC 27033-1:2009
review and analysis, and ongoing monitoring.
Authentication Provision of assurance that a claimed characteristic of an entity is ISO/IEC 27000:2016
correct.
Authenticity Provision of assurance that a claimed characteristic of an entity is ISO/IEC 27000:2016
correct.
Authorisation Authorization is the process of determining whether an OWASP
authenticated subject (a user) can see, change, delete or take other
actions upon data. For example, if you log into a time keeping
application, submit your timesheet and then your boss approves it,
the act of logging in is authenticating, the act of filling out your
timesheet and submitting should only be something your user is
authorized to do and approving the timesheet is something only the
boss is authorized to do.
Availability Property of being accessible and usable upon demand by an ISO/IEC 27000:2016
authorized entity.
Backdoor Malicious code inserted into a program for the purposes of OWASP
providing the author covert access to machines running the
program.
Big Data Data sets that are so large or complex that traditional data
processing applications are inadequate to deal with.
Biometrics The application of statistical analysis to biological data. Oxford English
Dictionary
Black Box Black box testing is when the information about the organisation is
Testing not available to the testers. The tester performs the attack with no
prior knowledge of the infrastructure, defence mechanisms and
communication channels of the target organisation.
Blacklist A list of people or groups seen as unacceptable or untrustworthy. Oxford English
Dictionary
Bot Small, hidden programs that are often controlled by a malicious
hacker. Bots can be installed on your PC without you knowing. Bots
on a large number of PCs can be connected to form a botnet.
Also known as a web bot.
Botnet When multiple copies of a bot are installed on many PCs and
controlled by a malicious hacker. The malicious hacker can use a
botnet for large attacks (such as DDoS attacks or " floods") that
wouldn't be possible if they used just one PC.
Bring Your Own Bring Your Own Device (BYOD) refers to the policy of permitting
Device employees to bring personally owned devices (for example laptops,
tablets, and smart phones) to their workplace, and to use those
devices to access privileged company information and applications.
This includes using the devices when working remotely
Brute Force An attack on an encryption algorithm where the encryption key for OWASP
Attack a ciphertext is determined by trying to decrypt with every key until
valid plaintext is obtained.
A brute force attack can also be used as an attack to recover

passwords stored in a password table/database even when stored
in hash form.
Buffer Overflow A buffer overflow is when you can put more data into a memory OWASP
location than is allocated to hold that data. Languages like C and
C++ that do no built-in bounds checking are susceptible to such
problems. These problems are often security-critical.
Bug Bounty A program rewards individuals for discovering and reporting
Program software bugs - in particular vulnerabilities. Typically individuals are
external to the organisation offering the bounty. They are often
used to supplement internal code audits and penetration tests as
part of an organisation's vulnerability management strategy.

Business Strategic and tactical capability of the organisation to plan for and ISO 22313:2012
Continuity respond to incidents and business disruptions in order to continue
business operations at an acceptable predefined level.
Business Holistic management process that identifies potential threats to an ISO 22313:2012
Continuity organization and the impacts to business operations of those
Management threats, if realized, might cause, and which provides a framework
for building organizational resilience with the capability for an
effective response that safeguards the interests of its key
stakeholders, reputation, brand and value-creating activities
Business Documented procedures that guide organizations to respond, ISO 22313:2012
Continuity Plan recover, resume, and restore to a pre-defined level of operation
following disruption.
Business Impact The business impact upon the organisation that might result from ISO/IEC 27005:2011
possible or actual information security incidents should be assessed,
taking into account the consequences of a breach of information
security such as loss of confidentiality, integrity or availability of the
assets.
Business Impact Business Impact Analysis (BIA) is a systematic process to determine
Analysis and evaluate the potential effects of an interruption to critical
business operations. Also referred to as a Business Impact
Assessment.
CAPTCHA. Completely Automated Public Touring test to tell Computers and
Humans Apart (CAPTCHA). A type of challenge‐response test
intended to distinguish human from machine input. An example is
the site request for web site users to recognise and type a phrase
posted using various challenging‐to‐read fonts, including images of
text strings.
Cardholder At a minimum, cardholder data consists of the full PAN. Cardholder PCI DSS
Data data may also appear in the form of the full PAN plus any of the
following: cardholder name, expiration date and/or service code
See Sensitive Authentication Data for additional data elements that
may be transmitted or processed (but not stored) as part of a
payment transaction.
Center for The Center for Internet Security (CIS) is an organisation dedicated to
Internet enhancing the cybersecurity readiness and response among public
Security and private sector entities. Utilizing its strong industry and
government partnerships, CIS combats evolving cybersecurity
challenges on a global scale and helps organisations adopt key best
practices to achieve immediate and effective defences against cyber
attacks. CIS is home to the Multi-State Information Sharing and
Analysis Center (MS-ISAC), CIS Security Benchmarks, and CIS Critical
Security Controls.
CERT Computer emergency response teams (CERT) are expert groups that
handle computer security incidents. Many CERT teams send out
alerts to customers. Alternative names for such groups include
computer emergency readiness team and computer security
incident response team (CSIRT).
Certificate An arrangement between a number of countries to ensure that
Authorizing evaluation of products against the Common Criteria are performed
Schemes to high and consistent standards and are seen to contribute
significantly to confidence in the security of those products.
Certification Authority trusted by one or more users to create and assign public ISO/IEC 27033-1:2009
Authority key certificates.
CESG Assisted CAPS (CESG Assisted Products Service). A scheme run by NCSC
Products certifying high grade cryptography products protecting the most
Service sensitive information of HMG. The scheme is also used by NCSC to
accelerate the development of high-grade products.
CESG Tailored CESG Tailored Assurance Service (CTAS) primary purpose is to
Assurance provide a tailored approach to gaining assurance in the specific
Service implementation of a product, system or service that a particular
HMG organisation wishes to use.
Chain of See Continuity of Evidence
Custody
Change Change Management (CM) sometimes referred to as Change
Management Control) is a formal process used to ensure that changes to a
product or system are introduced in a controlled and coordinated
manner. It reduces the possibility that unnecessary changes will be
introduced to a system without detailed consideration, introducing
faults into the system or undoing changes made by other users of
software and potentially having unintended consequences
CHECK Scheme The CHECK scheme enables penetration testing by NCSC approved
companies, employing penetration testing personnel qualified to
assess IT systems for HMG and other public sector bodies.
This can only be mandated for HMG national security requirements.
Chief The Chief Information Security Officer (CISO) is the senior-level
Information executive within an organisation responsible for establishing and
Security Officer maintaining the enterprise vision, strategy, and program to ensure
information assets and technologies are adequately protected.
Cipher An algorithm for performing encryption or decryption
Cipher Suite The collection of cryptographic algorithms used in TLS and SSL.
Ciphertext Data in its encrypted form. NIST SP 800-175A
Cloud Access A software tool or service, that is either on-premises or cloud-
Security Broker hosted which sits between an organisation's premises infrastructure
and a Cloud Provider's infrastructure. A CASB acts as a control point,
allowing the organisation to extend the reach of their security
policies beyond their own infrastructure. It provides compliance
checking, threat protection, and security for cloud services. Also
known as Cloud Security Gateway.
Cloud Auditor A party that can conduct independent assessment of cloud services, NIST_SP_500_292
information system operations, performance and security of the
cloud implementation.
Cloud Broker An entity that manages the use, performance and delivery of cloud NIST_SP_500_292
services, and negotiates relationships between Cloud Providers and
Cloud Consumers.
Cloud Carrier An intermediary that provides connectivity and transport of cloud NIST_SP_500_292
services from Cloud Providers to Cloud Consumers.

Cloud A model for enabling on-demand network access to a shared pool of NISTIR 7298
Computing configurable IT capabilities/ resources (e.g., networks, servers,
storage, applications, and services) that can be rapidly provisioned
and released with minimal management effort or service provider
interaction. It allows users to access technology-based services from
the network cloud without knowledge of, expertise with, or control
over the technology infrastructure that supports them. This cloud
model is composed of five essential characteristics (on-demand self-
service, ubiquitous network access, location independent resource
pooling, rapid elasticity, and measured service); three service
delivery models (Cloud Software as a Service [SaaS], Cloud Platform
as a Service [PaaS], and Cloud Infrastructure as a Service [IaaS]); and
four models for enterprise access (Private cloud, Community cloud,
Public cloud, and Hybrid cloud).
Note: Both the user's data and essential security services may reside
in and be managed within the network cloud.
Cloud A person or organization that maintains a business relationship NIST_SP_500_292
Consumer with, and uses service from, Cloud Providers.
Cloud Provider A person, organization, or entity responsible for making a service NIST_SP_500_292
available to interested parties.
Cloud Security A not-for-profit organisation with a mission to “promote the use of
Alliance best practices for providing security assurance within Cloud
Computing, and to provide education on the uses of Cloud
Computing to help secure all other forms of computing”
Cloud See Cloud Consumer. An entity that consumes services provided by
Subscriber a Cloud Provider. Usually just referred as a Subscriber
COBIT A good-practice framework created by ISACA for IT management
and IT governance. COBIT provides an implementable set of controls
over information technology and organises them around a logical
framework of IT-related processes.
Code Auditing Reviewing computer software for security problems OWASP
Code Injection The general term for attack types which consist of injecting code
that is then interpreted or executed by the application. This type of
attack exploits poor handling of untrusted data. These types of
attacks are usually made possible due to a lack of proper
input/output data validation.
Commercial Commercial Product Assurance (CPA) is a NCSC approach to gaining
Product confidence in the security of commercial products targeted at the
Assurance HMG market. CPA products are also recognised within the EU and
NATO.
Common The Common Criteria for Information Technology Security
Criteria Evaluation (abbreviated as Common Criteria or CC) is an
international standard (ISO/IEC 15408) for computer security
certification. For products and systems one can specify the security
functional and assurance requirements through the use of
Protection Profiles.
Common Common Vulnerabilities and Exposures (CVE) is a dictionary of
Vulnerabilities publicly known information security vulnerabilities and exposures.
and Exposures CVE and the CVE logo are registered trademarks of The MITRE
Corporation.
Common The Common Vulnerability Scoring System (CVSS) is an open
Vulnerability framework for communicating the characteristics and severity of
Scoring System software vulnerabilities.
Common Common Weakness Enumeration (CWE) is a software community
Weakness project that aims at creating a catalogue of software weaknesses
Enumeration and vulnerabilities. The goal of the project is to better understand
flaws in software and to create automated tools that can be used to
identify, fix, and prevent those flaws.
Communication In the internet protocol suite, a port is an endpoint of
Port communication in an operating system. It identifies a specific
process or a type of network service. A port is always associated
with an IP address of a host and the protocol type of the
communication, for instance port 80 is HTTP and port 443 is HTTPS.
Communications “communications data” means any of the following— Regulation of
Data (a) any traffic data comprised in or attached to a communication Investigatory Powers
(whether by the sender or otherwise) for the purposes of any postal Act
service or telecommunication system by means of which it is being
or may be transmitted;
(b) any information which includes none of the contents of a
communication (apart from any information falling within
paragraph (a)) and is about the use made by any person—
(i) of any postal service or telecommunications service; or (ii) in
connection with the provision to or use by any person of any
telecommunications service, of any part of a telecommunication
system;
(c) any information not falling within paragraph (a) or (b) that is held
or obtained, in relation to persons to whom he provides the service,
by a person providing a postal service or telecommunications
service.
Community The cloud infrastructure is provisioned for exclusive use by a specific NIST_SP_800_145
Cloud community of consumers from organizations that have shared
concerns (e.g., mission, security requirements, policy, and
compliance considerations). It may be owned, managed, and
operated by one or more of the organizations in the community, a
third party, or some combination of them, and it may exist on or off
premises.
Companies Act The Companies Act 2006 is an Act of the Parliament of the United
Kingdom which forms the primary source of UK company law.
Compartmental Separating a system into parts with distinct boundaries, using OWASP
ise simple, well- defined interfaces. The basic idea is that of
containment — i.e., if one part is compromised, perhaps the extent
of the damage can be limited.
A Security Design Principle.
Compliance A comprehensive review of an organisation's adherence to
Audit regulatory guidelines. Independent accounting, security or IT
consultants evaluate the strength and thoroughness of compliance
preparations. Auditors review security polices, user access controls
and risk management procedures over the course of a compliance
audit.
Compliance Ensuring that security controls required by legislation, directives,
Monitoring policies, regulations, standards or procedures are implemented.
Computer The Computer Misuse Act (1990) is designed to protect computers
Misuse Act against malicious attacks and theft of information. It is an Act of the
Parliament of the United Kingdom. Offences under the Act include
hacking, unauthorised access to computer systems and purposefully
spreading malware.
Computer Team of appropriately skilled and trusted members of the ISO/IEC 27035-1:2016
Security organization that handles incidents during their lifecycle.
Incident
Response Team A CSIRT is also known as a CERT.
Confidentiality Property that information is not made available or disclosed to ISO/IEC 27000:2016
unauthorized individuals, entities, or processes.
Consequence Outcome of an event affecting objectives. ISO/IEC 27000:2016
Content Control Controls used to block content entering or leaving an organisation
where that content does not conform to the corporate policy.
Continuity of The witnessed, written record of all of the individuals who maintain
Evidence unbroken control over items of physical or electronic evidence. It
establishes the proof that the items of evidence collected at the
crime scene is the same evidence that is being presented in a court
of law. Also referred to as Chain of Custody or Chain of Evidence.
Control A measure that is modifying risk. Security controls are also referred ISO Guide 73:2009
to as safeguards or countermeasures. Controls include any process,
policy, device, practice, or other actions which modify risk. Controls
may not always exert the intended or assumed modifying effect.
Controls can be classified as being a:

• Technical Security Control.
• Physical Security Control.
• Personnel Security Control.
• Procedural Security Control.
Measure that is modifying risk. ISO/IEC 27000:2016

Cookie A piece of state information supplied by a Web server to a browser, NISTIR 7298
in a response for a requested resource, for the browser to store
temporarily and return to the server on any subsequent visits or
requests
Copyright The exclusive and assignable legal right, given to the originator for a Oxford English
fixed number of years, to print, publish, perform, film, or record Dictionary
literary, artistic, or musical material.
Copyright, The Copyright, Designs and Patents Act 1988 (CDPA) defines and
Designs and regulates copyright law and is an Act of the Parliament of the United
Patents Act Kingdom. CDPA categorises the different types of works that are
protected by copyright.
Corrective A security control which reduces the business impact of an
Control information security incident.
Credential Something an entity, user or system presents to prove
(authenticate) their true identity, for example a password or
security token.
CREST CREST is the not-for-profit accreditation and certification body
representing the technical information security industry.
CREST provides internationally recognised accreditation for
organisations and individuals providing penetration testing, cyber
incident response and threat intelligence services.
Crisis The process by which a business or other organisation deals with a
Management sudden emergency situation.

Cross-site CSRF is an attack which forces an end user to execute unwanted OWASP
Request actions on a web application in which he/she is currently
Forgery authenticated. With little help of social engineering (like sending a
link via email/chat), an attacker may force the users of a web
application to execute actions of the attackers choosing. A
successful CSRF exploit can compromise end user data and
operation in case of normal user. If the targeted end user is the
administrator account, this can compromise the entire web
application.
Cross-site A class of problems resulting from insufficient input validation OWASP
Scripting where one user can add content to a web site that can be malicious
when viewed by other users to the web site. For example, one
might post to a message board that accepts arbitrary HTML and
include a malicious code item.
A type of code injection attack.
Cryptanalysis The study of ciphers, ciphertext, or cryptosystems with a view to
finding weaknesses in them that will permit retrieval of the plaintext
from the ciphertext, without necessarily knowing the key or the
algorithm.
Cryptographic A well-defined computational procedure that takes variable inputs, NIST SP 800-175B
Algorithm including a cryptographic key (if applicable), and produces an
output.
Cryptographic A function that maps a bit string of arbitrary length to a fixed-length NIST SP 800-175B
Hash Function bit string. Approved hash functions satisfy the following properties:
1. (One-way) It is computationally infeasible to find any input that
maps to any pre-specified output, and
2. (Collision resistant) It is computationally infeasible to find any two
distinct inputs that map to the same output.
Cryptographic A joint American and Canadian security accreditation program for
Module cryptographic modules against FIPS-140-2. The program is available
Validation to any vendors who seek to have their products certified for use by
Program the U.S. Government and regulated industries (such as financial and
health-care institutions) that collect, store, transfer, share and
disseminate "sensitive, but not classified" information.
Cryptography The science of information hiding and verification. It includes the NIST SP 800-175A
protocols, algorithms and methodologies to securely and
consistently prevent unauthorized access to sensitive information
and enable verifiability of the information. The main goals include
confidentiality, integrity authentication and source authentication.
Cyber Attack An attack, via cyberspace, targeting an enterprise’s use of NISTIR 7298
cyberspace for the purpose of disrupting, disabling, destroying, or
maliciously controlling a computing environment/infrastructure; or
destroying the integrity of the data or stealing controlled
information.
Cyber This brings the areas of information security, business continuity
Resilience and organisational resilience together. The objective of Cyber
Resilience is to maintain the organisation’s ability to deliver services
and intended outcomes despite adverse cyber events. Adverse
cyber events are those that negatively impact the availability,
integrity or confidentiality of IT systems and associated and services.

Cyber Scheme A non-for-profit organisation run by an independent Board of
Directors. The aim of the Cyber Scheme is to provide via training
and associated progressive qualifications a range of professional
capabilities in the areas of penetration testing, forensics, malware
analysis, risk assessment, risk management and related cyber
security capabilities.
Cyber Security The body of technologies, processes and practices designed to
protect networks, computers, programs and data from external
attack in cyberspace.
Cyberspace A global domain within the information environment consisting of NISTIR 7298
the interdependent network of information systems infrastructures
including the Internet, telecommunications networks, computer
systems, and embedded processors and controllers.
Data at Rest Inactive data that is stored physically in any digital form (e.g.
databases, data warehouses, spreadsheets, archives, tapes, off-site
backups, mobile devices etc.).
Data Controller A person who (either alone or jointly or in common with other Data Protection Act
persons) determines the purposes for which and the manner in
which any personal data are, or are to be, processed.
A data controller must be a “person” recognised in law, that is to
say:
• individuals;
• organisations; and
• other corporate and unincorporated bodies of persons.
Data Flow A graphical representation of the "flow" of data through an
Diagram information system, modelling its process aspects.
A Data Flow Diagram shows what kind of information will be input
to and output from the system, where the data will come from and
go to, and where the data will be stored.
Data Loss A set of controls used to make sure that end users do not send
Prevention sensitive or critical information outside the corporate network.
Data Processor “data processor”, in relation to personal data, means any person Data Protection Act
(other than an employee of the data controller) who processes the
data on behalf of the data controller;
Data Protection Defines how personal or customer information is used and
controlled by organisations or government bodies. Data Protection
laws includes strict guidelines and privacy policies on how to keep
information safe.
Data Protection The Data Protection Act 1998 is an act of the UK Parliament defining
Act the ways in which information about living people may be legally
used and handled. The main intent is to protect individuals against
misuse or abuse of information about them.
Data Protection A process which helps an organisation to identify and reduce the
Impact privacy risks of a project. An effective Data Protection Impact
Assessment Assessment (DPIA) is used throughout the development and
implementation of a project, using existing project management
processes. This is a term used with the GDPR.
Also known as a Privacy Impact Assessment.
Data Protection The Data Protection Officer (DPO) is person designated to take
Officer responsibility for data protection compliance within an
organisation.

Data Subject “Data subject” means an individual who is the subject of personal Data Protection Act
data.
Decryption The process of transforming ciphertext into plaintext for the
purpose of reading the information.
Deep Content A form of filtering that examines an entire file or MIME object as it
Inspection passes an inspection point, searching for viruses, spam, data loss,
key words or other content level criteria.
Defence in A principle for building systems stating that multiple defensive OWASP
Depth mechanisms at different layers of a system are usually more secure
than a single layer of defense. For example, when performing input
validation, one might validate user data as it comes in and then also
validate it before each use — just in case something was not caught,
or the underlying components are linked against a different front
end, etc.
Demilitarized Perimeter network (also known as a screened sub-net) inserted as a ISO/IEC 27033-1:2009
Zone “neutral zone” between networks.
Denial of Prevention of authorized access to a system resource or the ISO/IEC 27033-1:2009
Service delaying of system operations and functions, with resultant loss of
availability to authorized users.
Design Pattern A general reusable solution to a commonly occurring problem
within a given context. There are number of different types of
patterns – including software and architectural. Sometimes design
patterns are referred to as design templates.
Detective A security control used to identify and characterise an information
Control security incident.
Deterrent A security control used to reduce the likelihood of an attack.
control
Device Control Protects against data loss by monitoring and controlling data
transfers from PCs to removable storage devices such as USB drives.
Dictionary An attack against a cryptographic system, using precomputating OWASP
Attack values to build a dictionary. For example, in a password system, one
might keep a dictionary mapping ciphertext pairs in plaintext form
to keys for a single plaintext that frequently occurs. A large enough
key space can render this attack useless. In a password system,
there are similar dictionary attacks, which are somewhat alleviated
by salt. The end result is that the attacker — once he knows the salt
— can do a “Crack”-style dictionary attack. Crack-style attacks can
be avoided to some degree by making the password verifier
computationally expensive to compute. Or select strong random
passwords, or do not use a password-based system.
Digital Evidence Digital evidence is information stored or transmitted in binary form
that may be relied on in court. It can be found on a computer hard
drive, a mobile phone, a personal digital assistant (PDA), a CD, and a
flash card in a digital camera, among other places.
Digital A branch of forensic science encompassing the recovery and
Forensics investigation of material found in digital devices, often in relation to
computer crime.
Digital The result of a cryptographic transformation of data that, when NIST SP 800-175B
Signature properly implemented, provides the services of:
1. Source authentication,
2. Data integrity, and
3. Supports signer non-repudiation.

Disaster A set of policies and procedures to enable the recovery or
Recovery continuation of technology infrastructure and systems following a
natural or human-induced disaster. Disaster recovery focuses on the
IT or technology systems supporting critical business functions, as
opposed to business continuity, which involves keeping all essential
aspects of a business functioning despite significant disruptive
events. Disaster recovery is therefore a subset of business
continuity.
Discretionary A means of restricting access to objects (e.g., files, data entities) NISTIR 7298
Access Control based on the identity and need-to-know of subjects (e.g., users,
processes) and/or groups to which the object belongs. The controls
are discretionary in the sense that a subject with a certain access
permission is capable of passing that permission (perhaps indirectly)
on to any other subject (unless restrained by mandatory access
control).
Distributed DDoS is a type of Denial of Service (DoS) attack where multiple
Denial of compromised systems, which are often infected with a Trojan
Service Horse, are used to target a single system causing a DoS attack.
Dumpster A popular form of modern salvaging of waste in large commercial,
Diving residential, industrial and construction containers to find items that
have been discarded by their owners, but that may prove useful to
the picker.
In information security terms this means an attacker could retrieve
sensitive information, including personal data. It could allow an
attacker to launch a social engineering attack on an individual.
Eavesdropping Any attack on a data connection where one simply records or views OWASP
Attack data instead of tampering with the connection.
Encryption The process of transforming plaintext into ciphertext for the NIST SP 800-175A
purpose of security or privacy.
Endpoint Provides a collection of security utilities to protect PCs and tablets.
Protection Products usually include Application Control, Device Control, Port
Control, antivirus software and Web Application Firewall facilities.
Enterprise Also referred to as Enterprise Information Security Architecture
Security (EISA). This is a part of enterprise architecture focusing on
Architecture information security throughout the enterprise. It is the application
of comprehensive and rigorous methods for describing a current or
future structure and behaviour for an organisation's security
processes, information security systems, personnel and
organisation. Two frameworks of note are TOGAF and SABSA.
Entropy Refers to the inherent unknowability of data to external observers. OWASP
If a bit is just as likely to be a 1 as a 0 and a user does not know
which it is, then the bit contains one bit of entropy.
Evaluation Set of assurance requirements drawn from ISO/IEC 15408-3, ISO/IEC 15408
Assurance Level representing a point on the ISO/IEC 15408 predefined assurance
scale, that form an assurance package.
Fail Securely A security design principle. See failsafe.
Failsafe Concept used mainly in safety-critical or high-security system and
process designs, whereby a control failure leaves the
system/process in an inherently safe or secure condition, even if
that impairs availability.
False Negative A test result which wrongly indicates that a particular condition or Oxford English
attribute is absent Dictionary

False Positive A test result which wrongly indicates that a particular condition or Oxford English
attribute is present. Dictionary
Fault Tolerance A capability of a system or network to deliver uninterrupted service,
despite one or more of its components failing. The purpose is to
prevent catastrophic failure that could result from a single point of
failure.
Federated Identity for use in multiple domains, which together form an ISO/IEC 24760-1:2011
Identity identity federation.
NOTE 1 A federated identity may be jointly managed by identity
information providers of the federated domains.
NOTE 2 The shared attributes used in the federated domains may in
particular be used for identification, e.g. to support single-sign-on
(SSO).
NOTE 3 The federated identity may persist or may be a temporary
one, e.g. as single-sign-on identity.
Basically a federated identity is a means of linking a person's

identity and associated attributes when they are stored across
multiple identity management systems.
File Integrity A process that performs the act of validating the integrity of
Monitoring operating system and application software files using a verification
method between the current file state and a known, good baseline.
File Level A form of disk encryption where individual files or directories are
Encryption encrypted by the file system itself.
FIPS Federal Information Processing Standards; a set of standards from OWASP
NIST.
FIPS-140 A standard authored by the U.S. National Institute of Standards and OWASP
Technology, that details general security requirements for
cryptographic software deployed in a government systems
(primarily cryptographic providers).
The current version is known as FIPS -140-2.

Firewall Type of security barrier placed between network environments — ISO/IEC 27033-1:2009
consisting of a dedicated device or a composite of several
components and techniques — through which all traffic from one
network environment traverses to another, and vice versa, and only
authorized traffic, as defined by the local security policy, is allowed
to pass.
Forensics A plan that prepares an organisation to maximize its potential to use
Readiness Plan digital evidence while minimising the cost of an investigation - in
order for it to be able to collect, preserve, protect and analyse
digital evidence so that this evidence can be effectively used in any
legal matters, in disciplinary matters, in an employment tribunal or
court of law.
Freedom Of The Freedom of Information Act 2000 provides public access to
Information information held by public authorities. It is an Act of the Parliament
of the United Kingdom.
It does this in two ways:
• Public authorities are obliged to publish certain information
about their activities.
• Members of the public are entitled to request information from
public authorities.

Full Disk The encryption of all data on a disk drive, including the bootable
Encryption Operating System partition. It is performed by disk encryption
software or hardware that is installed on the drive during
manufacturing or via an additional software driver. It converts all
device data into a form that can be only understood by the one who
has the key to decrypt the encrypted data
Functional A software testing process used within software development in
Testing which software is tested to ensure that it conforms to all
requirements.
Fuzzing Fuzz testing or Fuzzing is a Black Box software testing technique, OWASP
which basically consists in finding implementation bugs using
malformed/semi-malformed data injection in an automated fashion.
General Data The General Data Protection Regulation (GDPR) (Regulation (EU)
Protection 2016/679) is a Regulation by which the European Parliament, the
Regulation Council and the European Commission intend to strengthen and
unify data protection for individuals within the European Union.
Governance The system by which an organization’s information security ISO/IEC 27000:2016
activities are directed and controlled.
Governing Body Person or group of people who are accountable for the ISO/IEC 27000:2016
performance and conformance of the organization.
Gramm-Leach- This US federal Act is also known as the Financial Modernization Act
Bliley Act of 1999. The Act includes provisions to protect consumers' personal
financial information held by financial institutions.
Guideline A general rule, principle, or piece of advice. Oxford English
Dictionary
Hardening Elimination of as many security risks as possible on an application,
device or operating system. This is typically done by removing all
non-essential services, software programs and utilities to reduce the
attack surface. Also all default user account and passwords should
be removed.
Hash Function See cryptographic hash function. NIST SP 800-175B
Hash Value The result of applying a hash function to information; also called a NIST SP 800-175B
message digest.
Heuristics Proceeding to a solution by trial and error or by rules that are only Oxford English
loosely defined Dictionary
Honey Pot A strategy of setting up resources which an attacker believes are OWASP
real but are in fact designed specifically to catch the attacker.
Host Intrusion HIDS. These products attempts to identify unauthorised, illicit, and
Detection anomalous behaviour on a specific device, whether it is a server or
System workstation. HIDS generally involves an agent installed on each
system, monitoring and alerting on local OS and application activity.
The installed agent uses a combination of signatures, rules, and
heuristics to identify unauthorised activity. Like a NIDS, the role of a
HIDS is passive, only gathering, identifying, logging, and alerting.
Host Intrusion HIPS. Similar to a HIDS except they can be configured to block
Prevention activity. Most products in this space can operate in either HIDS or
System HIPS mode, and usually on a rule by rule basis.
HTTP HTTP (Hypertext Transfer Protocol) is the set of rules for
transferring files (text, graphic images, sound, video, and other
multimedia files) on the World Wide Web. HTTP is an application
protocol that runs on top of the TCP/IP suite of protocols.

HTTPS HTTPS (HTTP over SSL or HTTP Secure) is the use of Secure Socket
Layer (SSL) or Transport Layer Security (TLS) to carry HTTP
application traffic.
Human Factors Human factors and ergonomics is the practice of designing
products, systems, or processes to take proper account of the
interaction between them and the people who use them.
Human Rights The Human Rights Act 1998 is a UK Act of Parliament. Its aim is to
Act incorporate into UK law the rights contained in the European
Convention on Human Rights.
Hybrid Cloud The cloud infrastructure is a composition of two or more distinct NIST_SP_800_145
cloud infrastructures (private, community, or public) that remain
unique entities, but are bound together by standardized or
proprietary technology that enables data and application portability
(e.g., cloud bursting for load balancing between clouds).
IAMM Information Assurance Maturity Model and Assessment Framework.
A tool used by the UK Government to assess the effectiveness of the
implementation of the Security Policy Framework (SPF). Although an
independent IAMM audit is not mandated, each UK Government
Department is required to deliver a report on the state of the SPF
controls in its annual statement on internal control. This report
must include details of how supply chain partners are meeting IA
best practice.
Identification Process of recognizing an entity in a particular domain as distinct ISO/IEC 24760-1:2011
from other entities
NOTE 1 The process of identification applies verification to claimed
or observed attributes.
NOTE 2 Identification typically is part of the interactions between an
entity and the services in a domain and to access resources.
Identification may occur multiple times while the entity is known in
the domain.
Basically identification is the process of verifying the identity of a

user, process, or device - usually as a means for granting access to a
resource.
Identification The action or process of identifying someone or something or the Oxford English
fact of being identified Dictionary
Identity Access Identity Access Management (IAM) is sometimes used as alternative
Management name to Identity Management. However, some commentators see
IAM as being an extension to Identity Management covering in
addition access management.
Identity Agreement between two or more domains specifying how identity ISO/IEC 24760-1:2011
Federation information will be exchanged and managed for cross-domain
identification purposes
NOTE 1 Establishing an identity federation typically includes an
agreement on the use of common protocols and procedures for
privacy control, data protection and auditing. The federation
agreement may specify the use of standardized data formats and
cryptographic techniques.
NOTE 2 The federation agreement can be the basis for identity
authorities in each of the domains of applicability to mutually
recognize credentials for authorization.
See Federated Identity.

Identity Processes and policies involved in managing the lifecycle and value, ISO/IEC 24760-1:2011
Management type and optional metadata of attributes in identities known in a
particular domain
NOTE 1 In general identity management is involved in interactions
between parties where identity information is processed.
NOTE 2 Processes and policies in identity management support the
functions of an identity information authority where applicable, in
particular to handle the interaction between an entity for which an
identity is managed and the identity information authority.
Basically identity management is a combination of administrative

and technical controls that deals with identifying individuals in a
system and controlling their access to resources within that system
by associating user rights and restrictions with the authenticated
identity.
See also Identity and Access Management.

IEC 62443 A series of standards, technical reports, and related information
that define procedures for implementing electronically secure
Industrial Automation and Control Systems (IACS).
Currently there are only 12 standards in the series.
Originally referred to as ANSI/ISA-99 or ISA99 standards,
Incident Actions of detecting, reporting, assessing, responding to, dealing ISO/IEC 27035-1:2016
Handling with, and learning from information security incidents.
Incident Actions taken to mitigate or resolve an information security ISO/IEC 27035-1:2016
Response incident, including those taken to protect and restore the normal
operational conditions of an information system and the
information stored in it.
Industrial Industrial Control System (ICS) is a term that encompasses several
control system types of control systems and associated instrumentation used in
industrial production, including Supervisory Control and Data
Acquisition (SCADA) systems, Distributed Control Systems (DCS),
and other smaller control system configurations such as
Programmable Logic Controllers (PLC).
Information The confidence that information systems will protect the
Assurance information they handle and will function as they need to, when
they need to, under the control of legitimate users.
Information The assignment of a level of sensitivity to information which defines
Classification the required security controls for each level of classification. The
classification level is an indication of the value or importance of the
data to the enterprise. It implies, according to the security policy
being enforced, a specific level of protection.
Information The head of the Information Commissioner's Office and the
Commissioner regulator in the UK responsible for compliance with a number of
laws and regulations including the Data Protection Act 1998 and the
Privacy and Electronic Communications (EC Directive) Regulations
2003.
Information The Information Commissioner's Office (ICO) is a public body which
Commissioner’s reports directly to the UK Parliament. It is the independent
Office regulatory office dealing with a number of Acts of Parliament
including the Data Protection Act 1998 and the Privacy and
Electronic Communications (EC Directive) Regulations 2003. It is
headed by the Information Commissioner.
Information Preservation of confidentiality, integrity and availability of ISO/IEC 27000:2016
Security information.
In addition, other properties, such as authenticity, accountability,

non-repudiation, and reliability can also be involved.
Information Identified occurrence of a system, service or network state ISO/IEC 27000:2016
Security Event indicating a possible breach of information security policy or failure
of controls, or a previously unknown situation that may be security
relevant.
Information A series of documented processes that are used to define policies
Security and procedures around the implementation and ongoing
Framework management of information security controls in an enterprise
environment.
Information Single or a series of unwanted or unexpected information security ISO/IEC 27000:2016
Security events that have a significant probability of compromising business
Incident operations and threatening information security.
Information Processes for detecting, reporting, assessing, responding to, dealing ISO/IEC 27000:2016
Security with, and learning from information security incidents
Incident
Management
Information Application of examinations, analysis and interpretation to aid ISO/IEC 27035-1:2016
Security understanding of an information security incident.
Investigation
Information An Information Security Management System (ISMS) consists of the ISO/IEC 27000:2016
Security policies, procedures, guidelines, and associated resources and
Management activities, collectively managed by an organization, in the pursuit of
System protecting its information assets. An ISMS is a systematic approach
for establishing, implementing, operating, monitoring, reviewing,
maintaining and improving an organization’s information security to
achieve business objectives. It is based upon a risk assessment and
the organization’s risk acceptance levels designed to effectively
treat and manage risks. Analysing requirements for the protection
of information assets and applying appropriate controls to ensure
the protection of these information assets, as required, contributes
to the successful implementation of an ISMS.
Information Applications, services, information technology assets, or other ISO/IEC 27000:2016
System information handling components
Infrastructure The capability provided to the consumer is to provision processing, NIST_SP_800_145
as a Service storage, networks, and other fundamental computing resources
where the consumer is able to deploy and run arbitrary software,
which can include operating systems and applications. The
consumer does not manage or control the underlying cloud
infrastructure but has control over operating systems, storage, and
deployed applications; and possibly limited control of select
networking components (e.g., host firewalls).
Input Validation The act of determining that data input to a program is sound. OWASP
Integer When an integer value is too big to be held by its associated data OWASP
Overflow type, the results can often be disastrous. This is often a problem
when converting unsigned numbers to signed values.
Integrity Property of accuracy and completeness. ISO/IEC 27000:2016
Internet of The interconnection via the Internet of computing devices Oxford English
Things embedded in everyday objects, enabling them to send and receive Dictionary
data.
Intrusion Technical system that is used to identify that an intrusion has been ISO/IEC 27033-1:2009
Detection attempted, is occurring, or has occurred and possibly respond to
System intrusions in information systems and networks.
Intrusion Variant on intrusion detection systems that are specifically designed ISO/IEC 27033-1:2009
Prevention to provide an active response capability.
System
Investigatory The Investigatory Powers Act 2016 is an Act of the Parliament of the
Powers Act United Kingdom and provides a framework to govern the use and
oversight of investigatory powers by law enforcement and the
security and intelligence agencies in the UK
Investigatory Investigatory Powers Commission ensure the public and Parliament
Powers are informed about how the powers laid out in the Investigatory
Commission Powers Act are used. The Investigatory Powers Commissioner
reports annually and will have the power to report more frequently
on any matter that they considers appropriate.
IoT Security The IoT Security Foundation (IoTSF). A non-profit organisation
Foundation dedicated to driving security excellence. Its mission is to help secure
the Internet of Things, in order to aid its adoption and maximise its
benefits.
IP Address An identifier for a computer or device on a TCP/IP network, such as
the Internet. Networks using the TCP/IP protocol route messages
based on the IP address of the destination.
IP Packet A segment of data sent from one computer or device to another
over a network. A packet contains the source IP address, destination
IP address, size, type, data, and other useful information that helps
the packet get to its destination and be read
IPsec A set of protocols that provides security for Internet Protocol.
IRAM2 Information Risk Analysis Methodology 2 (IRAM2) produced by the
Information Security Forum (ISF). ISF have also produced an
associated Risk Management Tool.
ISO/IEC 15408 ISO/IEC 15408. A three part standard.
ISO/IEC 15408-1:2009. Information technology -- Security
techniques -- Evaluation criteria for IT security -- Part 1: Introduction
and general model.
techniques -- Evaluation criteria for IT security -- Part 2: Security
functional components.
techniques -- Evaluation criteria for IT security -- Part 3: Security
assurance components
ISO/IEC 21827 ISO/IEC 21827:2008. Information technology -- Security techniques -
- Systems Security Engineering -- Capability Maturity Model® (SSE-
CMM®).
ISO 22301 ISO 22301:2012. Societal security -- Business continuity
management systems --- Requirements.
ISO 22313 ISO 22313:2012. Societal security -- Business continuity
management systems – Guidance.
ISO/IEC 24760 ISO/IEC 24760-1:2011 Information technology -- Security techniques
-- A framework for identity management -- Part 1: Terminology and
concepts.
ISO/IEC 27000 ISO/IEC 27000:2016. Information technology — Security techniques
— Information security management systems — Overview and
vocabulary. Part of the ISO/IEC 27000 family of standards.
ISO/IEC 27000 The ISO/IEC 27000 family of mutually supporting information
family security standards (also known as the ISO 27000 series) is developed
and published by the International Organization for Standardization
(ISO) and the International Electrotechnical Commission (IEC) to
provide a globally recognised framework for best-practice
information security management.
ISO 27001 Lead The ISO/IEC 27001 Lead Auditor certification consists of a
Auditor professional certification for auditors specialising in information
security management systems (ISMS)
—Information security management systems —Requirements. Part
of the ISO/IEC 27000 family of standards.
ISO/IEC 27002 ISO/IEC 27002:2013. Information technology -- Security techniques -
- Code of practice for information security controls. Part of the
ISO/IEC 27000 family of standards.
—Information security risk management. Part of the ISO/IEC 27000
family of standards. Part of the ISO/IEC 27000 family of standards.
— Requirements for bodies providing audit and certification of
information security management systems
ISO/IEC 27014 ISO/IEC 27014:2013 Information technology — Security techniques
— Governance of information security. Part of the ISO/IEC 27000
family of standards
ISO/IEC 27033- ISO/IEC 27033-1:2009. Information technology — Security
1 techniques — Network security —Part 1: Overview and concepts
ISO/IEC 27035 ISO/IEC 27035-1:2016. Information technology -- Security
techniques -- Information security incident management -- Part 1:
Principles of incident management.
techniques -- Information security incident management -- Part 2:
Guidelines to plan and prepare for incident response
ISO 31000 ISO 31000:2009. Risk management – Principles and guidelines
ISO 9000 ISO 9000:2015. Quality management systems -- Fundamentals and
vocabulary.
ISO Guide 73 Risk management — Vocabulary. First edition 2009.
ITIL A set of detailed practices for IT service management (ITSM). It
describes processes, procedures, tasks, and checklists for different
stages in the ITSM lifecycle. Formally an acronym for Information
Technology Infrastructure Library
Kali Linux Kali Linux is an open source Debian-derived Linux distribution
designed for digital forensics and penetration testing. Kali Linux is
preinstalled with over 300 penetration-testing programs.
Key A random piece of data used with encryption and decryption.
Encryption and decryption algorithms require a key and plaintext or
ciphertext to produce ciphertext or plaintext, respectively. Keys are
usually very large randomly generated numbers.
Key Distribution The mechanism used to delivering cryptographic keys to required
parties.
Key Exchange The process of two parties agreeing on a shared secret, usually OWASP
implying that both parties contribute to the key.

Key The activities involving the handling of cryptographic keys and other
Management related security parameters during the entire life cycle of the keys,
including the generation, storage, establishment, entry and output,
and destruction.
Key Pair A pair of cryptographic keys consisting of a public key and a private
key associated with an asymmetric cipher. They have a
mathematical relationship with each other.
Key Size The size of a cryptographic key. Usually specified in bits.
Key Space All possible values used to construct cryptographic keys. The larger
the key space the better. In the case of a 64-bit key, the key space is
64
2 to the power of 64 (2 ). In other words, the number of possible
values of the key, i.e. the key space, is 18,446,744,073,709,600,000.
Least Privilege All processes should run with the minimal possible set of privileges
and should retain those privileges for the minimal amount of time
possible.
Legislation Laws, considered collectively. Oxford English
Dictionary
Level of Risk Magnitude of a risk expressed in terms of the combination of
consequences and their likelihood.
Lightweight LDAP is an open, vendor-neutral, industry standard application
Directory protocol for accessing and maintaining distributed directory
Access Protocol information services over an Internet Protocol network.
Likelihood Chance of something happening ISO/IEC 27005:2011
Mail Filtering Inspection of incoming email and removal of spam and computer
viruses using antivirus software. A less common use is to inspect
outgoing email and enforce some type of Data Loss Prevention
policy.
Malware Software which is specifically designed to disrupt, damage, or gain Oxford English
authorized access to a computer system. Dictionary
Mandatory A means of restricting access to objects based on the sensitivity (as NISTIR 7298
Access Control represented by a security label) of the information contained in the
objects and the formal authorization (i.e., clearance, formal access
approvals, and need-to-know) of subjects to access information of
such sensitivity.
Man-in-the- An eavesdropping attack where a client’s communication with a OWASP
middle Attack server is proxied by an attacker. Generally, the implication is that
the client performs a cryptographic key exchange with an entity and
fails to authenticate that entity, thus allowing an attacker to look
like a valid server.
Message Digest See Hash Value. NIST SP 800-175B
Methodology A system of methods used in a particular area of study or activity. Oxford English
Dictionary
MIME Multipurpose Internet Mail Extensions is an Internet standard that
extends the format of email to support:
• Text in character sets other than ASCII.
• Non-text attachments: audio, video, images, application
programs etc.
• Message bodies with multiple parts.
Minimisation Do not execute any software, applications, or services that are not
required. Do not install any software you are not using. A security
design principle.
Mitigation The action of reducing the severity, seriousness, or painfulness of Oxford English
something. Dictionary
Multifactor Authentication using two or more factors to achieve authentication. NISTIR 7298
Authentication Factors include: (i) something you know (e.g. password/PIN); (ii)
something you have (e.g., cryptographic identification device,
token); and (iii) something you are (e.g., biometric).
Mutual A process or technology in which both entities in a communications
Authentication link authenticate each other. In a network environment, the client
authenticates the server and vice-versa. Also called two-way
authentication.
National Cyber The National Cyber Security Centre (NCSC) is the UK’s authority on
Security Centre cyber security. It is part of GCHQ. The NCSC brings together and
replaces CESG (the information security arm of GCHQ), the Centre
for Cyber Assessment (CCA), Computer Emergency Response Team
UK (CERT UK) and the cyber-related responsibilities of the Centre for
the Protection of National Infrastructure (CPNI).
National The National Institute of Standards and Technology (NIST) is a OWASP
Institute of division of the U.S. Department of Commerce. NIST issues standards
Standards and and guidelines, with the hope that they will be adopted by the
Technology computing community.
National The National Vulnerability Database (NVD) is a U.S. government
Vulnerability repository of standards based vulnerability management data.
Database
Need-To-Know A method of isolating information resources based on a user’s need NISTIR 7298
to have access to that resource in order to perform their job but no
more. The terms ‘need-to know” and “least privilege” express the
same idea. Need-to-know is generally applied to people, while least
privilege is generally applied to processes.
Negative Test Checks if a function/method behaves as expected with bad input
and can correctly handle error conditions.
Network NIDS. These products attempt to identify unauthorised, illicit, and
Intrusion anomalous behaviour based solely on network traffic as the traffic
Detection traverses a NIDS sensor. A NIDS, using either a network tap, span
System port, or hub collects IP packets that traverse a given network. Using
the captured data, the NIDS system processes and flags, and
optionally reports or alerts, any suspicious traffic. The role of a NIDS
is passive, only gathering, identifying, logging and alerting.
Network NIPS. Very similar to a NIDS except this device actually blocks any
Intrusion traffic it believes to be suspicious. Most network products of this
Prevention type can be configured to operate in either NIDS or NIPS mode.
System
Network A NOC, also known as a "network management centre", is one or
Operation more locations from which network monitoring and control, or
Centre network management, is exercised over a network.
Network Router Network device that is used to establish and control the flow of data ISO/IEC 27033-1:2009
between different networks by selecting paths or routes based
upon routing protocol mechanisms and algorithms.
Network Switch Device which provides connectivity between networked devices by ISO/IEC 27033-1:2009
means of internal switching mechanisms, with the switching
technology typically implemented at layer 2 or layer 3 of the OSI
reference model.
NIST SP 500- NIST Special Publication 500-292. NIST Cloud Computing Reference
292 Architecture. (September 2011)

NIST SP 800 NIST Special Publication 800-175A. Guideline for Using
-175A Cryptographic Standards in the Federal Government: Directives,
Mandates and Policies (August 2016).
NIST SP 800- NIST Special Publication 800-145. The NIST Definition of Cloud
145 Computing (September 2011)
NIST SP 800- NIST Special Publication 800-146. Cloud Computing Synopsis and
146 Recommendations (May 2012)
NIST SP 800- NIST Special Publication 800-175A. Guideline for Using
175B Cryptographic Standards in the Federal Government: Cryptographic
Mechanisms (August 2016).
NIST SP 800-30 NIST Special Publication 800-30. Guide for Conducting Risk
Assessments. (September 2012)
NISTIR 7298 NIST Internal/Interagency Reports (NISTIR) 7298 revision 2 Glossary
of Key Information Security Terms (May 2013)
(http://nvlpubs.nist.gov/nistpubs/ir/2013/NIST.IR.7298r2.pdf )
Non- Ability to prove the occurrence of a claimed event or action and its ISO/IEC 27000:2016
repudiation originating entities.
OASIS The Organization for the Advancement of Structured Information
Standards (OASIS) is a global non-profit consortium that works on
the development, convergence, and adoption of standards for
security, Internet of Things, energy, content technologies,
emergency management, and other areas.
Obfuscate Make obscure, unclear, or unintelligible. Oxford English
Dictionary
Some malware hides its code in this way to make it harder for
security software to detect or remove it.
Object A piece of data or a resource.
OCTAVE OCTAVE Allegro is a risk management methodology to streamline
and optimise the process of assessing information security risks so
that an organisation can obtain sufficient results with a small
investment in time, people, and other limited resources. Developed
by the Software Engineering Institute (SEI) within Carnegie Mellon
University
O-ESA Open Enterprise Security Architecture (O-ESA). O-ESA introduces
the notion of design patterns with the explanation of a number of
conceptual and logical security architectures for particular areas of
an IT system. It also describes a number of security services.
Open Source Opens Source Intelligence (OSINT) is intelligence created from
Intelligence public or open source information, including that published in the
media, or legislation, annual reports, or directories, or available
from conferences, theses, studies, websites, photographic satellites,
or maps, among others.
OWASP The Open Web Application Security Project (OWASP). A not-for-
profit charitable international organisation that publishes freely-
available articles, methodologies, standards documentation, tools,
and technologies in the field of web application security.
OWASP Top 10 OWASP publish a number of “Top Ten” lists. The most famous, and
what most people mean by the “Top Ten” is the OWASP Top 10
Most Critical Web Application Security Risks on what its members
consider to be the top 10 most critical web application security
flaws are.
Packet Filtering Passing or blocking packets at a network interface based on source
and destination IP addresses, ports, or protocols.
PAS 754 PAS 754:2014. Software Trustworthiness. Governance and
management. Specification.
A PAS (Publicly Available Specification) from BSI which identifies five
aspects of software trustworthiness: Safety, reliability, availability,
resilience and security. It defines a set of principles and techniques
for any software implementation. Currently undergoing BSI
standardisation work.
Passphrase A synonym for “password,” meant to encourage people to use OWASP
longer (it is hoped, more secure) values.
Password A secret string of characters that should only be known by one
person and can therefore be used to authenticate them.
Password Aging A mechanism used to force a user to change their password after a
defined period of time.
Password A scheme where special characters, numbers, a mix of lower and
Complexity upper case characters are used in a password in order to prevent
brute force attacks.
Password File A file or databases containing user or other subject’s passwords.
They are normally held in a hashed form.
Password An attempt to determine user credentials through the process of
Guessing Attack attempting to log in repeatedly. This is generally done by using
commonly used or default passwords—attempting every possible
combination until successful
Password Reset A facility that allows a user, an administrator or a helpdesk operator
to reset a user’s password to a desired new value, regardless of its
current value.
Password A measure of the effectiveness of a password in resisting guessing
Strength and brute-force attacks. The strength of a password is a function of
length, complexity, and unpredictability.
Patch An area of systems management that involves acquiring, testing,
Management and installing multiple patches (code changes) to an administered
computer system. Patch management tasks include: maintaining
current knowledge of available patches, deciding what patches are
appropriate for particular systems, ensuring that patches are
installed properly, testing systems after installation, and
documenting all associated procedures, such as specific
configurations required.
PCI DSS The Payment Card Industry Data Security Standard (PCI DSS) is a
proprietary information security standard for organisations that
handle branded credit cards from the major card schemes. The PCI
Standard is mandated by the card brands and administered by the
Payment Card Industry Security Standards Council. The standard
defines the security controls needed to protect cardholder data and
hence aim to reduce credit card fraud.
Penetration Is a simulated attack whereby the penetration tester uses tools of
Testing the hacking trade to attempt to break into a system, network,
device or application.
Permission An approval for a subject to perform an operation on one or more
protected objects. The set of operations supported depends on the
access control model and can include: read, write, delete, execute
and search.

Personal Data Personal data” means data which relate to a living individual who Data Protection Act
can be identified—
(a)from those data, or
(b)from those data and other information which is in the possession
of, or is likely to come into the possession of, the data controller,
and includes any expression of opinion about the individual and any
indication of the intentions of the data controller or any other
person in respect of the individual;
Personal A numeric password used on systems with numeric keypads instead
Identification of full alphanumeric keyboards. PIN is often misused as a synonym
Number for password
Personnel The controls and procedures that are established to ensure that all
Security personnel who have access to sensitive information have the
Controls required authority as well as appropriate clearances. Procedures
confirm a person’s background and provide assurance of necessary
trustworthiness.
Pharming A malicious website that resembles a legitimate website, used to
gather usernames and passwords.
Phishing A malicious technique used to gather sensitive information (credit
card data, usernames and passwords, etc.) from users. The
attackers pretend to be a trustworthy entity to bait the victims into
trusting them and revealing their confidential data.
Physical Controls and procedures put into place to prevent intruders from
Security physically accessing a system or facility. The controls enforce access
Controls control and authorised access.
Plaintext Intelligible data that has meaning and can be understood without NIST SP 800-175A
the application of cryptography.
Platform as a The capability provided to the consumer is to deploy onto the cloud NIST_SP_800_145
Service infrastructure consumer-created or acquired applications created
using programming languages, libraries, services, and tools
supported by the provider. The consumer does not manage or
control the underlying cloud infrastructure including network,
servers, operating systems, or storage, but has control over the
deployed applications and possibly configuration settings for the
application-hosting environment
Policy Intentions and direction of an organization as formally expressed by ISO/IEC 27000:2016
its top management
Polymorphic Polymorphic malware is harmful, destructive or intrusive computer
Malware software such as a virus, worm, trojan or spyware that constantly
changes ("morphs"), making it difficult to detect with anti-malware
programs.
Port Control Protects against data loss by monitoring and controlling access to
device ports on a user workstation.
Port Scanning Using a program to remotely determine which ports on a system are NISTIR 7298
open (e.g., whether systems allow connections through those
ports).
Positive Test Checks if a function/method behaves as expected with its expected
input.
Predict, Predict, Prevent, Detect, Respond (PPDR) is framework published by
Prevent, the analysts Gartner. It is a useful tool to communicate an
Detect, organisation’s strategy and approach to security.
Respond

Pre-production An environment for final testing immediately prior to deploying to
production. It seeks to mirror the actual production environment as
closely as possible, and may connect to other production services
and data, such as databases.
Pretty Good An encryption program that provides confidentiality and
Privacy authentication for data communication. PGP is often used for
signing, encrypting, and decrypting texts, e-mails, files, directories,
and whole disk partitions and to increase the security of e-mail
communications.
Preventive A security control designed to prevent an information security
Control incident from occurring.
Primary Primary Account Number (PAN) also referred to as “account PCI DSS
Account number.” Unique payment card number (typically for credit or debit
Number cards) that identifies the issuer and the particular cardholder
account.
Privacy Informational privacy is the ability of a person to control, edit,
manage and delete information about themselves and to decide
how and to what extent such information is communicated to
others. Intrusion can come in the form of collection of excessive
personal information, disclosure of personal information without
consent and misuse of such information. It can include the
collection of information through the surveillance or monitoring of
how people act in public or private spaces and through the
monitoring of communications whether by post, phone or online
and extends to monitoring the records of senders and recipients as
well as the content of messages
Privacy and The Privacy and Electronic Communications (EC Directive)
Electronic Regulations 2003 (PECR) is a law in the UK which makes it unlawful
Communications to, amongst other things, transmit an automated recorded message
Regulations for direct marketing purposes via a telephone, without prior
consent of the subscriber. It also covers the use of cookies. It
implements an EC directive and has been amended a number of
times.
Privacy Impact Also known as a Data Protection Impact Assessment.
Assessment
Private Cloud The cloud infrastructure is provisioned for exclusive use by a single NIST_SP_800_145
organization comprising multiple consumers (e.g., business units). It
may be owned, managed, and operated by the organization, a third
party, or some combination of them, and it may exist on or off
premises.
Private Key Key of an asymmetric key pair which can only be used by the owner
of that key. Hence it must be kept secret.
Privilege An identified right that a particular user has to a particular system
resource, such as a file folder, the use of certain system commands,
or an amount of storage.
Privilege A vulnerability that lets a hacker elevate their privilege and hence
Elevation do things on a PC, network or server that they otherwise wouldn't
be able to. This occurs when an unprivileged user gains privileged
status.

Procedural Security controls that mitigate identified risks by way of policies,
Security procedures or guidelines. As opposed to other controls, procedural
Controls controls rely on users to follow rules or performs certain steps that
are not necessarily enforced by technical or physical means. Also
known as administrative controls.
Procedure Specified way to carry out an activity or a process ISO 9000:2015
Process Set of interrelated or interacting activities which transforms inputs ISO 9000:2015
into outputs.
Protection Implementation-independent statement of security needs for a TOE ISO/IEC 15408
Profile type
Protective A set of processes and technologies aimed at improving risk profiles
Monitoring and reducing risk. Protective Monitoring provides essential
oversight of IT systems across the whole enterprise. Protective
Monitoring includes efficient, automatic monitoring, alerting and
reporting of system changes, significant system events and file
integrity monitoring. In order to implement protective monitoring
investment in a SIEM product is usually required.
Proxy Server A server that services the requests of its clients by forwarding those NISTIR 7298
requests to other servers.
Typical proxy servers accept a connection from a user, make a

decision as to whether the user or client IP address is permitted to
use the proxy server, perhaps perform additional authentication,
and complete a connection to a remote destination on behalf of the
user.
Public Cloud The cloud infrastructure is provisioned for open use by the general NIST_SP_800_145
public. It may be owned, managed, and operated by a business,
academic, or government organization, or some combination of
them. It exists on the premises of the cloud provider
Public Key Key of an asymmetric key pair which can be made public.
Public Key A set of data that uniquely identifies an entity, contains the entity’s NIST SP 800-175B
Certificate public key and possibly other information, and is digitally signed by
a trusted party, thereby binding the public key to the entity
identified in the certificate. Additional information in the certificate
could specify how the key is used and the validity period of the
certificate.
Public Key A cryptographic algorithm that uses two related keys, a public key NIST SP 800-175B
Cryptography and a private key. The two keys have the property that determining
the private key from the public key is computationally infeasible.
Public Key A framework that is established to issue, maintain and revoke public NIST SP 800-175B
Infrastructure key certificates.
Qualitative Relating to, measuring, or measured by the quality of something Oxford English
rather than its quantity. Dictionary
Qualitative risk analysis uses a scale of qualifying attributes to
describe the magnitude of potential consequences (e.g. Low,
Medium and High).
Quantitative Relating to, measuring, or measured by the quantity of something Oxford English
rather than its quality. Dictionary
(Quantitative risk analysis uses a scale with numerical values).
Rainbow Table A method of data attack using a pre-computed table of hash strings PCI DSS
Attack (fixed-length message digest) to identify the original data source,
usually for cracking password or cardholder data hashes.

Ransomware Malware that restricts access to the compromised systems until a
ransom demand is satisfied. You may be warned that you need to
pay money, complete surveys, or perform other actions before you
can use your PC again. Some forms of ransomware may encrypt files
on the system's hard drive, while others may simply lock the system
and display messages to coax the user into paying.
Some types of ransomware also prevent restoration of data from
incremental backups by deleting or corrupting the checkpoint data.
Regulation A rule or directive made and maintained by an authority. Oxford English
Dictionary
Regulation of The Regulation of Investigatory Powers Act 2000 (RIPA) is an Act of
Investigatory the Parliament of the UK, regulating the powers of public bodies to
Powers Act carry out surveillance and investigation, and covering the
interception of communications.
Release The process of managing, planning, scheduling and controlling a
Management software build through different stages and environments; including
testing and deploying software releases.
Reliability Property of consistent intended behaviour and results ISO/IEC 27000:2016
Remediation A plan of actions on how risks, usually found during a vulnerability
Action Plan assessment or penetration test, are to be addressed. Also known as
a Risk Treatment Plan (RTP).
Remote Access Process of accessing network resources from another network, or ISO/IEC 27033-1:2009
from a terminal device which is not permanently connected,
physically or logically, to the network it is accessing.
Reputation The beliefs or opinions that are generally held about someone or Oxford English
something. Dictionary
Residual Risk Risk remaining after risk treatment. ISO/IEC 27000:2016
Retention A document listing all the titles of each document or record will be
Schedule retained as an active record, the period of retention, when the
retention period starts and the reason for its retention
(administrative, legal, fiscal, and historical). A clearly defined plan
for a record retention and disposal is a vital component of a records
management program.
Review, A Review, Retention and Disposal (RRD) policy defines what an
Retention and organisation should do in terms retaining or disposing (i.e.
Disposal destroying) information – including personal data. This is in order to
be compliant with various legislation in terms of retaining
information (e.g. Companies Act for finance and accounting records)
and not retaining personal data for longer than necessary to be
compliant with principle 5 of the Data Protection Act.
The implementation of this policy is usually expressed with a
retention schedule.
Risk Effect of uncertainty on objectives. ISO/IEC 27000:2016
Risk Acceptance Informed decision to take a particular risk. ISO/IEC 27000:2016
Risk Analysis Process to comprehend the nature of risk and to determine the ISO/IEC 27005:2011
level of risk.
Risk Appetite Amount and type of risk that an organization is willing to pursue or ISO Guide 73:2009
retain.
Risk The overall process of risk identification, risk analysis and risk ISO/IEC 27005:2011
Assessment evaluation
Risk Avoidance Informed decision not to be involved in, or to withdraw from, an ISO Guide 73:2009
activity in order not to be exposed to a particular risk.

Risk Criteria Terms of reference against which the significance of a risk is ISO/IEC 27005:2011
evaluated.
Risk Evaluation Process of comparing the results of risk analysis with risk criteria to ISO/IEC 27005:2011
determine whether the risk and/or its magnitude is acceptable or
tolerable.
Risk Process of finding, recognizing and describing risks ISO/IEC 27005:2011
Identification
Risk IT Risk IT provides an end-to-end, comprehensive view of all risks
related to the use of IT and a similarly thorough treatment of risk
management. It is aligned with COBIT.
Risk Coordinated activities to direct and control an organization with ISO/IEC 27005:2011
Management regard to risk.
Risk Systematic application of management policies, procedures and ISO/IEC 27000:2016
Management practices to the activities of communicating, consulting, establishing
Process the context and identifying, analysing, evaluating, treating,
monitoring and reviewing risk
Risk A methodology that provides a systematic approach to performing
Management risk assessment and then undertaking risk treatment.
Methodology
Risk The level of risk should be managed by introducing, removing or ISO/IEC 27005:2011
Modification altering controls so that the residual risk can be reassessed as being
acceptable.
Risk Owner Person or entity with the accountability and authority to manage a ISO/IEC 27000:2016
risk
Risk Retention Acceptance of the potential benefit of gain, or burden of loss, from ISO Guide 73:2009
a particular risk.
Risk Sharing Form of risk treatment involving the agreed distribution of risk with ISO Guide 73:2009
other parties.
Risk Tolerance Organization's or stakeholder's readiness to bear the risk after risk ISO Guide 73:2009
treatment in order to achieve its objectives.
Risk Treatment Process to modify risk. ISO/IEC 27005:2011
Risk Treatment A plan of actions on how risks, usually found during a vulnerability
Plan assessment or penetration test, are to be addressed. Also known as
a Remediation Action Plan (RAP).
Role Based Role-based access control (RBAC) is a method of controlled access
Access Control to data or applications based on the roles of individual users within
an enterprise.
Rootkit A set of tools used by an attacker after gaining root-level access to a NISTIR 7298
host to conceal the attacker’s activities on the host and permit the
attacker to maintain root-level access to the host through covert
means.
S/MIME Secure Multi-Purpose Internet Mail Extensions is a secure method
of sending e-mail. S/MIME is included in the latest versions of the
Web browsers from Microsoft and Netscape
SABSA SABSA is a proven framework and methodology used successfully
around the globe to meet a wide variety of Enterprise needs
including Risk Management, Information Assurance, Governance,
and Continuity Management.

Salt A non-secret value that is used in a cryptographic process, usually to NISTIR 7298
ensure that the results of computations for one instance cannot be
reused by an Attacker.
A salt is random data that is used as an additional input to a one-
way function that "hashes" a password or passphrase. The primary
function of salts is to defend against dictionary attacks or against its
hashed equivalent, a pre-computed rainbow table attack.
Sarbanes-Oxley The Sarbanes-Oxley Act of 2002 (SOX) is legislation passed by the
Act U.S. Congress to protect shareholders and the general public from
accounting errors and fraudulent practices in the enterprise, as well
as improve the accuracy of corporate disclosures.
Screened Sub- A host or network segment inserted as a “neutral zone” between an
net organisation’s private network and the Internet. Also known as a
DMZ (Demilitarized Zone).
Secure Coding The practice of developing computer software in a way that guards
against the accidental introduction of vulnerabilities. Defects, bugs
and logic flaws are consistently the primary cause of commonly
exploited software vulnerabilities.
Secure Also known as hardening.
Configuration
Secure Sockets Secure Sockets Layer (SSL) is a security technology for establishing
Layer an authenticated and encrypted link between a server and a
client—typically a web server and a browser, or a mail server and a
mail client. Now overtaken by Transport Layer Security.
Secure the A security design principle. Usually attackers go after the weakest
Weakest Link point in a system. When it comes to secure design, consider the
weakest links in a system and ensure that they are secure enough.
Security Security Assertion Markup Language (SAML) is an XML-based, open-
Assertion standard data format for exchanging authentication and
Markup authorisation data between parties. Can be used to support identity
Language federation
Security The knowledge and attitude members of an organisation possess
Awareness regarding the protection of the assets of that organisation including
physical and information assets.
Security Culture Describes the kind of behaviours organisations would like to see in
their employees, in areas like cybersecurity, physical security and
personnel security.
Security Design A set of principles using in designing a system or coding an
Principles application or services
Security The Security Development Lifecycle (SDL or SDLC) is a software
Development development process that helps developers build more secure
Lifecycle software from its inception all the way to its decommission.
Security A set of subjects, their information objects, and a common security NISTIR 7298
Domain policy.
A collection of entities to which applies a single security policy
executed by a single authority.
A domain that implements a security policy and is administered by
a single authority.
Security Security information and event management (SIEM) software
Information products and services combine security information management
and Event (SIM) and security event management (SEM). They provide real-
Management time analysis of security alerts generated by network hardware and
applications.
Security A set of security procedures that are usually used to implement a
Operating particular policy.
Procedures
Security A SOC is a centralised unit that deals with security issues on an
Operations organisational and technical level. It is deployed to monitor, detect
Centre and handle security incidents.
Security Policy SPF. Describes the principles and approaches that HMG applies to
Framework protect its assets, be they people, infrastructure or information,
whilst at the same time assisting in the delivery of public services.
Security Target Implementation-dependent statement of security needs for a ISO/IEC 15408
specific identified TOE.
Sensitive Security-related information (including but not limited to card PCI DSS
Authentication verification value (CVV), full track data (from the magnetic stripe or
Data equivalent on a chip), PINs, and PIN blocks) used to authenticate
cardholders and/or authorize payment card transactions.
Sensitive In this Act “sensitive personal data” means personal data consisting Data Protection Act
Personal Data of information as to—
(a) the racial or ethnic origin of the data subject,
(b) his political opinions,
(c) his religious beliefs or other beliefs of a similar nature,
(d) whether he is a member of a trade union (within the meaning of
the Trade Union and Labour Relations (Consolidation) Act 1992),
(e) his physical or mental health or condition,
(f) his sexual life,
(g) the commission or alleged commission by him of any offence, or
(h) any proceedings for any offence committed or alleged to have
been committed by him, the disposal of such proceedings or the
sentence of any court in such proceedings.
Separation of Separation of Duties (SoD) is the concept of having more than one
Duties person required to complete a task. In business the separation by
sharing of more than one individual in one single task is an internal
control intended to prevent fraud and error. Also known as
"Segregation of Duties” Related to this concept is the Two Person
Rule. This requires two persons to complete a particular function,
for instance to logon to an administrative account.
Shared A shared responsibility model is a cloud security framework that
Responsibility dictates the security obligations of a Cloud Provider and the
Model consumer of its services.
Shoulder A type of social engineering technique used to obtain information
Surfing such as personal identification number, password and other
confidential data by looking over the victim's shoulder.
Simple Object Simple Object Access Protocol (SOAP) is a messaging protocol that
Access Protocol allows programs that run on disparate operating systems to
communicate using HTTP and the eXtensible Markup Language
(XML).
Single Sign-On Single Sign-On (SSO) is when a user logs in to one client and is then
signed in to other clients automatically, regardless of the platform,
technology, or domain the user is using.
Situational Within a volume of time and space, the perception of an NISTIR 7298
Awareness enterprise’s security posture and its threat environment; the
comprehension/meaning of both taken together (risk); and the
projection of their status into the near future.

Social A general term for attackers trying to trick people into revealing NISTIR 7298
Engineering sensitive information or performing certain actions, such as
downloading and executing files that appear to be benign but are
actually malicious
Software as a The capability provided to the consumer is to use the provider’s NIST_SP_800_145
Service applications running on a cloud infrastructure. The applications are
accessible from various client devices through either a thin client
interface, such as a web browser (e.g., web-based email), or a
program interface. The consumer does not manage or control the
underlying cloud infrastructure including network, servers,
operating systems, storage, or even individual application
capabilities, with the possible exception of limited user-specific
application configuration settings.
Software Software-defined networking (SDN) is a term used to describe
Defined network technology that is aimed at making the network as agile
Networking and flexible as the virtualized server and storage infrastructure of
the modern data centre, typically providing cloud services.
Source A process that provides assurance of the source of information. NIST SP 800-175B
Authentication
See also Authenticity.
Spam Unsolicited e-mails, which can carry malicious contents and/or scam ISO/IEC 27033-1:2009
messages.
Span Port The ability to copy traffic from any or all traffic ports to a single
unused port on a network switch. Also called port mirroring.
Spear Phishing Occurs when attackers obtain information about an individual (e.g.
from websites or social networking sites), and customise a phishing
attack against that individual.
Spoofing Impersonating a legitimate resource or user ISO/IEC 27033-1:2009
Spyware Software that is secretly or surreptitiously installed into an NISTIR 7298
information system to gather information on individuals or
organizations without their knowledge; a type of malicious code.
SQL Injection A type of code injection technique, used to attack data-driven
applications, in which malicious SQL statements are inserted into an
entry field for execution.
SSL Accelerator A device that uses separate hardware to perform processor-
intensive cryptographic operations for Transport Layer Security
(TLS) and its predecessor Secure Sockets Layer (SSL).
Standard A required or accepted level of quality or achievement. Oxford English
Dictionary
Stateful Packet A firewall technology that monitors the state of active connections
Filtering and uses this information to determine which IP packets to allow
through the firewall.
Stateless Packet Looks at each IP packet in isolation and makes decisions about
Filtering whether it be allowed through purely by inspecting the header
information in the IP packet. Stateless packet filtering is usefully
performed by network routers. Firewall technology tends to use
stateful packet filtering.
Statement of The SoA is one of the key documents in an ISO/IEC 27001 ISMS. It
Applicability identifies the controls relevant to an organisation and explains why
those controls have been selected to treat the identified risks.

Static Code A method of program debugging that is done by examining the code
Analysis without executing the program. The process provides an
understanding of the code structure, and can help to ensure that
the code adheres to industry standards. Automated tools can assist
programmers and developers in carrying out static analysis.
Strategy A plan designed to achieve a particular long-term overall aim. Oxford English
Dictionary
STRIDE STRIDE is a system developed by Microsoft for performing threat
modelling.
Strong A user password that is complex with a combination of uppercase,
Password lowercase, numbers and special characters. That is a password with
good password strength.
Subject Generally an individual, process, or device causing information to NISTIR 7298
flow among objects or changes to the system state
A process executing on behalf of a user

Subject Access The right that a data subject has under the Data Protection Act to
Request obtain from any organisation the information that is held about
them by that organisation.
Superuser A special user account used for system administration. Depending
on the operating system, the actual name of this account might be
root, administrator, admin or supervisor.
Supervisory Supervisory Control And Data Acquisition (SCADA) is a control
Control and system architecture that uses computers, networked data
Data communications and graphical user interfaces for high-level process
Acquisition supervisory management. See also ICS.
Symmetric Algorithm which use the same cryptographic key for both
Algorithm encryption of plaintext and decryption of ciphertext.
Symmetric Key A cryptographic key used in symmetric cryptography.
Target of Set of software, firmware and/or hardware possibly accompanied ISO/IEC 15408
Evaluation by guidance.
It defines the scope of a product or system evaluation and is a term
used by Common Criteria Evaluation methodology. Often just
referred as TOE.
Technical Security controls (i.e., safeguards or countermeasures) for an NISTIR 7298
Security information system that are primarily implemented and executed
Controls by the information system through mechanisms contained in the
hardware, software, or firmware components of the system.
Tenant In respect of Cloud computing a tenant is a group of users who
share a common access with specific privileges to the software
instance.
The Open The TOGAF® framework is the de facto global standard for
Group Enterprise Architecture produced by The Open Group.
Architecture
Framework
Threat A threat has the potential to harm assets such as information, ISO/IEC 27005:2011
processes and systems and therefore organisations. Threats may be
of natural or human origin, and could be accidental or deliberate.
Threat Actor A threat actor is a person who actually performs an attack or, in the
case of accidents, will cause the accident.
Threat Agent Originator and/or initiator of deliberate or accidental man-made ISO/IEC 21827:2008
threats.
Synonymous with Threat Source.
Threat Evidence-based knowledge, including context, mechanisms,
Intelligence indicators, implications and actionable advice, about an existing or
emerging menace or hazard to assets that can be used to inform
decisions regarding the subject’s response to that menace or
hazard.
Threat A process by which potential threats can be identified, enumerated,
Modelling and prioritised – all from a hypothetical attacker’s point of view. The
purpose of threat modelling is to provide defenders with a
systematic analysis of the probable attacker’s profile, the most likely
attack vectors, and the assets most desired by an attacker.
Threat Scenario A set of discrete threat events, attributed to a specific threat source NIST SP 800-30
or multiple threat sources, ordered in time, that result in adverse
effects.
Threat Source The intent and method targeted at the intentional exploitation of a NISTIR 7298
vulnerability or a situation and method that may accidentally trigger
a vulnerability. Synonymous with Threat Agent.
Tigerscheme Tigerscheme is a commercial certification scheme for technical
security specialists, backed by University standards and covering a
wide range of expertise.
Transport Layer Transport Layer Security (TLS) and its predecessor, Secure Sockets
Security Layer (SSL), both frequently referred to as "SSL", are cryptographic
protocols that provide communications security over a computer
network. It enables confidentiality, integrity and source
authentication protection for the data that's transmitted between
different nodes. Used for establishing an encrypted link between a
server and a client—typically a web server and a browser, or a mail
server and a mail client.
Trojan Horse A computer program that appears to have a useful function, but NISTIR 7298
also has a hidden and potentially malicious function that evades
security mechanisms, sometimes by exploiting legitimate
authorizations of a system entity that invokes the program.
Trustworthy A UK not-for-profit organisation, with stated aim of improving
Software software. As taken from the web site “The Trustworthy Software
Foundation Foundation (TSFdn) aims to collect, organise and share the wealth of
knowledge, experience and capabilities that already exist in the UK
public and private sectors and in academia about trustworthy
software to give people a joined-up, curated view of the information
that is available”.
User The process of validating a supplied user identity.
Authentication
Virtual LAN Logical segmentation of a LAN into different broadcast domains. A
Virtual LAN (VLAN) is set up by configuring ports on a network
switch, so devices attached to these ports may communicate as if
they were attached to the same physical network segment,
although the devices are located on different LAN segments. A VLAN
is based on logical rather than physical connections.

Virtual Private A VPN is a private network which is implemented by using the ISO/IEC 27033-1:2009
Network infrastructure of existing networks. From a user perspective a VPN
behaves like a private network, and offers similar functionality and
services. A VPN can be used in various situations, such as to:
• Implement remote access to an organization from mobile or
off-site employees,
• Link different locations of an organization together, including
redundant links to implement a fall-back infrastructure,
• Set up connections to an organization’s network for other
organizations/business partners.
Virus Computer program that self-replicates and automatically spreads
between systems. A form of malware.
Virus Signature A virus signature is the fingerprint of a virus. It is a set of unique
data, or bits of code, that allow it to be identified. Antivirus
software uses a virus signature to find a virus in a computer file
system, allowing to detect, quarantine and remove the virus.
Vulnerability Weakness of an asset or control that can be exploited by one or ISO/IEC 27000:2016
more threats
Vulnerability Vulnerability assessment is the process of identifying vulnerabilities
Assessment within a system. This could be a software system, a physical system
or even a mechanical system, and the testing can be targeted to
focus on components that might be technical, physical or even
administrative in their nature. Typically a vulnerability assessment
does not try and break into a system – unlike penetration testing.
Vulnerability assessment is where tools are used to scan a system or
network for a list of known vulnerabilities, such as system
misconfiguration, outdated software, or a lack of patching.
Vulnerability The practice of identifying, classifying and mitigating vulnerabilities.
Management Vulnerabilities can be from vulnerabilities assessments, external
sources or from threat intelligence.
Warning, Warning, Advice and Reporting Point (WARP) is a community or
Advice and internal company-based service to share advice and information on
Reporting Point computer-based threats and vulnerabilities.
Web A firewall that monitors, filters or blocks the HTTP traffic to and
Application from a Web application. They typically reside on a server.
Firewall
Web Filtering A program or device that screens an incoming web page and
restricts or controls its content.
White Box White box testing is when information about the organisation’s
Testing application, infrastructure or network is provided to the tester. The
tester performs the test with full knowledge of the infrastructure,
defence mechanisms and communication channels of the target
organisation.
Whitelist A list of people or things considered to be acceptable or Oxford English
trustworthy. Dictionary
Worm A computer worm is a standalone malware computer program that
replicates itself in order to spread to other computers. Often, it uses
a computer network to spread itself, relying on security failures on
the target computer to access it. Unlike a computer virus, it does
not need to attach itself to an existing program.
WS-Security An extension to SOAP to apply security to Web services. It was
published by OASIS.

Zero-Day A ‘zero-day’ is a vulnerability which is not publicly known and has
Exploit not been patched by the software developer. The exploit is how a
zero-day vulnerability is leveraged.

5. Abbreviations and Acronyms
3DES Triple DES
ABAC Attribute-based Access Control
ACE Access Control Entry
ACL Access Control List
AD Microsoft Active Directory
ADM Architecture Development Method
ADP Accreditation Decision Point
AES Advanced Encryption Standard
AH Authentication Header
AIA Authority Information Access
ARP Address Resolution Protocol
ASP Active Server Page
ASPX Active Server Page Extended File
ASVS OWASP Application Security Verification Standard
AV Antivirus
BCM Business Continuity Management
BCP Business Continuity Plan

Best Current Practice
BCS The Chartered Institute for IT. (Formerly known as the British Computer
Society)
BGP Border Gateway Protocol
BIA Business Impact Analysis

Business Impact Assessment
BIL Business Impact Level
BMS Building Management System
BPD Border Protection Device
BSI British Standards Institute
BYOD Bring Your Own Device

CA Certificate Authority
Certification Authority
CAB Change Advisory Board
CAPS CESG Assisted Products Service
CBC Cipher Block Chaining
CC Common Criteria
CCB Change Control Board

Configuration Change Board
CCP CESG Certified Professional
CCRA Common Criteria Recognition Arrangement
CDP CRL Distribution Point
CDPA Copyright, Designs and Patents Act 1988
CEH Certified Ethical Hacker
CEM Common Methodology for Information Technology Security Evaluation
CERT Computer Emergency Readiness Team
CESG Communications-Electronics Security Group (UK). Now subsumed into the

NCSC.
CFM Cipher Feedback Mode
CI Configuration Item
CIA Confidentiality, Integrity and Availability
CISA Certified Information Systems Auditor
CISM Certified Information Security Manager
CIO Chief Information Officer
CIRT Computer Incident Response Team
CIS Centre for Internet Security

Computer Information System
CISA Certified Information Systems Auditor
CISM Certified Information Security Manager
CISMP Certificate in Information Security Management Principles
CISO Chief Information Security Officer

CISSP Certified Information Systems Security Professional
CMA Computer Misuse Act
CMS Cryptographic Message Syntax
CMVP Cryptographic Module Validation Program
CNI Critical National Infrastructure
COBIT Control Objectives for Information and Related Technologies
CoCo Code of Connection
COTS Commercial off-the-shelf
CPA Commercial Product Assurance
CPNI Centre for the Protection of National Infrastructure (UK)
CPS Certification Practice Statement
CRISC Certified in Risk and Information Systems Control
CRC Cyclic Redundancy Check
CREST Council of Registered Ethical Security Testers
CRL Certificate Revocation List
CRTSA CREST Registered Technical Security Architect
CRUD Create, Read, Update, Delete
CSA Cloud Security Alliance
CSS Cascading Style Sheet
CSI Continual Service Improvement
CSIRT Computer Security Incident Response Team
CSP Communication Service Provider
CSRF Cross-site Request Forgery
CST Cryptographic and Security Testing
CTAS CESG Tailored Assurance Service
CTO Chief Technology Officer
CVV Card Verification Value
CVE Common Vulnerabilities and Exposures

CVSS Common Vulnerability Scoring System
CWE Common Weaknesses Enumeration
CyBOK Cyber Security Body of Knowledge
DAC Discretionary Access Control
DDoS Distributed Denial of Service
DES Data Encryption Standard
DFD Data flow Diagram
DH Diffie-Hellman
DHCP Dynamic Host Configuration Protocol
DISA Defense Information Systems Agency (US)
DLP Data Loss Prevention
DMCA Digital Millennium Copyright Act (US)
DMZ Demilitarized Zone
DNS Domain Name System
DNSSEC DNS Security
DoD Department of Defense (US)
DPO Data Protection Officer
DoS Denial of Service
DPA Data Protection Act (UK)
DPD Data Protection Directive (EU)
DPIA Data Protection Impact Assessment
DR Disaster Recovery
DRM Digital Rights Management
DSA Digital Signature Algorithm
DSO Departmental Security Officer
DSS Digital Signature Standard
E-DRM Enterprise Digital Rights Management
EA Enterprise Architecture

EAL Evaluation Assurance Level
ECB Electronic Code Book
ECC Elliptical Curve Cryptography
EE End Entity
EPL Evaluated Products List
ESP Encapsulating Security Payload
EWP Evaluation Work Programme
FAT Factory Acceptance Test
FDE Full Disk Encryption
FIPS Federal Information Processing Standards (US)
FLE File-level Encryption
FOI Freedom of Information Act
FQDN Fully-qualified Domain Name
FTP File Transfer Protocol
FTPS FTP over SSL
GCHQ Government Communications Headquarters (UK)
GDPR General Data Protection Regulation
GOTS Government Off The Shelf
GPO Group Policy Object
GRC Governance, Risk and Compliance
HAG High Assurance Gateway
HIDS Host Intrusion Detection System
HIPAA Health Insurance Portability and Accountability Act (US)
HIPS Host Intrusion Prevention System
HMAC Hash-based Message Authentication Code
HMG Her Majesty's Government (UK)
HMI Human–Machine Interface
HR Human Resource

HRA Human Rights Act
HSM Hardware Security Module

High Security Module
HTTPS Hypertext Transfer Protocol over TLS or SSL
HVAC Heating, ventilation and air conditioning
I&A Identification and Authentication
IaaS Infrastructure as a Service
IAM Identity and Access Management
IAMM HMG IA Maturity Model
IANA Internet Assigned Numbers Authority
IAO Information Asset Owner
ICA Independent Computing Architecture
ICANN Internet Corporation for Assigned Names and Numbers
ICMP Internet Control Message Protocol
ICO Information Commissioner's Office
ICS Industrial Control Systems
ICT Information Communications Technology
IdAM Identity and Access Management
IDEA International Data Encryption Algorithm
IDS Intrusion Detection System
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronics Engineers
IET Institution of Engineering and Technology
IETF Internet Engineering Task Force
IHM Information Handling Model
IIS Internet Information Services

Internet Information Server
IISP Institute of Information Security Professionals
IKE Internet Key Exchange

IPC Investigatory Powers Commission
IPR Intellectual Property Rights
IPS Intrusion Prevention System
IPsec Internet Protocol Security
IRAM2 Information Risk Analysis Methodology 2.
IRM Information Rights Management

Information Risk Management
ISACA Previously known as Information Systems Audit and Control Association
iSCSI Internet Small Computer Systems Interface
ISF Information Security Forum
ISM Information Security Management
ISMS Information Security Management System
ISO International Organization for Standardization
ISP Internet Service Provider
ISSAF Information Systems Security Assessment Framework
ISSEA International Systems Security Engineering Association
ITIL Previously known as Information Technology Infrastructure Library
ITSMF IT Service Management Forum
ITSO IT Security Officer
ITU International Telecommunication Union
KEA Key Exchange Algorithm
LAN Local Area Network
LDAP Lightweight Directory Access Protocol
MAC Mandatory Access Control

Media Access Control (network)
Message Authentication Code (crypto)
MD4 Message-Digest algorithm number four
MD5 Message-Digest algorithm number five
MDM Mobile Device Management
MFD Multi-Function Device

MIB Management Information Base
MIME Multi-Purpose Internet Mail Extensions
MITM Man-in-the-Middle
MLS Multi-level Security
MODAF MOD Architecture Framework
MTBF Mean Time Between Failures
MTMO Marlin Trust Management Organization
MTPD Maximum Tolerable Period of Disruption
MX Mail Exchange record
NAF NATO Architecture Framework
NAS Network Attached Storage
NAT Network Address Translation
NATO North Atlantic Treaty Organization
NCA National Crime Agency (UK)
NCSC National Computer Security Center (US)

National Cyber Security Centre (UK)
National Cyber Skills Centre (UK)
NFS Network File System
NIC Network Interface Card
NIDS Network Intrusion Detection System
NIPS Network Intrusion Prevention System
NIST National Institute of Standards and Technology (US)
NISTIR NIST Glossary of Key Information Security Terms
NMAP Network Mapper
NMC Network Management Centre
NOC Network Operations Centre
NSA National Security Agency (US)
NTP Network Time Protocol
NVD National Vulnerability Database

NVLAP National Voluntary Laboratory Accreditation Program
O-ESA Open Enterprise Security Architecture
OASIS Organization for the Advancement of Structured Information Standards
OAT Operational Acceptance Testing
OCSP Online Certificate Status Protocol
OCTAVE Operationally Critical Threat, Asset, and Vulnerability Evaluation
ODRL Open Digital Rights Language
OFM Output Feedback Mode
OGC Office of Government and Commerce (UK)
OID Object Identifier
OLA Operational Level Agreement
OSA Open Security Architecture
OSI Open Systems Interconnection
OSINT Open Source Intelligence
OSSTMM Open Source Security Testing Methodology Manual
OWASP Open Web Application Security Project
PaaS Platform as a Service
PAS Publicly Available Specification
PCI DSS Payment Card Industry Data Security Standard
PDP Policy Decision Point
PECR Privacy and Electronic Communications Regulations
PEP Policy Enforcement Point
PGP Pretty Good Privacy
PHP Originally stood for Personal Home Page it now stands for PHP: Hypertext
Preprocessor
PIA Privacy Impact Assessment
PKCS Public-Key Cryptography Standards
PKI Public Key Infrastructure
PKIX Public-Key Infrastructure (X.509) Working Group

PLC Programmable Logic Controller
PPDR Predict, Prevent, Detect, Respond
QSA Qualified Security Assessor
RA Registration Authority
RBAC Role-Based Access Control
RC2 RC stands for "Ron's Code" or "Rivest Cipher". A symmetric cryptographic

algorithm designed by Ron Rivest.
RC4 RC stands for "Ron's Code" or "Rivest Cipher". A symmetric cryptographic

algorithm designed by Ron Rivest.
RCP Remote Copy
RDP Remote Desktop Protocol
REST REpresentational State Transfer
RFB Remote Frame Buffer
RFC Request for Comments
RNG Random Number Generator
ROC Report On Compliance
ROI Return On Investment
RSA Rivest-Shamir-Adleman
RSH Remote Shell
RTO Recovery Time Objective
RTU Remote Terminal Unit
RWE Read, Write, Execute
S/MIME Secure Multi-Purpose Internet Mail Extensions
SA Security Architect
Security Association
SaaS Software as a Service
SABSA Sherwood Applied Business Security Architecture
SAML Security Assertion Markup Language
SAN Storage Area Network
SAQ Self-Assessment Questionnaire

SASL Simple Authentication and Security Layer
SAT Site Acceptance Test
SCADA Supervisory Control and Data Acquisition
SCEP Simple Certificate Enrolment Protocol
SCP Secure Copy
SDL Security Development Lifecycle
SDLC Security Development Life Cycle
SEI Software Engineering Institute
SFTP SSH File Transfer Protocol
SID Security Identifier (Microsoft Windows)

System Identifier (Oracle)
SIEM Security Information and Event Management
SIRO Senior Information Risk Owner
SLA Service Level Agreement
SMART Specific, Measurable, Achievable, Realistic and Time-related (or Time-

bounded)
SME Subject Matter Expert
SMI Structure of Management Information
SMTP Simple Mail Transfer Protocol
SNMP Simple Network Management Protocol
SOA Service Oriented Architecture
SoA Statement of Applicability
SOAP Simple Object Access Protocol
SOC Security Operations Centre
SoS System of Systems
SOX Sarbanes-Oxley Act (US)
SPF Security Policy Framework (UK)
SQL Structured Query Language
SRP Secure Remote Password protocol

SSE-CMM Systems Security Engineering Capability Maturity Model
SSH Secure Shell
SSID Service Set Identifier
SSL Secure Sockets Layer
SSO Single Sign-On
ST Security Target
STIG Security Technical Implementation Guide
STIX Structured Threat Information Expression
STRIDE Spoofing, Tampering, Repudiation, Information, Denial of service, Elevation of

privilege
SUSE Originally meant “Software- und System-Entwicklung”
SWOT Strengths, Weaknesses, Opportunities and Threats
TAXII Trusted Automated Exchange of Indicator Information
TCB Trusted Computing Base
TCP/IP Transmission Control Protocol (TCP) and the Internet Protocol (IP)
TLS Transport Layer Security
TOE Target of Evaluation
TOGAF The Open Group Architecture Framework
TPM Trusted Platform Module
TRM Technical Reference Model
UAT User Acceptance Test
UDP User Datagram Protocol
URI Uniform Resource Identifier
URL Uniform Resource Locator
VA Validation Authority
VLAN Virtual Local Area Network
VM Virtual Machine
VPN Virtual Private Network
WAN Wide Area Network

WARP Warning, Advice and Reporting Point
WEP Wired Equivalent Privacy
WPA Wi-Fi Protected Access
WSS Web Services Security
XaaS Anything as a Service
XML eXtensible Markup Language
XSRF Cross-site request forgery, also abbreviated as CSRF
XSS Cross Site Scripting

6. Skill Areas to Knowledge Areas
On the following page is a mind map containing a mapping from the IISP Skill Areas to the various
Knowledge Areas and sub areas. You will notice that many of the IISP Skill Areas to more than one
Knowledge Area.
A separate png file of the mind map is available.

2017 Copyright © The Institute of Information Security Professionals. All rights reserved. The Institute of Information Security Professionals®, IISP®, A.Inst.ISP™, M.Inst.ISP®, F.Inst.ISP™ and various IISP graphic logos are
trademarks owned by The Institute of Information Security Professionals and may be used only with express permission of the Institute.
Evesham & Postal Office
Basepoint Business Centre
Crab Apple Way
Evesham
Worcestershire
WR11 1GP
London Office
CAN Mezzanine
32-36 Loman Street
London
SE1 0EH
Website: www.iisp.org

IISP Knowledge Framework v1.0 - 2017-August

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IISP Knowledge Framework v1.0 - 2017-August

Uploaded by

Copyright:

Available Formats

IISP Knowledge Framework

Version 1.0 | August 2017

Non-Commercial - No Derivatives (BY-NC-ND) license.

IISP Knowledge Framework Version 1.0 August 2017 Page 1 of 195

IISP Knowledge Framework Version 1.0 August 2017 Page 2 of 195

Non-Commercial - No Derivatives (BY-NC-ND) license.

IISP Knowledge Framework Version 1.0 August 2017 Page 3 of 195

Non-Commercial - No Derivatives (BY-NC-ND) license.

IISP Knowledge Framework Version 1.0 August 2017 Page 4 of 195

Non-Commercial - No Derivatives (BY-NC-ND) license.

IISP Knowledge Framework Version 1.0 August 2017 Page 5 of 195

Level 2: (Knowledge and Understanding) Knowledge and Understanding of basic

The objectives of the Knowledge Framework are to:

Non-Commercial - No Derivatives (BY-NC-ND) license.

IISP Knowledge Framework Version 1.0 August 2017 Page 6 of 195

Non-Commercial - No Derivatives (BY-NC-ND) license.

IISP Knowledge Framework Version 1.0 August 2017 Page 7 of 195

Figure 2 - Structure of the Knowledge Framework

Non-Commercial - No Derivatives (BY-NC-ND) license.

IISP Knowledge Framework Version 1.0 August 2017 Page 8 of 195

Non-Commercial - No Derivatives (BY-NC-ND) license.

IISP Knowledge Framework Version 1.0 August 2017 Page 9 of 195

Non-Commercial - No Derivatives (BY-NC-ND) license.

IISP Knowledge Framework Version 1.0 August 2017 Page 10 of 195

2.1. Goals and Principles

Non-Commercial - No Derivatives (BY-NC-ND) license.

IISP Knowledge Framework Version 1.0 August 2017 Page 11 of 195

2.2.1. Risk Management

Non-Commercial - No Derivatives (BY-NC-ND) license.

IISP Knowledge Framework Version 1.0 August 2017 Page 12 of 195

Non-Commercial - No Derivatives (BY-NC-ND) license.

IISP Knowledge Framework Version 1.0 August 2017 Page 13 of 195

As an example of how the risk wheel works for a zero-day vulnerability:

Non-Commercial - No Derivatives (BY-NC-ND) license.

IISP Knowledge Framework Version 1.0 August 2017 Page 14 of 195

Figure 4 - Gartner's Predict, Prevent, Detect, Respond Framework

Non-Commercial - No Derivatives (BY-NC-ND) license.

IISP Knowledge Framework Version 1.0 August 2017 Page 15 of 195

Non-Commercial - No Derivatives (BY-NC-ND) license.

IISP Knowledge Framework Version 1.0 August 2017 Page 16 of 195

Non-Commercial - No Derivatives (BY-NC-ND) license.

IISP Knowledge Framework Version 1.0 August 2017 Page 17 of 195

2.2.2. Threat Modelling

Non-Commercial - No Derivatives (BY-NC-ND) license.

IISP Knowledge Framework Version 1.0 August 2017 Page 18 of 195

IP address Spoof ARP Poisoning

Figure 7 - Attack Tree

Non-Commercial - No Derivatives (BY-NC-ND) license.

IISP Knowledge Framework Version 1.0 August 2017 Page 19 of 195

Non-Commercial - No Derivatives (BY-NC-ND) license.

IISP Knowledge Framework Version 1.0 August 2017 Page 20 of 195

2.2.3. Vulnerability Assessment/Management and Penetration Testing

Non-Commercial - No Derivatives (BY-NC-ND) license.

IISP Knowledge Framework Version 1.0 August 2017 Page 21 of 195

Non-Commercial - No Derivatives (BY-NC-ND) license.

IISP Knowledge Framework Version 1.0 August 2017 Page 22 of 195

• Common Vulnerabilities and Exposures (CVE)

Commercial tools exist to assist organisations in performing vulnerability management.

Non-Commercial - No Derivatives (BY-NC-ND) license.

IISP Knowledge Framework Version 1.0 August 2017 Page 23 of 195

2.2.5. Topical References

Non-Commercial - No Derivatives (BY-NC-ND) license.

IISP Knowledge Framework Version 1.0 August 2017 Page 24 of 195