Risk assessment is at the heart of the ISMS. Understanding its significance to the overall process is critical, and is one of the keys to project success. The board adopts an information security policy because there are a number of significant risks to the availability, confidentiality and integrity of the organisation’s information, and it mandates the design and deployment of an ISMS in order to ensure that its policy is systematically and comprehensively implemented. The policy must, therefore, reflect the board’s assessment of information security risks and opportunities. This doesn’t mean the board needs to carry out a detailed risk assessment itself, but it does need to set out a clear, overall approach to risk that can be used to take forward the ISMS project.
The organisation needs, in other words, to determine its criteria for accepting risks and identify the levels of risk it will accept. It is a truism to point out that there is a relationship between the levels of risk and reward in any business. Most businesses, particularly those subject to formal corporate governance requirements, will want to be very clear about which risks they will accept and which they won’t, the extent to which they will accept risks and how they wish to control them. Management needs to specify its approach, in general and in particular, so that the business can be managed within that context.
Information risk is one of a number of risks that the organisation must control and it should, to the greatest extent possible, apply a common risk management framework to all the risks with which it is faced.
The starting point for any ISMS project manager’s consideration of risk is to embrace the existing risk management function (if there is one) inside the organisation in order to understand a) its overall approach to risk and b) its specific approach to information security risk. If the organisation doesn’t have any such formal function, it is imperative that the current approach to identifying, assessing and controlling risk, and those involved in the activity, are identified as quickly as possible. You will need to ensure that there is a consistent, organisation-wide approach to managing the information security risks.
Introduction to risk management
All organisations face risks of one sort or another on a daily basis. Risk management is a discipline for dealing with non-speculative risks, those risks from which only a loss can occur. Speculative risks, on the other hand, those from which either a profit or a loss can occur, are the subject of the organisation’s business strategy whereas non-speculative risks, those risks that can reduce the value of the assets with which the organisation undertakes its speculative activity, are (usually) the subject of a risk management plan. These are sometimes called permanent and ‘pure’ risks, in order to differentiate them from the crisis and speculative types. Usually, the identification of a risk as either speculative or permanent reflects the organisation’s risk appetite.
Risk management plans have four, linked, objectives, which are to:
1. Eliminate risks;
2. Reduce those risks that can’t be eliminated to ‘acceptable’ levels; and then to either
3. Live with them, exercising carefully the controls that keep them ‘acceptable’; or
4. Transfer them, by means of insurance, to some other organisation.
Pure, permanent risks are usually identifiable in economic terms; they have a financially measurable potential impact upon the assets of the organisation. Therefore risk management strategies are usually based on an assessment of the economic benefits that the organisation can derive from an investment in a particular control; in other words, for every control that the organisation might implement, the calculation is that the cost of implementation should be outweighed by the economic benefits that derive from – or economic losses that are avoided as – a result of its implementation.
The organisation should define its criteria for accepting risks (for example, it might say that it will accept any risk the economic impact of which is less than the cost of controlling it) and for controlling risks (for example, it might say that any risk that has both a high likelihood and a high impact must be controlled to an identified level, or threshold).
This chapter only provides a brief introduction to, and overview of risk management. There is more detailed guidance on this process in Information Security Risk Management for ISO27001/ISO27002.
The ISO 27001 requirement is that the risk assessment should take into account both the organisation’s context (internal and external) as well as the requirements of third parties that might be relevant to, or have an interest in, the organisation’s approach to information security. In other words, the risk assessment must be business-driven and must reflect legal, regulatory and contractual requirements. This is one of the most important ideas in information security: we recommend the business, managed by its board of directors, should identify the threats to assets, vulnerabilities and impacts on the organisation and should determine the degree of risk that it is prepared to accept in the light of its business model, business strategy and investment criteria.
Baseline security controls
Step five in the ISMS implementation process is to identify and implement the controls that are required to meet the organisation’s legal, regulatory and contractual obligations (and there might be a number of different obligations, depending on jurisdictions within which it operates). It is also necessary to identify any controls that might be required by customers and suppliers, or other contractual mandates, and to include them in the baseline control set. The ISMS Compliance Database (www.itgovernance.co.uk/shop/p-715.aspx) is a useful tool; it helps identify specific controls that might be required to control risks arising from a failure to meet legal, regulatory or contractual obligations.
Risk assessment
Risk assessment is defined in ISO 27000 as a process that combines risk identification, risk analysis and risk evaluation. Risk identification is the “process of finding, recognising and describing risks”, risk analysis is the “systematic use of information to estimate risk” and risk evaluation is the “process of comparing the estimated risk against given risk criteria” to determine its significance.
In simpler terms, risk assessment is the systematic and methodical consideration of: a) the realistic likelihood of a risk occurring and b) the business harm likely to result from any such risks.
The risk assessment should be a formal process. In other words, the process should be planned and the input data, its analysis and the results should all be recorded. ‘Formal’ does not mean that technical risk assessment tools must be used although, in more complex situations, they are likely to improve the process and add significant value. The complexity of the risk assessment will depend on the complexity of the organisation and of the risks under review. The techniques employed to carry it out should be consistent with this complexity and the level of assurance required by the board.
Five-step risk assessment process
There are five steps to a successful risk assessment.
1. Establish a risk assessment framework
2. Identify risks
3. Analyse risks
4. Evaluate risks
5. Select risk management options
Experienced information security and risk management practitioners know that manual risk assessment methods are highly dependent on one or two individuals within the organisation, are time-consuming (trial and error) and costly to create, and often suffer from data and process inconsistencies that undermine the integrity and dependability of the results. They will therefore always use a purpose-built ISO 27001 risk assessment software tool – one that follows the five steps to successful risk assessment outlined above – in order to achieve their organisation’s risk management objectives consistently and cost-effectively.
Who conducts the risk assessment?
Unless the organisation already has a risk management function staffed by people with training that enables them to carry out risk assessments, it will (depending on the complexity of the organisation) need to delegate the responsibility to a lead risk assessor. There are two ways of doing this. The first is to hire an external consultant (or firm of consultants) to do it. The second is to train someone internally. The second is preferable in most cases, as the risk assessment will need to be reviewed when circumstances change, and having the expertise in-house enables this to be done cost-effectively. If the organisation already has a trained information security adviser, this person could take on the role.
In circumstances where the organisation has existing arrangements with external suppliers for risk assessment services, or is in the process of setting up a risk management function or capability (in the context of responding to the requirements of the Turnbull Guidance, or Basel III, perhaps), then it should ensure from the outset that its information security risk assessment process is included.
Risk analysis
Qualitative risk analysis is by far the most widely used approach. Risk analysis is a subjective exercise in any environment where returns are derived from taking risks – and it is preferable to be ‘approximately correct, rather than precisely wrong’. The risk assessment process should also allow for the possibility of unexpected positive outcomes, or what the Standard calls “opportunities”. Risks are analysed in terms of their likelihood of occurrence and their impact if they do. The impact can be either positive or negative. Different organisations have different thresholds for what they consider acceptable – what they can live with – regarding likelihood and impact, and this threshold must be defined in terms of risk acceptance criteria.
Risk workshop
One way to perform the risk assessment (having first defined and documented the risk assessment process) is to hold a risk workshop. The starting point for this workshop would be for the lead risk assessor to create a list of relevant risks that would compromise the confidentiality, integrity and availability of information that is within the scope of the management system, and which roles within the organisation might own each of those risks.
The risk workshop would be convened and managed by the lead risk assessor and would involve all the risk owners from across the business. The role of the risk workshop is to ensure that the list of identified risks (and relevant opportunities) is complete, that risk owners have been appropriately assigned, to determine the likelihood and impact of each of the identified risks, and to evaluate those risks against the identified risk acceptance criteria.
Impacts
Identify the possible impacts that the occurrence of a risk event will have on an information asset’s availability, confidentiality or integrity (impact analysis). These impacts should all, wherever possible, be assigned an estimated monetary value, using a category system (e.g. less than £1k, between £1k and £10k, etc.) that reflects the size of the organisation and the total cost (direct and indirect) of the incident.
Assess the probability of the event occurring, using a classification system such as once every few years, once per year, once every six months, etc. Virus attacks would fall into the every day category.
This enables you to identify the level of risk (pragmatically, a low-medium-high classification for the impact and likelihood scales is usually adequate for a smaller organisation) and then to conclude, for each risk, and in the light of controls already in place, whether it is acceptable or if some form of additional control is required.
Controls
Your risk assessment drives your selection of controls over and above those that might fall within what I have called the baseline control set. The key thing to bear in mind about the risk assessment is that it is not a once-only exercise. You will need to repeat it on a regular basis, just to check that your baseline assessment is still accurate and that the controls you have deployed are still appropriate. You will need to carry out specific risk assessments on an ongoing basis whenever there is a change in circumstances, in business structure or environment, or in the risk profile. Every decision you make about the controls that you are going to deploy must be driven by your risk assessment.
Your approach to risk assessment will be a cornerstone of your ISMS. That is why many organisations use risk assessment tools as part of their management system.
Risk assessment tools
Most organisations will want to automate their risk assessment process so that this best practice becomes embedded in the organisation. This is most easily done by acquiring and using a standard ISO 27001 risk assessment software tool. The benefits of automation show through early on in terms of simplifying the actual risk assessment; the long term benefits are even greater because of the extent to which automation makes the process of review and maintenance so much more robust.
vsRisk™ is a software tool developed specifically for the automation of ISO 27001 risk assessments. You can read more about vsRisk™ here: www.vigilantsoftware.co.uk
Controls
The risk assessment is at the heart of the ISMS, as the controls adopted by the organisation will form a significant part of the completed system. The reality is that a significant part of the project time will be invested in designing, deploying, testing and revising appropriate controls that are intended to meet the identified risks. It is therefore important to have an overview of controls.
The concepts of risks and controls are linked and are fundamental to information security management systems. Risk might be defined as ‘the combination of the probability of an event and its consequences’. Control is defined in ISO/IEC 27000 as a “means of managing risk”; a control includes policies, procedures, guidelines, practices or organisational structures – these can be of an administrative, technical, management or legal nature. Please note that information security controls are not simply technical in nature. If they were simply technical, they would fail – if only because no control can implement and maintain itself autonomously.
Nature of controls
All information security controls are made up of a mix of process/procedure, technology and human activity. Looking, for example, at the virus and cyber threats that are widely recognised even by boards of directors, ISO 27001 Control A.12.2.1 – and common sense - require the implementation of controls against malicious software and, when you think about this issue, it is immediately clear that technological controls must be blended with procedural ones – neither on its own is adequate. It is also clear that malware that corrupts a system is not only a business continuity and reputational issue – it may also corrupt records that need to be retained or make it impossible for an organisation to complete or submit required reports on time:
At the same time, ISO 27001 Control A.13.2.3 requires that information “involved in electronic messaging shall be appropriately protected”. Anti-malware software, on its own, just doesn’t meet a requirement that clearly covers both email and instant messaging. What you need, according to both common sense and ISO 27001, is a mix of technology, process and correct behaviour.
Yes, you need an appropriate software package, one that will ensure that incoming viruses, worms and Trojans are stopped at the perimeter – and that spam is filtered out – but it’s no good if documents that users have specifically requested from external sources and that are coming by email are corrupted by the anti-malware software ‘just in case’ – we know, for instance, that pdfs sent via an automatic response e-marketer are often nuked by the recipient organisation’s anti-malware software and that the same document, when sent individually to the recipient, will pass through with little problem – this sort of software set-up promotes disrespect among its users and a tendency to try and bypass it, potentially with attachments that are really dangerous. Instant messaging has become one of the simplest ways for individuals to circumvent email restrictions and ISO 27001 now expects those risks to be identified and controlled.
End-point security is now also a huge issue – traditionally, the organisational information security perimeter was easy to define and defend, but with the proliferation of hand held devices, wireless networks and mobile working, the perimeter has become very hard to defend and very porous. Depending on the risk assessment, organisations need to be looking at software that will tackle the risks in handhelds rather than making them difficult to deploy. Wireless networks need to be properly set up – and mobile access should be by means of an appropriately secure connection, probably a VPN. This control area will be found to interact with Control A.6.2, which requires the organisation to have a formal policy and appropriate controls in place to protect against the risks of working with mobile computing facilities.
Of course, anti-malware software needs to work with the firewall seamlessly, and it goes out of date – fast – so you need to have procedures in place that ensure it is properly updated. Most organisations don’t have a lot of time for testing anti-malware or other updates and fixes. Nevertheless, exploits and attacks have revealed vulnerabilities are now happening faster and faster – rapid deployment of fixes is usually critical, and this can only be achieved if you’ve got the right structures and processes in place.
In addition, your staff need to be trained on what to do when there is an incident – whether that is an email virus, a hoax or someone uploading something from a USB stick. And when it all goes wrong (as, sooner or later, it inevitably will), you need to have put in place ways of keeping the ship afloat while you plug the holes.
Control selection criteria
You should only deploy controls that relate to, and are appropriate and in proportion to, the actual risks you face. While you can choose controls from any source you consider appropriate, ISO 27001:2013 requires that you compare any controls that you do select against its own list of the key best-practice controls relating to the whole range of potential risks (many of which your organisation may not face). The Standard also requires inclusions and exclusions to be justified.
Controls can be described as ‘countermeasures for risks’. Apart from knowingly accepting risks that fall within the (board-determined) criteria of acceptability, or transferring those risks (through insurance) to others, there are three types of control:
1. Preventative controls protect vulnerabilities and make an attack unsuccessful or reduce its impact.
2. Corrective controls reduce the effect of an attack.
3. Detective controls discover attacks and trigger preventative or corrective controls.
Controls are not implemented irrespective of the cost. No board should sign off on any ISMS proposal that seeks to remove all risk from the business – the business does, after all, exist within a risk framework and, as the only form of existence that is completely risk-free involves already being dead, there is little point in proposing to control every risk.
It is essential that any 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 identified and quantified cost of the impact of the identified threat (or threats). It is not possible to provide total security against every single risk; the trade-off involves providing effective security against most risks.
No organisation should invest in information security technology (hardware or software), or implement information security management processes and procedures, without having carried out an appropriate risk assessment that assures them that:
• The proposed investment (the total cost of the control) is the same as, or less than, the cost of the identified threat’s impact;
• The risk classification, which takes into account its probability, is appropriate for the proposed investment; and
• The priority of the risk has been considered – i.e. all the risks with higher prioritisations have already been adequately controlled and, therefore, it is now appropriate to invest in controlling this one.
If the organisation cannot satisfy itself that the proposed investment meets these criteria, it will be wasting both the money and the time required to implement the control, while leaving itself open to more likely risks and, conceivably, with inadequate resources to respond to the more likely risk when it occurs. There is, in other words, a risk associated with not carrying out – and maintaining – an adequate risk assessment.
Statement of applicability
The second most important document in your ISMS – after the information security policy statement itself – is your Statement of Applicability, or SoA. The SoA is, in essence, a list of all the controls identified in Annex A of ISO/IEC 27001:2013, together with your statement as to whether or not that control is applied in your organisation, the justification for its inclusion or exclusion, a statement as to whether or not the control is required and whether it has actually been implemented or not. The SoA also includes controls selected from other sources, if you have any.
Risk treatment decisions – accept the risk, reject it, transfer it through insurance or control it, also described as ‘Retain, Avoid, Share and Modify’ – have to be made for each risk on the basis of the organisation’s pre-determined risk appetite and within the context of the risk assessment framework. Risk treatment decisions must be justified by the risk assessment (recognise the baseline controls required to meet legal, regulatory and contractual objectives) and each control should be proportionate to the identified risk.
ISO/IEC 27002 has the status of a code of practice and it provides detailed guidance on how to implement each of the 114 controls listed in Annex A of ISO/IEC 27001.
The best detailed guidance that exists on the market today, and which tackles the SoA on a control by control basis, is IT Governance – An International Guide to Data Security and ISO27001/ISO27002, Sixth Edition, which was chosen as The Open University’s post graduate text book precisely because of the quality of its coverage of this core component of the ISMS. Whether you’re using consultants for your project or not, you will find this book indispensable1 to your ISMS project.
Risk treatment plan
The next most important document, after the SoA, is the Risk Treatment Plan (RTP). This sets out the steps to be taken to deal with each of the risks you identified in your risk assessment. Those risks that you are accepting or rejecting need no further action other than possibly finding a workaround for those you reject. Those that are being transferred need to be the subject of negotiations with insurers and/or suppliers. Those that are to be controlled need action, and your RTP describes those actions: what has to be done, by whom and by when.
1 While I am one of the co-authors of this book, the fact is that there is nothing like it on the market.