Podcast: What Is Virtual Patching and How Can It Enhance Security
Virtual patching is a way of implementing a security policy to eliminate or mitigate a vulnerability. It is not actually patching, but is a way to do something quick and external to the application. Why not just use a patch? Sometimes there is no patch available and other times speed is of the essence. And, patches sometimes introduce risk that something will break. Atomicorp CEO Mike Shinn developed some of the earliest virtual patches and explains what they are and why they are gaining in popularity.
Atomicorp provides unified workload security for cloud, data center or hybrid platforms. Built on OSSEC, the World’s Leading Open Source Server Protection Platform. See our products.
Podcast Transcription: What Is Virtual Patching and How Can It Enhance Security
Bret Kinsella: [00:00:00] This is the Linux Security Podcast Episode 11. Today we talk virtual patching what it is and why it’s beneficial.
Bret Kinsella: [00:00:17] Welcome back to the Linux Security Podcast. I’m Bret Kinsella. I’m here again today this week with Michael Shinn. CEO of Atomicorp and longtime luminary in the Linux and Linux security space. Today we are going to be talking about virtual patching. Mike welcome back. Why don’t you tell us what virtual patching is?
Mike Shinn: [00:00:39] So virtual patching is a way of… in technical terms… implementing basically a security policy to mitigate or eliminate a vulnerability. It’s not actually patching. So hence the name virtual. It’s a way of doing something very quickly external typically to the application to as I said mitigate or address the vulnerability that exist in that application.
Bret Kinsella: [00:01:06] OK so maybe we should start with what’s patching.
Mike Shinn: [00:01:08] Right. So patching is fixing something that doesn’t work right. Typically in a piece of software you can even be in a piece of hardware if the hardware is programmable. So this is what we’re typically all used to and update comes out for our phones we install the update or maybe there’s updates for you know our our laptops or workstations if you to Microsoft yes or if you play video games you know maybe maybe an update for your your favorite video game you know that adds perhaps new functionality or addresses bugs in it.
Bret Kinsella: [00:01:41] Ok. So that’s what patching is. So then virtual patching is a way to patch but not to patch.
Mike Shinn: [00:01:50] That’s basically it in a nutshell. So it’s a way to achieve the same thing without actually making any change to the software itself.
Bret Kinsella: [00:01:58] So why would you want to do that?
Mike Shinn: [00:01:59] Well that’s a good question. There’s really two things that drive that speed and risk. Speed is really the security guys. They’re the ones that care more about speed in this regard. Typically if you’re fixing something that’s maybe a purely functionality issue. You know business logic or something is nothing to do with security. Typically people patch the actual software itself but when it’s a security issue Time is of the essence. Bad guys typically find out about these things certainly at the same time the good guys do sometimes they know about it before. And so virtual patching is a way of addressing this security vulnerability faster maybe there isn’t a patch available. The other reason that people virtual patches risk. So anytime you make a change to something there is a potential risk that it won’t work correctly. We’ve probably all experienced this maybe in updates come out for phone or some some device that we have and it doesn’t work correctly maybe it makes it slower or maybe it breaks something maybe it causes it to crash. So patching is not without its risks. And the more complex a system is the bigger the risks are when you start patching things. And if the patches are to something that is is fundamental… we’ll say… like maybe you’re patching a programming language or you’re changing a programming language the applications that use that may not work anymore. So patching isn’t always something that we can do in patching is also risky for the vendor. If a vendor makes a mistake in a patch they can reasonably upset their customers and potentially damage their business.
Bret Kinsella: [00:03:42] Let’s talk a patching or using virtual patching in situations where there is no patch. So we see this as more and more with legacy systems something that was built in the 90s or even even ten, twelve years ago no longer supported by the vendor. It’s an operational capability for the enterprise might directly impact or scatter system or their GL or something like that and they can’t afford for it to go down.
Mike Shinn: [00:04:09] Yeah. That’s that’s a great example where virtual patching isn’t a nice thing to have. It’s the only thing that you have if you’ve got what’s sometimes referred to as legacy systems or end of support systems or and the life systems. You’re right. There may be no patching available at all the vendor may no longer support the product. The product might have been built in-house and maybe there isn’t anybody around that can… you know… fix it anymore or maybe this thing is just too sensitive or customized or or delicate for… for you to risk making some significant change to it. Maybe an example of that would be in some critical infrastructure where you had some older computer that controlled maybe the safety systems in that facility and it works great. It’s never failed to stop an accident from occurring but it’s really complicated and it’s and it’s old and nobody wants to you know touch it. It might break. So virtual patching, in those cases oftentimes is the only option that you have to address a security issue or potentially a bug that you want to win.
Bret Kinsella: [00:05:22] Yeah. So in those cases the the enterprise has this option. They can try to fix it themselves…there’s no patch let’s say… or there might be a patch but if they’re worried about because it’s heavily customized what it might do to the regression testing nightmare that might be before them so they can either try to fix it, they can just roll the dice and hope no one discovers that they have this vulnerability or they can wholesale replace the system.
Mike Shinn: [00:05:50] That’s right. That’s right. And one of the problems in the security industry is we have a tendency to assume that the risks that we’re trying to mitigate are automatically greater than the risks associated with the cure. And we oftentimes aren’t really in a position to know that. Right. And particularly in a large organization if you’re in the security group it’s unlikely that you are in a position to understand directly the risks that are associated maybe with maintaining this platform or application or whatever it is. So you may look at this and say well it’s really simple you just need to install this patch. It’s not that simple. As you said it could be that maybe the platform is just that sensitive but there’s also a rational reason why people do this sometimes. Security vulnerabilities are always hypothetical until proven otherwise. Right. That is to say whether or not someone’s going to hack you isn’t something that you can definitively say until it occurs. Right? We in this industry can say what the likelihood is that you’re going to get hacked by pointing at other examples and saying well they got hacked and you have the same vulnerability such probably could happen to you too.
Mike Shinn: [00:07:09] And that may be true but it’s much easier to ascertain the risk associated with making a change to a system because oftentimes the people that you’re asking to do it have tremendous amounts of experience making changes to these systems they know from experience what the risks are. Well if I make this change this could happen. This is the impact versus the hypothetical impact of a security event which in their mind may… this system may have never been penetrated or at least they don’t know that. Maybe it has been penetrated but there hasn’t been any impact that affects them.
Bret Kinsella: [00:07:45] Right.
Mike Shinn: [00:07:46] So virtual patching is one of these great win wins where we can balance those two things that typically oppose each other. That is the risk of making a change to a system in the risk of not making a change to the system. And we can actually make those two things the same thing and make everybody happy by addressing the security vulnerability and actually not changing the system. So everybody wins.
Bret Kinsella: [00:08:11] Ok. So how does it actually work. I mean are you writing rules who don’t allow certain things to happen?
Mike Shinn: [00:08:16] Well that’s the simplest way. Yeah I’m I’m kind of embarrassed to say that. Oh gosh more than a decade ago in a in a phone call with a colleague I was just kind of we were trying to come up with a way to describe this. And I just blurted out there are positive rules and negative rules because I would I really couldn’t think of a better way to describe it. You know we weren’t trying to come up with a marketing document. We were just describing it as engineers. And that’s that vernacular has kind of taken off. So negative rules are defining something that’s bad. That’s the most common type of virtual patch that there is. It is very easy to create. It is relatively low risk.
Mike Shinn: [00:09:00] If you can define what’s bad for example a sequel injection attack rate maybe there is a field and a web application address and you can say well address should never have many characters in it. Right. And address is just numbers and letters and that’s it. It’s very easy to write a… you know… a negative rule. A positive rule would be to say this is the known good thing that should be here. In other words it’s an address. It should only have the letters A through Z and 0 through 9 in it that’s all that it should have.
Mike Shinn: [00:09:37] That can be a problem though because well what if you know somebody needs to use an apostrophe. Right. Oh we forgot to add that. Well what if they happen to live on a street that is in… you know… a foreign country that happens to use letters that aren’t in the English alphabet you know.
Bret Kinsella: [00:09:55] Or just the number sign for an apartment.
Mike Shinn: [00:09:56] Right. Right. Exactly. You need to have a pound sign in there or whatever the case may be right. Exactly. So it’s harder to write positive rules but you can do that if you know it.
Mike Shinn: [00:10:08] But in either case are relatively easy to do compared to the potential risk of making a change to a system. The other advantage of doing things that way is you can decouple the security function from the operations function. That is to say the security organization can be responsible for creating and maintaining the virtual patches. And because the technologies are oftentimes applied external to the application it’s even easier to sort of separate these two. So it’s pretty easy to do. There are open source technologies out there. The most common place where virtual patches are used is with WAFs because lots of things are web based these days and there are free and open source WAF frameworks that make it very easy for you to create a virtual patch.
Bret Kinsella: [00:10:55] Ok. And essentially I think Gartner is clued into the idea that this is… it’s a little different than patching because what you’re doing is you’re shielding. You’re not actually making a change to the system. You’re shielding the system from potential vulnerabilities so I think you’re just at a conference where they’re talking about this.
Mike Shinn: [00:11:15] Yeah, I think it was last week or maybe the week before. There was a term that I had heard there called vulnerability shielding which is I think an equally good way to describe what this technology is. The idea that you’re going to put some active measure in place that shields a particular vulnerability from being exploited which is basically what virtual patching is trying to do. I personally like the phrase virtual patching because I think it it it helps to talk about the dual positive use of this technology. But virtual shielding is also an equally good way to describe what this is because it’s basically what you’re doing. The vulnerability still exists but you’re doing something to shield whatever this thing is from being exploited or in some cases a virtual patch may be applied after the fact. That is to say the vulnerability has been exploited and the application does something and the virtual patches job is to disrupt that. An example of that might be if an application generates output that is sensitive. So a really cool virtual patch would be one where you would look for maybe PII or privacy related GDP data or…you know… sensitive classified whatever and you see that in the output of the application and then you can do things you could you could even redact the content. Maybe this application returns everything and the virtual patch sees that there’s a credit card number there in it. It put the asterix in and it only lets you see the last four automatically. Those are really cool technologies because they’re… they have a prophylactic value to them because you can you can plan for the worst case using these technologies so that they it’s not a bad way to describe it. Calling it virtual or a vulnerability shielding.
Bret Kinsella: [00:13:14] Mike Shinn, thank you very much for giving us the lowdown on virtual patching.
Mike Shinn: [00:13:18] Thank you.
Atomicorp provides unified workload security for cloud, data center or hybrid platforms. Built on OSSEC, the World’s Leading Open Source Server Protection Platform. See our products.