For years, patch management has been treated as a solved problem—until reality strikes. Outdated applications, portable executables, patch conflicts, and shadow software leave organizations unknowingly exposed. The tools may exist, but the process often breaks down.
In this episode, Rob Allen, chief product officer at ThreatLocker, discusses why their new patch management solution goes beyond legacy approaches. With built-in patch packaging, pre-deployment testing, and granular control, the platform helps teams navigate complex environments while keeping rollback, risk tolerance, and deny-by-default strategies in play. Joining him are Mike Woods, vp of cybersecurity at GE Vernova, and Steve Zalewski, co-host of Defense in Depth.
Got feedback? Join the conversation on LinkedIn.
Huge thanks to our sponsor, ThreatLocker
Full Transcript
[Voiceover] Connecting security solutions with security leaders. Security You Should Know starts now.
[Rich Stroffolino] Welcome to Security You Should Know. Today, we’re talking with ThreatLocker and what they’re doing in patch management. The problem that they’re addressing is, we don’t have a lot of answers for patch management. Some people think we have it completely solved. Some people think it’s this endlessly manual process.
We need to get to answer some of these questions, so we’re turning to two spectacular panelists. We have Mike Woods, VP of Cybersecurity at GE Vernova, and Steve Zalewski, the co-host of Defense in Depth. Mike, I’m going to start with you. Why are we still struggling with patch management?
[Mike Woods] Yeah, it’s a good question. I think a lot of it’s been solved, but we go back to a lot of difficulty around older technologies or more complex technologies. We’ve got ERPs. We’ve got other things maybe. We even have some systems that are hybrid between cloud and on-prem, and when you work with application teams and system owners, often there’s a hesitancy to push these things out into production without going through a number of layers.
And then there’s a push and a pull here from a cyber perspective. That’s what I really care about, reducing the risk. And your scanners might not always be your patch solutions, so there’s still some work here to be done, I think.
[Rich Stroffolino] And Steve, from your perspective, have we solved patch management? Are we still struggling with it? What’s happening?
[Steve Zalewski] We’ve solved patch management. We’ve solved it a long time ago, meaning we certainly have the technology in place, and it is no longer leading edge, it’s trailing edge, but I think what we’re acknowledging is the process of implementing patch management doesn’t work. We have lots of edge cases and special cases that preclude us from effectively implementing patch management, and I think that’s what we want to talk about today.
[Rich Stroffolino] Yeah, I am excited to dig into this because we’re going to be talking with Rob Allen, Chief Product Officer over at ThreatLocker, about their patch management solution. So, Rob, we’re going to start at answering the three essential questions, the questions we ask each Security You Should Know.
How do I explain the value of your solution to my CEO? What does your solution do and what does it not do? And what is the pricing model? Can you give us these preliminaries?
[Rob Allen] How would you explain the value? I mean, I can give you an example of how you might explain the value. We thought patch management was a solved problem for us. We run a patch management solution within our own environment, and we thought we were up to date. We also run a very tight ship in terms of what software is allowed to run.
We don’t have all manner of things. Again, allow listing is going to stop most things that people try to run from being able to run. So, we don’t have a bunch of software, but when we actually used our own patch management, we discovered over 400 devices running out-of-date software, 20 different packages, basically 20 different pieces of software that were out of date.
And the reason we saw it and the other patch management solution didn’t is because it was looking for registry keys. It was looking for add/remove programs, that kind of stuff, to try and establish what version of software that’s running. So much software runs outside of that context. There’s portable applications.
People have got things sitting in their downloads folder and they just run it from there. None of that is visible to a traditional patch management system whereas all of that is visible to us because we log everything.
[Rich Stroffolino] All right, panelists, we’ve gotten a little taste of what ThreatLocker is doing with patch management, but I’m sure there’s a lot of question here. The devil is always in the details. Steve, I’m going to start with you. What other questions do you have for Rob and for ThreatLocker?
[Steve Zalewski] Yeah, so we’ve solved patch management, but I think when I talked about process, Rob, is just because it can be patched doesn’t mean it should be patched. So, can you talk to me about your learnings here, right? Which was, is this just a, “We’ll patch everything we see,” or do you have some intelligence and realize that you’re providing some additional value in how you’re managing kind of my patch edge?
[Rob Allen] Absolutely. I mean, look, you can be as granular as you want with this. You can say, “I want to update or automatically patch this piece of software across my entire environment.” You can say, “I want to do it for my entire environment, but not for this group of machines.” You can do it according to schedules.
You can patch Windows. Anything you want. You’ve got pretty much infinite granularity about what you want to do. So, I know that machine over there can’t run a new version of software. I’m just going to exclude that from my patching. Everything else will be patched, that won’t be. So, you can be extremely granular with what you want to patch and when.
[Rich Stroffolino] And Mike, I’m going to throw it to you. What questions do you have for Rob?
[Mike Woods] From a vulnerability management perspective, your scanners in the marketplace, how does this play with that? Because what we find is obviously when we execute our work, we’re doing vulnerability management, we’re looking for patch efficiency, right? How fast are we getting these things done?
We’re getting them done in 30 days, 60 days, 90 days, depending on what we’re looking at, right? The type of system or environment we’re in. How does this play into that and help us improve those KPIs and KRIs around vulnerability management?
[Rob Allen] So, again, I mean, it very much ties in with vulnerability management. I mean, it’s not something that we do, but I mean, presumably vulnerability management is going to say you’ve got these things out there. I mean, we similarly do see these things that are out there because again, anything that we run on, we have complete visibility of.
We can see every hash of every file that executes on every machine within an environment. We know what’s an up-to-date piece of software because the hashes matches our up-to-date applications. We know what’s an out-of-date piece of software because again, the hash matches the out-of-date software. So, it’s not just about scanning for vulnerabilities, it’s about knowing exactly everything that’s within your environment, what’s up to date and what isn’t up to date and then rectifying it.
[Steve Zalewski] Okay, but the big challenge, right, is if I’ve got 30 applications or 50 or 100, it’s always been update conflicts. How do I know that applying a patch to Adobe for my environment, given I have five other applications that integrate, don’t break? Do you do something about that for us?
[Rob Allen] That’s a really good question. It’s a really good question. Adobe is probably the worst example because of the amount of different things that they have.
[Laughter]
[Rob Allen] But again, as I said, it comes back to, you don’t necessarily have to patch everything everywhere immediately. You can be very specific, you can be granular, you can do it a machine at a time. So, I’ve got Creative Cloud and Acrobat running on this machine. I just wanted to patch Acrobat, I can just patch Acrobat.
I want to try Creative Cloud, I can do that. So, you can be very targeted with it until you’re satisfied that it’s going to work everywhere, and then you can roll it out everywhere if you want as well. I mean, it is pretty much as simple as you can do it as a click of a button per machine or a click of a button per organization.
[Mike Woods] That was a good answer. I like the response there, the granularity, but let me ask you a different question here because when you get into certain stacks like Linux, you can have multiple kernels out there. I think you understand this, right? So, how are you looking at those unused pieces of technology, right, that are sitting out there, our application owners and system owners are saying, “Hey, this is what my system is,” and it’s running X, but you’re finding Y and Z as well, right?
Are you patching those for us or is that not happening?
[Rob Allen] I mean, realistically, there’s a few different levels. Look, every environment has its eccentricities. I mean, in some cases it can be as simple as, look, this machine cannot be patched, it cannot be updated. What can I do about that? Well, I can protect the rest of my network from that machine, and it comes into network control, which is, look, I’m going to accept that this cannot be fixed for whatever reason.
So, let me just keep the rest of my network safe from that device should it get compromised. Again, application controls are going to take care of a lot of this as well. So, if certain things don’t need to be run, then why would you let them run? Just because we’ve seen something, just because we created a policy to allow application X to run on a machine, we can very quickly go through and remove unused policies, which will basically say, look, this software hasn’t been run in six months, therefore I’m going to remove the policy that allows that software to run.
So, it all sort of fits into the bigger picture of the platform. It’s not just about patching, it’s patching in the context of what’s needed, what’s not needed, what can run, what can’t run, etc.
[Steve Zalewski] So, I want to go back to update conflicts, right, what you did, it was a good answer. But you have a Cyber Hero team, right? What role do they play? Will they actually test, right, my environment, so to speak, and validate that there are no conflicts in real time for me, versus me having to go sit in a sandbox?
Like, you have such a huge, powerful concept with your Cyber Hero team. How does that work for me with patch management and conflicts?
[Rob Allen] Well, specifically in the context of patch management, what we do, so we’ve got an applications team. Now, their primary purpose is for cataloging applications. So, running software, gathering all the hashes, pushing it down to all the millions of machines that we manage so people don’t need to worry about software getting blocked unnecessarily.
But one of the other things that they do and specifically around patch management is they’re actually building the packages. They’re building the scripts. They’re building the patch definitions column. Now, as part of that, they are running the software. They’re running it in a testing environment, in a VDI where basically they can see how it behaves.
And this can also protect you against things like supply chain attacks. So, if there’s a malicious piece of software buried inside some other piece of software that isn’t otherwise seen, they’re running it in the testing environment. Before they make a patch package available, they will have run it, and they will have seen it has misbehaved.
And we have actually had situations like that when we’ve told other vendors about issues with their software. So, you do have that extra peace of mind as well to know that this has been run elsewhere before it actually gets to run on your machines.
[Mike Woods] Yeah, well, maybe I’ll lead on to this though, Rob. Can you walk me through, just give me what happens with your company and your customers when there’s a zero day?
[Rob Allen] Well, the beauty about what we do, the beauty about the approach that we take, which is to deny by default, you have to think – look, patching is important, patching is good. People should patch. I’m not going to say that they shouldn’t. I will always say that. But realistically, if something is vulnerable, if something vulnerable is exploited, what’s the next thing that will typically happen?
It’s normally something will run or it’s normally like, say, for example, a PowerShell will reach out to the internet and try and download a payload or whatever the case may be. So, by taking the default deny approach that we take, we don’t need to respond to individual zero days, to individual things that are going on.
The rest of the controls that we offer will keep you safe in the event of a vulnerable piece of software being exploitable and exploited.
[Steve Zalewski] So, I have to ask, can I do rollback on patches given the VDI and the testing and the deep knowledge you have of my environment? Could I actually roll back a patch with you?
[Rob Allen] Not yet, but soon.
[Steve Zalewski] Oh.
[Rob Allen] But soon. So, basically this is a new product. It was only announced a little, in fact, almost exactly a month ago. So, it’s a new area, it’s a new product for us. So, rollback is something that has been requested, and rollback is something that is planned for development, but it is not a thing yet.
[Steve Zalewski] I like that. I like the sound of that.
[Rob Allen] Yeah, no, as I said, it’s always being improved, as is everything that we do. Nothing is perfect, everything can be improved.
[Mike Woods] So, if you already have a couple of patch solutions out there, what would you say is the biggest differentiator for this product over some of the other solutions in the market?
[Rob Allen] It’s seeing things that aren’t seen by other solutions. It’s just it’s a depth of visibility that we have, everything that runs on machines, everything that is there, whether it be installed, not installed, portable application, run from downloads folder, anything. We see it all and we know if it is out of date, and we can advise you as such.
[Steve Zalewski] And then if you could wave the magic wand, right? Because we have a lot of these process issues, right? What would you add to your product at this point for patch management?
[Rob Allen] Rollback.
[Laughter]
[Rob Allen] Somebody came up with an idea and I thought it was absolutely awesome. So, yeah, the ability to roll a patch back. Look, it’s an excellent suggestion. As I said, it’s something that’s one of the first things that’s come up and it is genuine area that it can be improved. I mean, you like to think the patches are all perfect.
You like to think that they’re never going to cause problems, but unfortunately that isn’t the case. So, the ability to roll back is definitely something that we will add.
[Steve Zalewski] So, besides Adobe, right, you had said Adobe is problematic for patching because of it. What is the number two most problematic application from your perspective for patching?
[Rob Allen] Oh, that’s a good question. I mean, you’re probably asking the wrong person about specific applications, or which applications are specifically problematic. I mean, fundamentally we are building out, like we’ve got 8,000 applications that we have what we call built-ins for, which are those application definitions that we manage and maintain.
Some are big, some are small, some are complicated. There’s 17 different ways that Firefox can update, and we have to account for all of those 17 ways that it can update. So, our applications team would probably be better ones to say, “Well, these ones are problematic, these ones are difficult.” We’re rolling out new patchable programs at a rate of knots.
So, we’re basically adding about 10 new programs a week that we are able to patch. I don’t think, I mean, look, I didn’t say Adobe is problematic. I said potentially because of the complexity of it, it might be.
[Laughter]
[Rob Allen] But as far as I know, it hasn’t been problematic to date.
[Steve Zalewski] Let’s roll the tape again. Let’s roll the tape, I feel like.
[Laughter]
[Rob Allen] But yeah, again, assumptions, but I’m not aware of anything that has caused significant difficulty for them to create those patch packages and scripts.
[Steve Zalewski] Okay, just because I can patch it doesn’t mean I should. So, I was going to ask you with this, with your experience with patch management, right, given a hundred patches, how many are actually applied, right? You don’t want to make it a hundred. So, like, what are you doing to be able to also manage my vulnerabilities, right, by realizing which patches do need to be applied and leave the rest alone?
[Rob Allen] It kind of goes back to the answer of one of the previous questions, which is if you’d asked me six months ago about patch management, I would have said, look, patching is important. You should patch your things. Equally though, you should also assume that what you are using right now is full of holes.
Okay, so I’m talking to you on Chrome. Chrome is full of holes. It’s just a question of whether those holes are known about and actively being exploited. Likewise, Office. I mean, look at an average patch Tuesday. For Microsoft, for God’s sake, how many CVEs, how many serious vulnerabilities are fixed on an average patch Tuesday?
It’s terrifying. But what I would have said to you then was, look, assume your software is full of holes. Assume it is just a question of time until those holes are found out about and exploited. So, it comes back to what we were speaking about earlier, which is to assume breach. So, basically assume that they’re already in.
Assume that your software is exploitable. What happens next? And the what happens next is the important part. So, if something gets exploited in Chrome on my machine, what happens next is generally something will try to run. Well, we’re going to stop that thing from running because of default deny. Or as I said, PowerShell’s going to reach out to the Internet or run DLL is going to try and run remote code or cURL is going to try and download a payload.
If you control all of those next things, then it fundamentally may not matter that the software itself is vulnerable and has been exploited.
[Rich Stroffolino] All right, Rob, what’s one thing we didn’t ask about that we need to know?
[Rob Allen] Oh, God, I wasn’t expecting that. I know you asked that question before, but I wasn’t actually expecting it this time. Look, there are things in your environment that are unpatched, that are vulnerable, that are dangerous. Whether your current patch solution tells you that or not, I can pretty much guarantee that there are things out there.
So, find them, fix them, patch them.
[Rich Stroffolino] All right, well, that’s just about it for this episode of Security You Should Know. To learn more, head on over to threatlocker.com. Thanks to Mike Woods and Steve Zalewski for helping us learn more about ThreatLocker, and thank you, Rob Allen, for your time and being game to answer all of these questions.
And thank you for listening to Security You Should Know.
[Voiceover] That wraps up another episode of Security You Should Know. If you like this program, please subscribe, tell your friends, and leave us a review. All companies showcased on this program are sponsors of CISO Series. If your company would like to be spotlighted and interviewed by our security leaders, go to our contact page on CISOseries.com or just email us at info@CISOseries.com.
Thank you for listening to Security You Should Know, connecting security solutions with security leaders.