CHAPTER 4: MANAGING THE RISKS
Conducting a risk assessment is a critical part of identifying what cyber security measures you need to implement and to what degree. This also helps keep your defences effective and affordable. Before delving into the different steps involved in risk assessment and management, however, we need to make one thing clear: security requires trade-offs.
Making trade-offs
Making trade-offs is a simple reality of achieving security, both in terms of the individual measures chosen as well as the overall level of security implemented.
Looking at the overall level of security first, if you chose to implement none at all, that might be cheaper and more convenient in the short term. The trade-off, however, is the certainty of suffering an incident sooner or later, likely leaving you with a big bill and significant inconvenience (dealing with regulators and the press, operational impact, and so on) in the longer term. On the other hand, achieving absolute security might sound good, but the reality is that the trade-offs that approach would require would be too great. For a start, you would have to disable all Internet connections to ensure criminal attackers cannot exploit them. However, that would also mean that your organisation cannot use email, have a website or, in all likelihood, do business at all.
Instead, what you need to do is manage your risks, rather than seek to eliminate them. In other words, where the risk is too great, you simply take appropriate action to bring it down to an acceptable level. Often, that ‘appropriate action’ can be broken down into individual security measures, each of which will involve a trade-off. For example, some solutions are cheaper but would only protect you against one type of attack. Others are more expensive but would be easier to implement or more convenient to use and maintain.
Ultimately, this selection and trade-off process lies at the very heart of security: deciding what sacrifices you are prepared to make (and are necessary) so you can meet your security requirements. Much like many other decisions in business and life, it is a process of weighing up the pros and cons.
There are many factors you may need to consider as you decide what trade-offs to make, including but not limited to budget, privacy, convenience, complexity, resources, time and flexibility. Perfect security may not be possible, but there are certainly solutions out there that are perfect for meeting your security needs.
To help you judge whether a certain security trade-off is worth making, security guru Bruce Schneier’s five questions offer a straightforward yet sound approach4:
1. What assets are you trying to protect?
2. What are the risks to those assets?
3. How well does the security solution mitigate the risk?
4. What other risks does the security solution cause?
5. What trade-offs does the security solution require?
The next two sections address Schneier’s first two questions. After that, we will look at risk assessment before delving into Schneier’s final three questions on security solutions (which we refer to as ‘risk responses’).
Asset identification
Schneier’s first question reflects a common first step in risk management: asset identification. Like risk management itself, there are many valid ways to go about asset identification. Whatever method you choose, make sure you apply it consistently, and end up with a reliable asset inventory that can prove useful for a range of security and non-security activities.
Chapter 9 goes into more detail on asset inventories and management.
Risk identification
Schneier’s second question is on risk identification – another critical step in risk management.
With new vulnerabilities discovered every day, and many threat actors willing to exploit them, risk identification can feel overwhelming. To keep your efforts focused, consider conducting multiple smaller risk assessments – for example, one for network-related risks, another for remote-working-related risks, and so on. By limiting the scope of each assessment, you make the steps required in each – including risk identification – much more manageable. Just make sure that when you put all your smaller scopes together, they account for all your assets, business needs and requirements.
After defining your scope(s), you can take two different approaches to risk identification:
1. Asset-based
This approach requires an asset register, a list of business processes (if not included in your asset register), and ideally a database or list of threats and vulnerabilities to consider.
The idea is that you establish the vulnerabilities of each of your assets and consider the threats that might exploit each of those vulnerabilities. For instance, personal data (asset) will sometimes need to be transferred across a public network (vulnerability), where it may be intercepted by an unauthorised individual (threat).
Each ‘incident scenario’ – the combination of a specific threat exploiting a specific vulnerability – is a clearly defined risk that can be analysed and, if necessary, addressed. Asset owners and relevant stakeholders can offer valuable input in this process – they have the best understanding of the asset and how it is used, which naturally impacts the asset’s susceptibility to the threats identified.
2. Scenario-based
In a scenario-based risk assessment, you examine all the consequences of an event – often common larger-scale scenarios – in a broad fashion. A fire in a server room, for example, could impact the integrity and availability of a wide range of physical and digital assets, on top of health and safety and business continuity concerns.
Defending against fire also requires a broad approach. Are there smoking areas near any flammables? Are fire suppression systems installed? Is equipment with significant heat output adequately cooled? Each contributes to your defence, but relying on just one or two measures will probably prove insufficient – it is necessary to account for the whole threat scenario to be truly secure.
Identifying threat scenarios begins with discussions with key persons within the organisation, such as facilities managers, IT managers, and so on. They have the clearest overall picture of operations at the scale necessary to conduct scenario-based assessments, as well as valuable experience that can help identify relevant risks and suitable mitigations. Asset owners and lower-level stakeholders may also be able to provide valuable input for the same reasons they can aid an asset-based assessment.
It is quite acceptable to not identify every relevant scenario, so long as you gather enough information to be able to make informed decisions on what measures to implement.
Neither approach is superior to the other – the ‘better’ approach depends on your organisation’s needs. For example, one limitation of the asset-based approach is that it usually looks at a single threat per risk or incident scenario. If you expect to be targeted by, say, organised crime, it is important to consider combined attack methods that present more complex threats, for which scenario-based assessments are probably more suitable.
The scenario-based approach can also work well for smaller organisations or organisations with very specific requirements and obligations – for instance, in the gambling industry, a key concern is preventing fraud, while in publishing, the priority tends to be protecting manuscripts or papers from premature release. If you have a very clear idea of what scenarios you need to prevent, you should also have a good idea of what your critical risks are. On the other hand, if you prefer a more methodical, almost checklist-like approach, asset-based assessments are probably more suitable.
Whatever approach you choose, make sure you apply it consistently. It is vital that your process ensures repeated risk assessments produce consistent, valid and comparable results. Judging what constitutes a relevant risk and what the level of a risk is should not vary between departments,5 for instance, or the results of your assessments become unreliable. In turn, this will affect your ability to prioritise risks, allocate resources and judge trade-offs effectively. Each identified risk must also be assigned a risk owner, who must be in a position to implement any risk responses identified.
Risk appetite
Besides identifying risks, you must also establish criteria for determining what level of risk is tolerable – this is known as setting your ‘risk appetite’. This could be, for example, being unable or unwilling to accept any risks above ‘medium’ level, or any risks above minimum impact but with more leniency on frequency.
Your risk appetite should be based on your security requirements and objectives. It should also reflect how your organisation generally does business – your tolerance for security risks will probably reflect your tolerance for other business risks. Finally, you can adjust your risk appetite based on the resources available if necessary, though consider the trade-offs of this approach: tolerating more risk simply to save money could prove a false economy further down the line.
Risk assessment
Having identified your risks and established your risk appetite, you need to determine – in a justifiable, structured and consistent way – how significant each risk is before you can consider your trade-off options. To do that, you need to measure both frequency (how likely it is that the risk will materialise) and impact (how significant the consequences will be if the risk does materialise).
In security, risk assessments usually take a qualitative approach: relying on stakeholders’ knowledge and experience to determine an estimated risk. Despite the inherent subjectivity of this approach, it often still produces good results. It is also much quicker and easier to perform than quantitative assessments.6
To establish frequency and impact, you typically define between three and seven risk categories, for example:
• ‘Critical’, ‘high’, ‘medium’ and ‘low’
• ‘Catastrophic’, ‘major’, ‘modest’, ‘minor’ and ‘insignificant’
• ‘Almost certain’, ‘very likely’, ‘likely’, ‘possible’, ‘unlikely’ and ‘rare’
It does not matter what category names you choose, so long as you apply them consistently. It is also important to give each name a clear description or value, and preferably align them to multiple types of criteria when measuring impact. Table 1 and Table 2 provide example likelihood and impact criteria.
Table 1: Example Likelihood Criteria
Level | Likelihood | Description |
5 | Almost certain | Expected weekly. |
4 | Likely | Expected monthly. |
3 | Possible | Expected every one or two years. |
2 | Unlikely | Expected every three to five years. |
1 | Rare | Expected every five years or less frequent. |
Table 2: Example Impact Criteria
Level | Category | Financial impact | Reputational impact |
5 | Catastrophic | >£5 million | Losing >30% of customers. |
4 | Major | £2 million – £5 million | Losing 15% – 30% of customers. |
3 | Modest | £500,000 – £2 million | Losing 5% – 15% of customers. |
2 | Minor | £100,000 – £500,000 | Losing 1% – 5% of customers. |
1 | Insignificant | <£100,000 | Losing <1% of customers. |
Of course, the exact values for each level depend on the size of your organisation and the nature of your business, but it may be a good idea to set an even number of categories so people are forced to choose one of ‘medium/bad’ or ‘medium/good’. Also make sure assessors know, where they are not sure about the impact because it can vary depending on how the risk materialises, to assume the worst-case scenario. If the risk does materialise, and it turns out that the impact is not as bad as you had prepared for, all the better.
Having established impact and likelihood for each incident scenario, you need to measure the overall risk level. There are different ways of doing this – and generally any method is valid as long as it is applied consistently and provides useful outputs – but usually the ‘risk score’ is calculated as some product of impact and likelihood. That risk score can then be visualised in a likelihood–impact matrix such as Figure 1.
Figure 1: Example Likelihood–Impact Matrix
The matrix should clearly separate different areas, usually through colour-coding, to indicate – in line with your risk appetite – which risks are considered unacceptable, which require careful monitoring and more regular reviews, and which are tolerable as they are. Based on these findings, you should prioritise the risks. Any risk that exceeds your risk appetite will require a response.
Risk response
There are generally four ways you can respond to a risk (or to use Schneier’s wording, four types of ‘security solution’):
1. Modify
Implementing a security control to bring the impact and/or likelihood of the risk down to an acceptable level (in other words, modifying the risk). Those controls could be preventive, detective or responsive (which are all discussed further in Chapter 6), or any combination of them to help develop a defence-in-depth system. To help develop a multi-layered system, you should also rely on people, processes and technology, which are discussed further in Chapter 5. Part 2 of this book discusses a large range of controls you could implement.
2. Share
Sharing at least part of the risk with another party, such as through insurance or by outsourcing the process to an organisation that is better able to manage the risk.
3. Avoid
Avoiding the threat altogether by, for example, ending a processing activity or changing the way the activity is conducted.
Actively choosing to retain or tolerate the risk if it is not possible or too expensive to treat the risk, or if it presents an opportunity for a positive outcome.
Make sure that you document your chosen response, including justifications and, where applicable, your chosen controls. Also make sure that the risk owner has agreed to it after considering Schneier’s final three questions: how well the response mitigates the risk, what new risks the response introduces (if any), and what trade-offs the response requires.
After implementation, review the response’s effectiveness to ensure the risk has been sufficiently mitigated. Remember: you often do not need to (or cannot) eliminate a risk entirely, just lower it to a level that is within your risk appetite.
Risk owners should also regularly review the risks to make sure they are still acceptable, and review the risk treatments to make sure they are still working and achieving what was intended – particularly if the solution was a technological one, it is possible that it has been rendered invalid by new vulnerabilities or superseded by a better alternative.
_______________
4 Bruce Schneier, Beyond Fear: Thinking Sensibly About Security in an Uncertain World, Copernicus Books, 2003, pp. 14–15. Although this book dates back to 2003, many of its principles, including these five steps, are still applicable today.
5 Note that departments are naturally biased towards the risks directly affecting them – a finance team, for example, sees risks affecting the availability of their spreadsheet software as highimpact, whereas teams that do not use that same software would see it as low-impact. Both are perfectly reasonable assessments on a departmental level, so to make sure risks are judged consistently on an organisational level, it can be a good idea to appoint a moderator – an independent third party who can listen to all relevant parties, then judge the overall level of risk to the organisation as a whole.
6 Quantitative assessments, the main alternative approach to qualitative assessments, attempt to assign a precise numerical value to a risk based on large quantities of data. However, in many cases for security, there is not enough data to analyse or there are too many variables involved, making a quantitative approach impractical and cost-ineffective.