default-focus-right

Your load balancer, the hidden key for improved security posture

Episode Overview

Security is critical to a positive application experience for organizations of all sizes and has increasingly become a major consideration in recent years. Nearly 3 quarters of all businesses experience phishing and social engineering exploits and 2019 saw the most ransomware attacks ever. This makes cybersecurity top of mind for IT leaders and has resulted in a cybersecurity spend forecast of $133.7B USD by 2022. To improve their security posture, technology teams are augmenting their approach to application deployment and optimizing their environments by leveraging existing infrastructure in new ways. In this episode, we’ll discuss how application load balancers, which are already deployed in 99% of environments, can leveraged to play a key role across 3 areas of overall security architecture

Jason Dover photo
JASON DOVER

VP, Product Strategy, Kemp

@jaysdover

July 29, 2021

Jason Dover:
Hello, I'm Jason Dover, Vice President of Product Strategy at Kemp Technologies. Security has become even more critical in recent times for organizations of all sizes. It's noted that nearly three-quarters of all businesses experience phishing and social engineering exploits. 2019 saw the most ransomware attacks ever, and this has led to cybersecurity being top of mind for IT leaders looking at cybersecurity spend. The forecast for 2022 is just under $134 billion. That's billion with a B.
In order to improve security posture, tech teams are working on augmenting their approach to application deployment and optimizing their environments by leveraging existing infrastructure in new ways. In this chat with my colleagues and friends, Derek Kylie and Ian Kenny, we're going to discuss how application load balancers, which are already deployed in 99% of environments can be leveraged to play a key role across a number of areas of overall security architecture. The areas we're going to dive into are, authentication access, application layer security, as well as micro segmentation and [Proact 00:01:16] deployment.
Ian and Derek, do you guys want to introduce yourself?

Ian Kenny:
Thanks, Jason, appreciate the chance to be here. So my name is Ian Kenny. I'm VP of Product Management here at Kemp, and I definitely spend my days worrying or being concerned about the ever-changing security market.

Derek Kiely:
My name is Derek Kiely. I'm the Vice President of Engineering here at Kemp. Also delighted to be part of this conversation and looking forward to the discussion.

Jason Dover:
Same here. Same here. So I think just level-setting would be a good starting point. Why is a load balancer a relevant place for consolidating security functions in the first place? Historically, you think about load balancers for, well, doing what their name implies. I have servers, they get to their capacity and I need a smart device traffic cop as it's been referred to, to help distribute of that traffic to other places. And that's what's imprinted in people's minds when we think about a load balancer. And why today, in 2020, is it relevant for considering it for security functions as well?

Ian Kenny:
I think for me, and really what we see from our customers is that they're using load balancers to publish applications. It's all about the application. That's a Kemp message as well as an industry message. It's really all around the application. So if I have a new application or an existing application that I want to publish, either for my own workforce or potentially for external customers, then really, those applications must be protected. And each application often has unique security requirements. So as I say, it could be all internal people accessing an application. So therefore, I've got possibly VPNs and other types of technologies. Or, it could be open to the world. It could be an application or a site, which is being much more broadly shared and therefore there are different types of requirements.
So therefore, if I take my load balancer, which is already sitting usually very close to the edge of the network, or possibly even all the way out at the edge of the network, I've got really a good place to be able to get those connections from the customers or internal people, make sure they are secured before that data is sent on to the real servers, as we would call them, or the application servers usually inside the network itself. So you actually have that level of confidence about security before those packets get damaged in some way or basically some kind of rogue actor trying to hack into your environment. So I think really that, the idea of having these load balancers perfectly placed right at the edge of the network as an embedded appliance. Each application has got a different configuration and you're able to then be able to manage that effectively as a security device, as part of your strategy,

Derek Kiely:
Just to reemphasize some of what Ian has said as well. We always talk about the ADC having a privileged position in the network. We sit right in front of the applications. We have to have application awareness. We have to be able to decrypt traffic going to the applications in order to make the right decisions. The fact that we are already decrypting this and doing it in a secure manner, makes us the perfect point. Things around authentication, access restrictions, or access management around that and having the application awareness and applying security principles at that layer is critical.

Jason Dover:
Just a quick question to give us some more context. If I were not actually doing decryption at the load balancer, what would the consequences be of that? Or, put a different way, what's the difference in traffic flow to the backend server when I'm not doing decryption of traffic at the load balancer?

Derek Kiely:
Primarily, when you don't decrypt traffic at the load balancer, you miss out on some critical capabilities that your load balancer can offer. A load balancer will obviously just pass SSL encrypted traffic to your backend. There isn't any application awareness. There isn't the ability to do more events, traffic routing using content matching or content switching technologies, there are caching and compression for application optimization capabilities that aren't there. And fundamentally, I think this is why ADCs are optimized to terminate SSL. In a lot of cases also re-encrypting SSL back to the back end that further enhances security of your application.
So all in all, I think the ADC, given the role they already play from SSL offloading and the encryption perspective, is perfectly placed. If you don't offload, well, you're ADC is quite limited. It doesn't have all of the additional capabilities and you don't get the advantages and your users don't get the appropriate application experience.

Ian Kenny:
I think you're right there, Derek. I think you're absolutely right. The key thing with the decryption is also that you're putting the responsibility for that description on the real servers at the back. You're effectively letting any "attacks" get very close to the actual application servers themselves. And they're doing one job, which is serving potentially complex application for a range of users. And if you can effectively allow the load balancers sitting in front of that application to effectively be that barrier to keep those real servers protected, the users themselves, as well as the administrators are going to see a tremendous amount of value there, allowing the application servers to offer that bright part of the story, so to speak.

Jason Dover:
Makes a lot of sense. You've got the defense in depth. You've got proximity to the application. By doing the decryption, you can see a lot more and make decisions that helps keep the environment secure. I think that's a really good level set and gives us some good context for the rest of the discussion.
Slightly shifting gears, authentication access, which you briefly mentioned, we've definitely seen recently a trend towards every load balancer vendor having some sort of module, which basically is about single sign-on, tie into third-party and multifactor authentication services, SAML, et cetera. Why is that? Why have we seen such a trend towards authentication and pre-authentication services being consolidated at the load balancer level as well?

Ian Kenny:
I think often it's actually an extension of the same reason we just spoke about when it came to decrypting that we say the underlying packets. It's the idea that I'm going to take that security, I'm going to move it away from really the application servers to allow you to have that proper layering and what that offers the end users, they have confidence or certainly it'd be the administrator, I should say, that the end users are authenticating at the load balance, to allow them to say, "Nope, you are not allowed in here. You haven't provided the right certificate." If it's a certificate based system, or if it's literally a username and password or depending on their configuration options. And they can actually feel confident that when the data really gets to the back, not only do you have that decryption confidence and that level of security, but you also know that, Ian Kenny, in the case of me, is able to access that application directly. And I have provided the credentials for doing that.

Derek Kiely:
Just echo what Ian [inaudible 00:08:54] said already, I think there's benefits in it from a user experience perspective. Historically, the apps would have needed to be able to deal with ensuring your users would remain authenticated if they were to transition from one application server to another application server, offloading that and having your ADC not only provide the additional layer of security, but also manage the fail over of authentication to each of the backend servers is also an added bonus and another reason why we're seeing it in the majority of ADC vendors.

Jason Dover:
Makes sense. The load balancer has a lot of untapped potential from the sounds of it. So, here's a question. Obviously, the load balancer only plays one component within your overarching identity access management strategy. It's a really important part, obviously, because it's protecting the apps. It's validating access, as was mentioned, that Ian actually has access to this app before allowing him doing challenges, et cetera. But it can't do everything. What does an overarching authentication access infrastructure look like that a load balancer would have to interact with? Or put another way, if you were advising a customer as they were evaluating leveraging a load balancer for this role, what should they be looking for support of? What should that load balancer be able to interact with for it to actually be successful inside of their environment?

Ian Kenny:
I think we're seeing a lot more access using maybe other technologies. And obviously, we have things like SAML as another choice. It's not just about the username and password anymore. There's usually other aspects to the security infrastructure, possibly going across different applications and things like that to allow it to support, not just, shall we say, the username and password, but the addition of certificates, the additional connections into a SAML, a bigger SAML infrastructure as part of your application authentication approach is probably a good way to recommend customers to go.

Jason Dover:
And Derek, I remember we were chatting not so long ago about a fairly large customer that had a fairly complex infrastructure when it came to authentication requirements and such. Do you want to just recap what that use case was about just to give the listeners a picture of what a real infrastructure might look like?

Derek Kiely:
Sure. We had a customer approach us with very particular authentication requirements from a performance perspective. They had a minimum set of requirements supporting 60,000 authentication requests per second. They required the front end authentication to be a SAML and the backend application authentication to be Kerberos Constrained Delegation, or to add another acronym, KCD. And obviously, quite a large scale deployment there. We're using ADFS as the authentication IDP side of things. We acted as the service provider in the past true to the application. And it was a very interesting project, having 60,000 authentication requests per second. Just a second point to comment. I think a lot of what we're seeing nowadays is the majority of authentication end points, support things like LDAP and RADIUS, [inaudible 00:12:13] active directory, obviously you have those protocols as well. All things what I would expect to be there from an authentication and access perspective when I'm trying to get to my app.

Jason Dover:
Certainly, suddenly, there's a lot of moving parts. It's taking us slightly step further. So we obviously have the piece of being able to validate that a client has access, inter-operate with the rest of the infrastructure are all very important. Is there anything else that the load balancer can do with that information? Because obviously the load balancer is making decisions on getting traffic from point A to point B. If I've got the context of who's trying to get into the infrastructure. Since I'm an IP device, I can actually see where the person is coming from, can I use that as an example to make intelligent decisions downstream?

Ian Kenny:
I think it's a natural that the load balancer can leverage all with the different layers in the network stack to be able to make better decisions, all the way from [inaudible 00:13:16] services, which oversee our Kemp load balancers offer in terms of load master all the way up to the application that we've been speaking about with authentication and everything in between. You mentioned the idea of location-based services. Obviously, it's not really in that traditional security line, but obviously if you take something effectively like a geo type load balancing perspective, so therefore if I'm seeing traffic coming from the "wrong place", whatever the wrong place means to you and your organization that you're able to effectively block that. So you don't even get to the application in the first place. There's a lot of these kind of layering approaches, which are helpful for administrators to really be able to solve a lot of security concerns that they and their organizations have.

Derek Kiely:
Jason, your question actually reminded me of another use case, which we had, was about making decisions and traffic steering decisions, but also access decisions based on an active directory group membership. And so, as Ian mentioned, you can look at all the different layers, right from a DNS layer and identifying who's coming from what location right down to whether that person should even be trying to attempt to access that application. Lots of different layers, again, in terms of the ability to decide what's the right thing from a security perspective, what's the right level of access people should get to their applications.

Jason Dover:
Good points. You guys both referred to applications a number of times. I think I may have counted seven or eight times that the two of you used that application. When we think about security, we hear sometimes a differentiation. A network layer security versus application layer security. I remember reading just not that long ago about the fact that the majority of attacks and exploits that we see today are at the application layer. And of course, we're all familiar with the historical OSI model and you go up, please don't order sausage pizza or whatever the case may have been. But when you're talking about modern security, what is the real differentiation between securing your infrastructure at the network layer versus doing that at the web application tier? And how is that relevant to the load balancer technology of a web application firewall?

Ian Kenny:
Wow, that's a great question, Jason. I think the key thing from my side in terms of why I get excited about the application layer generally, is that that's the bit that people are actually interested in. And you have a lot of people who are trying to do bad things, shall we say, to your application. Either maybe take it down, denial of service, all kinds of things that they're trying to do to it. And if we're able to really catch those connections right at the top, then I think that that is really a good place to protect your network. But also, I think the other piece that's so vital is helping customers see what is actually going on with these attacks. The idea of there is an attack or there isn't an attack on your application isn't really the question anymore. It's really how many attacks are you getting? It's effectively a much more bleak picture that we could paint for people who are trying to deploy a new application tomorrow, so to speak. And really, what we see now are people trying to actively mitigate against attacks, which are going to happen on their infrastructure. Well, we see this in massive corporations with data leakage, things being stolen, ports being left open on servers, allowing people to get in there.
Things like that, we really attempt or trying to take, as I said before, this idea of all looking at all layers. So yes, the network stuff is the way you used to do it in the past, ACL's and other things which are still part of a story. But as the packet transfer goes up the IP stack and gets to the application layer, having ways to look at those packets, you're looking for cross site scripting, you're looking for other kinds of hacking. We can actually help customers block those right at the top. Because, as I say, it's not about whether you're going to be attacked or whether you're not going to be attacked, it's about how many times you're going to be attacked and what you're doing to mitigate against that, as well as the visualization of those things so you really see what's going on in your application at a live level.

Jason Dover:
We talked about attacks and so forth a lot, but there's also the challenge of vulnerabilities. And in recent times, we've seen publicized much, much more, a series of weird named vulnerabilities and common web application stacks such Heartbleed and POODLE, and most recently, Ghostcat. Given the position that the load balancer has, its proximity, its ability to decrypt and unpack the traffic and really understand what's going on, can a load balancer with its capabilities and consolidated with [WAF 00:18:35] services be leveraged to help a customer bridge the gap when these vulnerabilities are found?

Derek Kiely:
Yes, absolutely. We've seen multiple instances of this over the last couple of weeks. Most recent being Ghostcat, very simple remediation from a ADC perspective, content matching rule to identify the requests and simple, simple blocking exercise to prevent traffic going through. Remediation is very, very easy from that perspective and also helps that your ADC understands the majority of these applications.

Ian Kenny:
That is a huge area, but I think also we have to look at the fact that the way load balancers are put together is really around security. It's not having ports open here or ports open there or adding in, shall we say, some of the extraneous utilities and things that you can often find running on applications. So we switch all of that off inside the operating system, allowing us to have that door even more closed than others might. And I think that's another facet really stands Kemp in good stead that we can not only do the simple remediation.

Jason Dover:
Shifting gears to our last topic. And Ian, I know this was the one you were most excited to talk about, that micro-segmentation, right? It's a term that's been coming up more recently. It seems that VMware really helped popularize it and make it more of a household term when they came out with their NSX framework. What is micro-segmentation actually all about and how does it apply to security?

Ian Kenny:
Where should we begin? Maybe we should have a separate vlog on this, but the idea really is to try and look at how you're imagining your application infrastructure. Some ADC vendors build these giant boxes, where you have all of the responsibility for the protecting of many, many applications possible working in that single device. Whereas really, the way the industry seems to be moving and certainly the way that we as an organization are moving, is really about trying to take that and slice it down.
Another term that people like to use is maybe a per app ADC model, things like that. So I effectively limit the end user. And there's a cool term and I don't remember who coined this phrase. It certainly wasn't me, but the idea of a blast radius. The idea that I have a load balancer, it's supporting this particular application and I have another, probably totally separate, load balancer handling another application. And should there be... Because as I said, it's not about if there'll be attacks, it's when attacks come. And maybe there's some problem, or maybe there is a vulnerability that gets found and the customer isn't able to patch it quickly enough and that ABC or load balancer becomes compromised in some way.
The point is that it's not impacting any of the other applications that you're running this product through. And therefore, because you've got that separation, you have more confidence and more ability to control your infrastructure and your applications. Because it could be, if you are an application administrator or maybe a network administrator, you're actually dealing with many, many different business units within your organization, who all have slightly different ways of working. And you sometimes can't control them, things like that. And you need to feel confident that these devices that you're providing to these different business units and groups are not going to impact other ones. And that's certainly how I see it, at least at a simple level, the idea of taking these load balancer alliances and distributing them across your organization, maybe through some kind of centralized control, obviously. But each of these load balancers is responsible for that one application and is then able to service that best for the needs of that particular business unit.

Jason Dover:
It's really about getting to fine levels of granularity.

Ian Kenny:
Yes, exactly.

Jason Dover:
It's how you're going to control security. I've always loved that term blast radius too. Another term that comes to mind when I think about micro-segmentation is that of zones, right? So if you look at some of the architectures that are out there, it's about building an infrastructure where I've got these super small, tiny zones, or as you call them, blast radius, right? So that when something goes wrong in this one part of the infrastructure, it doesn't start affecting the entire app ecosystem. Now, you mentioned a load balancer or capabilities of playing a role in helping you to carve those zones. How small of a zone is a load balancer capable of carving in your app ecosystem?

Ian Kenny:
Jason, the idea of small zones is fascinating. For me, it's really all the way down to really deploying a load balancer, which is running one, what we call a virtual service, kind of a published application. Now, obviously, you can have one virtual service and maybe sub-virtual services, things like that, obviously. But the idea of trying to get that very simple deployment architecture has got to be vital for any organization. And obviously, that sometimes doesn't seem terribly practical with many budgetary concerns and things like that.
But, obviously with Kemp, we've sought to roll out basically a metered licensing model. So I can deploy a load balancer. They're always running one virtual service. Maybe that's a very busy virtual service. Maybe it's not a very busy virtual service. It doesn't really matter. But the idea is that I can basically just pay for what I need, what I use. And that I think is going to be very compelling or has been very compelling for a lot of our customers that have many applications to deploy but want to leverage this concept of the small zone, the minimizing of our favorite subject of today's podcast, the blast radius.

Jason Dover:
We've covered quite a lot today. One thing that becomes blindingly obvious for me is the fact that the load balancer can do a lot more than you might think of initially. When you think about it really, a load balancer plays a lot of the roles of a basic firewall. While you don't typically think about it that way, the fact that it terminates traffic, it doesn't allow flows to get through by default, it does decryption. It can do authentication, it can do all these things. It really does play the function of a basic firewall and should be considered as a part of a customer's overall security posture. If you were able to just leave the listeners with one thought, what would that be, Ian?

Ian Kenny:
Wow. One thought. I think the simple summary is that the load balancer offers you more than you thought it did. I think that's really the thing I'd like to leave the audience with today. And I certainly look forward to recording more of these to help customers learn more about what we can do to help them deliver applications for their customers.

Derek Kiely:
From my perspective, not only is the ADC perfectly placed to ensure that your apps are highly available, optimized, performant, but it's also perfectly placed to secure your apps.

Jason Dover:
I really enjoyed discussing this topic with you guys today and looking forward to the next time we get together. Have a great day.

Ian Kenny:
Thanks, Jase.

Derek Kiely:
Thank you.

texture

Lernen Sie Progress Kemp noch heute kennen

Kemp LoadMaster kostenlos testen

Einfache Bereitstellung und Konfiguration mit Zugriff auf Konfigurationsvorlagen und Bereitstellungsanleitungen für eine schnelle Inbetriebnahme.

Kostenlose Testversion starten

Lassen Sie uns reden

Haben Sie Fragen oder wollen ein Produkt von Progress Kemp kaufen? Sprechen Sie mit einem Experten: Wir beraten Sie individuell und finden eine optimale Lösung.

Vertrieb kontaktieren