Information Security A Practical Guide: Bridging the gap between IT and management (2015)

CHAPTER 3. BUSINESS RISK APPETITE

Chapter Overview

The business’ risk appetite is perhaps the most important thing to know when working to secure a system. When I began my career in security I understood how to secure a system; I had a wealth of knowledge, tools and techniques for protecting different systems. What I did not understand at that stage, however, was how do I know which controls to implement and how secure should each system be. What I did not understand was the risk appetite, which is (defined by ISO31000) how much risk is the business willing to accept in trying to achieve its goals. Of course it’s not simply a case of saying I’m this hungry for risk; we need to understand how to define that hunger and then apply it. Risk appetite allows us to look at our list of risks and then decide which risks we want to fix and which ones we are willing to accept and live with.

I recommend completing a risk appetite assessment for the organisation as a whole, as this will help you further understand the organisation’s security culture. An organisation may have a strong security culture where they understand the risks but their attitude may be to live with those risks in order to give them business agility and not be tied down by additional security controls. This attitude is fine as long as the risks are identified, fully understood and the impact fully considered. You should then conduct a separate risk appetite assessment for each system you work on using your organisation’s appetite as a baseline. The reason for this is that the person you are speaking to may not be fully aware of the organisation’s attitude to risk so you can help guide them using previous assessments if needed; but remember, it is ultimately up to the business.

In summary, this is just good risk management.

In this chapter I introduce risk appetite and show how you can assess and define a level of appetite by speaking to various people within the organisation. Ultimately the risk appetite is defined by a manager and those senior staff members who are responsible for the security of IT systems.

Objectives

In this chapter you will learn the following:

• The five levels of risk appetite

• How to describe the five levels of appetite and what they mean

• Risk treatments and how they are applied as security controls.

Risk Appetite

There are five basic levels to risk appetite, which range from averse to all risk all the way to hungry and willing to accept any risk as long as there is business benefit. The appetite level usually relates to the sensitivity of the data it relates to. For example, an organisation that is building a system that relates to people’s health and safety is likely to be more risk adverse, whereas a company that is trying to react to a market trend quickly may be more open to risk if the financial rewards are great.

While conducting your assessment it is worth referring back to the previous section and reminding yourself and the person you are in discussion with of the business impact. If the impacts are likely to be severe then ultimately we are going to want to be more cautious in our attitude to risk.

Averse

Every effort should be made to avoid risk, you will always favour the safer option when managing a risk, and if there is no safe option then there is a strong possibility that the system will not be implemented.

Minimal

The organisation still favours the avoidance of risk and will always choose the safest option. However, it is unlikely to go to such extremes as cancelling projects in order to avoid risk. It is, however, likely to spend more time rethinking its plans to mitigate after risks are found.

Cautious

The organisation has a pragmatic view of risk; it understands that with any potential business gain there will always be risks. The organisation will look to favour the safe option unless that option is too costly or technically difficult to achieve.

Open

The organisation is open to risk. It will mitigate risks when the option is cheap and easy, else it will favour the option that provides the most business benefit. However, the business still wants to maintain a handle on what the risks are and to what level they are.

Hungry

The organisation is eager to implement its new system and delivery of that system is its highest priority. It wants to be aware of risks but any mitigations proposed will also have to offer the highest business benefit for it to be considered.

Risk Treatments

Once we understand the business’ appetite for risk we can look at mitigations. Typically mitigations fall into one of the following four categories: avoidance, reduction, sharing and acceptance. Your risk appetite helps you decide which type of mitigation should be used. For example, a risk-averse organisation is unlikely to accept retention of a risk, whereas an open organisation is unlikely to favour avoidance if there are business benefits.

The order of the categories starts with the most risk-averse option, with their openness to risk increasing as you go down the list. This enables us to pick the most appropriate control: if a risk cannot be avoided then it should be reduced, if it cannot be reduced then it should be transferred, and if it cannot be transferred then we accept it.

Avoidance

The mitigation for the risk is to avoid it. At one extreme this could be to cancel the project in its entirety or simply build the system in a different way. When deciding to avoid the risk it is first important to understand what the impact of the risk is; for example, would you be in breach of the law. It is unlikely that even an open organisation is keen on breaking the law in order to achieve its goals.

Avoidance can also mean that a risk is fully managed so that it no longer exists, therefore it has been avoided. For example, if a system is likely to be attacked from the Internet then the best way to avoid this is not to connect it to the Internet, therefore the risk is fully managed.

Reduction

This is the most common action taken when managing risk. The reality is that most risks cannot be fully mitigated with controls and that some residual risk will always remain. If, for example, our system has the risk of being infected by malware, we may choose to install an anti-malware system in order to combat infections. We also know that anti-malware systems are not perfect and if exposed to new malware then it may not have been updated to detect the new infection. We must take time to understand how much we have reduced the risk and is this reduction adequate for the project. In fact we have possibly created another smaller risk of the malware failing to detect an infection, which may lead us to consider other controls such as limiting data into the system or even storing incoming data in a fashion that stops it from running. If we go down this route then we are actually applying many controls to the one risk in order to further reduce it. You will have no doubt come across this before, having heard of the term ‘defence in depth’, the idea being that if one control fails then there are others that will hopefully be able to resist the attack. It’s like a castle that has a wall, a moat and men to defend it.

Transfer

Typically the organisation is not able to or is unwilling to reduce or avoid the risk so it chooses to transfer it to someone else. There are many ways to transfer risk: via insurance, outsourcing or contractually. Say our system is going to handle lots of personal data and a breach may result in your organisation being sued; you may choose to take out liability insurance in order to mitigate the claim.

If the system you are proposing to build carries many risks and you believe you don’t have the skill or appetite to implement it, you may choose to outsource the function. A common example of this is online card payments where organisations are required to abide by the Payment Card Industry Data Security Standard (the PCI DSS). The organisation may decide that compliance is too expensive or onerous and choose to use a third party, for example PayPal or Sage Pay.

Finally we come to a contractual transfer. Returning to our anti-malware control, it is possible that we may get agreement from the supplier that they will accept a limited amount of liability should their software fail and damage is caused to our system. These types of agreed liabilities are more common when discussing the availability of a system where typically a service-level agreement will be made on how much uptime is expected of the system.

Accept

The final type of control is to simply accept and log the risk. However, an organisation may choose to put aside a cash reserve should it be sued or be subject to any fines for a data breach. An organisation should have a good reason to just accept the risk, as many countries now have data protection laws that must be followed if working with personal data. However, if you aren’t working with personal data then accepting the risks may be the most practical option.