CHAPTER 6: RISK MANAGEMENT

Risk assessment is at the heart of the information security management system (ISMS). Understanding its significance to the overall process is critical, and is one of the keys to project success. Top management adopts an information security policy because there are a number of significant risks to the availability, confidentiality, and integrity of the organization’s information, and it mandates the design and deployment of an ISMS in order to ensure its policy is systematically and comprehensively implemented. Therefore, the policy must reflect top management’s assessment of information security risks and opportunities. This does not mean top management 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 the ISMS project forward.

The organization needs to determine its criteria for accepting risks and identify the levels of risk it will accept. It is a truism to point out 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 will not, 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 the business can be managed within that context.

Information risk is one of a number of risks the organization must control, and, to the greatest extent possible, it should apply a common risk management framework to all the risks it faces.

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 organization in order to understand a) its overall approach to risk, and b) its specific approach to information security risk. If the organization does not have any such formal function, it is imperative to identify the current approach to identifying, assessing, and controlling risk—and those involved in the activity—as quickly as possible. You will need to ensure there is a consistent, organization-wide approach to managing information security risks.

Introduction to risk management

All organizations 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—those from which either a profit or a loss can occur—are the subject of the organization’s business strategy, whereas non-speculative risks—those risks that can reduce the value of the assets with which the organization 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 organization’s risk appetite.

Risk management plans have four linked objectives, which are to:

1. Eliminate risks
2. Reduce those risks that cannot be eliminated to ‘acceptable’ levels, and then either
3. Live with them, exercising carefully the controls that keep them ‘acceptable’, or
4. Transfer them, by means of insurance, to some other organization.

Pure, permanent risks are usually identifiable in economic terms; they have a financially measurable potential impact upon the assets of the organization. Therefore, risk management strategies are usually based on an assessment of the economic benefits the organization can derive from an investment in a particular control. In other words, for every control the organization 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 organization should define its criteria for accepting risks (for example, it might say 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 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 An International Guide to Data Security and ISO27001/ISO27002, Sixth Edition.

The ISO 27001 requirement is the risk assessment should take into account both the organization’s context (internal and external) as well as the requirements of third parties that might be relevant to, or have an interest in, the organization’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, identifies the threats to assets, vulnerabilities, and impacts on the organization, and should determine the degree of risk it is prepared to accept in the light of its business model, business strategy, and investment criteria.

Baseline security controls

As discussed earlier, step five in the ISMS implementation process is to identify and implement the controls required to meet the organization’s legal, regulatory, and contractual obligations (there might be a number of different obligations, depending on the jurisdictions within which it operates). It is also necessary to identify any controls that may be required by customers and suppliers, or other contractual mandates, and to include them in the baseline control set. The Compliance Manager is a useful tool; it helps identify specific controls that may 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, recognizing, 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 technical risk assessment tools must be used, although in more complex situations they will likely improve the process and add significant value. The complexity of the risk assessment will depend on the complexity of the organization 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 top management.

Five-step risk assessment process

There are five steps to a successful risk assessment.

1. Establish a risk assessment framework
2. Identify risks
3. Analyze risks
4. Evaluate risks
5. Select risk management options

Experienced information security and risk management practitioners know manual risk assessment methods are highly dependent on one or two individuals within the organization, 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. Therefore, they always will 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 organization’s risk management objectives consistently and cost-effectively.

Who conducts the risk assessment?

Unless the organization 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 organization) 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). 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 organization already has a trained information security adviser, this person could take on the role.

In circumstances where the organization 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 its information security risk assessment process is included from the outset.

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 analyzed in terms of their likelihood of occurrence and their impact if they do. The impact can be either positive or negative. Different organizations 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 is for the lead risk assessor to create a list of relevant risks that compromise the confidentiality, integrity, and availability of information that is within the scope of the management system, and which roles within the organization 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 the list of identified risks (and relevant opportunities) is complete and 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

It is necessary to identify the possible impacts 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, and so on) that reflects the size of the organization and the total cost (direct and indirect) of the incident.

Next, assess the probability of the event occurring using a classification system such as one time every few years, one time per year, one time every six months, etc. Virus attacks would fall into the ‘every day’ category.

These steps enable 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 organization) and then to conclude, for each risk, and in the light of the 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 keep in mind about the risk assessment is it is not a one-time exercise. You will need to repeat it on a regular basis, just to check your baseline assessment is still accurate and the controls you 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 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 organizations use risk assessment tools as part of their management system.

Risk assessment tools

Most organizations will want to automate their risk assessment process so this best practice becomes embedded in the organization. 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 organization will form a significant part of the completed system. The reality is 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. Therefore, it is important to have an overview of controls.

The concepts of risks and controls are linked and are fundamental to your ISMS. 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 organizational 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. For example, looking at the virus and cyber threats that are widely recognized even by boards of directors, ISO 27001 Control A.12.2.1—and common sense—require the implementation of controls against malicious software. When you think about this issue, it is immediately clear you must blend technological controls with procedural ones—neither on its own is adequate. It is also clear 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 organization to complete or submit required reports on time:

At the same time, ISO 27001 Control A.13.2.3 stipulates information “involved in electronic messaging shall be appropriately protected.” Anti-malware software on its own just does not 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 behavior.

Yes, you need an appropriate software package, one that will ensure incoming viruses, worms, and Trojans are stopped at the perimeter—and spam is filtered out. But it is no good if documents that users have specifically requested from external sources to be sent by email are corrupted by the anti-malware software ‘just in case.’ For example, we know PDFs sent via an automatic response e-marketer are often nuked by the recipient organization’s anti-malware software, and 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 to 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 organizational information security perimeter was easy to define and defend, but with the proliferation of handheld devices, wireless networks, and mobile working, the perimeter has become porous and very hard to defend. Depending on the risk assessment, organizations should look 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, like a virtual private network (VPN). This control area will be found to interact with Control A.6.2, which requires the organization 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. It becomes outdated fast, so you need to have procedures in place to ensure it updates properly. Most organizations do not have a lot of time for testing anti-malware or other updates and fixes. Nevertheless, exploits and attacks have revealed vulnerabilities are now arising faster and faster—rapid deployment of fixes is usually critical, and this can only be achieved if you have 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 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 you to compare any controls 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 organization 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 (top management-determined) criteria of acceptability, or transferring those risks (through insurance) to others, there are three types of control:

1. Preventative controls, which protect vulnerabilities and make an attack unsuccessful or reduce its impact.
2. Corrective controls, which reduce the effect of an attack.
3. Detective controls, which discover attacks and trigger preventative or corrective controls.

Controls are not implemented irrespective of the cost. No top management 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 any implemented controls are cost-effective. The principle is 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 organization 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 prioritizations have already been adequately controlled and, therefore, it is now appropriate to invest in controlling this one.

If the organization 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 such risks when they occur. 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 (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 organization, 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 organization’s pre-determined risk appetite and within the context of the risk assessment framework. Risk treatment decisions must be justified by the risk assessment (recognize 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 postgraduate 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 indispensable 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 take in order to deal with each of the risks you identified in your risk assessment. Those risks you are accepting or rejecting need no further action, other than possibly finding a workaround for those you reject. Those you intend to transfer need to be the subject of negotiations with insurers and/or suppliers. Those you intend to control need action, and your RTP describes those actions: what has to be done, by whom, and by when.