DDoS Detection, Mitigation, Orchestration, and Threat Intelligence
Consolidated Security & CGNAT
TLS/SSL Inspection
Web Application Firewall
Application Security & Load Balancing
Analytics & Management
CGNAT & IPv6 Migration
Organizations use encryption to keep sensitive traffic safe and protected. But the bad guys have caught on to that, are now using encrypted traffic to conceal their nefarious doings. This leaves security pros in a tough spot: encrypt traffic and run the risk of bad stuff slipping through the cracks or let traffic flow unencrypted, which is a massive security risk and likely a compliance violation. But those are no longer the only choices. Organizations can implement solutions that decrypt and inspect SSL encrypted traffic.
WANT TO HEAR ME TALK ABOUT THUNDER SSLi? CHECK OUT MY APPEARANCE ON THE PACKET PUSHERS PODCAST
Here, we look at the power of SSL (Secure Sockets Layer)/TLS (Transport Layer Security) decryption and why organizations should make it a key part of their security architecture.
In short, the bad guys are winning. You are spending more and more on security while getting less and less value. Breaches are still happening. Yahoo, Whole Foods, Equifax, Verizon; do those names sound familiar? They’ve all been in the headlines in 2017 admitting that they’ve had security breaches.
Hiding malicious traffic in SSL is the new frontier – whether for infiltration, exfiltration, or maintaining a foothold with Command and Control (also known as C&C or C2). Since upwards of 70 percent of outbound traffic to the internet is SSL, it’s the easiest way to go unnoticed in today’s world.
There’s an adage that goes something like this: “The best place to hide a tree is in the forest.” If malware’s SSL communication is the tree, are you less likely to spot it among all of the other trees (your legitimate SSL traffic), or if the proverbial tree was in a field by itself?
Most likely! But it comes at a cost. Most of the Next-Generation Firewalls (NGFWs) out there perform SSL/TLS decryption on the same general-purpose CPU (think Intel or AMD processor) as the rest of the data plane traffic. That means your firewall’s processing capabilities are significantly reduced because it’s trying to handle all of the resource-intensive SSL decryption at the same time as it’s trying to process the rules and policies you’ve configured.
What about your other security devices? Web Content Filter? IDS/IPS? DLP? Malware and threat prevention? Forensic tools that hang off a network tap? It’s great if your NGFW is decrypting traffic for itself, but it’s not sharing with the rest of the class. After decrypting the traffic (inefficiently in a general-purpose CPU), they have to re-encrypt the traffic before sending it on down the line. Assuming your other security devices can decrypt SSL traffic (not all can), you’re stuck doing the same “decrypt, analyze, re-encrypt” dance at every security device in the line.
“That’s great,” you may be thinking, “but how does A10 help us out here?” With A10 Thunder SSLi (SSL Insight) we leverage hardware ASICs, which are much faster at SSL decryption/TLS decryption/reencryption, to offload that responsibility from your security devices. This helps you truly eliminate the SSL blind spot by allowing ALL of your security devices to benefit from centralized decryption with hardware ASIC acceleration.
At that point, the data plane CPUs on your security devices are free to do what you purchased them for – keep you secure from the bad guys.
SSLi is designed from the ground up to be as flexible as possible, because no two networks are the same. Some of SSLi’s key features include:
At this point you’re probably thinking, “It’s great that you can decrypt all of my traffic, but what about traffic that I do NOT want decrypted?”
Through a partnership with Webroot, A10 Thunder devices have access to Webroot’s URL intelligence database for URL categorization data. Every site on the Internet carries one of nearly 90 different categories. You may be familiar with URL categorization in your content filters, where you can set a policy to allow or deny users on your network to access sites which fall into a particular category. However, we do not use the URL categorization data to allow or deny access, but to choose which traffic should or should not be decrypted.
For instance, if your company has an acceptable usage policy that says users can engage in casual web browsing during downtime as long as it doesn’t affect their normal duties, there is a high likelihood that a user may access their online banking or a healthcare site using the corporate network. That’s the type of traffic we do not want to decrypt.
In those scenarios, we can set a policy to allow traffic which falls into those “sensitive” categories to be excluded from decryption. The traffic still flows through the devices in your security stack, but it remains encrypted. You can also maintain a manual list of either DNS hostnames or source/destination IP addresses to be excluded from decryption.
The next question that usually comes up is, “That all sounds great, but how hard is this to set up?”
The answer is that it’s actually surprisingly easily. In most of the deployments I’ve done, about 80 percent of the effort is ensuring that the traffic flow is correct. Since this is a stateful device, we need to ensure that if traffic goes out, it comes back the same way, and we must avoid any asynchronous routing.
For common deployment methods like we talked about earlier, we have what we call an ACT, or App-Centric Template. This is like a “next, next, finish” wizard that does most of the deployment for you. You specify your incoming/outgoing interfaces, SSL decryption certificate, SSL decryption bypass list, apply the policy and go.
We also have a full REST+JSON API under the covers if you’re like me and into network automation, and are also certified with Cisco ACI.
There you have it. That’s just a short exploration of why you should decrypt and inspect traffic and how SSLi can do the heavy lifting for you, without sapping the performance of the rest of your security stack. Not a bad proposition, right? Now get out there and remove that SSL/TLS blind spot.
I recently sat down with the folks at Packet Pushers for a podcast talking through some of these points. You can tune in here (my appearance starts around 34:30).
Want to learn more about Thunder SSLi?
Seeing is believing. Schedule a live demo today.
