02:05 PM
Connect Directly

2012 Data Encryption Survey: Progress And Pain

As broken protocols, cloud, mobility, and key management woes add to IT's load, the best bet is to get self-sufficient.

"Trusted Clouds"

In our InformationWeek 2012 State of Cloud Computing Survey, 27% of 511 respondents from companies with 50 or more employees say they have no plans to use services from a public cloud provider. Right. We'll bet that a good number of those IT pros don't know that their businesses already are using these services, possibly for sensitive data.

Among companies using public clouds, 64% are dealing with two to five different providers. In our experience, as more servers and applications move from company-owned hardware and data centers to outside facilities, use of encryption drops off sharply. Cloud survey respondents admit that security is a big worry; among nine possible concerns, the three associated with security came in first, second, and third, and 44% say they believe risks are greater in the cloud vs. 6% who say providers do a better job at security than they could do internally.

The 44% are right. Many cloud providers won't even support a virtual server or database server that leverages encryption. They simply lack the expertise. Finally, late last year, providers got the means to change that when third-party vendors released encryption as a service, or "cloud encryption," tools, though it's unclear how many cloud providers are using these systems.

Let's put this into context using a software as a service example. There are basically two ways cloud encryption works in a SaaS environment: The cloud provider does the encryption, or you encrypt your data before you ship it into the cloud.

When SaaS providers do allow for encryption, they usually take the former route, encrypting your data with keys that they generate and control. The aim is to protect data at rest from outsiders, but if the provider wants to look at any piece of data on its servers, it can, at any time, because it has the keys. The upshot: You're putting 100% trust in the cloud provider. This all-or-nothing approach rightly doesn't satisfy most enterprise data protection and privacy standards, and it gives security professionals ammo to fight against data moving into the cloud.

In October, Amazon announced that it would give customers the ability to store their own encryption and decryption keys at their data centers, but they are required to give Amazon copies.

How is that better?

What security folks want is the ability to tell the cloud provider to encrypt their data with a client-controlled key of their choice, decrypt data only when asked, and to not be required to provide the key to the cloud vendor. But so far, that's a pipe dream.

Because cloud providers are moving so slowly to adopt security controls, including but not limited to encryption, companies including CipherCloud and Navajo Systems (which was acquired by Salesforce.com in August) are springing up to provide services that proxy calls to, for example, Salesforce or Google Apps, and encrypt and decrypt data from the moment it leaves your network. Instead of interacting directly with the cloud provider, such as Salesforce, you instead interact with a "trusted cloud," hosted either in your data center or off-site but in a private cloud that you control. The trusted cloud contains the cloud encryption vendor's software and your encryption keys; every time an employee wants to access data in the public cloud, the trusted cloud makes the call, gets the encrypted data, decrypts it, and delivers it in plain text, thus wrapping public cloud vendors such as Amazon, Dropbox, or Salesforce with encryption capabilities.

While a big step ahead, these services have limits, generally related to problems using proxy-based cloud encryption. First, if the public cloud's API changes, the proxy must change with it. That means updates from cloud providers may cause compatibility issues or even outages. Second, many SaaS providers give their customers massive customization options, from add-on modules to unique form fields. Each of these customizations can raise compatibility problems in terms of the cloud encryption provider, so you need to invest in additional testing and quality assurance to make sure new app updates don't break anything.

You're also trading trusting one vendor, like Amazon, with trusting another, albeit more security-focused, vendor. The saving grace is that your keys stay under your control.

Lastly, adding a proxy as a go-between from your employees to the cloud can cause significant performance and reliability problems. This is especially true if yours is a very distributed or global organization. One of our clients planned to implement a cloud encryption product by requiring that all of its European employees go through the cloud proxy in the United States--over a 4 Mbps link. Luckily for those users, the company chose instead to add a second proxy in Europe, but that doubled the cost of a project intended to save money.

The ultimate answer is for SaaS vendors to bake encryption capabilities directly into their systems while giving customer IT teams full control over the keys. We expect Salesforce to announce such an offering via its acquisition of proxy-based cloud encryption services provider Navajo Systems. Meanwhile, SpiderOak offers fully encrypted cloud storage with client-controlled keys; it has an API plus Windows and Linux clients. We believe other cloud providers will add this functionality over the next year to meet enterprise demand.

For now, realize that there are many types of cloud providers, so cloud encryption comes in many flavors, too. Porticor, SafeNet, and Trend Micro provide software that encrypts virtual machines so that you can more safely use such services as Amazon's EC2 or Rackspace's cloud hosting. If you're concerned with more than just encrypting your data in someone else's cloud, other systems, like SafeNet, Voltage, and Vormetric, provide end-to-end encryption from your on-premises servers to your cloud provider's servers.

A few bright spots: While adding encryption to servers at your data center usually brings decreased performance and additional management overhead, many cloud providers have the ability to place encryption at a level below the operating system and encrypt individual storage blocks used by any of your virtual machines. And these cloud encryption products are generally priced per user or device, per month, so the system can scale up and down. CIOs we work with who have experience with these cloud encryption systems report very little added latency; most development and IT staffers don't even realize it's in place.

One caveat is that few providers support standardized key management protocols; the exception is Vormetric, which does support Oasis. This means you're going to be stuck with the same problems you have now: disparate key management systems across vendors. Still, we think these services will continue to proliferate, as multiple respondents say encryption is a requirement for their companies to leverage the cloud. Also, having the ability to outsource an application or entire infrastructure to a cloud provider and have to worry only about the encryption keys (instead of managing what was outsourced) helps address hot buttons like interoperability, ongoing maintenance, and cost.

One interesting note, applicable to companies storing sensitive data off-site at cloud providers, is that we expected to see compliance as a main driver for encryption. Yet the percentage of respondents citing compliance as the biggest reason for these initiatives dropped 9 points, to just 14%, even as the number saying they're subject to some regulation stayed flat, at 89%.

While compliance seems to be losing its steam overall as an impetus for security, respondents still have high aspirations: While just 19% say they currently have pervasive encryption deployments with widespread use across the enterprise, 31% expect this to be their reality in 24 months, a jump of 12 points. Still, when we asked respondents what it would take to increase use of encryption, the overwhelming answer was "a breach."

If mobility trends keep up, they might just get their wish.

How concened are you ab out recent attacks agains SSL and TLS, such as the Beast attack?

2 of 3
Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Latest Comment: nice post
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2015-07-01
Open redirect vulnerability in nokia-mapsplaces.php in the Nokia Maps & Places plugin 1.6.6 for WordPress allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL in the href parameter to page/place.html. NOTE: this was originally reported as cross-sit...

Published: 2015-07-01
Absolute path traversal vulnerability in htdocs/libraries/image-editor/image-edit.php in ImpressCMS before 1.3.6 allows remote attackers to delete arbitrary files via a full pathname in the image_path parameter in a cancel action.

Published: 2015-07-01
Heap-based buffer overflow in libwmf allows remote attackers to cause a denial of service (crash) or possibly execute arbitrary code via a crafted BMP image.

Published: 2015-07-01
unattended-upgrades before 0.86.1 does not properly authenticate packages when the (1) force-confold or (2) force-confnew dpkg options are enabled in the DPkg::Options::* apt configuration, which allows remote man-in-the-middle attackers to upload and execute arbitrary packages via unspecified vecto...

Published: 2015-07-01
IBM PowerVC Standard Edition through does not require authentication for access to the Python interpreter with nova credentials, which allows KVM guest OS users to discover certain PowerVC credentials and bypass intended access restrictions via unspecified Python code.

Dark Reading Radio
Archived Dark Reading Radio
Marc Spitler, co-author of the Verizon DBIR will share some of the lesser-known but most intriguing tidbits from the massive report