SSL encryption, especially services using OpenSSL, was brought into the spotlight more than ever this year. As we all know, the Heartbleed vulnerability (CVE-2014-0160) gave cyberattackers a new weapon in their arsenal of tricks, allowing them to siphon off data from clients and servers around the world – including those within an enterprise itself.
The vulnerability sent major web servers around the world scrambling to patch services, renew certificates, and inform their uses of a potential breach. It also brought many of them to the realization that they couldn’t pinpoint exactly which vulnerable services they were running.
It’s difficult for the average enterprise to do an inventory of every internal service, let alone which ones are vulnerable to Heartbleed.
This knowledge gap has become a golden opportunity for attackers to compromise sensitive data from public-facing servers and move laterally within an organization. As a result of Heartbleed being one of the first “next-generation” bugs, with is own logo, webpage, massive media coverage, and even bigger impact, network users have been expecting the inevitable “change your password” email from their commonly used web applications.
Attackers took notice and have used such emails in an attempt to exploit the very vulnerability they warn users about. This has led to host of clever password change-based spearphishing emails, which appear to be legitimate, but actually lead a user to a compromised website used to collect their credentials or exploit them using a drive-by download.
These spearphishing attempts hint at the larger host of techniques cyberattackers are using to compromise enterprise networks using SSL, which I believe present a much wider threat. Attackers are increasingly using encryption to slip past traditional defenses, with the most common being spearphishing over popular Webmail applications that we each use every day, such as Gmail, Yahoo!, or Office 365, which all use SSL encryption by default.
Most network and endpoint defenses do not have the ability to natively analyze encrypted traffic, meaning users unknowingly open malicious attachments and visit compromised websites from their email under the assumption they are protected.
In other words, the bad guys have taken a tool developed to protect Internet-based communications and turned it against the good guys. They can use SSL protocols in Webmail applications to hide attacks from network security measures. Then, once the attacker has established an initial foothold on the network, they will deploy malware and move through the “squishy center” of an organization towards valuable intellectual property. Once identified, they will then use SSL encryption to hide the movement of stolen data off the network. In light of this situation, selective SSL decryption should be a requirement for your enterprise security architecture going forward.
While there are a variety of third-party SSL decryption solutions on the market, either as a standalone hardware device or a service, their use can be challenging.
First up, adding another standalone device to your network puts additional stress on understaffed and overworked network security teams, not to mention impacting throughput. Second, many markets (financial and healthcare, for example) are required by law to maintain strict privacy and security requirements. Sharing highly sensitive data with another party so they can decrypt and examine it could prove to be quite a regulatory challenge.
So while SSL decryption is necessary for maintaining network security, security admins are going to have to establish strict rules about how they handle decrypted data.
When implementing a new security device on your network, be sure to ask these questions:
• Are my employees using applications encrypted with SSL that could be used to deliver threats?
• Can the device natively decrypt SSL traffic, especially in light of the growing number of threats coming into organizations via common Webmail applications?
• Can you apply selective SSL decryption for only the traffic you want to examine?
• Can I decrypt SSL without compromising the security or privacy of traffic?
With enterprises and consumers becoming increasingly aware of online security, it follows that the more and more applications will start using SSL and potentially be vulnerable to Heartbleed. A well-prepared enterprise security strategy will take this likelihood into account and implement SSL decryption.
Upcoming Webcast 6/12: Managing Heartbleed Fallout – Register Now
