Nearly 90% of all Internet traffic is encrypted—and we’re quickly moving toward an Internet where that will be true of nearly every piece of data in transit. The need to inspect traffic with greater scrutiny has grown exponentially as the threat landscape has evolved and encryption has become ubiquitous. SecOps teams deploy many technologies to detect threats to their applications, including next-generation firewalls (NGFW), web application firewalls (WAF), and intrusion prevention systems (IPS). However, because these technologies do not have visibility into encrypted traffic, or struggle to decrypt at scale, they require SSL/TLS decryption to provide any value in inspection. In a traditional infrastructure, those decryption and re-encryption tasks must be repeated at each point in the inspection chain.

Decrypting at multiple points in a connection flow introduces several problems:
 

·      Additional investment for TLS decryption and key management on each device.

·      Additional performance overhead on each decrypting device.

·      Multiple points of failure and increased latency on the connection.

·      Increased troubleshooting difficulty and costs.

·      Challenges in scaling each service independently.

·      Inconsistent support of SSL/TLS protocols and ciphers across the security stack.

Many organizations have responded by creating decryption zones in the DMZ for inspection by multiple devices, but it’s usually a static path where all decrypted traffic is inspected by the same chain of devices. While this strategy does boost performance and lower management overhead, it can introduce scaling problems. It may also limit the environment to less secure crypto by restricting the use of the cipher suites required for forward secrecy. Finally, the process can be inefficient because your security devices are inspecting everything instead of identifying and inspecting only the suspicious traffic. Setting up a decryption zone without added intelligence and traffic orchestration isn’t the ideal solution to the pressing problem of visibility into encrypted traffic. The good news is that there’s a better way.

SECURE ALL TRAFFIC, INBOUND AND OUTBOUND

With the explosion of HTTPS traffic, decryption has become a requirement to enable application-layer traffic management decisions. Organizations frequently leverage an Application Delivery Controller (ADC) such as BIG-IP Local Traffic Manager (LTM) to provide visibility for other systems beyond the application server. A relatively new challenge is the requirement to provide visibility for multiple thirdparty inspection technologies on the same application connection.

Visibility is not enough. Security practitioners need orchestration in order to maximize security investments, and maintain consistent traffic steering policies regardless of device, topology, or SSL/TLS protocol/cipher. F5 SSL Orchestrator gives you the capability to dynamically chain multiple inspection services together for both inbound and outbound traffic flows. This new inbound service-chaining capability makes an existing BIG-IP LTM the logical place to add SSL Orchestrator to enable the security inspection today’s threat landscape demands.

Consider the scenario in which all decrypted traffic is sent to a performance monitoring system before sending it on to the destination application server. If the source IP address is suspicious, it would be advantageous to send that decrypted traffic to be inspected by the IPS and also to be logged by the performance monitoring system. With SSL Orchestrator, this extra inspection of a suspicious request can happen without complex routing or additional network paths. SSL Orchestrator’s unique service-chaining ability enables security operations to create one dynamic configuration adaptable to many different scenarios with multiple associated inspection paths.

SSL Orchestrator includes an easy-to-use Visual Policy Editor with workflows that accommodate both new and existing applications. This makes it simple to integrate into existing environments or build new ones. SSL Orchestrator can also be configured as it would be in a standalone architecture to send re-encrypted traffic to another routed destination instead of a pool of application servers.
 

ARCHITECTURAL CONSIDERATIONS

After passing each inspection device in the decryption zone, the traffic returns to the original BIG-IP device. As a result, traffic and utilization can ramp up quickly. For BIG-IP Cloud Edition deployments, this can entail utilizing larger or more instances. For BIG-IP hardware appliances, this means ensuring a new or existing appliance is specified with enough available capacity. Fortunately, the highly-optimized SSL/TLS stack in TMOS is extremely efficient for both decryption and re-encryption—and on hardware it has the added benefit of dedicated crypto processors.
 

CONCLUSION

Security is about controlling risk, and control is only possible with visibility. F5 SSL Orchestrator provides high-performance decryption of inbound and outbound SSL/TLS traffic, enabling security inspection to expose threats, stop attacks, and reduce business risk. It also enables security practitioners to add visibility into new and existing traffic flows to maximize the effectiveness of prior security investments. Adding SSL Orchestrator to BIG-IP Local Traffic Manager minimizes the impact to your existing architecture and leverages your ADC as a strategic point of control—which helps boost your security posture while maintaining the performance standards your business requires.