Working from home has made data security even more challenging for security managers, but finding the balance between user privacy over TLS inspection versus the risks of not inspecting encrypted traffic is a perenial issue.
Everyone I speak with, from architects to CISOs, wants to be able to inspect their company’s encrypted traffic between the internet, the corporate devices, and the end-users they are chartered to safeguard. And it is almost never anything to do with ‘snooping’. They are singularly looking for malware and other ‘bad actors’ attempting to compromise or those already communicating on the network
When asked about what they were trying to solve – The replies were:
- Visibility of security issues – Almost all traffic headed to the internet and cloud services is now TLS-encrypted
- Threat actor activity – Modern malware and bad actors are using TLS to mimic legitimate activity to carry out phishing attacks as well as hide malware downloads and command-and-control (C&C) activities
- Prevent loss of Sensitive data – Bad actors now use TLS encrypted channels to circumvent Data Loss Prevention (DLP) controls and exfiltrate sensitive data; our own employees may intentionally or unintentionally post sensitive data externally
With an understanding of the risks around encrypted traffic going uninspected, one would assume that everyone has already taken steps to enable inspection, right? Well…no. There are two major issues to overcome in order to implement this initiative—one is a technical hurdle, the other is political.
The technical hurdle is essentially ensuring that your enterprise network and security architecture supports a traffic forwarding flow for both your on and off-prem users. In other words, you need an active inline TLS inspection device capable of scaling to the processing load imposed by the 75% to 80% of your internet and SaaS-bound traffic that’s encrypted. In an enterprise network and security architecture in which all end-user traffic, even from remote users, flows through one or more egress security gateway stacks of traditional hardware appliances, the processing load imposed in doing TLS interception dramatically reduces the forwarding and processing capacity of those appliances, as evidenced in recent testing by NSS Labs.
The capacity issue is critical because most enterprises would need to augment their existing security appliance processing and throughput capacity by at least 3x to enable comprehensive TLS inspection. This constitutes a significant re-investment in legacy security technology that doesn’t align with a more modern, direct-to-cloud shift in enterprise network and security architecture designs.
The second concern, and the primary topic of a recent whitepaper issued by Zscaler, is balancing the user privacy concerns of SSL/TLS inspection against the threat risks of not inspecting an enterprise’s corporate device internet traffic.
Some of the key considerations in the privacy vs. risk assessment, and the subsequent move to proceed with an SSL/TLS inspection policy, are as follows:
- An organisation cannot effectively protect the end-user and the corporate device from advanced threats without TLS interception in place
- An organisation will be unable to prevent sensitive data exfiltration without TLS interception.
- Organisations should take the time to educate their end-users why instituting an TLS inspection policy is a security safeguard and not a “big brother” control.
- Organisations should inform employees of the extent to which traffic will and will not be inspected. This should be defined as part of an acceptable usage policy for internet use on corporate-issued assets and this policy should be incorporated into employment agreements.
- Organisations should review this policy with in-house legal counsel, external experts, and any associated workers’ councils or unions, as well as giving careful consideration to regional data safeguard compliance frameworks like GDPR.
- Organisations should take the necessary steps to ensure appropriate safeguards are in place for the processing and storing of logs associated with decrypted transactions, such as obfuscating usernames.
Unfortunately, when fighting the privacy vs. risk assessment battle, with all of the best intentions, many companies fail to find common ground with the privacy “warriors” in the organisation and are forced to resort to simply stating that it is a condition of employment.
What is your experience in deploying TLS inspection or Zscaler on your network? (Feel free to reply below).