SSL Orchestrator Advanced Use Cases: Defying the Datacenter Deployment Monster

Introduction

F5 BIG-IP is synonymous with "flexibility". You likely have few other devices in your architecture that provide the breadth of capabilities that come native with the BIG-IP platform. And for each and every BIG-IP product module, the opportunities to expand functionality are almost limitless. In this article series we examine the flexibility options of the F5 SSL Orchestrator in a set of "advanced" use cases.

If you haven't noticed, the world has been steadily moving toward encrypted communications. Everything from web, email, voice, video, chat, and IoT is now wrapped in TLS, and that's a good thing. The problem is, malware - that thing that creates havoc in your organization, that exfiltrates personnel records to the Dark Web - isn't stopped by encryption. TLS 1.3 and multi-factor authentication don't eradicate malware. The only reasonable way to defend against it is to catch it in the act, and an entire industry of security products are designed for just this task. But ironically, encryption makes this hard. You can't protect against what you can't see. F5 SSL Orchestrator simplifies traffic decryption and malware inspection, and dynamically orchestrates traffic to your security stack. But it does much more than that. SSL Orchestrator is built on top of F5's BIG-IP platform, and as stated earlier, is abound with flexibility.

SSL Orchestrator Use Case: Defying the Datacenter Deployment Monster

It happens. You do the research, watch the videos, read the docs, and you're sure you have everything as it should be. You need to add a new security device to your architecture, so you spin it up in a lab and throw some traffic at it. It looks good, so you schedule a maintenance outage. The team gathers, some in the datacenter, some on the phone, and you start plugging things in and turning things on. It's late at night, because...that's when you do maintenance. But you feel good, so people go home. Next thing you know it's 6am and you're getting frantic calls from the help desk that the network is down, the c-level staff is fuming and mission critical apps are offline. Your thoughts scramble to what could be happening, hoping it isn't the new security device. But of course that's exactly what it is, so you rush to the datacenter, rip out all of the cables and put it back to the way it was before. You've effectively undone days of work in a single instant, and now have to spend days more reassessing. If this story hasn't made you sick to your stomach, then you've never really lived the life of an IT professional. Truth is, we've all been through this at one point or another. And whether it was last week or 10 years ago, the notion of it still brings thoughts of dread.

This article is less of a technical how-to, and more about how to prevent the above narrative. And as always, F5, and SSL Orchestrator have some unique and innovative ways to accomplish this. Specifically, I'll cover two core concepts of the SSL Orchestrator architecture that helps to prevents the above situation: deploying security services within the SSL Orchestrator service chain, and deploying the SSL Orchestrator itself. The former a description, the latter a recommendation.

Deploying Security Services within the Service Chain

In the typical network architecture, security devices are stacked one after another. This "daisy chain" presents some challenges. At the very least, if you enable decryption and re-encryption at each, you're going to grind throughput down to a crawl. But perhaps more pervasive, these devices are inline, so they're in the path of ALL traffic whether they care about that traffic or not. If your pipe is 5Gb, then everything along the path has to support that. And if it can't, then you need to insert load balancing. And worse, if a device fails closed, it's typically going to take everything with it. 

figure 1: daisy chain architecture

Now, let's shift that daisy chain paradigm to a "service chain" model. In the service chain, or more specifically a "dynamic service chain", the security devices are independently addressed. You can almost think of this visually as a hub-and-spoke. In any case, as these security devices are now independently addressed from a central orchestrator, you can do some pretty cool things. 

figure 2: service chain architecture

For starters, each service gets its own built-in load balancer. So scaling up to meet the pipe doesn't have to mean a huge investment in big boxes. Second, because you can now freely scale the different security devices, you can also actively monitor and go around failed services. No single service failure ever needs to take out the entire network. Third, it's "dynamic" because flow through the services is defined by traffic rules. You can define rules that send traffic only to the set of devices that can actually do something useful with it. And since not all services need to see all traffic, they don't have to scale equally. But the most compelling aspect of the service chain is FREEDOM. Remember when you had to deploy a new device in stages: first in the lab, then again in production in a late-night maintenance evolution? Imagine deploying a security device directly into production traffic. In SSL Orchestrator, you can simply attach a security device, create a separate service chain that includes that device (and maybe other already-in-production devices), and then build a traffic rule that carves out some portion of traffic to that service chain. I've seen companies carve out small IP subnets, or maybe specific URL categories. However you do it, you're testing a new security product with real production traffic. If it fails, just remove the traffic rule. Chances are you didn't include the c-levels and critical business units in that test, so no harm done. But if it succeeds, just add the new device to your production service chains and you're done. And if you need to take a device out of service, maintenance windows are so 2017. Just remove the device from the production service chain and bleed off traffic to it. The service chain orchestration model gives you the freedom and flexibility to move security devices in and out of service at will.

Deploying the SSL Orchestrator

You may be thinking at this point, "Well, that's fantastic, but what about deploying the SSL Orchestrator box itself? What if it fails in production?". And to that I say, "fair point". You are effectively eliminating the brittle daisy chain, but there's still a device in the path. We humans have a tendency to react erratically in pressure-filled situations. So if someone is screaming at you to restore the network, your first inclination is probably to pull cables and put it back the way it was. What we don't typically take into account when introducing new devices in a traffic flow...is the diversity of the traffic itself. Yes it's TCP and UDP, and ICMP and BGP... But it's just as important to understand what that traffic really is, as it is understanding the devices we introduce. And invariably, a lot of these outages happen because we underestimate our users and what they're trying to do. Think about it. All other things being equal, what's different between the lab environment and production? 

Hint: it's the users. 

Security isn't a one-size-fits-all equation. There's no one single WAF policy for all applications. That's equally true of SSL visibility. While the VAST majority of your Internet traffic will work as advertised, some things just...don't. Granted it's a small list, but things like certificate pinning will break when you try to decrypt. And there are protocols, however rare and industry-specific, that have a hard time passing through a security device. All SSL visibility products are going to deal with this. 

So then what do you do? Well, herein lies another unique way SSL Orchestrator can make this more resistant to failure. When you insert the SSL Orchestrator into your production traffic flow, set it up in a pass-through mode first. You'll create your topologies as necessary to consume traffic, but then send it directly to egress. Get traffic moving. Get comfortable with the device in path. Then, as described earlier, carve out some of that traffic to decrypt and service chain. Again, I've seen companies carve up IP subnets, specific URL categories, and ports. However you do it, introduce a section of traffic at a time. In doing this, you're not just testing the device, you're also getting a chance to better understand your network and what your users are doing. It's far better to find that one wonky application in this phase than it is at 6am from frantic help desk calls. Resist the pressure-induced urges to pull cables when something doesn't work. Just reset to a pass-through mode.

Of course, I am by no means saying this is how you have to deploy SSL Orchestrator. You can slide it into the rack, cable it up and turn it on. But it's a good idea to deploy in increments, and something F5 makes extremely easy to do. And frankly, there are few network and security devices this flexible. With dynamic service chaining freeing you from the brittleness and complexity of the daisy chain security stack, and a solid best practice in deploying the SSL Orchestrator itself, you hopefully recognize the immense flexibility at your command.