Cloud Vendor Lock-Ins Lock Out Secure Practices

The ramping up of the Open Cloud Initiative (OCI) brings to light an important security issue that makes the development of a federated cloud framework essential. The corporations and governments that will use these services will not only want to be able to move services from one cloud supplier to another but, more importantly, they will want to use several suppliers.

As has been seen from recent hacks, putting all your data within a single third-party’s cloud infrastructure leaves everything open if the chosen supplier is breached. It would be foolhardy not to spread the risk by storing data and applications with several suppliers.

Customer Need v Corporate Greed

The problem is that the suppliers are aware of the pure concept of federation but resist interoperability because they are busy locking users in – just as the minicomputer and mainframe companies did in their day.

It’s a question of trying to reach critical mass which, in this case, simply means grabbing the lion’s share of the market before the users stop to think about what the lock-in means. The ambitions of the suppliers and their shareholders’ desire for profits conflict with the actual needs of the customers.

When I have used the “lock-in” phrase in the presence of cloud vendors, they deny there is anything stopping users from moving elsewhere. Though there is truth in this, it is the manner in which that move has to be made. It could mean being given a carrier bag full of optical discs with CSV files to take to your next supplier – hoping to sort things out before the business starts to miss the information source. It’s unlikely to be as crude as this but the reality of the problem existing is apparent.

To have data in one place and applications in another allows some kind of freedom but we’ve yet to see a true mechanism for making it work without introducing serious latency problems.

Federated Data In The Cloud

From a security angle, it would be better to split a single body of data across several providers. If a hacker should then find a vulnerability in one system, the damage would be limited to a subset of the database and not the whole information store. Equally, if a site experiences a major distributed denial of service attack, at least some of the data will be available which could minimise the damage.

Complacency is not an option. As has been shown many times, nobody is safe these days and, while companies are becoming aware of the new set of best practices they need to follow to combat stealthy and persistent attacks, there is no guarantee that a third party is showing the same degree of vigilance.

Hacking is a professional market with gangs pooling their resources to wage a kind of guerilla war, nation states funding disruptive or espionage attacks. With such great, dark powers ranged against them and the import of increasingly mission critical data, the cloud providers are set to become major targets and the likelihood of a successful breach is only a matter of time.

Can A Hack Be Forgiven?

It would be interesting to see tolerance levels tested. Is the inconvenience of a data breach in the cloud enough to make a corporation move to a new supplier or will the event be shrugged off in the face of the further disruption that would be caused and the financial gain accrued from any penalty clauses?

While the current cloud silos exist, I would argue the customer is running a risk that is beyond acceptable. Vulnerabilities will be found and exploited as new techniques are discovered or as cloud employees are handsomely bribed or blackmailed into the service of the miscreants.

Standards development and interoperability are welcomed – though the number of “standards” are increasing rather than consolidating – but these new bodies have yet to prove their worth by gaining the membership of all the big players. Perhaps it is time for citizen power or corporate push to force the issue and combine their clout into a mighty blow that will knock some greater sense of responsibility into the cloud providers.