Recent incidents of data leaking from cloud-based applications have given many organisations pause when it comes...
to launching their own information into the ether. Andrew Collins asks: what are the vendors doing to secure your data?
Google recently ran into trouble when a bug in its cloud-based office suite, Google Docs, compromised the privacy of some users’ data. The bug inadvertently exposed some documents hosted on the service to other Docs users, who should not have had such access.
To its credit, Google’s response was prompt and fairly transparent. The company came forward with details of the problem, revealing that 0.05% of documents hosted on the service had been compromised. Furthermore, Google emailed all the users who were affected by the bug, explaining the problem and how it affected them.
Of course, considering the public and damaging instances of data leakage in the last decade, Google’s slip-up did not go unnoticed. And given that the internet loves nothing more than a good controversy, many bloggers leapt aboard the bandwagon of derision, publishing posts and articles with titles like “Google fail: how reliable is the cloud?’, “Should the FTC [US Federal Trade Commission] shut down Gmail and Google Docs?’, and “Can We Continue to Trust Google?’.
These angry posts reveal a common sentiment among users of cloud-based applications: that it’s unthinkable that a service provider could let any such breach occur, no matter how small. And given that 0.05% of all documents hosted on Google Docs probably amounts to a significant number of documents, the concerns are certainly warranted.
With the egg still sliding off Google’s face following the incident, we are left with one question: how are cloud providers keeping your data safe?
Three ways to cloud security
There are several ways in which web app vendors secure their offerings, which roughly fall into three categories.
1. Data centre security
The first thing a vendor must do is secure the location where the data is stored. This entails both network and physical security measures.
With its eight web applications, Australian web services company Elcom has become deft at deflecting web-based attacks such as SQL injection and cross-site scripting attacks. Angus McDonald, Elcom’s technical director, explains that these network security measures include layered routers and firewalls, as well as active and passive checks for network intrusion.
The physical measures of these data centres are often quite elaborate. Websense, a provider of web filtering and other security apps through the cloud, offers up some details of its own data centre. The list of features reads like a shopping list for a maximum security prison: 24/7 staff presence, CCTV surveillance cameras, locked cages, high-security electronic access and highly restricted access to specific areas.
Of course, it would be a bit silly for a company that specialises in security to reveal the full extent of the security measures safeguarding its data centre. Andy Lake, GM Messaging Security, Websense Asia Pacific, warns of “other security measures that cannot be disclosed”.
The safeguards don’t stop once you get your hands on the actual servers. EMC, which offers its own web services (such as Decho and Mozy) as well as the infrastructure on which other service providers can build their own services, heavily encrypts the databases enclosed on its servers. So in the event that someone successfully penetrates EMC’s data centre, they’ll have some trouble accessing any data.
Greg Singh, Pre-Sales Engineering Team Leader at EMC subsidiary RSA, explains: “We encrypt data as it sits within web service databases. So if the databases were to be hacked and someone could get to the data, it would mean nothing to them. They have to come through the front-end application, have the correct decryption keys allocated to them, and the right ticketing, to actually see that data in clear text.”
2. Securing data in motion
But securing the data as it sits on a server is only part of the equation: the data must also be protected as it wings its way across the internet. It’s no good locking down your data in an impenetrable underground bunker if a hacker can sit right outside, lazily intercepting your unsecured regular HTTP packets with a wireless modem and a laptop.
RSA’s Singh, obviously a great fan of encryption, chips in: “Everything that’s traversing across public space, we can encrypt that information so if someone wants to intercept it, and perhaps take a look at it, it would mean nothing to them.”
Alternatively, McDonald says, you could force your users to access web services through a virtual private network, bypassing the public internet altogether.
3. End-user access control
Lastly, an organisation needs the ability to control what permissions each of its employees has in a given web app. Measures must be taken to make sure that only those who need certain information have access to it. If this provision is not made, information can leak out of any number of outlets.
“It needs to be easy for your business users to control and not make mistakes,” says Elcom’s McDonald, “and it must also be easy for them to give access. Because if you’re putting information in the cloud, it’s usually because you want to share it with others.”
This access control can take a number of forms, such as a simple password or a cookie that tracks a user’s identity as they travel through the pages in a web application. Says RSA’s Singh: “Quite often after you’ve authenticated, we’ll drop some sort of a key or cookie in your browser, so while you’re in that browser session and in that web service, you’re able to get to your information, and your information alone.”
Notably, it’s this third principal that Google violated with its Docs snafu. The bug that compromised users’ data did so by blowing open a hole in the service’s access controls, so the wrong people were given access to private information.
There is another side of user control that is not explored by every service provider: specifically, how to control data that has left the client organisation. It’s all very well to restrict a particular section of a web application to certain staff. But what happens when someone’s job requires them to send that classified information off to a third party, one that you don’t want to let into your web application at all?
Potentially, this third party could print off the document and mail it to whomever they wanted. Sure, you may have grounds for litigation, but the damage will be done. In response to this need, some service providers also offer a form of information rights management (IRM). One such provider is EMC.
EMC’s Clive Gold, Marketing CTO for ANZ, describes IRM as a way of controlling information once it’s left the system. IRM users can apply viewing rules to data, restricting who can access the data, when, how many times, and so on. So if your staff absolutely must share confidential data, they can at least apply some restrictions to its use, minimising the chances of a data leak.
The human element
But in spite of all these precautions, there’s one source of potential problems that no service provider can control: a client’s end users. Even with the most stringent security precautions in place, end users — well-intentioned or otherwise — have the potential to cause problems.
When it comes to cloud computing, these problems occur when users act outside of policy, says RSA’s Singh. For example, a user might violate company policy and send some confidential data to their personal webmail account so they can finish off a job at home. If that webmail account does not employ a secure means of transport — such as HTTPS — a hacker could intercept the data and let it loose upon the world.
This aspect of cloud security, at least, is in your hands.
The cost of doing business
All traffic-chasing, rhetoric-slinging headlines aside, the Google Docs incident highlights one thing: that despite any precautions that a cloud-computing provider or a user takes, there’s still a possibility of data loss and ensuing damage. So like every business decision, the question of whether or not you should employ the cloud comes down to one thing: is the risk worth the benefit? Or phrased another way: is the cost of avoiding the cloud’s benefits worth the reduced risk?