The Evolution of Patch Management with Eran Livne at QSC24

This is Textron tv. Hey, everyone. We're back here live at Qualys QSC in Salt Lake City.

I'm really happy to have back with me. Imran lived Na Yeah, I got it right. Imran, it was actually the last time I interviewed you.

You had just recently joined Qualis, wasn't it? You interviewed me first when I just joined Qualis Yes. A few years ago.

Yeah. And back then you were, uh, endpoint remediation is, yeah. Still am.

But now more, Now. More, more, yeah. That and more.

Yeah. That and more. Exactly.

So Iran, what I, I'm, you know, I'm being flippant, but tell people more about a little, your background. Yeah. So I'm, I'm started as a, you know, like many pe other people, like developer working a lot development, but then I moved to some product management world, working with a lot of, uh, security, network security, endpoint security, and recently working for Qualys, helping our customers fix all the vulnerabilities that basically Qualys find, and we find a lot.

So. Absolutely. You know, I, I think it's pretty well known.

I actually, I think the last time I interviewed you, Qualys was just rolling out their patch management, remediation, uh, solution. So that was probably, what, three years, two, three years ago. About Fours.

Three fours. Yeah. And, and that's come along nicely, right?

Yep. Today, you know, it's funny, I think we spoke about it back then when I had started a company also in the vulnerability management space. We interviewed a lot of customers and a lot of customers were not in to having patches automated.

Mm-Hmm. They wanted to test everything. As a matter of fact, the time from when a patch would come out to the time that a patch was applied was usually 90 days or more.

Mm-Hmm. Which is, you think about it, mind Blowing. Yeah.

Part of the problem. It's gotten much better. A lot of people are okay applying patches and updates without testing them until you get CrowdStrike.

Of course. Right? Yeah.

But it's better. But as we were talking a little and, and about remediation, applying a patch, that's the way I want to say it. Applying a patch is not the only form of remediation.

There's more to remediation than a patch. Applying a patch. Look, that's relatively simple, and we can automate it.

You got this version of the software we update you to that version of the software. We see this vulnerability and here's the, the fix for it. But that, as they say in Las Vegas, that's a fine beginning.

Yeah. But it's not the end. Talk to us about that.

So, so first of all, what you said about automation and, and you 100%, right? When I joined Quas, it was everybody was doing SECM or doing a, a big process of deploying those patches. And we saw a huge change from customer thinking, from patch management as, or as a it Yeah.

To moving a lot to security and thinking about it as a complimentary to it. So they don't replace what it is doing still it is doing this stuff. Yeah.

But now security has something to say and security can help. Okay. And then automation come into place, and many customers figure out just because looking at the data that so many vulnerabilities are very easy to fix.

The Chrome, the Firefox, those guys are very easy to fix. And many ci, ciso and CIOs agreed with, with literally their, their guys that says, if we just go ahead and automate the, the, the risk of chrome breaking something is so low, it's much lower than the end user clicking on a link and, and, and, And get Phish do something. Right.

Get, exactly. So we saw a lot and more and more automation coming in in the last, uh, um, a few years. And I can we have customer that reduced hundreds of thousands of vulnerabilities just by enabling automation in a way in a, in a month.

Absolutely. So that was an amazing journey. And as you said, what we saw is that many customers are now getting better and better with addressing those, uh, vulnerability with patches.

But vulnerability is a risk. It's not a patch. Patch is just a software update that may or may not solve the vulnerability.

It may be just update solving bugs or, you know, or, um, solving or adding more features. There are many vulnerabilities that don't have a patch. So Wintrust Wintrust, I think that's what the name, what's called, but there's no patch for it.

Right? You have to make some configuration change end of life software. There are a lot of cvs and end of life software.

You can patch it. It's not, there's no patch for that. So you have to uninstall it.

A taking different action. And many other example, SMBs and old SMBs. And what happened in many organization is they're stuck because security teams send them a list of, you know, a laundry release of tons of things that they need to do and they don't need do know where to start.

And they spend a lot of time researching, what do I need to do in that case? How can I respond? And it's basically, instead of those days actually deploying those fixes, what they're doing, they're doing the research.

So the end result, they can respond slower and they're fixing vulnerabil less vulnerabilities than they should because they spend the time research Speed kills is what it comes down to. Or a lack of speed kill. Exactly.

You know, this was something, again, 10 years ago, 15 years ago, I remember working with Philippe, uh, you know, the, the CEO, the old CEO here, rest soul about this. And, um, the, the, the problem is, and they used to have, look, obviously putting a patch is easy, but then you'll run into situations where putting in a patch does break something else. Yeah.

Down the, you know, down the road a bit. And so there's other ways of remediating. I could, I could put something behind a, a firewall or IP to block traffic going to it.

I could change a configuration. I could, you know, gnat something at a firewall or, or Mm-Hmm. Or what have you.

I could fundamentally change, I could upgrade to a different, you know, if it's a, uh, obsolete or no longer supported system to something that is supported. These are things that are harder to automate, number one. Mm-Hmm.

And number two, do take time. It is just, you know, it's not as easy as like my phone updates every day or whatever. How does Qualys help with that though?

So to compliment what we just described, right? So there it, yes. Fixes a change, can break something that's based, everybody agrees that It happens.

It happens again. If you can classify what is my operational risk on those kind of vulnerability and, and on those kind of vulnerability, it'll allow you to be faster, right? Because the are vulnerability that they're very low risk.

So you can just go ahead and automate. But for the rest, for the javas, for the tomcats, for the much, uh, uh, vulnerabilities that are much harder to fix. What we are doing now is basically what you described.

But what happened in the industry, when you have those vulnerability, you send 'em to your remediation teams and those guys will say, no, no, no, we can't do it. There's big risk. We can't take this action.

So security team will come back and say, you have to address it. Do something. And then there is a research, either the security or IT team doing the research.

Is it a firewall block? If we block port 80, is that enough? Or do we know need to block port 4, 4, 3?

How do we know it's enough? And even then, if we did everything, how do we know on our, on our quality environment that actually we, the change was actually applied and the risk is reduced. So again, we are trying, our goal here at Quas is to help you address the risk.

We're not the patch management solution. We are here to address risk. So what we're doing, we are having our, the same team that is finding all those vulnerabilities are now exploiting and finding those Cs a K vulnerability, those marquee vulnerabilities.

They're actually exploiting those vulnerabilities. They're figuring out how you can mitigate the vulnerability without deploying the patch. What you can do to reduce the risk.

And we basically offer it to our customers. So you'll see the vulnerability and then you'll see the offer, what you can do to reduce the risk without actually deploying the patch. And those things are amazing.

I'll give you one example. Uh, very recently, there was an Outlook vulnerability, right? The Outlook vulnerability was using a very specific feature in Outlook.

Most customers don't even use it. Now, the solution is to patch outlook. But assuming you're not using 365, it takes time, right?

Right. So does Anyone not use 365? Apparently the are vulnerability in Outlook, and apparently are we discovered them in customer environment.

So yes, not everybody's using 365, but what we did is we basically said, our research and figure out they can easily disable this feature just by sending some command to the, the host. And then you're not vulnerable, disabled. And the beauty here, everything then is reflected back in our console.

So you can see the vulnerability is not fixed because you haven't fixed it, but you can see that it's mitigated. It's been mitigated. So You can report up and say, don't worry, this here is a proof.

This vulnerability is being mitigated. We address this vulnerability. The risk has been reduced.

And you know what, the nuance of that should not be lost, especially our audience as a cyber audience, right? Yes. There was a vulnerability.

No, the patch was not applied. Yes. The risk has been mitigated.

Exactly. Or negated period, right. By shutting that particular feature set down, whatever.

And this is, this is bread and butter security. This is what security teams do. Unfortunately, in today's world, I think, you know, SU ed was talking about it at the opening keynote.

The runway from stuff happening to boom is a very short Yeah. Runway. And so organizations don't have the time to investigate these things, don't have the time to run their test.

And, and that's where a trust relationship between a vendor like a Qualys and the end user, your customer, if they say, Hey, Qualis got this, you know what? They're going to send the command. We could use it to send the command, shut down the Outlook Mm-Hmm.

Uh, feature set. And we're good until we can Yep. Update.

But it takes that level of trust. Yep. And that I, you know, you'd like to say you have that trust with all of your customers, but that takes time usually too.

But I, I agree. But, but I agree. And that's a new capability that we're introducing.

So it's a new capability, but it is based on everything quality has been doing for the last 25 years. Yeah. So it's using, leveraging the same technology, leveraging the same people that built all the detection, logic, and understanding of vulnerability.

So yes, a trust need to be built, but we hope that we have that, you know, uh, because customer have been using us and they know that we're been doing it for so long. I hope they can also trust us here. And I want to mention one more thing, addressing what you just said.

When you talk about zero days, many zero days are just getting there. In a marquee zero days, they're getting out without any patch. There's just no patch.

The vendor says, we'll give you a patch in 2, 3, 4 weeks, whatever. In the meantime, you can do something to mitigate the risk. That's a huge thing that can, that's the boom thing, right?

Qua will give it to you as soon as the, or as soon after, the zero days out, we'll give to tell you, here's what you, here's your insurance. You can use us as an insurance to make sure we can mitigate this vulnerability until your IT team can actually take the action and, and fix it. So that's, again, this is something our, our big, uh, um, roadmap of vision to help our customer address the vulnerability.

The way I like to say it is you don't want to show, uh, a red dashboard to your management. You want to share a green dashboard, and we want to help you get there. Absolutely.

Amen. A pleasure as always. Thank you very much.

We're live here at Qualys QSC today. We're gonna have some content until our next guest will be here, probably just about 10 minutes. Stay tuned.

We're at Quas QSC in sunny San Diego.