Risk
1/18/2012
02:05 PM
Connect Directly
Google+
LinkedIn
Twitter
RSS
E-Mail
50%
50%

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?

Previous
2 of 3
Next
Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Tech Digest, Dec. 19, 2014
Software-defined networking can be a net plus for security. The key: Work with the network team to implement gradually, test as you go, and take the opportunity to overhaul your security strategy.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-8142
Published: 2014-12-20
Use-after-free vulnerability in the process_nested_data function in ext/standard/var_unserializer.re in PHP before 5.4.36, 5.5.x before 5.5.20, and 5.6.x before 5.6.4 allows remote attackers to execute arbitrary code via a crafted unserialize call that leverages improper handling of duplicate keys w...

CVE-2013-4440
Published: 2014-12-19
Password Generator (aka Pwgen) before 2.07 generates weak non-tty passwords, which makes it easier for context-dependent attackers to guess the password via a brute-force attack.

CVE-2013-4442
Published: 2014-12-19
Password Generator (aka Pwgen) before 2.07 uses weak pseudo generated numbers when /dev/urandom is unavailable, which makes it easier for context-dependent attackers to guess the numbers.

CVE-2013-7401
Published: 2014-12-19
The parse_request function in request.c in c-icap 0.2.x allows remote attackers to cause a denial of service (crash) via a URI without a " " or "?" character in an ICAP request, as demonstrated by use of the OPTIONS method.

CVE-2014-2026
Published: 2014-12-19
Cross-site scripting (XSS) vulnerability in the search functionality in United Planet Intrexx Professional before 5.2 Online Update 0905 and 6.x before 6.0 Online Update 10 allows remote attackers to inject arbitrary web script or HTML via the request parameter.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Join us Wednesday, Dec. 17 at 1 p.m. Eastern Time to hear what employers are really looking for in a chief information security officer -- it may not be what you think.