Risk
1/18/2012
02:05 PM
Connect Directly
LinkedIn
Twitter
Google+
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
Cartoon
Current Issue
Dark Reading Must Reads - September 25, 2014
Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2003-1598
Published: 2014-10-01
SQL injection vulnerability in log.header.php in WordPress 0.7 and earlier allows remote attackers to execute arbitrary SQL commands via the posts variable.

CVE-2011-4624
Published: 2014-10-01
Cross-site scripting (XSS) vulnerability in facebook.php in the GRAND FlAGallery plugin (flash-album-gallery) before 1.57 for WordPress allows remote attackers to inject arbitrary web script or HTML via the i parameter.

CVE-2012-0811
Published: 2014-10-01
Multiple SQL injection vulnerabilities in Postfix Admin (aka postfixadmin) before 2.3.5 allow remote authenticated users to execute arbitrary SQL commands via (1) the pw parameter to the pacrypt function, when mysql_encrypt is configured, or (2) unspecified vectors that are used in backup files gene...

CVE-2012-5485
Published: 2014-09-30
registerConfiglet.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via unspecified vectors, related to the admin interface.

CVE-2012-5486
Published: 2014-09-30
ZPublisher.HTTPRequest._scrubHeader in Zope 2 before 2.13.19, as used in Plone before 4.3 beta 1, allows remote attackers to inject arbitrary HTTP headers via a linefeed (LF) character.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Chris Hadnagy, who hosts the annual Social Engineering Capture the Flag Contest at DEF CON, will discuss the latest trends attackers are using.