TLS or Transport Layer Security is the evolution of SSL, and the terms are often used interchangeably. TLS is designed to increase security by encrypting data end-to-end between two points, ideally preventing bad actors from having visibility into the traffic of your web session. However, threat actors have also come to see the value in utilizing TLS encryption for delivering malware and evading security controls.
This can be indirect via the leveraging common sanctioned SaaS applications (Office365, Box, Dropbox, GDrive, etc.) as delivery vectors or direct by using free certificates from Let’s Encrypt. Let’s Encrypt is a free and open certificate authority created and run for the benefit of the public. Despite being designed for good, threat actors wasted no time in leveraging the advantages of free encryption in their activities.
The point here is that most traffic, good and bad, is now TLS encrypted and can create challenges for IT and security teams.
TLS Inspection to the Rescue
TLS inspection is almost completely transparent to the end-user and sits between the user and their web applications. Like the malicious activity known as a man-in-the-middle attack, TLS inspection intercepts the traffic, enabling inspection by security engines. For this to work without disruption to the end-user, an appropriate certificate must be installed on the client device.
TLS inspection has been available for some time now but isn’t widely used due to a variety of reasons, primarily cost and complexity. Historically NGFW or other appliances have been the source of TLS inspection capabilities for organizations. With any appliance, there is a fixed amount of capability, and the more features you enable, the lower the throughput. TLS inspection is no different and often requires double (or more) hardware investment to accomplish at scale. Additionally, TLS inspection brings up privacy concerns about financial and health information that are not always easily addressed by legacy products.Cato Demo | TLS Inspection in Minutes
SASE Makes it Possible
SASE or Secure Access Service Edge removes most of the challenges around TLS decryption, allowing organizations to secure their users and locations more effectively. SASE offers TLS inspection capabilities as product functionality, with no need to size and deploy hardware. Simply create desired exceptions (or alternatively specify what traffic to inspect), deploy certificates to endpoints, and enable the feature. This easy alternative to NGFW TLS decryption makes it possible for organizations to gain visibility into the 95% of their traffic that is hiding in TLS. There are still some challenges, primarily certificate pinned websites and applications. Most SASE providers will manage a bypass list of these for you, but you can always improve your security posture by blocking un-inspectable traffic where it makes sense.
Gain Visibility Today
The question remains, if you are not inspecting TLS today, why aren’t you? You have most likely invested in security technologies such as IPS, CASB, SWG, Next-Generation Antimalware, DLP, etc., but without complete visibility, these tools cannot work effectively. Security engines are a bit like the x-ray machine at airport security, they reveal the contents of luggage (packets) to identify anything bad. Now imagine if you are in the security line and they are only inspecting 5 out of every 100 bags. How secure does this make you feel, would you still get on the plane?
SASE has removed many of the obstacles to adopting TLS inspection and provides complete visibility to all security engines to maximize their value. If you have not considered SASE yet, now may be the time. If you already have SASE and do not know where to start with TLS inspection, start small. You should be able to selectively enable the capability for risky categories of URLs and applications and then increase the scope as your comfort level grows.