CHAPTER 3: CYBER SECURITY RISK MANAGEMENT

Disturb us, Lord …

Because we have dreamed too little,

When we arrived safely

Because we sailed too close to the shore.

Prayer often attributed to Sir Francis Drake

Introduction and overview

We all take risks every day. Life is a risky business. But without risk there is no progress. The same applies to organisations in the cyber world: there are risks of hacking, fraud, state interference and identity theft. But these have to be matched against risks of not doing business via cyber (e.g. failure to win new customers or reduce costs). The risks are great but so are the potential rewards: competitive advantage, reduction in costs, increased awareness of your products and services via social media, to name but a few. These risks can be managed in the same way you manage the daily risk of driving – by controls (ensuring your car is roadworthy and that you wear a seat belt, and having it serviced by a qualified technician), by following the rules (speed limits) and by insuring against the unknown risks that you cannot prevent. Every organisation needs to have a process for managing cyber risks.

The process and terminology will vary between organisations, but the basic steps are likely to be as shown in Figure 2. Wherever possible, they should also be followed for cyber. They will help ensure that risks are stated in a format and style that business managers and executives can relate to.

Figure 2: Risk management process

The objective, key activities and deliverables for each of these steps is described below. We will also consider how the risk management process can be made more agile.

Risk management scoping

When undertaking a risk management review, it is important to ensure that the scope is understood and agreed so that there are no gaps or duplication of effort.

For cyber, we need to ensure that all risk assessments are conducted to the same level of detail, based upon the risk appetite of the organisation, otherwise:

•Controls may be defined at too fine a level of detail, leading to extra effort with little or no reduction in the risk profile; or

•Risks identified as strategic for the organisation may not be covered adequately. For example, strategic risks relating to sensitive geographic operating locations or trading in restricted parts of the world could have cyber implications that need to be considered.

The main activities will be:

•Identifying relevant strategic risks, based on the enterprise risk strategy and level of risk appetite determined by the key stakeholders;

•Agreeing the processes, technology and locations in scope, and whether to include activities of third parties/the supply chain;

•Identifying any known incidents or risks specific to the review;

•Identifying all stakeholders, people, procedures and technology to be included in the review; and

•Determining the legal and other regulations that must be considered during the review.

The deliverable from the scoping exercise, which may be from a workshop or a series of meetings, will be an agreed scope, a high-level plan and background notes. To reduce the risk of scope creep or change during the exercise, this documentation should be reviewed and approved by all key stakeholders before the work starts.

Process and control mapping

Documenting the process and related controls helps confirm understanding and ensure that the controls are located at the point of risks so that any errors or attacks can be identified effectively and efficiently. If controls are located too far into the process, this can lead to additional, unnecessary corrective work. The documentation does not need to be too detailed – the aim is to consider the end-to-end process and identify key inputs, outputs and sub-processes. Often this documentation can be prepared following interviews, reviews of existing documentation, and workshops. The key step is to walk through the process and controls wherever possible to confirm understanding and identify any potential variations. For example, if we were looking at access controls for a new cyber application, we may consider whether they will work the same way for all devices/platforms. This step can also ensure that the documentation is accurate and easy to follow, and can highlight where additional documentation may be required to help users undertake key steps.

Output from this phase will be process maps and documentation. The format and tools used to generate these vary between organisations.

Risk assessment

A risk assessment can now be performed to identify key weak points in the process where error or attack could occur. This may also include considering known vulnerabilities for the technology. Key questions to ask for each process step are:

•What could possibly go wrong?

•How likely is it?

•Does it matter – what’s the impact?

•Are there any existing mitigations in place (consider TRAM (transfer/reduce/accept/mitigate)) and if so, are they adequate for the level of risk?

To provide clarity when describing risks, the following formula can be used:

X happens because of Y, leading to Z

For example:

The main way of classifying IT risks is using the initialism CIA (M):

•Confidentiality

•Integrity

•Availability

•Management

These will be explained further in the next chapter.

Where a control is in place, this should be reviewed against the identified risks to consider:

•Is it a detective control to identify an error or attack, where a preventive control would be better?

•If operated properly, would it fully mitigate the risk?

•Is it operated effectively?

•Is it redundant – where, for example, another control already fully mitigates the risk?

The output from this step may be in the form of a risk and controls matrix (RACM). The RACM is a spreadsheet-based document that contains details of the risk and control and can include details such as frequency, location, etc. It should also include details of observed control gaps and weaknesses.

Designing and implementing controls

Objective

Where there are control gaps or inadequacies, new controls will need to be implanted. They should be designed in a way that will mitigate the risk and be easy to operate, ideally automatically operated within the process with minimum impact on its operation.

Often it may not be possible to implement controls immediately, so temporary compensating controls may be required to provide mitigation during this build phase. Accepting the risk by having a ‘waiver’ (or exception) alone is rarely adequate.

Testing of controls

Where new controls have been designed and implemented, the following testing should be performed:

1.Test design – does the control fully mitigate the risk?

2.Walk-through – has the control been implemented? Is it working as intended?

3.Is evidence retained?

4.Which controls are key?

5.Has all relevant documentation been updated?

6.Are test scripts written in a way that they can be used by others and will generate similar results?

Summary

In this chapter we considered the techniques to identify, assess, build, design, test and monitor controls. In the next chapter we will consider some of the risks and controls specific to cyber.