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

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
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-3946
Published: 2014-04-24
Cisco IOS before 15.3(2)S allows remote attackers to bypass interface ACL restrictions in opportunistic circumstances by sending IPv6 packets in an unspecified scenario in which expected packet drops do not occur for "a small percentage" of the packets, aka Bug ID CSCty73682.

CVE-2012-5723
Published: 2014-04-24
Cisco ASR 1000 devices with software before 3.8S, when BDI routing is enabled, allow remote attackers to cause a denial of service (device reload) via crafted (1) broadcast or (2) multicast ICMP packets with fragmentation, aka Bug ID CSCub55948.

CVE-2013-6738
Published: 2014-04-24
Cross-site scripting (XSS) vulnerability in IBM SmartCloud Analytics Log Analysis 1.1 and 1.2 before 1.2.0.0-CSI-SCALA-IF0003 allows remote attackers to inject arbitrary web script or HTML via an invalid query parameter in a response from an OAuth authorization endpoint.

CVE-2014-0188
Published: 2014-04-24
The openshift-origin-broker in Red Hat OpenShift Enterprise 2.0.5, 1.2.7, and earlier does not properly handle authentication requests from the remote-user auth plugin, which allows remote attackers to bypass authentication and impersonate arbitrary users via the X-Remote-User header in a request to...

CVE-2014-2391
Published: 2014-04-24
The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

Best of the Web