Security and Privacy on the Encrypted Network: Use Cases
In the first post of this series on Security and Privacy on the Encrypted Network, we argued that organizations need to encrypt more traffic. Unfortunately the inability to see and inspect encrypted traffic impairs the ability to enforce security controls/policies and meet compliance mandates. So let’s dig into how to strategically decrypt traffic in order to address a few key use cases – including enforcing security policies and monitoring for security and compliance. We also need to factor in the HR and privacy issues associated with decrypting traffic – you don’t want to end up on the wrong side of a worker council protesting your network security approach. What to Decrypt The first step in gaining visibility into the encrypted network is to set policies for when traffic will be decrypted and for how long. These decisions depend more on organizational culture than anything else, so you need to figure out what will work for your company. As security guys we favor more decryption than less, because that enables more comprehensive inspection… and therefore stronger monitoring and enforcement. But this is a company-specific choice. Several factors influence decryption policies, most obviously the applications themselves. Let’s briefly cover the main applications you are most likely to decrypt: Webmail: Employees think they are doing your organization a favor by working at all times of the day. But this always-on workforce requires use of personal devices, and may decide (however misguided) that it’s easiest to send work documents to personal machines via personal email accounts. What could go wrong? And of course there are more malicious uses for webmail in a corporate environment. There are endpoint DLP agents that should catch this behavior, but if you don’t have them deployed you should be inspecting outbound webmail traffic. The complication is that most webmail is now encrypted so you need to decrypt sessions to inspect the traffic. Web browsing: Similarly social media sites and other web properties utilize user-generated content that may be protected or sensitive, so you need to ensure you can enforce policies on web application traffic as well. Many apps use SSL/TLS by default, so you will need to decrypt to enforce acceptable use policies and protect data. SaaS Apps: Business functions are increasingly migrating to Software as a Service (SaaS) so it is important to inspect SaaS traffic. You may want to enforce tighter content policies on SaaS apps, but first you need to decrypt their traffic for inspection and enforcement. Custom Apps: Similarly your custom web apps (or partner web apps) require scrutiny given the likelihood that they will use sensitive data. As with SaaS apps, you will want to enforce granular policies for these apps, which requires decryption. To net it out, if an application has access to protected or critical data you should decrypt and inspect its traffic. Within each application defined above, secondary attributes may demand or preclude decryption. For example certain web apps/sites should be whitelisted because they handle private employee data, such as consumer healthcare and financial sites. Another policy trigger will be individual employees and groups. Maybe you don’t want to decrypt traffic from the legal team, because it is likely protected and sensitive. And of course there are the folks who require exceptions. Like the CEO, who gets to do whatever he/she wants and may approve an exception for their own traffic. There will be other exceptions (we guarantee it), so make sure your policies include the ability to selectively decrypt and enforce policies. For example one app may need to always be inspected (regardless of user) based on the sensitivity of data it can access. Likewise perhaps one set of users won’t have their traffic inspected at all. You should have flexibility to decrypt traffic to enforce policies, based on applications and users/groups, to accurately map to business processes and requirements. Regardless of the use case for decryption, you will want to be flexible about what gets decrypted, for whom, and when. Where to Decrypt? Now that you know what to decrypt you need to determine the best place to do it. This decision hinges on type of traffic (ingress vs. egress), which applications need to be inspected, and which devices you need to send data to for monitoring and/or enforcement. Firewall: Firewalls frequently take on the decryption role because they is inline for both egress and ingress, and already enforcing policies – especially as they evolve toward application-aware Next Generation Firewalls (NGFW). Unfortunately decryption is computationally demanding, which creates scaling issues even for larger and more powerful firewalls. IPS: IPS is an inspection technology, so an inability to inspect encrypted traffic is a serious limitation. To address this some organizations decrypt on their IPS devices. The IPS function is computationally demanding so these devices tend to have more horsepower, which helps when doing decryption. But as with firewalls, scalability can be an issue. Web filter: Due to their role, web filters need to decrypt traffic. They tend to be a bit underpowered compared to other devices in the DMZ, so unless there is minimal encrypted traffic, they can run out of gas quickly. Dedicated SSL decryption device: For organizations with a lot of encrypted traffic (which is becoming more common), a few dedicated decryption devices are available which specialize in decrypting traffic without disrupting employees, offering flexibility in how to route decrypted traffic for either active controls (FW, IPS, web filter, etc.) or monitoring, and then re-encrypting as it continues out to the Internet. We will get into specifics of selecting and deploying these devices in our next post. Cloud-based offerings: As Security as a Service (SECaaS) offerings mature, organizations have the option to decrypt in the cloud, removing their responsibility for scalability. On the other hand this requires potentially sensitive data to be decrypted and inspected in the cloud, which may be a cultural or regulatory challenge. These devices are typically deployed inside your network permiter, so you remain blind to attackers encrypting internal reconnaissance traffic, or traffic moving
