CHAPTER 13: RISK TREATMENT AND THE SELECTION OF CONTROLS

Once you have completed the risk assessment, you can move on to the selection of controls, and this chapter reviews the requirements of ISO27001 around control selection, which is also known as ‘risk treatment’.

As we said in Chapter 1, there are four risk treatment decisions that can be made:

The criterion that is used in making the decision is simple: either the risk is within the risk tolerance level, in which case it is accepted, or it is not, in which case it must be avoided, controlled or transferred. So, in principle (unless the risk is too great), if:

If the risk is too great (i.e. the potential impact is off the scale, or is greater than the ‘very high’ level chosen in the risk assessment methodology), then the risk must be avoided, which might involve implementing some form of ‘work-around’ in order to do so. A simple example of this response to a risk assessment might be where the potential impact of theft of equipment from the offices of a company would be so great if it moved to a particular neighbourhood that it decided against the move.

Types of controls

Controls (4.2.1 – f) are the countermeasures or safeguards designed to reduce risks, and are applied to reduce the likelihood of something happening or of its impact, if it were to happen. There are three types of control that are commonly applied to reduce the risk:

Control types can fall into three different categories:

As we indicated in Chapter 3, it is essential that the controls that are implemented are cost-effective. The principle is that the cost of implementing and maintaining a control should be no greater than the cost of the impact at the identified frequency, and this principle should be written into the board-approved risk acceptance criteria contained in the information security policy.

There are also practical considerations that should be borne in mind when selecting controls:

ISO13335-3 (now replaced by ISO27005, which includes the same material – but less clearly set out – at clause 9.2) suggested that there are six constraints that should be considered when selecting controls:

ISO27005 identifies, in addition to the above:

It provides no guidance on why these might be constraints.

It is not possible to provide total security against every single risk. It is possible to provide effective security against most risks, but the risks can change and so the process of reviewing and assessing risks and controls is an essential, ongoing one.

At clause 4.2.1 – g, ISO27001 requires the organisation to select appropriate control objectives and controls from those specified in Annex A, and requires this selection to be justified. However, it clearly invites organisations to approach this exhaustively and says, quite clearly, that additional controls may also be selected. ISO27001 auditors are likely to challenge implemented controls that are in excess of those required by the risk assessment on the basis that this may indicate inadequate controls applied elsewhere. ISO27002 provides good practice on each of the listed controls. There are, however, some areas in which organisations may need to go further than is specified in either standard and the extent to which this may be necessary is driven by the extent to which technology and threats have evolved since the publication of both standards.

It may also be that the organisation needs, in the light of its risk assessment, to implement controls other than those listed in Annex A. It might, for instance, have specialist processes that require additional security measures, or highly sensitive equipment that needs added protection. Additional controls can be added to the 133 that are already listed in Annex A. It would be sensible for an organisation that is adding controls to choose them from a reputable source (and to document the reasons for the choice), such as the hardware or software vendor (e.g. Microsoft or CISCO), NIST,⁵¹ the ISF,⁵² COBIT⁵³ or some other source of good practice guidance.

Controls are selected in the light of a control objective. A control objective is a statement of an organisation’s intent to control some part of its processes or assets and what it intends to achieve through application of the control. The cost of implementing (in cash and resource deployment) each control should not exceed the potential impact (assessed in line with the guidance in Chapter 6) of the risks (including safety, personal information, legal and regulatory obligations, image and reputation) it is designed to reduce.

It is important that, when considering controls, the likely security incidents that need to be detected should be considered and planned for. Clause 4.2.2 – h of the standard requires the implementation of controls that will enable ‘prompt detection of and response to security incidents’. In effect, the process of selecting individual controls from those listed in Annex A should also include consideration of what evidence – measures of effectiveness⁵⁴ – will be required:

Annex A of ISO27001 has 11 major categories, each of which has a number of subsections. There are, in total, 133 sub-clauses, each of which has a four-character alpha-numeric clause number. Each of these is a control under ISO27001 and each needs to be considered and a decision made as to whether or not it is applicable. The outcome of that decision is recorded in the Statement of Applicability, which is described in the next chapter.

The application of a control should reduce the risk it is designed to address. It will not always reduce that risk below the acceptable risk level. In this case, additional controls must be selected and applied until the cumulative effect of the controls is to reduce the identified risk below that acceptable risk threshold. The principle of not investing more on controlling a risk continues to apply as the size of the risk is reduced by the application of successive controls. It is, in other words, worth remembering that each additional control that is applied, is applied to a reduced risk level and that, therefore, it would be inappropriate to invest as much in the subsequent controls as in the initial one.

Risk assessment and existing controls

ISO27001 says that the risk assessment should ‘assess the realistic likelihood of security failures occurring in the light of prevailing threats and vulnerabilities, and impacts associated with these assets, and the controls currently implemented’.⁵⁵ Whilst this is obviously the correct approach for second and subsequent risk assessments, it is not terribly helpful in respect of the initial risk assessment, in that it assumes that all the controls which have already been applied, usually without the benefit of a structured risk assessment, are appropriate controls for the identified risk.

In fact, it is quite often the case that, in the course of an ISO27001 risk assessment, organisations discover that some of their controls are in excess of their requirements and can be reduced; the consequent savings benefit the bottom line or enable deployment of other controls needed elsewhere.

The logical approach (which should be reflected in your methodology and, therefore, in your choice of risk assessment tool) is, as we indicated earlier, for the initial risk assessment to take place only after identifying the existing controls. It makes sense, in other words, to identify all existing controls that are applied to each asset at the point of identifying the assets and then carrying out the initial risk assessment and then potentially do both a ‘before’ and an ‘after’ assessment.

You should easily be able to identify, in the ‘after’ assessment, those assets which you have ‘over-controlled’ by the fact that, in comparison to the ‘before’ assessment, the ‘after’ assessed risk level is very close to zero (i.e. well within the risk acceptance criteria) and where the removal or reduction of controls would not necessarily move the risk out beyond the level of risk tolerance.

This approach will enable you to link your risk treatment plan (see Chapter 15) directly to the risk assessment, insofar as you will be able to identify that, for some risks, no further action is necessary whereas, for others, controls will either be implemented or dismantled.

Some refer to risk levels calculated ignoring the effect of any controls that may be in place as the ‘gross risk’ and those that are estimated in light of the prescribed controls as ‘net risk’. Note that the Statement of Applicability should identify the controls required by the ‘before’ assessment and should, therefore, reflect all the controls applied.

Residual risk

Whatever risk is left after all selected controls have been applied is known as ‘residual risk’. In most cases, this residual risk will be below the acceptable threshold and, therefore, obtaining management’s approval (prior to implementation) should be a formality.

There will be circumstances where it has not been possible to reduce risk below the acceptable level (where, for instance, the cost of implementing an appropriate control is much greater than the impact value of the remaining risk that is outside the risk tolerance level) and this residual risk must also be explicitly signed off as acceptable by management.

Risks can, as we’ve said before, never be reduced to zero, even with the largest security budget. The possibility that one of the attributes of information security (i.e. confidentiality, integrity and availability) will be compromised will always exist. Prescribing additional measures will, of course, incur extra cost, and will offer diminishing returns in terms of increased information security. This is where the fourth option for treating information security risks comes in.

Risk transfer

Most organisations will at least consider transferring some of the risk or, rather, reducing the impact of some risks by transferring them to a third party via insurance. The aim here is to limit the potential financial losses by obtaining protective cover at a reasonable cost.

Insurance can be purchased to cover most risks. It is vital to ensure that any insurance you purchase matches the exact needs and risks identified. Buying inadequate cover, whether an inappropriate amount or for the wrong circumstance, will leave an unacceptable level of residual risk that may only be identified when it is too late.

In addition to the traditional insurance policies, specialised policies addressing information security risks are becoming more widely available. Underwriters can be found for all types of insurance needs, with sufficient shopping around.

Marrying suitable arrangements to transfer risks with risk control and avoidance policies can provide a risk strategy that meets organisational needs. Suitable implementation and monitoring result in a residual risk that reflects the organisation’s risk appetite.

Risk transfer, though, is not the same as risk avoidance. When transferring risk, the ultimate accountability for that risk still rests with the transferor. If, for instance, the transferee insurance company refuses to pay, or becomes insolvent, the transferor will still bear the full impact of the risk. It is important, therefore, that the effectiveness of risk transference strategies is reviewed on a regular basis; risk transfer policies should be subject to testing in just the same way as are business continuity plans.

Optimising the solution

There is a lot of benefit to preparing a cost-benefit analysis for the Risk Treatment Plan, which itself will be further discussed in Chapter 15. A cost-benefit analysis could also be a sensible step in the ‘plan’ phase for all future control decisions, for proposed new controls or for enhanced controls. It would encompass the following:

A cost-benefit analysis, carried out at the point of selecting controls, enables the organisation to select those controls that will deliver most security enhancement for the lowest total cost, and will provide the basis for driving future improvements through the ISMS.