Gigamon VP breaks down how to eliminate TLS, and considerations for a decryption and encryption approach
By Bassam Khan, VP of Product and Technical Marketing Engineering, Gigamon
Many who work in IT are still of the mindset that encrypted traffic means safe traffic. That’s a dangerous generalization. Encrypted traffic simply means it’s private, and private communications does not equate to safe communications.
Security teams’ use of encryption continues to grow steadily for legitimate privacy and protection purposes – and unfortunately, is growing even faster for nefarious purposes. While most network-based analysis tools benefit from inspecting decrypted traffic, risk grows exponentially with each tool that receives clear text traffic, since the tool itself can be compromised. Decryption is not a binary decision and there are several options for how to decrypt.
Further, to address significant blind spots like Transport Layer Security (TLS), security teams should consider a decryption and encryption approach. Whichever path your organization chooses, the most important step is to document and communicate your approach and the decision factors leading to it.
Encryption and Decryption
Network traffic encryption is critical for securing networks from unauthorized access and data theft. By encrypting your network traffic, you can prevent others from being able to see or steal the data passing through your network. In addition, increasing adoption of TLS encryption helps protect against “man-in-the-middle” attacks and other malicious activities.
With its growing adoption, threat actors are turning to encryption as their default method for operating and remaining undetected. From command and control, to malware insertion, to data exfiltration –encryption allows adversaries to do their work without fear of being caught. Additionally, encryption allows for longer dwell times and insert encryption malware on as many hosts as possible for a ransom payout, exfiltrating sensitive data and intellectual property for a double extortion. Most current tools, including Suricata and Snort rules, are useless against encrypted payload.
There are a few key challenges to consider when decrypting network traffic. First, decrypting the data can open up privacy concerns. In addition, decrypting the traffic may violate compliance requirements or even require re-architecting the network and datacenter infrastructure. Finally, decrypting the traffic is central processing unit (CPU)-intensive and places significant strain and bandwidth reduction on the tools that are used to decrypt it.
By understanding these challenges, organizations can better plan for and mitigate them.
TLS Traffic Inspection With Network Detection and Response Solutions (NDRs)
Modern network detection and response (NDR) solutions can function solely on encrypted traffic using only Secure Sockets Layer (SSL)/TLS traffic metadata, such as:
- Server Name Indication (SNI) certificate attributes: Helps identify when the entity was registered, who owns the entity, and suspicious attributes like randomness, name/typosquatting, and uncommon top-level domain.
- Cipher Suite – JA3 / JA3S: Helps find suspicious encrypted session’s “Hello” connection. Detection-based solutions that rely solely on IP address and known bad domains are often ineffective; these two fields can change at any point or malware could be constantly morphing its command-and-control infrastructure. JA3 and JA3S, which are hashes of how the encrypted connection was established, are less likely to change – therefore, frequently changing JA3 and unknown JA3s are suspicious.
- User agent: Helps identify the user agent (i.e., browser). This data can be useful to differentiate automated systems used for web advertising and marketing purposes, versus a more nefarious intent.
- Certificate info: Think through when the certificate was issued. A few day-olds issuance that is a few days past expiration is considered as concerning as it is for 10 years past expiration.
While it’s possible to make detections on encrypted traffic metadata, these techniques have their limits. For the level of threat detection you want, NDRs need to work with both traffic metadata and the full content of packets, which provides access to unified resource identifiers (URIs), parameters, responses code, user-agent, request and response body, files, and much more. With this rich data set, analyzing intrusions over hypertext transfer protocol (HTTP) can be more straightforward. Therefore, the combination of encrypted traffic metadata and decrypted payload analysis provides the maximum number of data points for threat detection.
Choices For Decryption
Even though it might be easy to say “don’t do this,” for some organizations, traffic decryption may not be an option. This could be due to reasons like compliance requirements, corporate policy, tools overload, current datacenter architecture, cost, or others.
If this is your path, your most important step is to over-communicate the reasons and risks associated with this approach.
Decryption by each tool
This is the easiest approach because most tools will have a built-in decryption feature. You just turn it on, and the tool will do the work for you. There are three things to think about when using this approach.
- If a tool is deployed inline, it becomes a single point of failure. If the tool goes down, the entire flow downstream will break.
- This approach will not work with TLS 1.3, which requires a “man-in-the-middle” inline deployment.
- This is the most expensive approach. Decryption is a resource-intensive function that can dramatically degrade the tool’s performance and throughput.
Dedicated decryption appliance
Another option is to use a standalone appliance that decrypts and forwards traffic to all the other tools. A decade ago, this was more common, but people stopped using it because decrypting traffic is not the end goal. The end goal is inspecting network traffic safely.
Centralized Decryption and Smart Traffic Brokering
Visibility fabrics (also known as packet brokers) provide the security, flexibility, and cost-efficiency needed for decrypting traffic by:
- Allowing for a centralized “decrypt once, feed many tools” deployment model
- Conforming to any policy regarding plain text access
- Offering masking of personally identifiable (PII) data
- Maintaining IP and URL “blacklists” where sensitive traffic from trusted sites is kept encrypted, like employee personal banking and healthcare websites
- Eliminating the need for physical wiring changes when modifying decryption policies
- Supporting TLS 1.3 through an inline deployment, utilizing both inline tools and out-of-band traffic tools
Finally, it is a good idea to review the National Security Agency’s (NSA) advisory on TLS decryption. This advisory advocate for a centralized decryption model.
Wrapping Everything Together Through Increased Visibility
From a larger level, in order to eliminate the blind spots that come with TLS, in addition to a number of other security vulnerabilities – network visibility is critical. Visibility can be useful in tasks such as decrypting data, which can be done more selectively based on traffic type, destination tool, and industry-specific requirements. These types of capabilities also provide flexibility for teams to configure data in any way they need and also support the agility necessary for changing the configuration quickly if policies change.
No matter what decryption method you choose, it is important to communicate the reasons and trade-offs with upper team management. Key security decision-makers at your organization need to understand the implications of decrypting network traffic and feel aligned with your team’s approach. Otherwise, you may not have their support when that day comes.
About the Author
Bassam Khan is the Vice President of Product and Technical Marketing Engineering at Gigamon. He brings 20 years of experience managing products for security, cloud and collaboration technology companies. Prior to Gigamon, he held executive positions at ControlUp, AppSense, PostPath, Cloudmark and Portal Software. Bassam can be found on LinkedIn, Twitter, and on our company blog at https://blog.gigamon.com/author/bassam-khan/.