What You Might be Missing with SSL/TLS Inspection

What You Might be Missing with SSL/TLS Inspection

There are many points of entry for attackers in today’s borderless network architectures.  According to the 2019 Verizon Data Breach Investigation Report, most cyber attacks still originate from external network sources, with 69% of data breaches reported coming from outside actors.

Once initial compromise occurs, malicious network traffic typically ensues in the form of payloads, data exfiltration, connections with Command and Control (C2) points, and so on. At this layer, a vast number of network security controls and tools are typically deployed to monitor, detect, or block intrusions and attacks by inspecting network traffic as it passes through them. Some of the more traditional network security tools that do their job of defending organizations by looking at what is in your network traffic include:

  • NextGen Firewalls (i.e., application layer)
  • Data Loss Prevention (DLP)
  • IDS/IPS
  • Web Filtering
  • Anti-malware
  • Application Control
  • Secure Email Gateway (e.g., Spam filtering, malicious attachments and links, etc.)
  • IP/Domain block lists/whitelisting

Additionally, there are other security tools and practices supportive of cyber defense that depend on visibility into network communication, such as malware analysis, cyber forensics, SIEM, threat intelligence, etc.

Security tools or methods that rely on seeing what is in a network packet won’t be able to fully deliver their value or provide their defensive capability if they can’t see what is in those packets.

Secured network protocols such as HTTPS, SMTPS, FTPS, and VPN connections use SSL/TLS to encrypt communications, keeping them private and ensuring integrity. While long overdue, the web is becoming a bit more secure with the broader use of TLS encryption and HTTPS. In fact, well over half of all web traffic is now encrypted, with recent estimates around 72%. This is a trend we hope to see continue and it should, with efforts like HTTPS Everywhere and Let’s Encrypt to help further the use of encryption. While this is currently the most effective means to ensure privacy and integrity of legitimate web traffic, it is also increasingly leveraged by threat actors to carry out their objectives and avoid detection. The latter being possible since network security tools are basically ineffective on the encrypted traffic passing through them.

Performing TLS inspection has become the standard countermeasure to this, albeit one that comes with some warnings and considerations. TLS inspection requires the interception of TLS connections through a capable solution that acts as a “Man-in-the-Middle” to proxy the encrypted communication, so inspection can then occur. Doing this prompts some concerns related to confidentiality and availability.

  1. An interception solution can actually degrade the security of encrypted communications if it does not do so in a secure manner. Failing to use the latest secure versions of TLS, not properly performing certificate validation, or avoiding strong encryption methods can actually do more harm than good. A study conducted in 2017 found that some popular middleboxes and client-side security software reduced connection security and many introduced severe vulnerabilities.
  2. Privacy also needs to be considered since sensitive data such as health and financial information, intended to remain encrypted between client and server, can now be seen via the interception solution.
  3. Network performance is almost always impacted when doing TLS interception, as the solution has to decrypt and re-encrypt data in real time.

It might appear you can’t do both–inspect the other half (or more) of your web traffic and maintain the security TLS provides with proper configuration. The good news is it can be done as long as it is implemented using standard levels of TLS security and with minimal impact to network performance. Just as with any security tool deployment, proper and secure configuration is paramount.

Essentially, any TLS interception solution must be able to provide the same level of security as modern browsers and secure web servers, since it is responsible for performing the functions of secure TLS communication between both ends of the connection. Doing this requires the use of industry-standard technology and methods, so it is not too much to ask of a security vendor. Any TLS interception product must be built to support secure use of TLS and there is really no room for compromise here.

While not all concerns with TLS inspection may be completely alleviated, if it is done properly encrypted TLS conversations can be safely inspected, enabling the organization to apply security to much more traffic passing through its network—traffic it was previously blind to that could be used by an adversary to evade detection.


Ready to get started?

Download our tip sheet, 9 Best Practices for Evaluating and Implementing TLS Inspection Solutions.

Get the Tip Sheet

Topics

No Love for CVSS—ICS Industry Leaders Caution Reliance on the IT Standard
Combat Insider Threats with an Integrated Enterprise Defense Strategy