Background

There’s no such thing as “Perfect Security”, and implementing excessive controls can be detremental to the business.

When I first started out on this journey of Risk Management, my boss (The Group Controller) said to me the following wise words. “Imagine a shop. Shops are prone to theft, both from customers and staff. The “safest” shop would be one where all the doors were locked tight and nobody was allowed in. Howeve this would stop the shop from achieving its purpose. Any deviation from the locked door scenario introduces risk. It’s our job to balance those risks, the potential losses they might introduce and the potential losses the business might incur if we didn’t introduce the risks. We then need to understand the costs associated with managing those risks (for example, tags that set off alarms) and the amount of loss those management controls can mitigate.”

It was this moment that I got hooked on Risk Management. Something like 10 years on, I still remember this conversation as clear as day. It can be summed up as follows:

RISK = (Value of the thing you are protecting) x (What people might do to that thing that incurs loss to the business) x (How likely the business is to fall prey to that thing)

Simplifying this:

RISK= (Asset value) x (Threat) x (Vulnerability)

Risk Management Frameworks

ISO/IEC 27005

This describes a Risk Management Process for IT that aligns with ISO/IEC27001, using controls from ISO 27002. The overview of the process can be seen in the image below, a 7 stage process that contains 5 consecutive processes, which combine with continuous monitoring and communication, and it is this process that we follow when establishing and managing risks within an organisation. 

Risk Management Process ISO/IEC 27005 2018 (P3)

Other Risk Management Frameworks exist; two others that I’m familiar with:

NIST RMF (Special Paper 800-37)

A seven-step cyclical process that aligns with Security controls found in NIST SP800-53:

1. 1. Prepare: Activities that are essential for preparing the organisation for Risk Management activities
   2. Categorize: Categorize the system and information processed, stored, and transmitted based on an impact analysis
   3. Select: Select the controls from SP800-53 to protect the system based on risk assessment(s)
   4. Implement: Implement the controls and document how controls are deployed
   5. Assess: Assess to determine if the controls are in place, operating as intended, and producing the desired results
   6. Authorize: Senior official makes a risk-based decision to authorize the system (to operate)
   7. Monitor: Continuously monitor control implementation and risks to the system

The reason NIST RMF is not favoured by me is that it does not allow for the context of the enterprise. NIST SP800-53 (and consequently the RMF) is aimed at US Federal agencies where information is (supposed to be) strictly managed and controlled.

SP800-53 has over 1000 controls listed within Control 20 families. ISO27001 has either 114 (v. 2013) or 93 (v. 2022) controls.

While this might sound like the NIST approach is more secure, as I said above, in the introduction, you need to balance risk against getting things done. And in an environment where you don’t have basically unlimited budgets and manpower, too many controls can actually reduce the security in your environment by introducing communication and responsibility gaps (“I didn’t do it because I thought it was their responsibility”, “Nobody told me that I needed to do it”).

Obviously, Communication and Responsibility Gaps can be addressed by introducing well-documented RACI charts and Communications standards, but these require a good governance framework. (See my page on Business Governance) which may not currently exist.

RISK IT

The other Risk Management Framework I’m familiar with is the RISK IT Framework, designed by ISACA (On which my CRISC credential is based), which is aligned with COBIT (See my page on Business Governance) objectives EDM03 (Ensured Risk Optimisation) and APO12 (Managed Risk)

RISK IT is designed to integrate Risk Management with business strategy. The RISK IT Framework is comprehensive in nature and strongly aligns with ISO/IEC 27005 as can be seen below; the implementation of COBIT 2019 Governance framework is strongly recommended since the RISK IT framework aligns RACI roles with that framework.

As such, we recommend ISO/IEC 27005 for enterprises that wish to gain ISO27001 certification and/or have not implemented COBIT, and RISK IT for those that have implemented COBIT (or wish to do so).

RISK IT Risk Management Workflow (RISK IT Framework 2nd Ed. ISACA 2020 p.32)

The Risk Management Process

Let’s go through the main steps for conducting Risk Management: 

Asset Discovery

“What you don’t know about, you can’t manage”, so you must go through a discovery phase to find them.

Don’t forget about shadow IT, those devices, applications, services and accounts used to store or manipulate data outside of the purview of Enterprise IT. Unmanaged data means unmanaged risk.

Assets are described by the Zero Trust Architecture as falling into 5 categories:

• Devices
  • Servers, websites, Virtual machines, IAAS and PAAS and so on. Generally, a Device can be described as a piece of software or hardware that is used to store or transmit data where the “owner” has control over how the data is stored or transmitted.
• Applications
  • Applications are those pieces of software that we use to access, manipulate or transmit data, whether Excel, Photoshop or Outlook, these are applications that are generally installed on devices.
  • OKTA’s Business at work report suggests that the average number of apps deployed by an organization is 89, with larger businesses (Larger than 2000 employees) deploying an average of 187.
• Services
  • Services can include Databases, ERP systems, Email systems and SAAS, such as Salesforce, Office 365 and Creative Cloud. Generally, a service is different from an application in that it stores data behind a presentation layer which is accessed through an application of some description. Unlike devices, generally does not allow direct access to the data. Data access is protected by Roles into which user accounts are placed.
• Accounts
  • Accounts are the way that a User is identified, this can be on a per service basis, per device basis, or federated to allow one account access to multiple services.
• Data
  • Proper data management is the goal of the Risk Management process. The crown jewels of the organisation. Risks generally occur to data in one of the CIA triad. Confidentiality, Integrity and Availability.

Identify Consequences

What would the consequences be if an organisational asset suffered a failure of the CIA Triad on an asset? What would happen if you suffered:

• Confidentiality Failure: e.g. Business secrets became public knowledge. 
• Integrity Failure: e.g. Your financial system was no longer able to produce accurate financial reporting. 
• Availability Failure: e.g. Your ERP system was not available for an extended period.

Considering the consequences of system loss allows us to put a value in our risk management plan. 

Threat Identification

A threat is anything that might exploit a vulnerability to breach your security and cause harm to your assets, such as:

• Natural disasters – Fires, floods and so on.
• System failure – Server outage. HVAC failure in the data centre etc.
• Accidental human interference – Spilling coffee on a server, accidental deletion following poorly configured access permission
• Malicious human actions – interference, interception or impersonation by both internal and external actors

There is a process that can be undertaken here, known as “Threat modelling” that allows the Risk Management team and security experts to undertake a table top exercise that envisages (models) the threats that might be pertinent

Vulnerability Identification

A vulnerability is a weakness that allows some threat to breach your security and cause harm to an asset. It is necessary to assess what vulnerabilities are applicable, and what their likelihood 

Think about what protects your systems from a given threat — if the threat actually occurs, what are the chances that it will actually damage your assets? Vulnerabilities can be physical (such as old equipment), problems with software design or configuration (such as excessive access permissions or unpatched workstations), or human factors (such as untrained or careless staff members).

Risk Assessment

The risk assessment is the part of the process where a value (Usually from a range, such as 1-5, Very low-Critical etc.) is given to each, and subsequently the combination of Threat, vulnerability and Consequence. It is this assessment that allows prioritisation and actions to be attributed to the risks in the form of a Risk management plan. An example can be seen in the table below.

Risk Strategy

Once a Risk manage plan has been created, it is neccesary to present the plan to the relevant stakeholders (Risk and Governance Committee for example) and get management sign off for actions.

Risk Register

The final part of this process is to create a Risk Register. This would be a list of the risk, risk owners, and tracking data. This allows for follow-up over time with the relevant stakeholders. Much of this data is transferred over from the Risk Management plan to ensure Risks, once identified, are properly tracked.

A Risk Register should contain the following:

• Risk Identification: A name for the risk, a tracking ID and date first identified
• Risk Description: A brief overview of the risk and why it is a potential issue
• Risk Category: Categorising the risk helps with assigning the relevant teams. Categories might be, for example:
  • Operations
  • Budget
  • Schedule
  • Technology
  • Information
  • Security
  • Quality
  • Project plan
• Risk Likelihood: Helps to prioritise the risks. Here we have used
  • VERY LIKELY (Capitalised to make it stand out)
  • Likely
  • Possible
  • Unlikely
  • Very Unlikely
• Risk Analysis: From the “Risk” column of the Risk Management Plan. For consistency, develop a formula (for example, “High” or “Critical” in 2/3 columns = “Critical”, “Very Low” in 1 column and “Moderate” or lower in another = “Low” etc. Use the 5 point system in the Risk Management plan:
  • CRITICAL (Capitalised to make it stand out)
  • High
  • Moderate
  • Low
  • Very Low
• Risk Mitigation: A detailed mitigation plan as summarised in the Risk Management plan including:
  • A step-by-step solution on how to lessen the risk
  • A brief description of the intended outcome
  • How the plan will affect the impact
• Risk Priority: Different from the Risk management plan, this combines the likelihood and analysis. Often this can be a 3 or 5 level priority list, e.g.
  • 1 – Low – Take no action until the next review data unless the likelihood or analysis change. In reality, these often remain on the risk register forever, until the system is decommissioned. The default action is, therefore, “Accept”
  • 2 – Medium – Address if time/budget after priority 3 actions have been addressed. Often these will remain on the risk register unaddressed until something changes in the Likelihood or the Analysis scores. The default action is, therefore, “Accept” until the next review date at least.
  • 3 – High – Priority 3 Risks are actively acted upon using the defined risk mitigation solution. Budgets are requested and due dates and next review dates assigned. The default action is “Mistigate”
• Risk Ownership: Every risk is assigned an owner. This is the person who is accountable for overseeing the Risk, ensuring any changes are reported, and overseeing the implementation of mitigation measures. Here, also, should be noted any additional team members with assigned responsibilities.
• Risk Status: The current status of the risk
  • Open – The risk action has not been started
  • In Progress – The risk actions are in the process of being implemented
  • Closed  – The risk actions have been completed, and the risk management team have Assessed any residual risks, which are either accepted or added to the Risk Register.
• Trigger: Any triggers (for example, increased failure rate of HVAC system) that might cause the Risk Assessment to change.
• Timeline: Next review date and due date (For Priority 3)