Performing a security risk assessment

In cyber security, the nature of ‘risk’ can change depending on the issues being faced. The definition used across the Secure by Design approach is based on risk management guidance provided by HM Treasury.

By assessing the importance of service assets and performing threat modelling you will have gained a detailed picture of the different ways your service is likely to be attacked. The next stage is to conduct a security risk assessment which will allow you to:

• understand and prioritise inherent security risks prior to making risk management decisions
• determine how best to apply appropriate and proportionate security controls to reduce weaknesses
• evaluate residual risks to inform decision makers and support your organisation’s risk response
• feed insight into the ongoing risk management process

Risk assessments should be carried out initially at the beginning of a project and ongoing throughout the service delivery lifecycle so decisions can be based on the most recent threat and vulnerability information available.

Completing this activity will help you to achieve the outcomes included in the Secure by Design principle to adopt a risk-driven approach.

Who is involved

This activity should be carried out by security professionals with experience in risk assessments, with support from your delivery team and the technical architects designing the service.

Accountability for the risks identified will lie with the Senior Responsible Officer (SRO) and service owner so they should be included in the process of developing risk assessment criteria.

Risk assessments are not an exact science and each individual involved may interpret the results differently. Ensure the team conducting your risk assessment are provided with good quality data (such as threat actor capabilities) and a structured model to work with so they can come to a consistent conclusion. Be clear about who has the final say and makes the decision where there is conflicting advice.

How to perform a cyber security risk assessment

The following steps are aligned to the basic risk assessment and management method provided by the NCSC.

Your organisation may already have an established process for cyber security risk assessments. Check with your risk management team before you begin and make use of any available support or templates.

Step 1. Establish the scope and method

Begin by outlining the users, data assets, system components and interconnections that are being assessed and note any assumptions and constraints associated with the assessment.

Create a diagram that shows the boundaries of your assessment, including both the in and out of scope elements. This line is typically drawn where you have influence on the security controls that are put in place.

You should agree how long the results of a risk assessment can be used to accurately inform risk-based decisions. This is particularly relevant to projects where business requirements may remain unchanged for a long period of time. While the nature of the service may not change, the threat landscape that affects it is likely to evolve so risks should be reviewed periodically. In more iterative projects, the scope of the assessment should be revisited as the service expands to include more data, users and components.

As part of the scoping exercise, agree on the risk assessment method and terminology being used for risk components, such as threat actor, threat event, impact and vulnerabilities. The accuracy and effectiveness of a risk assessment relies upon unambiguous and clearly defined risk components.

Step 2. Collate your asset analysis

As part of the Secure by Design process, you should have documented your assets and assessed the importance of your assets to establish what is considered to be of value to your organisation and what the business impact would be should the assets be compromised.

Step 3. Collate your threat analysis

As part of the Secure by Design process, you should have assessed the capabilities of threat actors as part of your threat assessment and identified the likelihood of threat events and cyber attack techniques by performing threat modelling.

Step 4. Assess the vulnerabilities

Conduct a workshop with the security professionals and representatives from your delivery team to identify how service assets may be compromised due to vulnerabilities which could be exploited by the threat events.

You may require multiple sessions to work through each element of the service, assigning appropriate time to focus on the most valuable assets and the highest priority threat actors.

Each vulnerability needs to be examined to determine the ease of exploitation and the exposure to threat. Structure the discussion around questions such as:

• How easy is it for an attacker to discover this vulnerability?
• How likely is it for an attacker to want to exploit this vulnerability?
• How much time, effort and expertise is needed to exploit the threat?
• Can an attacker exploit this remotely?
• Does an attacker need to be authenticated?
• Can the exploit be automated by attackers?

If your organisation does not have a methodology for assessing potential weaknesses in your system, the MITRE CVE (Common Vulnerabilities and Exposures) database provides a catalogue of publicly disclosed vulnerabilities and the MITRE ATT&CK framework provides details of the tactics and techniques that could exploit vulnerabilities. The security professionals conducting your assessment can use this to evaluate the effectiveness of existing or proposed security controls in mitigating or preventing the identified threats, creating a proactive and targeted approach to cyber security risk management.

Step 5. Identify and analyse the risks

Once the threats, vulnerabilities and business impacts have been established, the information can be collated into a series of statements that capture risk across the service.

Security risk statement structure

There is a risk that [threat actor] [threat event] by exploiting [vulnerability of asset] resulting in [consequences].

Security risk statement example

There is a risk that cyber criminals install software backdoors by exploiting DevOps hard-code authentication credentials stored in plain text on a Github repository resulting in personal information and bank account data being stolen.

It’s recommended to create a risk severity score (using the information and data collected as part of your workshops that’s based on the likelihood of a threat occurring (from ‘1 – Unlikely’ to ‘5 – Almost certain’), and the potential organisational impact of a compromise (from ‘1 – Minor’ to ‘5 – Critical’), taken from your asset evaluation activity.

For example, a threat with a likelihood of ‘4 – Probable’ against an impact of ‘4 – Severe’ would have a risk severity of 16 out of 25, which would be considered ‘High’. It’s important to agree the parameters for this evaluation so it can be repeated in future, making sure any assigned scores are in line with risk management frameworks used within your organisation.

Step 6: Create a risk register

The result of your risk assessment activity is a risk register that provides a prioritised summary of the risks that exist across the service, along with the associated timelines and responsibilities

It should include currently accepted risks, and risks that are deemed to be above the acceptable project risk appetite prior to any mitigations being implemented.

Example risk register entry

• Risk ID: 007
• Description: There is a risk that a cyber criminal might upload a document containing malicious code resulting in compromise of the integrity of the Grant Management System.
• Threat: Cyber Criminals
• Threat Event Type: Tampering
• Information Asset: Grant Management Application (SaaS)
• Component: Application Server
• ​​Business Impact: 3 – Moderate
• Threat Likelihood: 4 – Probable
• Risk Severity: 12 – Medium
• Accountable: Senior Responsible Owner (SRO)
• Risk Owner: Information Asset Owner (IAO)

Your risk register should be a living document that can also include comments on each risk and details of whether higher-level risks have been escalated (who to, and when).

It should be shared with those responsible for responding to and mitigating security risks as well as project decision makers and delivery team leads. Once security controls have been put in place to mitigate unacceptable risks, the risk register should be updated with the scores adjusted to reflect the latest information.

The risk register is a technical document, however due to the audience that needs to refer to it, information should be written in plain English with clear explanations for any abbreviations and acronyms. Those maintaining the risk register over the course of a service’s life should ensure it’s regularly shared during updates and planning sessions so delivery teams can see it as an integral part of the project.