1

Information Security Risk Management

May 2019

2

Document Information

Document name:

Information Security Risk Management

Prepared By: Robert Morgan Document Version No: 1.1

Published date June 2019 Next review Date: April 2010

Reviewed By:

Security Committee 28 May 2019

Version History

Ver No.

Ver. Date Revised By

Description Filename

0.1 March 2018 R Morgan First Draft

0.2 March 2018 R Morgan Initial comments from NS incorporated

1.0 April 2018 R Morgan Validated by Security Committee

1.1 May 2019 R Morgan Annual Review Updated risk appetite to “Averse”

3

Table of Contents

1 INFORMATION SECURITY RISK MANAGEMENT ........................................................................................ 4

1.1 INTRODUCTION .......................................................................................................................................... 4 1.2 PURPOSE .................................................................................................................................................. 4 1.3 DEFINITIONS .............................................................................................................................................. 4 1.4 RISK APPETITE ............................................................................................................................................ 6 1.5 ROLES & RESPONSIBILITIES ........................................................................................................................... 6 1.6 GOVERNANCE ............................................................................................................................................ 7

2 INFORMATION SECURITY RISK MANAGEMENT PROCESS ......................................................................... 7

2.1 RISK MANAGEMENT CYCLE ........................................................................................................................... 7 2.1.1 DEFINE THE CONTEXT .................................................................................................................................. 7 2.1.2 IDENTIFY ................................................................................................................................................... 8 2.1.3 RISK OWNER ............................................................................................................................................. 8 2.1.4 ASSESS ..................................................................................................................................................... 9 2.1.5 MANAGE .................................................................................................................................................. 9 2.1.6 RISK ESCALATION...................................................................................................................................... 10 2.1.7 REVIEW & REPORT ................................................................................................................................... 10

3 ANNEX A – THREATS AND VULNERABILITIES ...................................................................................... 1211

4 ANNEX B – RISK SCORE FRAMEWORK ................................................................................................ 1312

CALCULATION OF LIKELIHOOD ................................................................................................................... 1413

4

1 Information Security Risk Management

1.1 Introduction

Ofcom recognises that the need to effectively manage its risks underpins the successful delivery of its objectives. Ofcom’s Risk Management Policy and Procedure provides the context for all risk management activities carried out by Ofcom. This document focuses specifically on the management of risk to Ofcom information. It forms part of Ofcom’s Information Security Management System. Managing information security risk, like risk management in general, is not an exact science. It brings together the best collective judgments of individuals and group stakeholders. The objectives of Ofcom’s Information Security Risk Management are to:

• Maintain consistency with established Ofcom risk management oversight, governance and reporting structures.

• Ensure that risks to the confidentiality, integrity or availability of Ofcom information are identified and managed with appropriate controls and risk acceptance processes.

• Create a climate where information security risk is considered within the context of the design of business processes, and ICT development life cycle processes; and to help individuals with responsibilities for information system implementation or operation to better understand how information security risk associated with their systems translates into organisation-wide risk that may ultimately affect business success.

1.2 Purpose

The purpose of Ofcom’s information security risk management framework is to:

• identify information assets and potential threats that could exploit vulnerabilities which may result in a financial, legal or business operational impact any of which may have an adverse impact on Ofcom’s reputation

• evaluate the likelihood of those risks occurring and their impact, should they occur;

• identify appropriate controls that could mitigate the risk to an acceptable level

• manage, review and report on information security risks; and

• embed a risk aware culture into Ofcom’s wider set of business processes and into the day to day activities of colleagues.

1.3 Definitions

Term Definition

Information Security Risk

The risk to the achievement of business objectives due to the potential for unauthorized access, use, disclosure, disruption, modification, or destruction of information and/or information systems.

Risk Management

The process through which we identify, evaluate, manage and report on those risks which may impact on the achievement of our objectives. It includes: (i) establishing the context for risk-related activities;

5

Term Definition

(ii) assessing risk to information assets from threats exploiting vulnerabilities.

(iii) Deciding on risk treatment method (avoid, transfer, tolerate, treat)

(iv) identifying and implementing mitigating controls for risks that will be treated.

Assets Information, software, hardware or premises involved in the processing of information assets.

Threat An event with the potential to adversely impact organisational operations (including mission, functions or reputation), information assets or individuals.

Vulnerability Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source.

Risk Appetite The level of risk that is acceptable in the context of business operations that has been agreed and validated by the Board.

Control A safeguard or countermeasure prescribed for an information system or an organisation designed to protect the confidentiality, integrity, and availability of its information and to meet a set of defined security requirements.

Impact The financial, reputational or business effect on organisational operations, resulting from of a loss of confidentiality, integrity, or availability of information or an information system.

Likelihood Likelihood is determined by a combination of the frequency that an event has already occurred or could occur in the future and the skill/knowledge, finance or motivation that is necessary to exploit a vulnerability.

6

1.4 Risk appetite

Ofcom’s risk appetite statement is approved by the main Board. The current risk appetite for security as at February 2019 is:

“Averse” –. Avoidance of risk and uncertainty is a key organisational objective

If a change in risk appetite is noted, the information security risk register should be reviewed to ensure the risk treatment actions are sufficient to manage the risks in line with the revised risk appetite. The Board formally reviews the risk appetite statements annually and any significant changes are cascaded to the organisation through presentations to the Leadership Group, at Group and team meetings and via the Loop.

1.5 Roles & Responsibilities

Head of Risk Management & Insurance

The Head of Risk Management & Insurance is responsible for overseeing Ofcom’s risk management framework and the associated plan for continuous improvement. Information Security Manager The Information Security manager is responsible for ensuring that this policy and procedure document reflect best practice and continues to meet Ofcom’s requirements.

Steering Groups

Within the context of Ofcom’s risk appetite and consistent with this policy and process document, Steering Groups help project teams to determine the approach to information security risk that is appropriate for a particular project to take. Project Directors & Managers

Project Directors oversee the risk identification, evaluation, management and reporting that takes place at a project level and have a key role in escalating information security risk to the information security manager. Their wider perspective on how an individual project fits with and impacts on others both at the scoping and delivery phases, combined with the more project specific knowledge of the project manager allows information security risk management to be both well informed and consistent. Project managers play a key role in the successful management of risk through their input to project risk records, their regular update of this information and taking actions with their teams to manage risk. Colleagues

Most importantly, every colleague has a responsibility for contributing to the management of risk within Ofcom. We all must accept responsibility for the decisions we make, whether it be individually, collectively or as part of a project. Part of that decision-making process should involve a consideration of risks to the security of Ofcom information. We need to be aware of the impact that our actions and decisions will have not only on ourselves, our colleagues and our customers, but also our objectives and the reputation of Ofcom.

7

1.6 Governance

The Head of Risk Management & Insurance is responsible for ensuring that the overall risk management policy and process continually reflects Ofcom’s operational requirements, any appropriate legislative guidelines and best practice. Any changes should be communicated to all stakeholders. The Information Security manager owns this document and must take account of changes made to the overall risk management policy and process to ensure that consistency is maintained. The Security Committee will review this document annually for appropriateness.

2 Information Security Risk Management Process

Managing information security risk is an important part of Ofcom’s strategic and operational management and governance structure. The information security risk management process outlined in this document is consistent with Ofcom’s wider risk management framework and defines the methodology for identifying, assessing, managing and reporting information security risks.

2.1 Risk Management Cycle

It is important to recognise that risk management isn’t an activity that takes place in a silo; it should form part of your day-to-day activities. Nor is risk management a one-off exercise; it’s an ongoing cycle of identification, assessment, management and review. Ofcom’s risk management process can be illustrated as a 5 stage continual cycle.

Figure 1. Risk Management Cycle

2.1.1 Define the Context

In order to ensure that the information security risk management process delivers benefits, it is important that there is a clear understanding of the context within which the process will be applied i.e. what is it that we are trying to achieve?

Define Context

Identify

AssessManage

Review & Report

8

What are our information

assets?

What could happen?

How could it Happen?

What can be done to reduce

the Risk

The risks to Ofcom information will never be eliminated, but will be managed at an acceptable level, consistent with the risk appetite. Any security measures, mechanisms or controls that are put in place to mitigate risk, to an acceptable level, will come at a cost of either direct financial cost or impact on business processes. This document sets the foundations for the information security risk process to follow a logical path:

2.1.2 Identify

Within the context above, risks should be identified that threaten the confidentiality, integrity or availability of information. When identifying information security risks, it is important to establish what we are protecting, i.e. Information Assets. It is useful to group them firstly under the category of asset type (see below). There will be common threats, vulnerabilities and relevant controls associated with each asset type:

Information Software Hardware Premises

This methodology will allow a granular definition of vulnerabilities and identification of specific controls that can be implemented as mitigation actions. For example:

Asset Group

Asset Type Threat Threat Description Vulnerability Risk Owner Control

Information Highly Sensitive

Information Leak

Information uploaded to unauthorised internet cloud storage

Inadequate security awareness

Group Director e-Learning

Software Internet Browser

Information Leak

Information uploaded to unauthorised internet cloud storage

Access to internet Cloud storage not blocked

ICT Director Cloud storage sites blocked on browser firewall

The identified assets, threats, vulnerabilities and associated controls will be validated at workshops with key stakeholders Tables showing common threats and vulnerabilities (taken from ISO27001) can be found at Annex A

2.1.3 Risk Owner

In order to ensure accountability for the overall management of the risk, each risk should be assigned a risk owner. This will normally be the same as the Asset Owner and should be at least Director (SMS) level.

9

2.1.4 Assess

A risk is assessed by evaluating the likelihood of the threat event occurring and the potential impact should a vulnerability be exploited, and the event occurs The overall risk matrix rating for assessing both the likelihood and impact of risks is consistent with the Ofcom Risk Management policy. The framework has 5 ‘bands’, ranging from ‘very low’ to ‘very high’. There are 4 types of impact; Cost, Delay, Reputation and Objective Realisation. If a risk affects more than one impact type, then the risk should be assessed against the impact type which is most severe. For example, if a risk is assessed as having a ‘high’ likelihood and a ‘medium’ impact, it is assigned a risk score of 17.

There is an additional context for assessing the likelihood rating. This is based on a combination of the frequency and the level of expertise/knowledge required to exploit a vulnerability. Risk score framework is at Annex B Risks should be assessed at two states. The initial risk rating reflects the potential impact of the risk without consideration of any controls. The residual risk rating reflects the potential impact of the risk after mitigating controls are implemented. This assessment assumes that the mitigating actions will be delivered on time and that they are effective.

2.1.5 Manage

The purpose of the manage phase is to outline and deliver a clear decision on how identified risks will be treated. This phase of the process is critical to the realisation of benefits from managing risks. Often, considerable effort is spent in creating a risk register,

Threat Vulnerability Likelihood impact Risk Rating Control Likelihood impact Risk Rating

Information accessible

to unauthorised external

parties

Inadeqaute level of

authentication3 5 22

Two factor

authentication1 5 15

Inherent Risk Residual Risk

10

but the management of the risk treatment is overlooked. There are four key approaches for addressing risk. These are outlined in the table below.

Risk Treatment

Avoid Some risks may only be contained by stopping the underlying activity.

Mitigate/Reduce Actions are taken to mitigate or reduce the risk impact to acceptable levels by implementing controls.

Transfer For some risks the best response is to transfer the impact through insurance or contractual negotiation. It is important to recognise that not all of the impact of a risk may be transferable i.e. there may be a reputational element of a risk which is not transferable.

Tolerate A risk impact may be acceptable without any further action being taken or the ability to do anything about the risk effectively may be limited. In these cases it may be appropriate to tolerate the risk.

When developing a plan for those risks that have been selected for mitigating action it is important that it is proportional to the risk itself. In most cases (excluding safety of life etc.), actions should be designed to give a reasonable assurance of confining the impact of a risk within Ofcom’s risk appetite. It is important to recognise that mitigating actions have an associated cost, so they should be developed in such a way that they are effective in reducing the risk to an acceptable level which may not always be to eliminate it completely To ensure accountability and to allow the completion of actions to be managed, each action should be assigned an owner and an expected delivery date. Action owners are responsible for successfully completing mitigating actions and are accountable to the risk owner.

2.1.6 Risk Escalation

Information Security risks are only one category of risk that are managed using the general Ofcom risk registers (Project, Committee, Group and Strategic level registers). Any risks that that are identified in this operational level process should be used to populate the existing registers. Risk escalation should follow the existing risk escalation process.

2.1.7 Review & Report

The Information Security manager is responsible for ensuring that any changes to the Information Security risk are appropriately reflected in the Group level risk registers and considered in the review of the Strategic Risk Register. The review activity should address (but not be limited to):

• legal and environmental context

• risk assessment approach

• asset, threat and vulnerability categories

• impact criteria

• risk evaluation criteria

11

Any identified changes that may be required to address new or changed threats or vulnerabilities will be reported to the Security Committee.

12

3 Annex A – Threats and Vulnerabilities

Threats Vulnerabilities

Bomb or Terrorist attacks Default passwords not changed

Breach of contractual relations Disposal of storage media without deleting data

Breach of legislation Inadequate cabling security

Compromising confidential information Inadequate capacity management

Damage caused by a third party Inadequate change management

Destruction of records Inadequate classification of information

Disaster (human caused) Inadequate control of physical access Disaster (natural) Fire, Flood, Thunderstrike (Acts of God)

Inadequate maintenance

Eavesdropping Inadequate network management

Embezzlement Inadequate or irregular backup

Errors in maintenance Inadequate password management

Failure of communication links Inadequate physical protection

Falsification of records Inadequate protection of cryptographic keys

Fraud Inadequate replacement of older equipment

Industrial espionage Inadequate security awareness

Information leakage Inadequate segregation of duties

Interruption of business processes Inadequate segregation of operational and testing facilities

Loss of electricity Inadequate supervision of employees

Loss of support services Inadequate supervision of vendors

Malfunction of equipment Inadequate training of employees

Malicious code Incomplete specification for software development

Misuse of information systems Insufficient software testing

Misuse of audit tools Lack of access control policy

Social engineering Lack of clean desk and clear screen policy

Software errors Lack of control over the input and output data

Theft Lack of internal documentation

Unintentional change of data in an information system Lack of or poor implementation of internal audit

Unauthorized access to the information system Lack of policy for the use of cryptography

Unauthorized changes of records Lack of procedure to remove access rights at end of employment

Unauthorized installation of software Lack of protection for mobile equipment

Unauthorized physical access Lack of redundancy

Unauthorized use of copyright material Lack of systems for identification and authentication

Unauthorized use of software Lack of validation of the processed data

unauthorized Access to the network Location vulnerable to flooding

User error Uncontrolled download from the Internet

Vandalism Uncontrolled use of information systems

Undocumented software

Unprotected public network connections

User rights are not reviewed regularly

13

4 Annex B – Risk Score Framework

Like

liho

od

Very High 11 16 20 23 25

High 7 12 17 21 24

Medium 4 8 13 18 22

Low 2 5 9 14 19

Very Low 1 3 6 10 15

Very Low Low Medium High Very High

Impact

Cost <£25k

or minimal cost-over

£26k-£99k or

cost over-run can be accommodated within agreed

project budget

£100k-£499k or

cost over-run will exceed agreed project budget

£500k-£2,499k or

cost over-run may result in Group expenditure exceeding agreed

budget

>£2,500k or

cost over-run may result in total expenditure exceeding Ofcom

budget

Delay

1 day or

delay can easily be accommodated within overall

project plan

Up to 1 week or

no significant impact on benefits to consumers and citizens or

dependant projects

Up to 2 weeks or

benefits to consumers and citizens offsets 'costs' of delay

Up to 1 month or

delay may undermine the benefits to consumers and citizens

Greater than 1 month or

benefits to consumers and citizens are severely damaged by

delay

Political, stakeholder or media scrutiny

Outcome is unlikely to attract any negative commentary

Outcome that may result in isolated, low level, negative

commentary

Outcome is unlikely to be seen as controversial, but may attract

some public negative commentary and political opinion

Outcome is likely to attract some public negative commentary and political opinion but is consistent with our duties and benefits to consumers & citizens are clear

Outcome is seen as being controversial, perceived to be at

odds with our values or duties and results in overwhelming, co-

ordinated and public negative stakeholder commentary and

political opinion

Objective Realisation

Will result in a minor delay in completing a project or package

of work

Will result in the failure to successfully deliver a project or

package of work aligned to a Team objective

Will result in the failure to successfully deliver a project or

complete a package of work aligned to a Group objective

Will result in the failure to deliver one or more of Ofcom's priorities or major work areas as outlined in

the Annual Plan

Will materially undermine the achievement of a stated outcome

as defined in the Annual Plan.

The following guidelines should be followed when considering risks for escalation:

1. Where the residual risk score is ≥ 15 (this captures all risks with a very high impact)

14

Calculation of Likelihood

Frequency

Very High Likely to occur many times or has

occurred > 4 times in last year 5.0 11 16 20 23 25

High Likely to occur some times or has already occurred infrequently < 4

times per year

4.0 7 12 17 21 24

Medium unlikely to occur but possible or has occurred at least once in last 2 years

3.0 4 8 13 18 22

Low Very unlikely to occur or not known to have occurred in last 5 years. Has occurred in other similar companies

2.0 2 5 9 14 19

Very Low extremely improbable that it will occur

or is not known to have occurred in the past 5 years but it has occurred

in a UK based organisation in the past

1.0 1 3 6 10 15

0 1.0 2.0 3.0 4.0 5.0

Skill / Knowledge / Capability/ funding/ Motivation criteria (the higher the skill etc required the lower the rating as it will be available

to a smaller number of threat actors)

Nation State High level of funding and

technical expertise and

motivation

Organised

Crime/ Terrorist Group with high

level of funding,technical

expertise and motivation

Organised crime with moderate level of

funding, technical expertise and motivation

Criminal /protest group with minimal

funding, technical expertise

Little or no funding, technical skill

required.

1-5 very low

6-10 Low

11-15 Med

16-20 High

21-25 v.high

Example 1 - Internal threat – Colleague transfers Ofcom Highly sensitive information to unauthorised internet storage (i.e drop box))

NO FUNDING /SKILL REQUIRED. SCORE = 5 HAS HAPPENED IN THE PAST <4 TIMES IN A YEAR SCORE = 4

LIKELIHOOD SCORE FOR THIS EVENT HAPPENING = 24

RISK RATING FOR THIS LIKELIHOOD = VERY HIGH

MODERATE FUNDING/SKILL SCORE = 3 UNLIKELY /BUT POSSIBLE SCORE = 3

LIKELIHOOD SCORE FOR THIS EVENT HAPPENING = 13

RISK RATING FOR THIS LIKELIHOOD = MEDIUM

Example 2 - External threat –Denial of Service attack against internet facing website