Our Use Cases post ran through setting policies for decryption, and specific use cases driving decryption of network traffic. We also brought up human resources and compliance considerations when building policies. But that doesn’t address the technical nuances of actually figuring out where to decrypt, or how to select and deploy the technology, so here we go. First let’s talk a bit about whether you need a standalone device.

Standalone or Integrated?

Many network and security devices can terminate and decrypt network sessions – including firewalls, IPS, load balancers, UTM, and web & email security gateways. Obviously using an existing device is simpler, often the path of least resistance for decryption and inspection. You don’t have to add other boxes or risk messing up your network addressing scheme, and you can enforce policies right at the point of decryption/inspection. A security device can decrypt traffic, inspect it, apply policy, and re-encrypt – all within a single product. For environments with minimal network volumes and simple policies, integrated devices work well.

But those who need to decrypt substantial network traffic tend to quickly crush the performance of existing security devices if they try to decrypt on existing devices. As we mentioned in our last post, onboard decryption may reduce performance of security devices by 33% to 80%. If you have plenty of performance headroom on your security devices that’s OK. If you don’t you need to look at another device to offload decryption load, in order to let your security devices do what they do best: inspect traffic, apply policies, and monitor or capture traffic.

If you deploy complicated policies, such as multiple policy triggers across the entire network stream rather than limiting yourself to port 443 (HTTPS), an integrated device’s relatively simple decryption policies may be insufficient. Additionally, if you need to send decrypted traffic to multiple places, such as a SIEM or network packet capture device, an integrated solution may not be a good fit.

We have nothing against the integrated option, but pragmatism and drives us toward the right tool for the job. If onboard decryption can meet your performance and policy requirements, do it. But if not you likely need a standalone decryption device.

Selection Criteria

Once you have decided to use a dedicated decryption device, what should you look for? Here are a few things to think about:

• Performance: Much of the value of dedicated hardware is its ability scale up with traffic volume. Make sure any device or devices you buy can scale to your current and future volumes. Don’t paint yourself into a corner by buying equipment that will need to be replaced when traffic volume grows.
• All Port Support: One of the easiest evasion techniques for attackers is to simply change the port number of their outbound traffic, sending encrypted traffic where it is not expected or monitored. Inspection devices cannot afford to trust port numbers – you need deep packet inspection looking at payloads to detect evasion.
• Accuracy: Decryption strategy is highly policy dependent, so success requires accurate categorization of traffic. Related to looking at the full traffic stream, you need to ensure your devices accurately find encrypted traffic and categorize it effectively.
• Policy actions: Once you have a policy hit, make sure your device supports a variety of different actions. You should be able to decrypt, not decrypt, drop the session, or reject the session (with a website failure code). You also want the ability to list sources or destinations as always decrypt (blacklist) or never decrypt (whitelist), by group or user.
• Website category/reputation support: A big chunk of our use case post talked about setting policies; they may include websites, IP addresses, and applications. Given how quickly website reputation and categories change (minutes – if not seconds), it is important to have a dynamic source of current information to base policies on. That usually means some kind of cloud-based website categorization service for whitelisting, along with dynamic reputation scoring for websites and applications.
• Multiple device support: Given the varied decryption use cases, these devices should be flexible in how they forward traffic, and to how many devices. For example you might want to send traffic to both an IPS for active control, and also a packet capture device for monitoring and forensics. It is also important for decryption devices to interoperates natively with security devices, so that (for instance) an IPS which detects decrypted attack traffic can drop that session without human intervention.
• Security: This is a security device, so you will want to ensure that decryption/resigning keys and data on the device are protected. You also want the ability to reject/drop sessions if their security is insufficient. For example a weak encryption cipher could data at risk; it might be forbidden to transmit encrypted data which cannot be decrypted by the security device, to prevent unknown data from leaving your environment.
• Transparency: It is also important to ensure decryption doesn’t impact application behavior or user interaction. End users should not need to concern themselves with security inspection. Further, the decryption device shouldn’t alter packet headers in any way, as that might impair other security devices’ inspection. Basically, nobody should know the device is there.
• Deployment flexibility: Decryption needs to be inserted into the flow of traffic, so you want a device that supports multiple deployment models, discussed below. For devices with multiple ports, you should have flexibility in assigning them to specific devices. You should also be able to apply policies both actively and passively.

Deployment

Decryption device deployment should be as non-disruptive as possible. You don’t want to mess around with IP addressing schemes, force every user to see a security warning every time they make an SSL connection, or have the device manipulate IP address headers and screw up your ability to monitor and analyze traffic. You want transparency, as mentioned above.

Also make sure you are seeing all relevant traffic. Don’t make assumptions about what is relevant and what isn’t. Attackers frequently hide encrypted traffic on odd traditional ports to evade decryption. So you should look at all traffic – not just the most obvious ports (HTTPS, SSH, SFTP, etc.) to make sure you don’t miss anything.

There are a few deployment options.

• Passive Inline: In this configuration the decryption device is positioned as a bump in the wire – inline to ensure that all traffic can be inspected and decrypted according to the policy. Once traffic is decrypted the device can forward it to a variety of different security devices for inspection/monitoring, and can load balance between security devices if throughput is an issue. As a passive device, it won’t drop or block sessions itself, nor will it re-encrypt traffic – it just copies traffic to inspection devices, while forwarding the original (encrypted) traffic on to the network.
• Active Inline: This configuration is similar to passive inline but can enforce policies. Based on policy the device decrypts traffic and forwards it to an inspection device. It queues the encrypted session until it receives a verdict back from the security device. If the session is fine it re-encrypts and sends the traffic on its way. If the session looks like an attack it is dropped.
• Passive Tap: In this deployment the decryption device is connected to a network tap or span port on a switch to receive a copy of all the traffic. These passive devices aren’t in the flow of traffic, so they cannot enforce policy by dropping or blocking sessions. You will also need the private keys of receiving servers to decrypt because in this configuration you cannot get in the middle of the session to resign traffic. This model is only appropriate for inspecting traffic to internal servers, and so not commonly used.

In inline deployment models the device is basically a man-in-the-middle between your employees and their website destinations. The decryption device terminates user sessions, and establishes new sessions with destination websites. To avoid having the user see a security alert every time they initiate a secure session, users need to trust a certificate issued by the decryption device. That means either loading up a signed certificate into every user’s browser (typically through a workstation policy) or having decryption device certificates signed by a root which users (browsers) already trust, such as a public Certificate Authority (CA). This way the TCP session is not interrupted, and neither side has any idea that decryption is happening or that you are inspecting traffic.

These devices inspect and influence sensitive traffic, so availability is critical. Availability isn’t an issue in a passive tap deployment because tapas aren’t in the traffic flow. But in an inline configuration you need to decide what happens if the device fails. Choices include:

• Fail to Network: If the device fails, the traffic is sent to the outbound network port but not to inspection devices. Sessions are not disrupted, but failure circumvents inspection and monitoring.
• Fail to Device: In this scenario if the decryption device fails, traffic is still sent to inspection devices. Encrypted traffic cannot be decrypted, but unencrypted traffic can still be inspected and monitored/captured.
• Fail Closed: This configuration takes the network offline by not forwarding traffic when the decryption device is down. This ensures you don’t miss an attack by taking the network out of commission entirely.

Most organizations choose Fail to Network – if decryption fails they do not want to stop all traffic. But that is something you will need to figure out with senior management, to ensure they understand the ramifications.

Now that you know how you should set policies to deal with encrypted traffic, where to decrypt it, and the criteria that should guide your selection of a dedicated device (if you go in that direction), you are ready to deal with the reality of encrypted networks. That was our objective for this short series. We will build a paper from this series before the end of the year, so keep an eye out.