The Problems With Encryption

Newly released findings from the Ponemon Institute and A10 Networks reveal that nearly half of cyber attacks in the past 12 months used encryption to evade detection and distribute malicious software. These findings challenge how we think about the powerful technology we use to protect privacy, security and authenticity. They also demonstrate very effectively how this security technology has been subverted into a powerful weapon for cyber criminals. This research is another damning piece of evidence that a significant chunk of enterprise security spending is not effective. Possibly half, or even more, of our security technology is doing little to effectively identify bad guys hiding within encrypted traffic. And because the increasing regulations around encryption will continue to drive a dramatic increase in the volume of encrypted traffic, the number of opportunities for bad guys to hide in plain sight is increasing exponentially. We’re fixing one illness but creating a new disease. See also: The Costs of Inaction on Encryption Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), encrypt traffic. TLS and SSL turn on the padlock in our web browsers—they are the most widely relied upon indicators for consumers that a transaction is “secure.” This technology is used to hide data traffic from would-be hackers, but it also hides data from the latest, hot-selling security tools. Because businesses now are being required to turn on encryption by default, encryption keys and certificates are growing at least 20% year over year—with an average of 23,000 TLS/SSL keys and certificates now used in the typical Global 2,000 company. Volume overwhelms security efforts As enterprises add more keys and certificates and encrypt more traffic, they are increasingly vulnerable to malicious encrypted traffic. Administrators simply do not have the tools to keep up with the growing number of keys and certificates. Venafi customers reported finding nearly 16,500 unknown TLS/SSL keys and certificates. This discovery represents a huge volume of encrypted traffic on their own networks that organizations don’t even know about. Sadly, enterprise spending on next-generation firewalls, sandboxing technologies, behavior analytics and other sexy security systems is completely ineffective to detect this kind of malicious activity. What does a next-generation firewall or sandbox system do with encrypted traffic? It passes the traffic straight through. If a cyber criminal gains access to encrypted traffic, then he is given a free pass by a wide range of sophisticated, state-of-the-art security controls. Inspection a formidable task The hard work of SSL/TLS inspection is at the core of today’s cybersecurity dynamics, but it remains largely overlooked in most enterprises. The challenge of gaining a comprehensive picture of how encryption is being used across enterprises and then gathering the keys and certificates that turn on HTTPS is daunting for even the most sophisticated organizations. See also: How Safe Is Your Data?   Throw in the challenge of keeping keys and certificates updated as they are renewed and replaced, and most enterprises can’t keep up. Even if multiple full-time employees are applied to the problem, they won’t be able to move at a pace that will enable them to identify bad guys hiding in encrypted traffic. Unfortunately, as an industry we continue to ignore this gaping blind spot. For example, when the federal government’s chief information officer issued requirements for protecting all government websites with HTTPS by Dec. 31, 2016, no guidance was provided on how to defend against cyber crime that uses encryption as an attack vector. As an industry, we’ve got to acknowledge and eliminate this blind spot. We need to be able to inspect traffic and automate the secure issuance and distribution of keys and certificates. The technology is available to solve these problems so we can use encryption safely. But before we can solve any problem we first need to admit that we have one. This article was written by Kevin Bocek and originally appeared on ThirdCertainty.