F5 SSL Orchestrator and Cisco Firepower Threat Defense (FTD) Integrated Solution
The Secure Sockets Layer (SSL) protocol and its successor, Transport Layer Security (TLS), have been widely adopted by organizations to secure IP communications, and their use is growing rapidly. While TLS/SSL provides data privacy and secure communications, it also creates challenges to inspection devices in the security stack when inspecting the encrypted traffic. In short, the encrypted communications cannot be seen as clear text and are passed through without inspection, becoming security blind spots. This creates serious risks for businesses: What if attackers are hiding malware inside the encrypted traffic? However, performing decryption of TLS/TLS traffic on the security inspection devices, with native decryption support, can tremendously degrade the performance of those devices. This performance concern becomes even more challenging given the demands of stronger, 2048-bit certificates. An integrated F5 and Cisco solution solves these two SSL/TLS challenges. F5 SSL Orchestrator centralizes TLS/SSL inspection across complex security architectures, enabling flexible deployment options for decrypting and re-encrypting user traffic. It also provides intelligent traffic orchestration using dynamic service chaining and policy-based management. The decrypted traffic is then inspected by one or more Cisco FTD systems, which can prevent previously hidden threats and block zero-day exploits. The Cisco Firepower Threat defense may be delivered using several combinations of Cisco Firepower and ASA platforms and software images. This solution eliminates the blind spots introduced by TLS/SSL and closes any opportunity for adversaries. Solution Deployment The F5 and Cisco integrated solution enables organizations to intelligently manage SSL/TLS Traffic while providing visibility into a key threat vector that attackers often use to exploit vulnerabilities, establish command and control channels, and steal data. Without SSL visibility, it is impossible to identify and prevent such threats at scale. F5 SSL Orchestrator intercepts both outbound and inbound traffic. Other security services like DLP (using ICAP), IPS, and HTTP(s) Proxies can also be deployed alongside Cisco FTD when configured in a service chain within the decrypt zone. Cisco FTD supports both Inline (Layer 2 and Layer 3) and TAP mode of operation. In this example solution, Cisco FTD is configured as Layer 3 / routed hop. I. Bill of Materials F5 SSL Orchestrator 5.1 Optional functional add-ons include URL filtering subscription, IP Intelligence subscription, network hardware security module (HSM), F5 Secure Web Gateway (SWG) Services and F5 Access Manager (APM). Cisco FTD II. Pre-requisites F5 SSL Orchestrator is licensed and set up with internal and external VLANs and Self-IP addresses. An SSL certificate—preferably a subordinate certificate authority (CA)—and private key are imported into F5 SSL Orchestrator. The CA certificate chain with root certificate is imported into the client browser. Cisco FTD is setup with physical connectivity to F5 SSL Orchestrator. This Cisco FTD system is managed by Cisco Firepower Device Manager (FDM). III. IP Addressing When a Cisco FTD is deployed as an Layer 3/ routed hop, we recommend configuring its IP addresses for interface in the inside zone and interface in the outside zone, from default fixed addressing subnets, provided by SSL Orchestrator, that are derived from a RFC2544 CIDR block of 192.19.0.0. This minimizes the likelihood of address collisions. In this example, the Cisco FTD is configured with IP address 198.19.64.61/25 on the interface in the inside zone (connected to SSL Orchestrator ‘To Service’ VLAN) and 198.19.64.161/25 on the interface in the outside zone (connected to SSL Orchestrator ‘From Service’ VLAN). You will also need to configure static routes to the internal networks with 198.19.64.7 as the next hop and a default route to the Internet with 198.19.64.245 as the gateway. The table below explains the IP addresses that you need to configure when deploying multiple FTDs in the service pool. IV. Configure Cisco FTD Configure the interfaces with IP addresses and assign them to Inside and Outside zones. Configure the static route to internal network (192.168.16.0/24) with next hop as the IP address on the ‘To Service’ VLAN of the SSL Orchestrator (198.19.64.7). Also, configure the default route to internet with IP address on the ‘To Service’ VLAN of the SSL Orchestrator (198.19.64.245) as the gateway. V. Deploy F5 SSL Orchestrator using Guided Configuration SSL Orchestrator version 5.1 introduced Guided Configuration, a workflow-based architecture that provides intuitive, re-entrant configuration steps and presents a completely new and streamlined user experience. To deploy the SSL Orchestrator application, log into the F5 system. On the F5 Web UI Main menu, navigate to SSL Orchestrator > Configuration and follow the guided configuration steps. Step 1: Topology Properties SSL Orchestrator creates discreet configurations based on the selected topology. Selecting explicit forward proxy topology (as shown in the example) will ultimately create an explicit proxy listener. Step 2: SSL Properties Select the previously imported subordinate CA certificate (see Prerequisites, above) to sign and issue certificates to the end-host for client-requested HTTPS websites that are intercepted. Step 3: Create the Cisco Inline L3 Service The services list section defines the security services that interact with SSL Orchestrator. The guided configuration includes a services catalog that contains common product integrations. In the service catalog, double click on the Inline L3 service and configure the service settings: service name, VLAN pair and port remap. The ‘To VLAN’ and the associated interface define the network connectivity from SSL Orchestrator to the interface in the inside zone on the Cisco FTD. The ‘From VLAN’ and the associated interface define the network connectivity from SSL Orchestrator to the interface in the outside zone on the Cisco FTD. For the Cisco FTD to recognize that the steered traffic has been decrypted, it needs to be sent on a non-443 TCP port. Using the service catalog, create additional security services as required, before proceeding to the next step. Step 4: Service Chains Create a service chain, which is an arbitrarily ordered lists of security devices. The service chain determines which services receive traffic. Step 5: Security Policy SSL Orchestrator’s guided configuration presents an intuitive rule-based, drag-and-drop user interface for the definition of security policies. In the background, SSL Orchestrator maintains these security policies as visual per-request policies. If traffic processing is required that exceeds the capabilities of the rule-based user interface, the underlying per-request policy can be managed directly. Use this section to create custom rules as required. Step 6: Intercept Rule Interception rules are based on the selected topology and define the listeners (analogous to BIG-IP Local Traffic Manager virtual servers) that accept and process different types of traffic, such as TCP, UDP, or other. The resulting BIG-IP LTM virtual servers will bind the SSL settings, VLANs, IPs, and security policies created in the topology workflow. Step 7: Egress Settings The egress settings section defines topology-specific egress characteristics like NAT and outbound route. Step 8: Summary The configuration summary page presents an expandable list of all the workflow-configured objects. Review the setting and click the Deploy button to deploy SSL Orchestrator. SSL Orchestrator will be successfully deployed on the F5 system. VI. Verification Navigate to http://www.eicar.org/ and download a malware test file via HTTP and HTTPS links from the client. Login to Cisco FDM Web UI and navigate to Analysis > Intrusions > Alerts to view the malware alert. Conclusion The joint solution from F5 Networks and Cisco brings together the best of application delivery and advanced malware protection to help you identify and stop even the most sophisticated attacks, whether in the data center or at the perimeter of your network. Together, we help you accelerate business growth while decreasing the risk of security breaches. Learn more: Product page: F5 SSL OrchestratorOrchestrated Infrastructure Security - Change at the Speed of Business - Cisco Firepower
Editor's Note:The F5 Beacon capabilities referenced in this article hosted on F5 Cloud Services are planning a migration to a new SaaS Platform - Check out the latesthere Introduction 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, Protocol Inspection (IPS) with AFM as well as leading Security Solutions like Cisco Firepower and WSA.It is assumed that SSL Orchestrator is already deployed, and basic network connectivity is working. If you need help setting up SSL Orchestrator for the first time, refer to the Dev/Central article series on Implementing SSL Orchestrator here or the CloudDocs Deployment Guide here. This article focuses on using SSL Orchestrator as a tool to assist with simplifying Change Management processes, procedures and shortening the duration of the entire process. Configuration files of Cisco Firepower can be downloaded fromherefrom GitLab. Please forgive me for using SSL and TLS interchangeably in this article. Click here for a demo video of this Dev/Central article This article is divided into the following high level sections: ·Create a new Topology to perform testing ·Monitor Firepower statistics – change the weight ratio – check Firepower stats again ·Remove a single Firepower device from the Service ·Perform maintenance on the Firepower device ·Add the Firepower device to the new Topology ·Test functionality with a single client ·Add the Firepower device back to the original Topology ·Test functionality again ·Repeat to perform maintenance on the other Firepower device Create a new Topology to perform testing A new Topology will be used to safely test the Service after maintenance is performed.The Topology should be similar to the one used for production traffic.This Topology can be re-used in the future. From the BIG-IP Configuration Utility select SSL Orchestrator > Configuration.Click Add under Topologies. Scroll to the bottom of the next screen and click Next. Give it a name, Topology_Staging in this example. Select L2 Inbound as the Topology type then click Save & Next. For the SSL Configurations you can leave the default settings.Click Save & Next at the bottom. Click Save & Next at the bottom of the Services List. Click the Add button under Services Chain List.A new Service Chain is needed so we can remove Firepower1 from the Production Service and add it here. Give the Service Chain a name, Staging_Chain in this example.Click Save at the bottom. Note: The Service will be added to this Service Chain later. Click Save & Next. Click the Add button on the right to add a new rule. For Conditions select Client IP Subnet Match. Enter the Client IP and mask, 10.1.11.52/32 in this example.Click New to add the IP/Subnet. Set the SSL Proxy Action to Intercept. Set the Service Chain to the one created previously. Click OK. Note: This rule is written so that a single client computer (10.1.11.52) will match and can be used for testing. Select Save & Next at the bottom. For the Interception Rule set the Source Address to 10.1.11.52/32.Set the Destination Address/Mask to 10.4.11.0/24.Set the port to 443. Select the VLAN for your Ingress Network and move it to Selected. Set the L7 Profile to Common/http. Click Save & Next. For Log Settings, scroll to the bottom and select Save & Next. Click Deploy. Monitor Firepower statistics – change the weight ratio – check Firepower statistics again Check the statistics on the Firepower device we will be performing maintenance on.It’s “Firepower1” in this example. Connect to the CLI via SSH.At the prompt enter ‘capture-traffic’.Select the correct ‘inlineset’ (2 in this example) and hit Enter for no tcpdump options: > capture-traffic Please choose domain to capture traffic from: 0 - management0 1 - inlineset1 inline set 2 - inlineset2 inline set Selection? 2 Please specify tcpdump options desired. (or enter '?' for a list of supported options) Options: You should see an output similar to the following: This Firepower device is actively processing connections. Change the Weight Ratio Back to the SSL Orchestrator Configuration Utility.Click SSL Orchestrator > Configuration > Services > then the Service name, ssloS_Firepower in this example. Click the pencil icon to edit the Service. Click the pencil icon to edit the Network Configuration for Firepower2 Set the ratio to 65535 and click Done. Click Save & Next at the bottom. Click OK if presented with the following warning. Click Deploy. Click OK when presented with the Success message. Check Firepower Statistics Again Check the statistics on “Firepower1” again.With the Weight Ratio change there should be little to no active connections. It should look like the following: Note: The connections above represent the health checks from SSL Orchestrator to the inline Service. Remove a single Firepower device from the Service Back to the SSL Orchestrator Configuration Utility.Click SSL Orchestrator > Configuration > Services > then the Service name, ssloS_Firepower in this example. Click the pencil icon to edit the Service. Under Network Configuration, delete Firepower1. Click Save & Next at the bottom. Click OK if presented with the following warning. Click Deploy. Click OK when presented with the Success message. Perform maintenance on the Firepower device At this point Fireower1 has been removed from the Incoming_Security Topology and is no longer handling production traffic.Firepower2 is now handling all of the production traffic. We can now perform a variety of maintenance tasks on Firepower1 without disrupting production traffic.When done with the task(s) we can then safely test/verify the health of Firepower1 prior to moving it back into production. Some examples of maintenance tasks: ·Perform a software upgrade to a newer version. ·Make policy changes and verify they work as expected. ·Physically move the device. ·Replace a hard drive, fan, and/or power supply. Add the Firepower device to the new Topology This will allow us to test its functionality with a single client computer, prior to moving it back to production. From the SSL Orchestrator Configuration Utility click SSL Orchestrator > Configuration > Topologies > sslo_Topology_Staging. Click the pencil icon on the right to edit the Service. Click Add Service. Select the Cisco Firepower Threat Defense Inline Layer 2 Service and click Add. Give it a name or leave the default.Click Add under Network Configuration. Set the FROM and TO VLANS to the following and click Done. Click Save at the bottom. Click the Service Chain icon. Click the Staging_Chain. Move the CSCO Service from Available to Selected and click Save. Click OK. Click Deploy. Click OK. Test functionality with a single client We created a policy with source IP = 10.1.11.52 to use the new Firepower Service that we just performed maintenance on. Go to that client computer and verify that everything is still working as expected. As you can see this is the test client with IP 10.1.11.52. The page still loads for one of the web servers. You can view the Certificate and see that it is not the same as the Production Certificate. Add the Firepower device back to the original Topology From the SSL Orchestrator GUI select SSL Orchestrator > Configuration > Service Chains Select the Staging_Chain. Select ssloS_CSCO on the right and click the left arrow to remove it from Selected. Click Deploy when done. Click OK. Click OK to the Success message. From the SSL Orchestrator Guided Configuration select SSL Orchestrator > Configuration > Services. Select the CSCO Service and click Delete. Click OK to the Warning. When that is done click the ssloS_Firepower Service. Click the Pencil icon to edit the Service. Under Network Configuration click Add. Set the Ratio to the same value as Firepower2, 65535 in this example.Set the From and To VLAN the following and click Done. Click Save & Next at the bottom. Click OK. Click Deploy. Click OK. Test functionality again Make sure Firepower1 is working properly. To ensure that everything is working as expected you can view the Statistics on Firepower1 again. This Firepower device is actively processing connections. Repeat these steps to perform maintenance on the other Firepower device (not covered in this guide) ·Create a new Topology to perform testing ·Monitor Firepower statistics – change the weight ratio – check Firepower stats again ·Remove a single Firepower device from the Service ·Perform maintenance on the Firepower device ·Add the Firepower device to the new Topology ·Test functionality with a single client ·Add Firepower device back to the original Topology ·Test functionality againImplementing SSL Orchestrator - L2 Service Configuration (Firepower)
Introduction This article is part of a series on implementing BIG-IP SSL Orchestrator. It includes high availability and central management with BIG-IQ. Implementing SSL/TLS Decryption is not a trivial task. There are many factors to keep in mind and account for, from the network topology and insertion point, to SSL/TLS keyrings, certificates, ciphersuites and on and on. This article focuses on configuring a 3rd party, inline Layer 2 security device and everything you need to know about it. This article covers the configuration of Cisco Firepower running version 6.4. Please forgive me for using SSL and TLS interchangeably in this article. A common Firepower deployment mode is in Layer 2, using “Inline Sets”.This combines 2 interfaces to act as an L2 bridge where data flows into one interface and is passed out the other interface. Firepower Management Center must be used when configuring this because Firepower Device Manager does not support the configuration of Inline Sets. From the Firepower Management Center click Devices.It should look like the following. Double click the Name of the Firepower device you want to configure. This should bring you to the Interfaces screen.We will be configuring Ethernet 1/3 and 1/4.Click the pencil on the right to edit Ethernet 1/3. Enable the interface and give it a name, “frombigip11” in this example.Click OK. Repeat these steps for Ethernet 1/4, giving it a unique name too. It should look like the following. Notes: when configuring for High Availability repeat these steps for another Ethernet pair, like 1/5 and 1/6. Go to the Inline Sets tab and click Add Inline Set. Give it a Name, inlineset11 in this example.The Interface Pair should appear on the left.Select it and click Add to move it to the right.Then click OK. Notes: when configuring for High Availability repeat these steps for the other Interface Pair. Click Save and then Deploy. Check the box next to the Firepower device you configured and click Deploy.This process may take several minutes. When done, the screen should look like this. Summary In this article you learned how to configure Cisco Firepower in Layer 2 mode. Configuration of Cisco Firepower can be downloaded from here in GitLab. Next Steps Click Next to proceed to the next article in the series. Contact Cisco if you need additional assistance with their products.Incident Remediation with Cisco Firepower and F5 SSL Orchestrator
SSL Orchestrator Configuration steps This guide assumes you have a working SSL Orchestrator Topology, either Incoming or Outgoing, and you want to add a Cisco Firepower TAP Service.Both Topology types are supported, and configuration of the Cisco Remediation is the same. If you do not have a working SSL Orchestrator Topology you can refer to the BIG-IP SSL Orchestrator Dev Central article series for full configuration steps. In this guide we will outline the necessary steps to deploy the Cisco FTD with SSL Orchestrator.FTD can be deployed as a Layer 2/3 or TAP solution.SSL Orchestrator can be deployed as a Layer 2 or 3 solution. SSL Orchestrator gives you the flexibility to deploy in the manner that works best for you.As an example, SSL Orchestrator can be deployed in Layer 2 mode while FTD is deployed in Layer 3 mode, and vice versa. A familiarity with BIG-IP deployment concepts and technology as well as basic networking is essential for configuring and deploying the SSL Orchestrator components of the BIG-IP product portfolio. For further details on the configuration and networking setup of the BIG-IP, please visit the F5 support site at https://support.f5.com . The SSL Orchestrator Guided Configuration will walk you through configuration of the Services (Firepower nodes), Security Policy and more.Lastly, iRules will be applied. Guided Configuration: Create Services We will use the Guided Configuration wizard to configure most of this solution, though there are a few things that must be done outside of the Guided Configuration.In this example we will be working with an existing L2 Outbound Topology. From the BIG-IP Configuration Utility click SSL Orchestrator > Configuration > Services > Add. For Service properties, select Cisco Firepower Threat Defense TAP then click Add. Give it a name.Enter the Firepower MAC Address (or 12:12:12:12:12:12 if it is directly connected to the SSL Orchestrator). For the VLAN choose Create New, give it a Name (Firepower in this example) and select the correct interface (2.2 in this example).If you configured the VLAN previously then choose Use Existing and select it from the drop-down menu. Note: A VLAN Tag can be specified here if needed. Enabling the Port Remap is optional.Click Save & Next. Click the Service Chain name you wish to configure, sslo_SC_ServiceChain in this example. Note: If you don’t have a Service Chain you can add one now. Highlight the Firepower Service and click the arrow in the middle to move it to the Selected side.Click Save. Click Save & Next. Then click Deploy. Configuration of iRules and Virtual Servers We will create two iRules and two Virtual Servers. The first iRule listens for HTTP requests from the Firepower device. Firepower then responds via its Remediation API and sends an HTTP Request containing an IP Address and a timeout value. The address will be the source IP that is to be blocked by the SSL Orchestrator; the SSL Orchestrator will continue to block for the duration of the timeout period. For details and tutorials on iRules, please consult the F5 DevCentral site athttps://devcentral.f5.com. Create the first iRule on the SSL Orchestrator. Within the GUI, selectLocal Traffic > iRules then chooseCreate. Give it a name (FTD-Control in this example) then copy/paste the iRule text into the Definition field. Click Finished. This iRule will be associated with the Control Virtual Server. iRule text when HTTP_REQUEST { if { [URI::query [HTTP::uri] "action"] equals "blocklist" } { set blockingIP [URI::query [HTTP::uri] "sip"] set IPtimeout [URI::query [HTTP::uri] "timeout"] table add -subtable "blocklist" $blockingIP 1 $IPtimeout HTTP::respond 200 content "$blockingIP added to blocklist for $IPtimeout seconds" return } HTTP::respond 200 content "You need to include an ? action query" } Create the second iRule by clicking Create again. Give it a name (FTD-Protect in this example) then copy/paste the iRule text into the Definition field. Click Finished. This iRule will be associated with the Protect Virtual Server. iRule text when CLIENT_ACCEPTED { set srcip [IP::remote_addr] if { [table lookup -subtable "blocklist" $srcip] != "" } { drop log local0. "Source IP on block list " return } } Create the Virtual Servers from Local Traffic select Virtual Servers > Create. Give it a name, FTD-Control in this example. The type should be Standard.Enter “0.0.0.0/0” for the Source Address Host.This indicates any Source Address will match. The Destination Address/Mask is the IP address the SSL Orchestrator will listen on to accept API requests from Firepower.In this example it’s “10.5.9.77/32” which indicates that the SSL Orchestrator will only respond to connections TO that single IP address. Note: The Destination Address/Mask must be in the same subnet as the 2 nd Management Interface on the Firepower Management Center.We’ll go over this later. For VLANS and Tunnels Traffic it is preferred for this to be enabled on the specific VLAN that the Firepower 2 nd Management Interface will be using, rather than All VLANs and Tunnels. Choose Enabled on… Select the same VLAN that the Firepower 2 nd Management Interface will be using, in this example vlan509.Click the double << to move the vlan to Selected. In the Resources section click the FTD-Control iRule created previously.Click the double << to move it to Enabled. Click Finished when done. Click Create again. Give it a name, FTD-Protect in this example.Set the Type to Forwarding (IP).The Source Address in this example is set to 10.4.11.152/32.This Virtual Server will only accept connections with a Source IP of 10.4.11.152.It is being done this way for testing purposes to make sure everything works with a single test client.With an Incoming Topology the Source Address might be set to 0.0.0.0/0 which would allow connections from anywhere. The 10.5.11.0 network is the Destination the 10.4.11.0 network must take to pass through SSL Orchestrator. Under Available, select the ingress VLAN the SSL Orchestrator is receiving traffic on, Direct_all_vlan_511_2 in this example.Click the double << in the middle to move it from Available to Selected. In the Resources section click the FTD-Protect iRule created previously.Click the double << to move it to Enabled. Click Finished when done. Steps Performed: 1.Firepower TAP Service created 2.iRules created 3.Virtual Servers created 4.iRules attached to Virtual Servers Cisco Firepower (FTD) Setup and Configuration This Guide assumes you have Cisco Firepower and Firepower Management Center (FMC) deployed, licensed and working properly. After logging into the Firepower Management Center you will see the Summary Dashboard. Click System > Configuration to configure the Management settings. Click Management Interfaces on the left. A Management Interface on FMC must be configured for Event Traffic.This interface MUST be on the same subnet as the Control Virtual Server on SSL Orchestrator (10.5.9.77).If using a Virtual Machine for FMC you need to add a 2 nd NIC within the Hypervisor console, like this: Refer to your Hypervisor admin guide for more information on how to do this. To configure the 2 nd Management Interface click the pencil icon. Click Save when done. Firepower Access Policy This guide assumes that Intrusion and Malware policies are enabled for the Firepower device.The Policy should look something like the image below. Firepower Remediation Policies Next, we need to create a Firepower Remediation Policy. A Remediation policy can take a variety of different actions based on an almost infinite set of criteria.For example, if an Intrusion Event is detected, Firepower can tell SSL orchestrator to block the Source IP for a certain amount of time. From FMC click Policies > Responses > Modules. The F5 Remediation Module is installed here.Click Browse to install the Module.Locate the Module on your computer and select it, click Open then Install.Click the magnifying glass on the right after it’s installed. Note: The F5 Remediation Module can be downloaded from a link at the bottom of this article. Click Add to Configure an Instance. Give it a name, Block_Bad_Actors in this example.Specify the IP address of the SSL Orchestrator Control Virtual Server, 10.5.9.77 in this example.Optionally change the Timeout and click Create. Next, configure a Remediation by clicking Add. Give it a name, RemediateBlockIP in this example and click Create. Select Policies > Correlation > Create Policy to create a Correlation Policy to define when/how to initiate the Remediation. Give it a name, Remediation in this example and click Save. From the Rule Management tab click Create Rule. Give it a name, RemediateRule in this example. For the type of event select ‘an intrusion event occurs’ from the drop-down menu. For the Condition select Source Country > is > North Korea > Save Note: FMC can trigger a Remediation for a variety of different events, not just for Intrusion.In fact, while configuring Remediation you might want to use a different Event Type to make it easier to trigger an event and verify it was successfully Remediated.For example, you could choose ‘a connection event occurs’ then set the Condition to URL > contains the string > “foo”.In this way the Remediation rule should trigger if you attempt to go to the URL foo.com. Go back to Policy Management and click the Policy created previously, Remediation in this example.Click Add Rules. Select the RemediateRule and click Add. Click Save. Correlation policies can be enabled or disabled using the toggle on the right.Make sure the correct policy is enabled. Remediated Policy Reporting The status of Remediation Events can be viewed from Analysis > Correlation > Status. Here we can see the “Successful completion of remediation” message. Conclusion This concludes the recommended practices for configuring F5 BIG-IP SSL Orchestrator with the Cisco FTD. The architecture has been demonstrated to address both the SSL visibility and control and IPS Policy Based Traffic Steering and Blocking user scenarios. With the termination of SSL on the SSL Orchestrator, FTD sensors are provided visibility into both ingress and egress traffic to adapt and protect an organization’s applications, servers and other resources. By leveraging the Security Policy Based Traffic Steering, an organization can leverage this configuration and can continue to scale through the addition of more FTD managed devices in order to provide more traffic capacity for the protected networks and applications. This policy based flexibility which can be provided by the SSL Orchestrator, can also be leveraged to selectively direct traffic to different pools of resources based on business, security or compliance requirements.
