Orchestrated Infrastructure Security - Getting Started

Note: The Beacon capabilities referenced in this article hosted on F5 Cloud Services are planning a migration to a new SaaS Platform - Check out the latest here.

Introduction

A typical daisy-chained security stack is difficult to manage and make changes. All devices in the chain are physically wired to each other in a serial arrangement. Each device performs SSL decryption and re-encryption when needed. All devices in the chain need to have similar performance capabilities. All devices in the chain need to be properly configured to route traffic to their neighboring devices, and likely will need to be manually configured to trust SSL certificates used by neighboring devices for decryption and re-encryption.

Failure of any device in the security chain brings the entire chain down. Capacity cannot be increased simply by adding another like-device (i.e. a NGFW) to the chain. Capacity can only be increased by replacing a single device with a higher capacity device.

Removing or adding a device to the chain is problematic. For one, the entire security stack will need to be unavailable while removing or adding a device. Proper routing between devices must be maintained or the whole chain will not pass traffic. Certificate trust and other factors may need to be addressed as well.

High availability is also problematic. The only way to ensure high availability is to create another daisy-chain, identical to the first. This chain needs to wait in standby mode until the primary chain fails or is taken down, and then the standby chain can take over for the primary.

Managing a single daisy chain security stack is not easy. Managing two for high availability is significantly more complicated and overly expensive.

Some security devices are deployed differently and cannot operate together in the security stack. Those devices would need their own separate deployment from the devices in the daisy chain, further complicating the configuration. As an example, it’s not an uncommon security practice to employ network TAP devices, explicit proxies, ICAP servers as well as Layer2/3 devices. All of these devices cannot be configured to properly route traffic in a daisy chain.

SSL Orchestrator solves almost all of these challenges, and enables you to have a nimble security solution capable of adapting to almost any type of threat.

High Level Network Topology

The network topology used for this setup is below. BIG-IP-11 and 12 are deployed in Layer 2 mode. The Advanced WAF and AFM devices will also be deployed in Layer 2 and will be physically wired to the SSL Orchestrators. This is a high availability environment where there is one Active BIG-IP and one ready on Standby. The Port Objects (511 & 512) allow traffic to flow through either BIG-IP, in case of a failure. The applications being protected are represented by the Ubuntu servers connected to the South switch.

BIG-IP Network Topology

A zoomed in view of the BIG-IP devices is below. This shows the physical connectivity and the specific interfaces used by SSL Orchestrator, Advanced WAF and AFM devices.

Summary

This article is part of a series on implementing Orchestrated Infrastructure Security. It includes High Availability, Central Management with BIG-IQ, Application Visibility with Beacon and the protection of critical assets using F5 Advanced WAF and Protocol Inspection (IPS) with AFM. It is assumed that SSL Orchestrator is already deployed, and basic network connectivity is working.