The Role of Network Packet Broker (NPB) with SSL decryption in Network Monitoring

SSL technology significantly impacts the way IT departments now monitor their networks. Data that could once be captured and sent to security and monitoring tools for analysis is now completely unreadable by those same tools. Learn how a NPB that has integrated SSL decryption capabilities can be used to overcome this issue.

New Monitoring Challenges Result From Data Encryption

Secure Sockets Layer (SSL) technology significantly impacts the way IT departments monitor their networks. As of the end of 2016, Sandvine Research estimates that almost 70% of Internet traffic is now encrypted. Data that could once be captured and sent to security and monitoring tools for analysis is now completely unreadable by those tools. This creates a major source of blind spots within your network that include hidden sources of security threats operating without your knowledge.

While decryption of the data would be the most obvious answer, most IT organizations struggle with the following problems:

• They have multiple, often more than three, tools that need to see decrypted (clear text) traffic which causes a significant burden
• Decryption (and re-encryption) has a high CPU resource tax making it inefficient to run this SSL function on multiple security tools
• The serial chaining of multiple security tools together while properly handling and protecting clear-text traffic is difficult
• Maintaining the isolation of clear-text traffic for regulatory compliance is often difficult

Technology, like a network packet broker (NPB) with SSL decryption capability, can be used to correct these problems by decrypting network data, aggregating and filtering the data, data masking as needed, and then distributing it to the proper security and monitoring tools for analysis. The data is then re-encrypted by the NPB without impacting tool performance or causing compliance issues.

SSL technology significantly impacts the way IT departments monitor their networks. Data that could once be captured and sent to security and monitoring tools for analysis is now completely unreadable by those tools.

HTTPS – The Solution For Online Privacy

HTTPS, which includes both the original SSL standard and the updated version Transport Layer Security (TLS) standard, is intended to secure Internet-based communications. While SSL was developed in 1994 for encrypting Internet data, it did not go mainstream until Facebook adopted it in 2013 and Google started penalizing business website rankings in 2014 if the protocol wasn’t used. In addition, web applications, Office 365, and cloud-based traffic have also accelerated the adoption of SSL encryption.

Other huge drivers include regulatory and compliance initiatives. One example is the Health Insurance Portability and Accountability Act of 1996 (HIPAA) which mandates the use of TLS 1.0 or higher. The Payment Card Industry has also mandated the use of TLS in their PCI-DSS standard. In fact, PCI mandates the migration to a more secure version of TLS (TLS 1.1 or higher) by June 30, 2018.

Improvements to SSL technology like the use of ephemeral keys, where new encryption keys are exchanged between the server and clients for each session, have increased the security and effectiveness of data encryption and are also increasing adoption of the technology. In fact, all of these factors have increased the proliferation of SSL for security of online browsing and data storage. However, as we shall see, the use of encryption is not without its perils.

For security and troubleshooting purposes, organizations must examine the traffic on their networks. Unfortunately, firewalls, intrusion prevention systems (IPS), monitoring tools, and other equipment do not understand encrypted traffic.

The Problem With SSL Encryption

While the use of SSL has helped to encrypt data from prying eyes, it is now being used by bad actors to obscure security threats as well. In a May 2016 study, “Hidden Threats in Encrypted Traffic,” the Ponemon Institute found that 40% of cyberattacks leveraged SSL encryption to bypass traditional security solutions. And according to Gartner, over 50% of security attacks will use SSL and TLS by the end of 2017 to cover up malware threats and command and control (CNC) transmissions.

For security and troubleshooting purposes, organizations must examine the traffic on their networks. Unfortunately, firewalls, intrusion prevention systems (IPS), monitoring tools, and other equipment do not understand encrypted traffic. So, to actually inspect the traffic, it must first be decrypted before it can be analyzed. This often extracts a significant performance penalty. Depending upon where and how this decryption takes place, it will create different, sometimes significant, burdens on the network infrastructure to decrypt and process the data. The key to avoiding the decryption pitfall is to create a visibility architecture that can be used to effectively decrypt the necessary data and efficiently deliver it to where it needs to go—without causing a performance burden or significant time delay.

Overcoming The SSL Security Threat

To overcome the encryption security threat, businesses need to decrypt the traffic crossing their network and analyze it. There are two popular methods to achieve this: active decryption and passive decryption. Here is a review of both approaches.

Passive SSL Decryption

Passive SSL relies on static (rather than ephemeral) keys, and forces the IT department to copy the encryption keys from the target servers onto the decryption device. This is typically used for decrypting inbound connections from users on the Internet to internal servers. Once the decryption device has the keys, the device can decrypt traffic which can then be passed on to security and monitoring tools (like an intrusion detection system (IDS), data loss prevention (DLP), web application firewall (WAF), etc.) for analysis in clear text format. This mechanism is referred to as “passive” because the decryption device is not an active part of the SSL connection, it can decrypt traffic by merely observing it go past.

As shown in the picture below, passive decryption is for inbound only traffic monitoring scenarios (i.e. out-of-band monitoring solutions) and not does allow for the encryption/re-encryption of outbound communications.

Passive SSL relies on static (rather than ephemeral) keys, and forces the IT department to copy the encryption keys from the target servers onto the decryption device.

Active SSL Decryption

Active SSL decryption is a “man in the middle” approach where the off network sever communicates directly with the decryption device to exchange encryption keys. In this scenario, IT personnel do not have to get involved to manually load decryption keys, as ephemeral keys can be supported.

Once the clear text data is analyzed for security threats, the good data can be re-encrypted and sent on to its destination within the business’ network. In this instance, the SSL decryption device digitally signs the keys and negotiates the decryption keys with the endpoint device on the network, for decryption at the endpoint and is transparent to the recipient.

When using this scenario, decryption/encryption can be supported in both directions, i.e. for inbound and outbound network traffic. This means that both inline or out-of-band security and encryption tools can be used to analyze the network traffic.

Some security tools, like firewalls and IPS systems, can be purchased that include integrated SSL decryption capability. Unfortunately, studies have shown that there can be a significant performance impacts (up to an 81% drop in CPU processing capability) for devices that have this decryption feature turned on.

Three Scenarios For Active SSL Decryption

Due to the exchange key simplicity (from an IT personnel perspective) of active SSL decryption and the ability to be used for both inline and out-of-band monitoring solutions, active SSL decryption is the most popular decryption scenario. It is also the only solution applicable to connections using ephemeral keys. So what are some of your options? As detailed below, there are three common decryption scenarios.

Purpose Built Decryption Device

The first type of solution includes the category of purpose-built decryption devices. This type of solution excels in high volume transaction scenarios at high speeds. Typically, these solutions come with a high price tag to match the high performance. Since these devices are purpose built, once they are added to the network architecture they can create complexities when it comes to forwarding the decrypted data to multiple, sequential inspection tools (firewall, IPS, DLP, etc.), then redirecting the data back to the decryption device for re-encryption, and then the reintroduction of that data back into network. These solutions typically have fairly basic capabilities to complement their SSL engines.

Decryption Integrated Into Security Tools

In contrast to the purpose built device, some security tools, like firewalls and IPS systems, can be upgraded to include integrated SSL decryption capability. Unfortunately, studies have shown that there can be a significant performance impact (up to an 81% drop in CPU processing capability) for devices that have this decryption feature turned on.

This creates a significant network performance impact that will result in the costly purchase of additional security tools, i.e. additional firewalls in this case, to process the same amount of network traffic. As a result, an IDC survey found that only 25% of the companies surveyed actually use SSL decryption to inspect inbound and outbound communications for potential threats. Also, the decryption capability was not applied to all traffic, just some of it.

For enterprises who have adopted the industry best practice of “defense in depth,” relying on encryption built into multiple security devices has additional penalties. Forcing multiple inline devices to each decrypt and re-encrypt data has obvious performance and latency impacts.

Some security tools, like firewalls and IPS systems, can be upgraded to include integrated SSL decryption capability. Unfortunately, studies have shown that there can be a significant performance impacts (up to an 81% drop in CPU processing capability) for devices that have this decryption feature turned on.

Decryption Integrated Into An NPB

The third approach is to deploy a network packet broker. In contrast to the purpose built device, an NPB can essentially deliver one stop shopping. Data can be aggregated from multiple sources, decrypted by the NPB itself, and then distributed to the proper security and monitoring for analysis. Data can also be filtered and load balanced, if needed, at the same time and data decryption can be performed at line rate. Since the NPB decryption scenario does not place any decryption responsibility on the security and monitoring tools, those tools continue to function at optimum capability. If the decryption function needs to be disengaged, the feature is simply turned off. There is no need to take the network down or reroute data. For inline monitoring scenarios, the NPB can then effortlessly reintroduce the analyzed traffic back into the network for further propagation downstream.

With this decryption scenario, the NPB offers a cost effective alternative to both the purpose-built and the security plus decryption tool scenarios discussed previously. While performance at large scale can be less than the purpose built scenario, the NPB filtering, masking, and distribution capabilities of the data is far superior to purpose-built solutions. In addition, network traffic performance delays caused by the introduction of multiple, serially connected devices for SSL decryption is eliminated. These multi-component delays can add up and create noticeable delays for real-time traffic like voice and video. Thus, the integrated NPB approach provides excellent value across all decryption performance ranges.

Optimizing The Monitoring Architecture For SSL

It is important to pick the right decryption scenario for your network. The solution needs to be flexible as well as easy to deploy. A clear set of objectives are required as well. For instance, which of the following capabilities are required for your deployment?

• Extremely high or medium to high data throughput for SSL decryption
• Applications that require minimal data delay
• A cost effective solution
• Easy installation and maintenance
• Minimal impact to the network service to disengage SSL decryption
• Additional features like data aggregation, data distribution, packet filtering, load balancing, and deduplication of decrypted data
• Encryption details and application data reported over NetFlow

Once you know these answers, you can select one of the three decryption methods above that gives you the right solution at the right price for your network.

Since the NPB decryption scenario does not place any decryption responsibility on the security and monitoring tools, those tools continue to function at optimum capability.

Summary

Most enterprise applications are now encrypted and the use of SSL encryption is here to stay. While SSL provides some protection of network data and improves security and compliance initiatives, it does have its drawbacks. Encryption itself can introduce hidden security risks. For instance, the use of encryption to hide malware is growing rapidly. In addition, encryption makes the analysis of trouble shooting and performance monitoring data much more difficult.

Decryption of network at the enterprise is one of the newest capabilities to counteract this danger. Network packet brokers are a key piece of functionality to help enterprises and service providers optimize their visibility architecture and maximize the return on their investment for the following reasons:

• Integrated SSL decryption within an NPB is simpler and easier than other alternatives
• NPBs have no performance impacts for decryption and re-encryption
• The NPB easily connects dozens of security tools to the traffic they need to inspect
• Isolation of clear-text traffic can be maintained by the NPB
• The NPB solution delivers highly resilient security processing with load-balancing of tools and fail-open behavior

One of the dangers with SSL decryption is that it makes sensitive data available to anyone with access to network monitoring tools. This is a common problem for monitoring data stored in DLPs, logs, and other databases, as it often violates regulatory compliance mandates. Network packet brokers can be used to mask data that doesn’t need to be exposed, to ensure regulatory compliance at all times.

The combination of these feature sets allows the NPB to deliver a broad set of value-added features at a very cost effective price point.