CHAPTER 3: RISK ASSESSMENT

Any organisation pursuing ISO27001 certification for its information security management system will need an approach to risk assessment that meets the requirements of ISO/IEC27001:2013. Clause 6.1.2 of ISO27001 requires the organisation to take an explicitly risk-based approach to the selection and operation of information security controls.¹⁰ The approach to risk in ISO2001:2013 can be described as scenario-based rather than asset-based; each risk is treated across the entire organisation rather than on an asset-by-asset basis.

Risk management

Risk management is a discipline for dealing with non-speculative risks – those risks from which only a loss can occur. In other words, speculative risks can be seen as the subject of an organisation’s business strategy whereas non-speculative risks, which can reduce the value of the assets with which the organisation undertakes its speculative business activity, should be the subject of a ‘risk treatment plan’. Non-speculative risks should be identified and plans made to deal with them ahead of their occurrence.

Risk treatment plans

Risk treatment plans have four, linked, objectives. These are to:

• eliminate risks (terminate them);
• reduce those that cannot be eliminated to ‘acceptable’ levels (treat them);
• tolerate them, exercising carefully the controls that keep them ‘acceptable’;
• transfer them, by means of contract or insurance, to some other organisation.

Risk assessment

ISO27001 specifies a risk assessment process and ISO27002:2013 provides substantial further guidance on using controls to treat the risks, but does not provide detailed guidance on how the assessment is actually to be conducted. Every organisation has to choose the approach that is most applicable for its industry, complexity and risk environment. It is simplest if these definitions of risk, risk analysis, risk assessment, risk evaluation, risk management and risk treatment are, for the sake of consistency with ISO27001 and commonality of approach across the integrated management system, adopted from the ISO Guide by any organisation tackling risk management.

A risk treatment plan can only be drawn up once risks to the confidentiality, availability and integrity of the organisation’s data have been identified, analysed and assessed. Risk assessment is based on a data-gathering process and, as all individual inputs into the analysis will reflect individual prejudice, so the process of information gathering should question inputs to establish what really is known – and what is unknown.

The process for carrying out a risk assessment under ISO27001 can be broken into ten steps:

1. Establish and maintain information security risk criteria and risk acceptance criteria.
2. Identify threats to the confidentiality, availability and integrity of information within the scope of the ISMS.
3. Identify the risk owners.
4. Assess the possible impacts of those threats if they were to materialise.
5. Assess the likelihood of those events occurring.
6. Determine the level of risk.
7. Compare the results of the risk assessment with the risk assessment criteria.
8. Prioritise the analysed risks for treatment.
9. Retain documentation about the entire process.
10. Ensure that repeated information security risk assessments produce consistent, valid and comparable results.

Threats

Threats are things that can go wrong or that can ‘attack’ your information assets. They can be either external or internal. Examples might include fire or fraud, virus or worm, hacker or terrorist. Threats are always present for every system or asset – because it is valuable to its owner, it will be valuable to someone else. So the first stage mandated by ISO27001 is to identify the potential threats to the systems and assets ruled as in scope.

Identify threats to the confidentiality, integrity and availability of any and all in-scope information assets – the idea is to treat each risk rather than secure each asset individually. It is likely that an individual threat may appear against a number of assets. You can do this through a brainstorming exercise or by using an appropriate threat database; technical expertise is essential if the threat identification step is to be carried out properly.

Risk owners

An ‘owner’ is the individual or entity that has approved management responsibility for monitoring a threat, and possibly reducing the likelihood that it will occur or the potential damage it could cause. Every threat must have an owner.

Assessing risk

Assets are subject to threats that exploit vulnerabilities; some threats are more likely than others, and every threat may have a unique impact. Risk assessment involves identifying all these aspects for every threat.

Vulnerabilities

Vulnerabilities leave a system open to attack by something that is classified as a threat, or allow an attack to have some success or greater impact. For example, for the external threat of ‘fire’, a vulnerability could be the presence of inflammable materials (e.g. paper) in the server room. In the language of information security, a vulnerability can be exploited by a threat.

The next stage in the assessment process, therefore, is to identify the vulnerabilities that each threat could exploit. Clearly, each threat could exploit more than one vulnerability. You need to identify them all, and one way of doing this – particularly for computer hardware and software – is to refer to standard industry sources such as Bugtraq and CVE. Any manufacturer’s updates that identify vulnerabilities should be taken into account, as should the fact that not all vulnerabilities have, on any one day, yet been identified and, therefore, the organisation will need to be able to identify new vulnerabilities as and when they occur.

Impacts (ISO27001 Clause 6.1.2 d) 1)

A risk that materialises will have an impact on information’s availability, confidentiality or integrity. A single risk could impact more than one information asset, and each instance could have more than one type of impact. These impacts should all be identified. Risk assessment involves identifying the potential business harm that might result from each of these identified impacts.

The way to do this is to assess the extent of the possible loss to the business for each potential impact. One object of this exercise is to prioritise treatment (controls) and to do so in the context of the organisation’s acceptable risk threshold; it therefore makes sense to categorise possible loss rather than attempt to calculate it exactly. A stepped set of monetary, financial levels (e.g. high-medium-low) should be designed that, under the board’s guidance, are appropriate to the size of the organisation and its current risk treatment framework. In assessing the potential costs of impact, all identifiable costs – direct, indirect and consequential (including the costs of being out of business) – should be taken into account.

Risk assessment (likelihood and evaluation) (ISO27001 Clauses 6.1.2. d) and 6.1.2.e)

Practically speaking, the process until this point has been about data gathering and factual assessment. Each of the preceding stages has a relatively high degree of certainty about it. The vulnerabilities should be capable of technical, logical or physical identification. The way in which threats might exploit them should also be mechanically demonstrable. The decisions that have to be made are those that relate to the actions the organisation will take to counter those threats. This means that the actual risks now have to be assessed and related to the organisation’s overall ‘risk appetite’ – that is, its willingness to take risks.

Until this point, the assessment has been carried out as though there was an equal likelihood of every identified threat actually happening. This is not really the case and this is therefore where there must be an assessment – for every identified impact – of the likelihood or probability of it actually occurring. Probabilities might range from ‘not very likely’ (e.g. major earthquake in Southern England destroying primary and back-up facilities) to ‘almost daily’ (e.g. several hundred automated malware and hack attacks against the network). Again, a simple set of stepped levels should be used.

Risk level

Risk level is a function of impact and likelihood, or probability. The final step in this exercise is to assess the risk level for each impact and to transfer the details to the corporate asset inventory and, possibly, the configuration management database (CMDB). Three levels of risk assessment are usually adequate: low, medium and high. Where the likely impact is low and the probability is also low, then the risk level could be considered low. Where the impact is at least high and the probability is also at least high, then the risk level would be high; anything between these two measures would be classed as medium. However, every organisation has to decide for itself what it wants to set as the thresholds for categorising each potential impact and from time to time it may be helpful to have four or more risk levels (including one such as minimal) in order to better prioritise actions.

Figure 2 is a simple risk level matrix. It shows that the risk events with a high likelihood of occurring, and a high impact when they do, are the high risks and should be given priority treatment.

Risk treatment plan

Clause 6.1.3 of ISO27001 requires the organisation to “define and apply an information security risk treatment process”.

The risk treatment plan must be documented. It should be set within the context of the organisation’s information security policy and it should clearly identify the organisation’s approach to risk and its criteria for accepting risk. These criteria should, where a risk treatment framework already exists, be consistent with the requirements of ISO27001 as well as with the criteria the organisation uses for evaluation of all sorts of risk.

The risk assessment process must be formally defined and described and the responsibility for carrying it out, reviewing it and renewing it, formally allocated. At the heart of this plan is a detailed schedule, which shows, for each identified risk:

• the acceptable level of risk;
• the risk treatment option that will bring the risk within an acceptable level;
• how the organisation has decided to treat it;
• what controls are already in place;
• what additional controls are considered necessary; and
• the timeframe for implementing them.

The risk treatment plan links the risk assessment in the corporate information asset and risk log to the identification and design of appropriate controls, as described in the Statement of Applicability, such that the board’s defined approach to risk is implemented, tested and improved. This plan should also ensure that there is adequate funding and resources for implementation of the selected controls and should set out clearly what these are.

The risk treatment plan should also identify the individual competence and broader training and awareness requirements necessary for its execution and continuous improvement. It is necessary to check with the risk owners to make sure that they accept your assessment of information security risks and approve of the treatment plan.

If you are using the PDCA cycle, the risk treatment plan is the key document that links all four phases in the ISMS. It is a high-level, documented identification of who is responsible for delivering which risk management objectives, of how this is to be done, with what resources, and how this is to be assessed and improved. At its core, it is the detailed schedule describing who is responsible for taking what action, in respect of each risk, to bring it within board-defined acceptable levels. The table below shows an outline risk treatment plan.

Table 1: Outline risk treatment plan

Risk assessment tools

The risk assessment is a complex and data-rich process. For an organisation of any size, a practical way to carry it out is to create a database that contains details of all the assets within the scope of the ISMS, and then to link to each asset the details of the risks facing it, along with the impacts and their likelihood, together with details of the asset ownership and its confidentiality classification. The risk assessment process is made enormously simpler if one can also use pre-populated databases of information security risks.

This database must be updated in the light of new risk assessments, which should take place whenever there are changes to the assets or to the risk environment.

The complexity of this task is such that many organisations want to use some form of automated tool¹¹ to aid in the risk assessment.