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.

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.

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:
  • Why 2012 will be the year of the self-encrypting disks
  • Top 10 encryption product evaluation criteria, rated
Get This And All Our Reports

Previous
1 of 3
Next
Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-1544
Published: 2014-07-23
Use-after-free vulnerability in the CERT_DestroyCertificate function in libnss3.so in Mozilla Network Security Services (NSS) 3.x, as used in Firefox before 31.0, Firefox ESR 24.x before 24.7, and Thunderbird before 24.7, allows remote attackers to execute arbitrary code via vectors that trigger cer...

CVE-2014-1547
Published: 2014-07-23
Multiple unspecified vulnerabilities in the browser engine in Mozilla Firefox before 31.0, Firefox ESR 24.x before 24.7, and Thunderbird before 24.7 allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via unknown vectors.

CVE-2014-1548
Published: 2014-07-23
Multiple unspecified vulnerabilities in the browser engine in Mozilla Firefox before 31.0 and Thunderbird before 31.0 allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via unknown vectors.

CVE-2014-1549
Published: 2014-07-23
The mozilla::dom::AudioBufferSourceNodeEngine::CopyFromInputBuffer function in Mozilla Firefox before 31.0 and Thunderbird before 31.0 does not properly allocate Web Audio buffer memory, which allows remote attackers to execute arbitrary code or cause a denial of service (buffer overflow and applica...

CVE-2014-1550
Published: 2014-07-23
Use-after-free vulnerability in the MediaInputPort class in Mozilla Firefox before 31.0 and Thunderbird before 31.0 allows remote attackers to execute arbitrary code or cause a denial of service (heap memory corruption) by leveraging incorrect Web Audio control-message ordering.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Sara Peters hosts a conversation on Botnets and those who fight them.