Philosophy of Security, part 8 – Risk Management – Consequences and “Risk Appetite”
So far, looking back at security discussion series in part 7 we took a side trip to explore a different way of looking at vulnerabilities called the Attack Surface.
Earlier, in part 5, we have looked at the overall Risk Management process using AS/NSZ 4360 Risk Management standard as an example of a well documented process and methodology and in part 6 we discussed the concept looking at of risks as combination of Vulnerabilities and Threats.
What I would like to do next is to explore the consequences of a risk event, and the concept of “risk appetite” (also known to some as “risk tolerance”).
Consequence of an event is a collective term used to describe the outcome of an event and impacts of that outcome .
Whenever a threat or a risk comes to pass, the event has some outcomes. What actually matters to most organisations and individuals (and is therefore the focus of Risk Management and Risk Analysis efforts) is what impacts these have have on the business systems, processes and assets (including reputation and customer goodwill).
The outcomes by themselves are simply objective observations on what actually happened.
However objective and factual the statement of outcomes of an event might be, what is critical to most organisations is the impact of the event, that is how the event affects a system, a process or an asset. The impact to reputation of an organisation (an asset) from a simple and minor flaw in an on-line ordering system may actually be very high.
In all cases it is the owners and stakeholders (who have been identified in the context setting phase of the Risk Managemnt process) of the impacted systems, processes and assets who are responsible for deciding and communicating what is the level of impact of a set of events.
Examples of events, outcomes and impacts:
Event 1: Warehouse burglary
- Outcome: a warehouse was broken into, doors are damaged and 100 flat screen television sets were stolen
- Impacts: financial and potential reputation damage:
- warehouse insurance (if we have any) premiums will go up;
- need to pay to repair damage to the warehouse;
- need to replace lost stock;;
- can’t service customers orders on on time, which affects our reputation as a reliable trader;
Event 2: exploitation of a flaw in a web application
- Outcome 2: an external party to obtained personal information about some of the organisation’s clients.
- Impact: loss of reputation, incident recovery costs, software update costs , loss of client base.
- reputation of the organisation will be damaged and there will be a need to handle the matter carefully to prevent widespread loss of customer trust.
- there is a need (this is a legal requirement in some jurisdictions ) to notify customers whose details have been accessed. This process can be quite embarrassing for the organisation and for the the clients, causing them to leave.
- need to cater for large volume of calls to the support call centre
- need to restore the server from backups, because we need to be certain that there is no malicious code running on our server
- need to develop and apply a patch the faulty software
Event 3: natural disaster – flooding
- Outcome: an area is flooded, buildings cannot be accessed and are without electricity
- Impacts: business continuity plans (if any) invoked; sites and systems are inoperative;
- reduced capacity for, or loss of, customer services;
- reduced capacity for, or loss of, production and distribution of goods;
- costs of infrastructure recovery;
- cost to replace lost stock;
- insurance (if we have any) premiums will go up;
As we can see above the can be quite difficult to keep the natural language used for describing consequences consistent. Also we need to recognise that event the same example will cause different people to react very differently to some of the impacts. This becomes even more pronounced when we start to deal with a specific industry such as mining, health and medical services or information technology services, where certain words (like “infrastructure” for examaple) have very specific but very different meanings.
This is why many industry specific risk management and security standards and methodologies have introduced specific terminology to help define the impacts of events. For example the AS/NZS ISO/IEC 27002:2006 series of Information Technology security standards uses the Confidentiality – Integrity – Availability triad of attributes of a systems, processes and assets, to describe impacts of events. Vast majority of ICT security and risk management standards follow the same pattern.
Closer to Home: language for consequences in the Information and Communications Technology Systems
In the Information and Communications Technology (ICT) risk management the terms Confidentiality, Integrity and Availability have a specific meaning:
- Confidentiality – the information held within a system, a process or an asset is held and processed in such a way as to be accessible only to the authorised users. In this context, confidentiality is a necessary condition for privacy of data.
- Integrity – a system, a process or an asset behaves in a consistent manner, that was intended by its designers and that no data is being modified in an unintended fashion without that modification being detected.
- Availability – a system, a process or an asset, and the services and the information they hold and process is available for use by authorised users as required and when required.
Note : Personally, when dealing with ICT systems I like to add another attribute: “auditability”. In this context auditability refers to the ability of the owners and stakeholders of an ICT based system, business process or an asset to satisfy themselves that the levels of confidentiality, integrity and availability are maintained in line with their business requirements.
“I don’t care about that” is a valid risk management statement, provided the person or the organisation using this method have high enough level of risk appetite.
“Risk Appetite” (also called “Risk Threshold” by some) is simply a measure of how much risk a person or an organisation is prepared to live with before they will commit resources to mitigate these risks associated consequences. In a It is an expression of a particular type of cost-benefit analysis which pits potential costs and consequences of an event, againt the costs of attempting to minimise the chances or reducing the impacts.
Unless there is a legal or contractual requirement to deploy certain kinds of security measures, or to minimise certain kinds of risks, the decision on how much risk to accept and which need to be treated is a decision that is the responsibility (and a privilege of sorts)of the the owner of a system, a process or an assets.
Given the variable risk appetite of various organisations and individuals (based on the varied perception of the severity the consequences of an event) involved in a risk management process, it is our goal to provide ( as far as is possible) an objective and unbiased assessment of the risks, their likelihood and their potential impacts, because that will be the information that will be used to make decisions about severity, risk prioritisation and risk treatment. Some of the below pointers might be helpful in achieving this aim:
- use a consistent risk analysis methodology
- be aware of biases in your own perception of risks
- where possible, attempt to use quantitative methods to estimate the likelihood of each risk (how likely it is to happen)
- be (as far as we can) objective in describing the outcomes of an event
- engage the asset owner and other stakeholders when working out the impacts and grading their severity, as different people will have a different focus and different views
- not all risks can be eliminated or reduced. All risks can, to some extent, be managed.
I will discuss the various methods for risk treatment and management, in the next instalment of this series