One of the biggest stumbling blocks for companies contemplating entrusting a cloud-computing vendor with their data is the risk of unintended data exposure. A lot of data is sensitive. It might contain employees' financial information, patients' statutorily protected health information, other regulated information or proprietary intellectual property. Quite often, companies feel more control when they keep that sort of data in-house. But the risk that a cloud vendor might not handle your information as securely as you'd like can be mitigated.
One good way to do that is with encryption. An encryption algorithm encodes data, rendering it unreadable to those who don't possess the decoding key. The idea is that, if encrypted data falls into the wrong hands, it will be of little or no use without the encryption key. This can help mitigate concerns related to the data being hacked or even being legitimately accessed by a government, which is a particular concern when the data center where the data is being stored by the cloud vendor is located in a foreign country.
If you're depending on encryption to protect your cloud-based data, you'll need to determine how the cloud vendor facilitates encryption. Questions to ask include the following:
* Does the cloud vendor encrypt your data both at rest and in transit?
* What level of encryption does the cloud vendor employ (128-bit, 256-bit, etc.)?
* Who has access to the encryption key (customer, cloud vendor, third parties, key escrow)?
* What encryption standards have been employed by the cloud vendor? For example, Federal Information Processing Standard (FIPS) 140-2?
*How are encryption keys managed, and where is the encryption key located?
This last question is particularly important because sloppy handling of the key can negate the value of encryption. For example, in December 2011, SpecialForces.com was hacked by the hacktivist group Anonymous). SpecialForces.com's data was encrypted, but those diligent Anonymous folks hacked in again, found and accessed the encryption keys, used them to decrypt the data obtained during the initial hack, and posted that data on the Web for public viewing.
Even when used and configured appropriately, encryption isn't always a silver bullet. As with most risk mitigation strategies, there's a trade-off between costs and benefits. Risk might go down with encryption, but adding encryption typically increases the total cost of using a cloud solution. What's more, adding encryption can result in slowed or diminished performance due to the extra steps introduced into the process. And in reducing one risk, an entirely new one is introduced: If the encryption key is lost, the data can no longer be decrypted and essentially becomes useless, even to the customer.
Meanwhile, cloud vendors themselves are developing and deploying alternative techniques for rendering compromised data useless. Examples include these two:
* Distributed file systems -- Individual files are essentially split into multiple pieces and stored on multiple machines in multiple locations. The idea is that if any one data element falls into the wrong hands, it will be of little or no value without access to the remaining parts of the file.
* Data masking/obfuscation -- The relationship of sensitive data to related data elements and/or data subjects is obscured, rendering the data useless should it be inappropriately accessed.
Any company thinking about adopting a cloud-computing service should identify the mechanisms for addressing data risks that the vendor uses or supports, determine which meet the customer's needs and ensure that those are codified in the contract as minimum requirements.
Thomas Trappler is director of software licensing at the University of California, Los Angeles, and a nationally recognised expert, consultant and published author in cloud computing risk mitigation via contract negotiation and vendor management. For more information, please visit thomastrappler.com.