Editor’s note: Element #5 of the Seven Elements of Highly Successful Zero Trust Architecture focuses on using SSL/TLS inspection to scan for malicious content.
The number of threats using SSL/TLS encrypted channels increased 314% annually between 2020 and 2021, comprising more than 80% of attacks. Thus, implementing a corporate policy of SSL/TLS inspection is a must for the identification of risky content and subsequent protection of the enterprise.
Encrypting HTTP internet traffic has become a trivially simple process, leading to greater protection for consumers, ensuring their privacy isn’t compromised by unscrupulous snoops on the internet. Services like LetsEncrypt allow anyone to obtain trusted public key certificates, driving an incredible rise in encrypted traffic.
But bad guys have also caught on and now deliver their attacks via encrypted channels like HTTPS. In the 2022 Zscaler Ransomware Report, ransomware as a service (RaaS) was leveraged by eight of the top 11 ransomware families. Each of these RaaS services uses SSL/TLS encryption to protect its actors as well as for delivering ransomware payloads.
Identifying and protecting against ransomware attacks can therefore only be achieved by inspecting SSL/TLS traffic. Without inspection, it’s impossible to protect against initial attacks against enterprises or to stop the exfiltration of data (see Element 4). Nor is it possible to see command and control (C2) traffic infected devices use to reply to malicious command centers.
Compromise prevention must take into account all threats targeting enterprises, which fall into two categories:
- Inline threats – Malicious actors, code, plugins, and more also use SSL/TLS encryption as a means of transport. SSL/TLS public key encryption is the global standard for data protection of secure web transactions for the majority of the internet. Each data packet is turned into a code string decipherable only between an initiator and a destination service, regardless of the network. This helps protect against eavesdropping and data tampering by untrustworthy parties, but also gives threat actors the ability to hide their attacks. To guard against threats via inline communication, enterprises must perform inline traffic decryption at scale.
- Out-of-band threats – It’s important to also address risks stored within SaaS, PaaS, IaaS, and other cloud solutions. An out-of-band assessment, as part of a unified threat management solution, provides enterprises with a full view of inbound threat paths and actively identifies threats before malware is downloaded, shared, or launched.
The ability to view traffic and cloud app use is critical for ensuring malicious content like botnets and malware isn’t hidden within. With the bulk of internet-bound traffic being encrypted, allowing this traffic to pass through unexamined or services to be used without inspection is risky. Inspection of both external and internal application access is critical since both traffic flows may be encrypted.
However, enterprises must consider the value of the visibility and insight garnered by inspecting traffic in relation to privacy controls and restrictions for end users. They must establish a balance between their right to be protected from threats and a user’s right to privacy. This balance must be considered and implemented granularly, not as a binary “inspect or don’t inspect” policy. It should be implemented based on business risk and application type (see Element 2 for details on application categorization). Controls should provide protection where needed—e.g., to stop malicious files from being downloaded—while also ensuring end-user privacy is protected when personal data like healthcare or finance information is involved.
Technology and architecture considerations
Visibility of enterprise threats requires the ability to uniformly look inside traffic in motion (inline) and files stored in services (out-of-band). Each discipline has different implementation considerations, but ideally should be managed with one set of policies.
Inline considerations
The ability to inspect encrypted traffic requires a forward proxy architecture that’s built for the cloud to allow for intensive inspection with minimal latency. For internet-bound traffic, decryption standards must support up to TLS 1.3 on all ports (which have improvements over earlier versions to ensure the confidentiality and integrity of communications) and check against techniques like DNS tunneling. Inspection also integrates with technologies like sandboxing, where potentially risky files can be “detonated” before being served to the user, as well as browser isolation, where pixels can be streamed to the user instead of the actual web page.
Zero trust architecture must scale to function as an SSL/TLS, person-in-the-middle proxy that provides complete inbound and outbound content analysis able to immediately block threats detected anywhere in the enforcement plane. Threat actors continue to evolve their tools and techniques, which include abuse of legitimate storage service providers like Dropbox, Box, OneDrive, and Google Drive for hosting malicious payloads.
In addition to stopping hackers, SSL/TLS inspection is useful when an enterprise wants to know when employees are intentionally or accidentally leaking organizational data. SSL/TLS inspection is also required for maintaining compliance by ensuring employees are not putting confidential data at risk (outlined in Element 6).
Therefore, true zero trust vendors must provide full inline SSL/TLS inspection capabilities. The most effective implementation of SSL/TLS inspection is through a native, proxy-based solution that is transparent to the end user. Bolting on a function to existing next-generation firewalls (NGFWs), which have inherent challenges scaling, is not recommended.
Implementing SSL/TLS inspection has been historically challenging for various reasons. Your own chosen zero trust vendor should be the foremost trusted expert and provide guidance, understanding, and implementation when enabling SSL/TLS inspection. Again, SSL/TLS inspection is non-negotiable for the SSE, but it need not sacrifice speed for security.
Out-of-band considerations
Leveraging the same policy controls for inline inspection, a zero trust platform should govern data at rest within cloud applications, preventing dangerous file sharing and even file oversharing. When considered holistically, out-of-band controls complement previously outlined inline controls so cloud apps cannot be used as an attack vector.
Zero trust progress report
After the SSL/TLS inspection and threat prevention phase, the zero trust process has oversight of the applications the initiator has accessed. The contents of this view allow further insights to be applied to the policy decision.
Download the Seven Elements of Highly Successful Zero Trust Architecture eBook and stay tuned for more installments of our accompanying commentary