Castles in the Cloud

Let’s start with a simple question – I give you a pound to look after for me. How much would you spend of your own money on protecting that pound?

Less than a pound? A pound? More than a pound?

You have almost certainly gone for the first option. After all if you lose the pound then the most you will be out is one pound so why pay more?

Ok, but what if you are a bank? You expect to be looking after lots of money so you build vaults, employ guards and build processes. All of this costs significant sums of money but there has to be a chance, small though it may be, that at any moment in time you may just be protecting one pound with all this security and investment.

So what about cloud computing? I put a “pound’s” worth of data into the cloud. How much are you going to spend protecting my data?

People sometimes pitch to me that they are like “a bank for data based in the cloud”. And then I ask them what they do to prevent bank robberies…

So your data is in the cloud, and that is nice, it is accessible from anywhere, it is transparently backed up. Everything is wonderful, and then the bank goes out of business. What happens to your data then?

I once had someone telling me about their wonderful cloud based data bank service which lots of people had bought. I asked them what would happen if they went out of business. Oh, they said, no one has ever asked us that question before.

If your organization has a contract for cloud based data storage – back up, live use, whatever – I strongly suggest you find out the answer to that question if you do not already know!

So your data is in the cloud and you have proper governance arrangements in place in case the supplier goes bust. All is fine. Until suddenly someone mentions aggregation.

Aggregation is the principle that the more of something you have then the bigger a target it becomes and the greater the consequences are of loss.

Back to money again, if I put a million pounds in the bank vault then the Willy Sutton principle applies. If I leave my million pounds scattered in piles of one hundred then the risk to me is that I lose at most one hundred pounds, if the vault is raided then I lose all one million.

The same with data, finding data in most organizations is usually a matter of luck. It is hidden in emails, shared folders, private folders, EDRM systems, databases etc. Data loss or theft tends to be of individual documents and any sensible risk management policy segregates data access to minimise the threat of some one person having access to all the pieces.

But now we are putting them all into the cloud, all in one place. Ah, hello Mr Sutton.

Part of the problem is that our security model remains essentially medieval. We build a vault, we put our treasure in the vault, we post guards around it. We need a different model in the cloud age, one where security is embedded into the individual atoms of information.

And atoms of information is a good way of thinking about the potential implications of bringing some of these individually innocuous but collectively explosive nuggets of data. People may recall in the early days of chip and pin some tills would print out the last 4 digits of your debit card number, some would print out the first 4 digits, and some the middle digits. Individually, each piece was of little threat, collectively… Hello empty bank acount!!

You might just want to spend some time going through your last bank statement…

Advertisement

Breaking rocks

There was an interesting post on Slashdot this week about someone who went to load their official Cisco VPN client CD only to find that it was in fact a bootleg music disc. These things happen,  suppliers outsource to third parties who subcontract to others who find slack in someone else’s JIT delivery system.

Then I read this piece and cogs slowly, rustily start turning in my mind.

Complexity adds risk. If I have just a single rock then my risks are limited, the rock basically sits there. I could lose it or drop it or trip over it or break it but that’s about it. If I have two rocks then not only have I now doubled the number of those risks but I gain new ones as well – one of the rocks could fall off the other for example or I could lose one rock behind the other.

So complexity breeds risk, so far so obvious. Companies outsource and there is now an added creator of risk to mispress CDs, government buys from the cheapest supplier and there is now an added creator of risk to mis-sell hooky gear, you can name your own examples.

We work to try and mitigate these supply or delivery chain risks but there are two additional sources of complexity which we do not always consider.

The first is that risk mitigation can itself be a source of risk. Recent events in the financial world are a classic example of this. Some people thought that they had cracked the secret of achieving high returns without high risks. IT supports the creation of complex and often opaque financial risk management tools which make Black-Scholes seem like basic addition. Combine this with automated trading engines and we create a vast cybernetic plate-spinning engine which works until the first plate starts wobbling.

Paul Samuelson said “Business is the management of risk”, for me this means that unless you are willing to manage your risks then you should not be in business. And management does not mean magical thinking.

The second source of emergent risk arises out of the complexity of individual systems. Think for an instance about how you are reading this piece. You are using a computer whose hardware you trust, whose operating system you trust, a browser you trust, a network connection you trust, a network protocol you trust, a website you trust, a web server you trust, web server hardware you trust, and network hardware you trust.

That’s a lot of trust isn’t it?