Security Vulnerability are a fact of modern-day digital-life, which can (and eventually will) strike any brand, vendor or appliance at any moment in time. This is inevitable in the digital pioneering world we live in, always pushing the envelope and trying to beat the competition in speed and features. When you accept the fact we all make mistakes (either in programming, configuring or life in general) and thus a (completely) bulletproof IT platform does not exist, other topics become important.
Lets compare IT platforms to human life for a minute, who survives the harsher times in life? Is it the men or women who is strongest? fastest? smartest? Charles Darwin states the following:
So in the end its the person who is able to adopt and deal to their new really quickest. Then how would this analogy play out for a Application Delivery Controllers (ADC) or Advanced Load-Balancers (ALB)? We would need a architecture that is flexible, adaptable, elastic, self-healing, fast to patch, easy to update and free of proprietary specialized hardware.
In my opinion the following topics will take us to the a new generation of Application Delivery Controllers or Advanced Load-Balancers:
Decouple Data-plane from the Control-plane
The current or previous generation of Load-Balancers combine the Control- and Data-Plane into one appliance, often running both of these planes in the same OS or kernel-space. When a security vulnerability is discovered in the Data or User-traffic plane(the one handling the web-traffic), the small layer of separation between the two planes could be compromised. Now the “evil” (web)users are able to access the Control or Management plane of the appliance and things start to get hairy really fast! The appliance that we trust and use as a extra security measure to connect the outside world to my internal application-servers could now become a proxy not just to my application but possibly my entire network! (Impact depending on network segmentation boundaries). And if the appliance is used to off-load SSL connections (most company’s do), the copy of the private decryption key which is stored in the appliance, could now be compromised! (specially nice if you are one of those leazy *.wildcard certificate users, yes … you will have to replace the certificate everywhere you’ve used it …).
By decoupling the Data-Plane from the Control-Plane we end up with separate “appliances”, this will make sure user/web-traffic will only pass though the Data-Plane appliance or “Service-Engine”. Isolating the user-traffic completely from the Control-Plane or Management/Orchestration components.
The Orchestration (or Control) part of the solution (being its own entity) can now be placed in a different network or management domain, completely protected though network segmenting, firewalls and/or IPS systems, which greatly improves security by true plane and user separation.
Central orchestration makes for replaceable user/web-traffic appliances
Having central orchestration gives us the opportunity to control multiple “Service-Engies” making the solution scale by providing elastic capacity when needed, or simply manage different environments, locations, OTAP’s and/or multiple tenants through a single pane of glass.
The central orchestration monitors, health-checks and controls all of the deployed Service-Engines holding a blue-print configuration of each Service-Engine (group). In it’s self that’s nice from a administrative point of view, but also gives us the possibility to just throw out and replace a Service-Engine in a matter of minutes by replacing a compromised or bogus Service-Engine with a shiny new one and then off-loading its workload and traffic to this new Service-Engine.
Decouple from (proprietary) specialized hardware
What if you’re ADC/ALB didn’t need proprietary hardware or dedicated ASIC’s to preform at high-speeds anymore? And you could run it in ANY environment in ANY format: VM, Container or on Bare-Metal? Provisioned on just plane off-the-shelve x86 Hardware?! Meet DPDK or The Data Plane Development Kit:
By providing the application direct access to the underling hardware and by-passing the kernel and driver stack completely, software can now work at hardware speeds:
What is required is a DPDK enabled Physical Network Interface Card or NIC. Supported hardware can be found HERE
Being decoupled from hardware gives tonnes of advantages, imagine being able to run and load-balance your applications cross cloud, datacenters and/or platforms. Now if and when a certain devices has a security flaw in firmware or you’re cloud is under major cyber-attack, we just move the applications to different x86 environment or hardware/compute vendor.
Divide and Conquer, Micro-Services and Auto-Scaling
By running in software, having complete plane separation and having central orchestration we are able to decentralize the Data-Plane or Service-Engines, enabling us to configure Micro-Services. Imagine a Service-Engine group per Application, allowing us to limit impact of a security related event to just one application!
Load-Balancing in the Container and Service-Mesh world is going to be an important feature in the not so distant future. Ingress container Load-Balancing is already wide spread, but advanced features like WAF (Web Application Firewalling) are usually not included, a true next generation of ADC/ALB should also be able to provide this features. The truth of the matter is, we are at the doorstep of the next generation of applications and it will require a different type of Application Delivery Controller :
By running in software with centralized orchestration, it’s possible to scale Vertically (by adding more resources to individual Service-Engines) or horizontally (By adding more Service-Engines to a LB Group and spreading the load across). This results in predictable linear scaling capacity, able to scale out as long as x86 power is available.
Linear scaling is just awesome, increasing your traffic and processing capabilities with the press of a button (or API call). A new Service-Engine is deployed and load is being disturbed accordingly. But the Orchestration is monitoring the load and the overall bigger picture, so why not fully automate the scaling? Auto scale up when needed and scale down when possible to conserve resources. You’ll never now, maybe this absurd scaling could just out-scale a DDOS attack, as long as there are x86 resources available to scale to.
Lighting fast software upgrades and patches
Lets say Darwin strikes again and a new security vulnerability is found, a new patch or software update is released (preferably before the vulnerability hits the world-press). We just roll-over the new software version (without rebooting and nightly changes) Just spin up a new version of the patched or updated Service-Engine and offload the connections. Then just throw away the old vulnerable one! The process actually works the same as Auto-Scaling but just with a new software version.
Combine all this with a zero-trust platform a.k.a. implement Micro-Segmentation/Services, have IDS/IPS everywhere, Record the know good sate of you’re applications so we can identify and alert/kill the bad! Don’t just stack security on top of you’re IT platform but intrinsically embed security in you platform making it part of you’re overall solution and not just a “bolt on”.
To busy fighting fires?
No doubt at this very moment a lot of admins are quite busy on patching their previous generation ADC/ALB boxes, Albert Einstein also had something to say about doing the same thing over and over again:
Of-course we could keep on running fighting fires, patching an updating all of these individual boxes, but will it really change things in the long run? It’s time to change you’re ADC/ALB Security-Architecture today, because you wont be able to keep this up tomorrow!
Meet AVI Networks or the NSX Advanced Load-Balancer by VMware:
It’s clear to see Albert and Darwin are both:
Also want to become a AVI BADaaS? VMware has got you covert, check out the HOL (Hands-on-Labs) on AVI Networks / NSX ALB:
HOL-2037-01-NET - VMware NSX Advanced Load Balancer (Avi Networks) - Getting Started HOL-2037-02-NET - VMware NSX Advanced Load Balancer (Avi Networks) - Global Server Load Balancing HOL-2037-91-NET - VMware NSX Advanced Load Balancer (Avi Networks) Lightning Lab
* Some of the pictures and diagrams are courtesy of VMware, blogs, opinions and stories on this website are my own!