Operational Risk Treatment

Recently I’ve blogged about how to reduce Risks from Threats using Vulnerabilities by eliminating Threats, by reducing Vulnerabilities or by reducing Consequences – or by a combination. Acting this way is an example of one of the three major strategies for Operational Risk Treatment – Risk Reduction.

The Risk Management Concept is about optimizing your outcome of Risk. Your Management should contain your organization’s expertise on managing Business Risk, and you may be your organization’s Operational Risk Management guru. If so, you know that Operational Risk Treatment is about minimizing the total costs for Risk outcome and protection and about keeping your Risk within limits defined by your organization’s Risk Appetite.

One good source for knowledge about Operational Risk Management is ISO/IEC 27005. For those of you who prefer free access to information, open sources include ENISA, who presents the following list of your Risk Treatment options:

1. to avoid the Risk by deciding to stop, postpone, cancel, divert or continue with an activity that may be the cause for that Risk; 
2. to modify the likelihood of the Risk trying to reduce or eliminate the likelihood of the negative outcomes; 
3. to try modifying the consequences in a way that will reduce losses; 
4. to share the Risk with other parties facing the same Risk (insurance arrangements and organizational structures such as partnerships and joint ventures can be used to spread responsibility and liability); (of course one should always keep in mind that if a Risk is shared in whole or in part, the organization is acquiring a new Risk, i.e. the Risk that the organization to which the initial Risk has been transferred may not manage this Risk effectively.) 
5. to retain the Risk or its residual Risks 

The (residual) Risk level is a result of your application of the three major Risk Treatment strategies: Risk Reduction (p. 2 & 3), Risk Avoidance (p. 1) and Risk Sharing (p. 4). Or, of course, if Risk is acceptable from the beginning, by applying the fourth strategy: Retaining Risk (p.5). In either case, you may not stop treating Risk before each and every (residual) Risk is either explicitly accepted by the Risk Owners or fitting into your organization’s Risk Appetite picture. I.e. every application of a Risk treatment Strategy ends in Retaining Risk.

To Be Compliant Or To Be Secure? There Is A Risk...

Both Compliance and Risk are Business issues. Security deals with Operational Risks, which may include the Risk of being non-compliant. But Compliance seldom cares about Risk or Security. It cares about whether you follow the rules or not.

IMHO, Compliance is Compliance and Security is Security, and they seldom meet. Being compliant might give you  some protection you need - and some you don't need as well - but to achieve the security level optimal for you, you must do your entire homework. 

What I try to point out is that Security needs a Risk based approach to be successful. Of course you need to be compliant, too. But Compliance only gives you license to play a risky game. It does not make the game a safe one. 

"I follow law, agreements and policies" is a poor excuse for not doing the right things. 

Policies are decisions made beforehand, assuming a specific reality, both in-house and in the surroundings. Think budget, as an analogy: Budgets are predictions, built on plans and assumptions about the future economic outcome. If reality turns other ways than predicted, even if you follow your plans your results will not be as budgeted. 

And as reality changes, following policies will give other results than expected, too - unless you are Aware of the changes and Able to change or neglect policies when appropriate, or at least to initiate policy changes (always assume you are Accountable!). 

Did you see the AAA Triplet in the paragraph above? Here is another triplet: There are three levels of defense in an organization: Management, Control, and Audit. Never mix them! And never assume that Control or Audit can establish Security in your organization! What is poorly done in Management may be found by Control and criticized by Audit, but only Management has the means and the obligation to introduce the corrective changes needed.

Compliance (i.e. abiding law, agreements, incl. agreed standards, and policies) will introduce some good "security" and some good "governance", but it cannot give you all you need in either respect; there will be wants and deficits to deal with, which you will not find if "Compliance" is your only tool. And there is an obvious Risk (sic) with a Compliance based approach that you get - and pay for - much more than you need; lookout for the "best practice trap"! This your stakeholders will dislike...

In short: Do not abdicate by letting Compliance (or Audit) set your agenda! You cannot afford it.

Security Aware Employees - Yes, It Is Possible!

I often use the thought model AAA = Awareness, Accountability and Ability.

There is a "lowest organizational level" where formal Accountability may be found, and that is just so far from Management where you still are allowed to use your Abilities to manage both the costs for risk and the costs for mitigation connected with the information. On and above that level, too little Risk (and Cost) Awareness hurts severely.

But to get that full engagement from all your co-workers, you need a little more. Your Co-workers will never act "correctly", from your point of view, if they are not Risk Aware and thus understand how threats use vulnerabilities to create damage. And they will not read - or understand - all your policies, rules and smart blog posts on your intranet if they lack time or interest.

So how do you create that interest? By giving, and asking for, confidence, down to the lowest levels. By communicating (give and take) on risks, threats, vulnerabilities, and mitigation, and by positive(!) and negative feedback on behavior. By Good Management, to be short. MBWA, if you wish.

Communication is both ways (up, and down) and mutual understanding smoothes the road. But to start with, and often down the road, too, it is one way information. Since "we", the senders, really want to share our knowledge with "them" and "they", the receivers, have very little time for us (being just one of a zillion eager senders with each his own professional language), "we" are accountable for the results of the communication and thus need to make our message observed and easily digested. 

You cannot blame the receiver for not observing or understanding a message in a difficult language...

Profitable Security

Security is when no possible threat will result in consequences you cannot accept. If you are not already secure, you need to mitigate your risks. But how do you efficiently mitigate risks? Is risk mitigation profitable? 

First of all, how and when does a threat become a risk? 

In my last blog post I wrote that a threat needs a vulnerability to be able to cause damage. No vulnerability or no threat means that no damage will occur. If both exist, future damage is probable. How probable damage is depends on the nature of both the threat and the vulnerability. So the probability part of “risk = probability * consequence” depends primarily on how threats interact with vulnerabilities. 

But there are interdependencies between threats, vulnerabilities and consequences that need to be understood. Let’s take a look at an attacker whose rule of decision is “maximize profit” (a fairly simple scenario). 

The probability of damage from an attacker is a function of the attacker’s decisions. Those in turn depend on the presumed consequences from attacks (i.e. the earnings) and on the “cost of use” of your vulnerabilities. 

The attacker wants your money to add to his earnings. He has a couple of methods that use your vulnerabilities, he knows how much each method will cost him (in time, money, punishment etc.) and he estimates how much money there will be left for himself in each case. He also contemplates over his ability to use his methods on you – does he need to enhance his knowledge or abilities (or your vulnerabilities) beforehand (i.e. more costs)? 

He adds up all the costs and the expected earnings for each of the possible attacks and decides which, if any, to use. If you are more costly (= secure) than he likes, he is no threat for the moment – he will attack someone else instead. 

It is all summed up in this simple picture (adapted to the Attacker Scenario): 

As you see, there is a battlefield to keep within for both of you. There is no point in this scenario to work with other parts of the Risk Pyramide than Ability, Vulnerability and Consequence. The attacker works steadily on his Ability to use our vulnerabilities (and to make them worse, if he can). Our choice of Risk Mitigation is to reduce our Vulnerabilities and the Consequences of attacks – in fact we are trying to persuade the attacker that it is uninteresting for him to attack us. If he agrees, it is Game Over. For a while.

OK, with all this cleared out, how do you know when enhanced risk mitigation is profitable? You must think Return On Investment (ROI). What is the Present Value, or the Annuity, of your suggestion? What do you put into your calculations?

The only really difficult part should be the probabilities. A small tip is to transform probabilities into frequencies, i.e. make your consequences distributed over time, just as your activities. You initially need the frequency of the damage you want to avoid and the distributed value – or costs – of that damage (the Zero Alternative, i.e. doing nothing). Then you need to know the frequencies and the values – or costs – of the damages that will occur after your selected choices of activities are implemented and the frequencies and the values – or costs – of the corresponding suggested sets of activities. Then calculate e.g. the present value of each of your cases defined, including the case of doing nothing. Your prime choice is the cheapest.

Done. No go and inform your peers and ask for their support for your suggestions.