Times have changed since our last InformationWeek Data Encryption Survey, and not for the better. There's growing angst over encryption of data on mobile devices and off-site in the cloud, but IT is still as worried as ever about old problems like key management and interoperability among encryption products. Instead of making progress, the woes are just stacking up, according to the 506 business technology professionals responding to our InformationWeek 2012 Data Encryption Survey. Databases are still largely unprotected--just 33% have implemented encryption at the database level, statistically unchanged from 2009. Fewer than half encrypt company data on mobile devices.

And just 15% are getting proactive in the wake of attacks on SSL/TLS, one of the most-used encryption implementations. That's perhaps the most troubling trend, as respondents seem to be sitting back and waiting for vendors to fix things. When the you-know-what hits the fan, it's the self-sufficient who survive. By developing core encryption-related people skills in house and, where necessary, partnering with specialists, you take back control. From protecting against encryption flaws to securing cloud apps and mobile devices, there are steps IT can and should take now.

Dead Protocol Walking?

SSL/TLS has been subject to aggressive cracking attempts. When the Beast attack hit in September, it spurred fears of the end of SSL/TLS as we know it. And the carnage didn't stop there; multiple SSL certificate companies, including DigiNotar and Comodo, were hijacked last year by attackers who then used these registration authorities to create duplicate certificates for malicious sites--including high-profile destinations like Google, Yahoo, and Microsoft's Hotmail.

While vendors that implement SSL/TLS are (slowly) fixing flaws, we simply can no longer fully trust the encryption algorithms we use. Yet 49% of our respondents are content to wait for the same vendors at fault for attacks to fix problems.The reason most infosec pros are either hoping vendors step up or in a state of denial is likely that they don't think they can do anything to fix these problems. But you do have the power to prevent encryption disasters.

For example, SSL enables a server to provide a client with proof that it is what it says it is. The client then leverages the trust of a certificate authority to verify the identity of the server. The problem is that each CA has its own set of processes and policies for how it verifies that a server is actually owned and operated by the entity it says it's maintained by. If a CA is compromised, as in the DigiNotar and Comodo cases, then the attacker who compromised the CA can create new certificates willy-nilly. When a browser goes to a site that claims to be, say, Hotmail.com but that is actually hosted on an attacker's server, the site will validate as Hotmail.com because the attacker created a fake certificate.

Enter DNSSEC. The DNS Security Extension spec provides the capability for a domain owner--the IT team--to place additional encryption validation at the DNS layer. First it will verify that the SSL certificate is valid. But it also will verify that the DNS server that is authoritative for the domain being requested actually belongs to the certificate owner.

In our example, if a user went to the breached Hotmail.com site and got a Hotmail.com certificate, it wouldn't validate with the DNS server hosting Hotmail.com, because the certificate generated by the attacker using the hacked CA wouldn't match. The browser could display a big red box telling the user he's going to an invalid site. Currently, Google's Chrome supports DNSSEC natively, and there are plug-ins for Firefox. Internet Explorer 9 doesn't support DNSSEC, but version 10 is expected to.

The other benefit of DNSSEC is that DNS queries are validated by all servers--from the domain's authoritative server to the local DNS server to the browser--which means that even man-in-the-middle attacks on DNS queries will be caught.

DNSSEC isn't perfect, and it's not a complete replacement for SSL/TLS. But it is a step in the right direction to put control of certificate verification into the hands of certificate owners, instead of the CAs. Furthermore, using DNSSEC is a great solution for organizations with their own internal CAs that don't want to deploy certificates to every possible device. Most of our respondents, 55%, have their own internal CAs; an additional 15% plan to within 24 months.

Having the keys to your own castle is an important step in controlling your encryption destiny, and if you plan to leverage cloud services securely, it may just be a requirement.

Data Encryption

Ushering In A New Era
Our full report on data encryption is free with registration.

This report includes 34 pages of action-oriented analysis, packed with 25 charts. What you'll find:

Get This And All Our Reports

"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.

Starbucks Is The New Corner Office

To some extent, most organizations have put in place an "access from anywhere" computing program. Respondents to our 2009 survey saw this coming and were scrambling to figure out how to secure data; most opted for full-disk encryption, or FDE, for laptops and blocked access to the corporate network from other mobile devices.

Then, in January 2010, just a few short months after we issued our report, the world changed. Apple released the iPad, and rejoicing ensued. Now, almost 80% of respondents to our InformationWeek Mobile Device Management and Security Survey say tablets will grow in importance. In response, we got one of the largest jumps in our encryption survey, with 79% of 2012 respondents saying they either have mobile device encryption in place now or will within 12 to 24 months, compared with 64% in 2009. To go along with the surge in mobile device growth, email encryption has also continued to gain traction, as 81% of respondents using encryption now use or plan to use email encryption, compared with 72% in 2009. Rounding out the top three is the Trusted Platform Module, used by laptops to implement FDE. That's important, because for all the light and noise around smartphones and tablets and ultrabooks, most real work is still done on laptops. No one is writing a legal brief or marketing plan on a tablet, much less an iPhone. If you haven't yet implemented FDE, note that the negatives to locking down hard disks--mainly reduced performance and problems troubleshooting issues--have disappeared over the past three years, thanks to the advent of self-encrypting drives. (We discuss SEDs in depth in our full report, which is available free.)

As for other mobile devices, the devil is in the platform details when it comes to encryption.

Apple iOS 4 provides file-based encryption using a key generated uniquely per phone. The caveat is that a device password must be in place for data protection to work, and the app itself has to opt in and leverage the data protection APIs, otherwise the data is recoverable via a jail break or rooting. By default, only iOS Mail and a few other apps, like GoodReader and Box, incorporate these APIs. If you support devices using iOS 4 or higher and require that a passcode be configured, and the device is jailbroken or rooted, data protected by the data protection APIs is not readable unless the passcode is provided to the app.

As for Android, only versions higher than 2.3.3 support data encryption, and that is only for flash storage. Prior to version 2.3.3, it was up to the handset manufacturer to provide encryption--a losing proposition for IT. When it comes to Android tablets, Honeycomb (Android 3.0) provides built-in FDE and operates similarly to laptop-based FDE, but it has problems, specifically around performance and with USB mounting of a device that is unlocked. Also, like Apple, Android provides libraries that developers can employ to encrypt data, but it's left to the app creator to use these libraries. History has shown they don't always implement properly; for example, in 2010, Citibank's iPhone app improperly stored account numbers and other sensitive data on the device in clear text.

The clear winner when it comes to on-device encryption is BlackBerry. Research In Motion implements centralized management through BlackBerry Enterprise Server and provides APIs, automatic encryption of user data, and full-device encryption. BlackBerry's end-to-end encryption and content protection is so well implemented, it's approved for use by NATO to send classified information.

Remember, no matter what platform you use, a passcode to lock the device is a must. If your users don't lock their devices, encryption doesn't matter because the mobile OS will decrypt data automatically. This is why we recommend a mobile device management system, to force that pesky passcode to stay enabled.

Michael A. Davis is the CEO of Savid Technologies, a technology and security consulting firm based in Chicago. Write to us at [email protected]

InformationWeek: Jan. 30, 2012 Issue

Download a free PDF of InformationWeek magazine
(registration required)