Name: Unified Vulnerability Management: Risk Reduction Beyond the Patch
Uploaded: 2026-09-23T15:51:08.496Z
Duration: 35 min 4 s
Description: Unified Vulnerability Management: Risk Reduction Beyond the Patch

Transcript for "Unified Vulnerability Management: Risk Reduction Beyond the Patch": Hi, everyone, and thank you so much for joining our webinar today. In the next thirty minutes or so, we'll be covering vulnerability management or unified vulnerability management, if you will. It's one of the oldest disciplines in cybersecurity, and one of the few that hasn't changed much in this, say, in the last fifteen years or so. You scan, you give it a score, you open up a ticket, you patch, and then you report back. This model, assumes two things. It assumes that you knew about your asset estate, and it also assumed that you had a few days or maybe weeks between disclosure of a vulnerability and the exploitation. I think it's fair to say that in 2026, in retrospect, we we we will, accept that both assumptions are now broke, and we need to talk about what will replace this approach. And to talk about this, I'm joined by two experts today. We have Bennett Norton, David Bauer. How are you guys today? Doing good. Doing very well. Thank you. Cool. Well, Bennett, maybe you can introduce yourself and then pass it over to David before we kick off the the chat. Yeah. Great to be working with you guys all today. I am one of our center of excellence team members here at ServiceNow. I'm focused on exposure management and figuring out how we can best approach processes and and build out the right success paths to ensure that we're reducing risk in environments. So looking forward to the conversation today. Thank you, Matt. What about your day? Yeah. And my name is David Bauer. I'm the, COE global director for exposure management. I've been in cybersecurity now for over twenty years and working in, a a wide variety of, different security topics and challenges across the board. Oh, cool. Thanks again for joining. My name is Maxim. I'm a director of product marketing. We all came in, to ServiceNow through the Armys acquisition, so we're all part of this big family now. To guide a bit of this of the conversation today, I put together a list of discussion topics. Obviously, this will be a non scripted conversation, but it it gives us a bit of a structure. And, we'll be discussing first how we shift from, traditional vulnerability management to the exposure management. One hot topic, obviously, is how can we defend against autonomous AI threats in today's world. The part that is most practical and I think for our audience to learn most, on on the reality of things is how we go around smart prioritization mitigation and remediation. So we'll definitely, spend a a lot of time on that topic. And then, you can detect all you want. You can prioritize all you want, but you have to close the loop. So closing the loop with with remediation, whether that's manual remediation, automated remediation, all of these things will come together in the final, topic of the day. I have to say to our audience, if you have any questions, please use the dedicated q and a functionality. If we cannot answer during our webinar, we'll definitely get back to you. So we have a lot to cover, and I suggest we just kick it off. Bennett, you and your daily reality, you have so many conversations. You're in front of both existing customers as prospects. When you talk to a vulnerability management team or when you talk to security operation team that tells you, hey. We're good. We're covered. We have a vulnerability management program. It's working as intended. What is it that you actually find when you look under the hood? You know, Maxine, that's a great question. The reality is when you start looking under the hood, often what's missing is context. Right? Most of the processes that are in place kinda go back to that traditional, methodology that you mentioned in the beginning of, hey. We're scanning and we're creating tickets and and we're getting work done. But they're using more of a peanut butter and jelly approach to addressing risk. You know, not all assets are the same. Not all vulnerabilities have the same impact on different assets. And so, really, under the hood, what we find is things aren't prioritized, and we're not efficiently handling the right remediations and making sure the teams have the right information to to focus on what is most important inside the business. Got it. So you could say that without this context, even though the program seems to be working, that teams would be working on the wrong priorities. Like, they would be putting a lot of time and effort on things that maybe they're chasing ghost in some some instances probably. Yeah. That's a great recap. And then kinda to follow-up on that is timing of things. I think that has somewhat changed, to where we we really need to focus a little bit differently more on the continuous aspect of CTAM. And I think we'll get into that a little bit more in in further discussions. Yeah. Speaking of which continues is exactly like the the next topic that I want to touch with you, David, because you've been instrumental in the market, through through all of your different roles over the last couple of years in guiding so many customers, so many, partners from traditional vulnerability management to what the analyst community is now framing for a few years as CTEM continues threat exposure management. Can you cut it for us? Like, what did what does that shift mean? What did what did it actually change in in a team and its operation? How how does VM changed, the data reality from Teams when they went through a c 10 approach? Yeah. Great question. I I think, it starts with what Bennett mentioned. It it's context. Having better context, better information to be able to make more impactful and smarter decisions around what it is that we wanna prioritize to fix. But, really, CTEM, what it did for the market was really open up a framework, that we've been helping organizations really journey to. And and, essentially, that's what CTEM is. It's a journey for a lot of our organizations. It's, not only taking, new concepts, right, and making them, scalable and, obviously, having them running, in their systems today, but, you know, when we look at, continuous threat and exposure management, it's also now looking at the asset. Right? So we spend so much time work looking at the severity of an issue, and in reality, the asset is equally, if not more important than the actual issues at hand is what we've learned from, the CTEM process and and really deploying it across the, many different organizations. And so context is big, but also, taking into consideration assets, is much more, important in the CTEM framework. So now with with CTEM, we have more context, which in many cases also means more findings, like teams are getting flooded with with more information. And we know that the the average enterprise kind of runs, I don't know, 70 ish or 70 plus security tools. In many cases, I think you can argue that throwing another scanner will not be the answer. Right? Because there's been so many new, threats being discovered in 2026 that people might get tempted to try just adding one more scanner or a different type of scanner. But why does an another scanner never solve their problem? Why why why is that? Yeah. I think I think what we what CTEM has done for a lot of organizations is really allow them to look at their existing tooling, and really understand how it's being used, what information's available. And most of the time, it's about, beyond just, hey. Are we seeing the same vulnerability from the same, you know, two different scanners? But it's really more about the asset and what what does the scanner say about that asset. Does it work within the existing tooling sets, that they have today to enrich the data that, they're scanning? It it it's essentially, allowing, or CTEM is allowing organizations to, really stretch across their existing ecosystem and, and really inner work and use the existing datasets that they have and opens the door for actually, an ROI and a collapsing moment, because CTEM really will be one place where they can see all of their the different risks that they're getting from all the different tooling, across all the assets. And so, you know, CTEM not only helps them with prioritization and making smarter and faster decisions, but it's absolutely helping with tool rationalization as well. Got it. So assuming we have that rationalization in place, that's one thing. There's another thing that changed, I would say this year, even though this has been happening for a moment, but this year has been like a turning point. What changed is the speed? Like, we we came to realize with those, frontier models that demonstrated that they could discover thousands of new, critical vulnerabilities and generate even working exploits. We can't realize that speed is being used against us. Like, how can we defend, or can we set the scene on how we could potentially defend against these autonomous AI threats? What what has changed for the defender, David or Bennett? Yeah. I'll I'll I'll take this one, Bennett. Essentially, what what has kinda happened to a lot of organizations is essentially when we woke up and and we all got the same news and same articles talking about how, one, new AI model or many different, AI models that are emerging into the market has the ability to, find a a a a weakness in the environment and be able to exploit that and then ultimately, execute the attack that they were trying to get done inside of a very short window of time. What we realized is is from that data and all the information we got is not only do we need to speed up, the the fixing part of, of of phone management or or risk management, we actually need to now take a look at the entire process from detection to communication to fixing and and really what types of risk we're gonna now accept, in the organization. And and so, really, when the attackers, and the tools that they have enhanced, we needed to refine not only our approaches and how we work together amongst human beings inside of an organization, but we now need to look at our tooling to see if we can now speed up the process in terms of their ability to detect these issues as well. And so, again, it's it's a a process that needs to speed up, but it's also your tooling and how they inner work with your, with your existing technologies. That was also a big, game changer in terms of a a wake up call for our customers as well. Yeah. So speed is definitely a key driver here, a big, a big issue as well. When we say that window has collapsed, Bennett, can can you put some numbers on that window? Like, how long did the team have historically between disclosure and a realistic exploitation? What is it now? Like, what what's the difference that we're looking at? Gary, we used to say it was days, Maxine, in between when a vulnerability was released to when it could be exploited. And that could be was an average. Right? And now what we're hearing from the industry is we're down to about an average of ten hours from a CVE being dropped to when it can be exploited or weaponized. Right? And so when when you talk about what's changed in, like, you know, shifting in that baseline, generally, we were looking at about 50,000 CVEs in a given year. Now we saw just recently it was 30,000 in a month. Right? So when we talk about refining our processes, as David had mentioned, this really comes into light of how can we scale our practice in a way where we can handle the influx of information. Right? Going back to one more scanner, we have a lot of data about the environment. How do we process it efficiently, and how can we move at a scale where it's quick enough to where we can battle this scenario of, an exploit being available within ten hours from early. So that's really kind of the key crux to a lot of what we need to reevaluate inside of our processes. Yeah. I like that. And and ten hours, sometimes minutes, a related one is the fact that many organizations are now using AI assisted coding and that there's research that confirms that they're introducing way more vulnerabilities into the code as well. So, it seems to be like the narrative seems to be that AI is always something that is, and that that is an attacker advantage. Like, AI is being used by the bad guys, but the the narrative can also be can also be turned around. David, I think there's a version of this story where AI isn't just an attacker's advantage. Can can you make the other case? Like, where where does machine scale discovery actually favor us as a defender? Yeah. Yeah. I think, well, I think you kinda called it right out. It's what is gonna be your kilo for for these new, AI, models and these new frontier models that are coming our our way from an attacking perspective. And, you know, really, our answer over here at ServiceNow is, an an approach where we say security for AI and let's use AI for security. And, essentially, we've sent basically, we've taken that approach and that that concept, and we've now, ingrained that and even, what I would say, even upgraded all of the technologies that we have within, the security, business unit over here at ServiceNow, but they're all moving faster in terms of how they work better together, moving a lot of the backplanes together, a lot of the data sharing, a lot of the collaboration that we have, is is really moving in not only a continuous approach, but is now all being built, and has been transformed by our AI engines under the hood across the board. So we have the ability now to, identify those exposures in the environment or what assets are exposed. We have the ability to close the gap on making sure that, we're addressing the right issues and ultimately doing that in a, a very singular motion from left to right. And, within our business unit, what we do is essentially complement where they are, and fill the gaps first and, and then land into an entire process that has been completely transformed from where they were yesterday to, now being able to be ready for the future. Yeah. I like that. It's it's using AI to our advantage. And and you mentioned a few things that are key here, like all of your assets, all of the context. That that is really the one thing that the attacker doesn't know. Like, for you, you can build something where you have a complete understanding of your attack surface, a complete understanding of your environment, and that is kind of key. That will buy you time. And this is how you use AI, in favor of the defender so that, when attacker does come in, they don't know your environment. They are seeing this for the first time, and you are, better prepared than they are. Essentially, that's that's what we are saying here. Alrighty. I think it's time to move to the next section because we we keep this short and sweet. We will discuss smart prioritization, not just prioritization, but how to do this smart and, everything that speaks remediation and mitigation. This is the most practical news block, useful block, I would say. Hopefully, we can give some some, some practical takeaways to our audience as well. Look. This is a given. Severity scoring is not the way forward. We know it's inadequate. We know we are not going to clear the backlog with CVSS as your organizing principle. But what is the the new approach, David? If you you can walk us through, a bit of the the smart prioritization that that we put into our products. We heard things like exploitability, reachability, business context. What does that actually mean in a technical reality? Yeah. And I I think, the the the scoring of this is, also taken on a a little bit of a life of its own. And in reality, what we do on our side is we provide a prioritization score, a prioritization score on fixing. And going back to our original, point here, it's heavily based on asset context, and then it moves downstream into the other properties that we wanna look at to define what exactly is our 1% or what is that critical definition from an SLA perspective. So absolutely, exploitability, reachability, exposures, right, are all a part of that formula that we look at. We then, take a look at our exploit intelligence by early warning. We wanna get factually based evidence that, something is in fact being weaponized or exploited today, and we wanna do that with, speed and scale. And so we take the combination of, all the, different object and properties that, really, CTEM is is, built upon. But, ultimately, even customer, very specific, metrics and and requirements that they have fold into the prioritization as well, because, again, you're back to your earlier question above. They know their assets. They know their network. They know what's important. And even though we're all dealing with relatively the same assets, they're slightly, the importance is slightly different, based on each organization. So we wanna understand what that business context is as well so that we can, again, include that in our our prioritization scoring. Yeah. I think that's the key thing because we heard this from from many customers. Even though I'm I'm not in sales, I hear these conversations where customers would say risk scoring is one thing, but if you have your own algorithm that is like a black box and I cannot tweak it to my business, then we have an issue. So the fact that we provided this openness is is super important. And, for you, Bennett, can you give us a real example, like, from your daily reality? Have you seen findings that were maybe scored critical in the old way, but generally weren't urgent or the opposite? You saw something that was scored medium and should have been top of the queue. Did did you see that in your daily reality? Yeah. It happens in both directions, and I'm glad you asked the question that way because the reality of the scenario is we, as in in our security programs are inundating our remediation owners. We hand them so many problems. They generally have context around the asset that the security program itself sometimes lacks or is often lacking as in, like, a media a mitigation control. Right? You you send over a problem saying there's an issue with, you know, port 22 being exploited on a certain CVE, and the remediation owner comes back and says this isn't critical. Our EDR policy and our web application firewall policy blocks port 22. So do they need to get the CVE address? Yes. But was it critical? Did it have to be done within the SLA that they were just handed? The answer is no. And that's that friction that we're seeing between the security teams defining what needs to be addressed and when it needs to be addressed. And the remediation owner's coming back saying you're giving me false positives. And sometimes even if the CVE or weakness misconfiguration lands on the asset, it doesn't have that level of criticality that has been assessed originally. So it goes that direction. But then David just had mentioned too that we have a kind of a product as part of our prioritization called early warning that helps us have evidence on an exploit. You know, so a CVE or misconfiguration could be exploited or weaponized, but still be classified as a medium or low. That problem is worse than the other false positive. It doesn't waste as much time, but it means that we've left holes in our kind of defense. And these reasoning models, these frontier models, what they're able to do is daisy chain these issues together. So those mediums and lows that are scored as such from a CVS perspective can become very problematic within the realm of the days that we live in today. Got it. But in order to get there, like, the promised land of contextual prioritization, it all sounds good, but it does require that an organization know, which asset runs what, who has access to what, who owns what, what breaks if you touch it. So most organizations will say that they don't have that if they're, a 100% honest. Is it a prerequisite to start building something like CTIM, or is it something that you build as you go? I'm I'm gonna go with definitely build as you go. Now most people don't necessarily have this all documented, Maxine, but we call it tribal knowledge. Right? It is in their heads. There are people that have been working for these organizations for a very long time. That information we need to extract out and put begin to put inside of the process. So any good CTIM program needs to be able to address that by starting. Right? You you have to go because that's when you start to find where are the chinks in the armor. If you sit and try and plan forever, you're gonna get into that analysis paralysis. So I definitely say go. Discover as you go, and you'll start to be able to pull out from those team members what are those crucial pieces, what are the crown jewels from an asset perspective, what are the mitigation controls in place, what are the scenarios where we have to document so that we know next time how to handle that better. But there's no better way to do it than just by starting. I like that. Just go and you'll learn along the way and you build all of that context, along the way. Absolutely. We have a a short format here. So, we'll move to the next section, which is our final session about closing the loop. Because as I mentioned earlier, you can detect all you want. You can have all the context in the world and all of your smart prioritization in place. If you cannot fix, remediate, or mitigate, all of this doesn't make any sense. So maybe for you, David, can you take us from your experience to to this loop, like, of finding lens? It's a new vulnerability. There's maybe prioritization going on. How do we close the loop? Like, can can you make this practical and tangible for us? Absolutely. I I I think this is now coming back to a couple new requests that, have been kind of, coming coming to light and and more frequently being asked by organizations and and specifically from the the remediation side, which is how do we actually do a confer confirmation of a of a fix. Right? How do we do that? How do we pull it from multiple sources? And and we've absolutely come up with a way to validate the fix. On our side, we have our own ability to passively detect vulnerabilities on all devices. And so, today, what we do is actually complement existing, VMDR or APSEQ, programs today where we're running alongside of their programs and actually validating what gets fixed while we're doing all the facilitation, communication, automation of, let's call it the the fixing, taking in the the CTEM framework and, obviously, their prioritization. And so, it was very easy for us to to quickly start to, work around the existing program that they have to offset some of the gaps and challenges that they have with their legacy technologies and how they operate. So we wanted to make sure that their investments that they put into their VMDR program was still being maximized, and they weren't a victim of of just the way their old tooling kinda operates in their environment today. Right? And so if we're talking about speed and being able to enhance not only the process, we wanna be able to enhance the validation and the detection process for our organizations as well. No. Thanks, David. And there's one thing that struck me. You mentioned the automation of remediation, which, again, sounds like, either the promised land or recipe for disaster. So let's let's address the objection directly because I know it's it's one that every CISO, will raise in a conversation. Autonomous remediation sounds, to to some people, sounds like autonomous outage. How do you get comfortable as as an end user? How do we get comfortable as an industry for a system to act like with without somebody clicking a proof, without the human in the loop? Where where do we draw the line? The the trust, Maxine, and I'm glad you asked this because I wasn't trying to tease this out. But, on the on on our security side of the house, we have a new, concept that we've, now delivered to the market called Shift Zero. And what Shift Zero is all about is all about fixing at inception. Doesn't matter the asset type. It doesn't matter, what type of application, or, what type of resource it is. This is all around fixing and managing your exposure across the board amongst all of your assets. And so what we offer is one place for, our customers now to upload or provide us their standards, their policies on how they wanna build and inject security from inception. But the same goes with proactive in going forward, which is what types of fixes do they wanna implement in their environment, and that is the information that we'll catalog for the organization. And now we can make it very easy to push the automation button and turn that workflow on because I'm now curating the information that they've now provided given any scenario that they that they're trying to remediate on their side of the fence. So, we absolutely take into the consideration, what the service advisories and all the public source information has out there related to fixing. But now we have one curated place for organizations to provide what is called an ideal fix, to any given solution that they have. Sounds like a promising, next step. I would say, it's it's time to wrap up. So I would like our audience to to walk away with something that is tangible, that is an action that they could put in place. And maybe, Bennett, I'll start with you. If somebody has been watching this and they're running a traditional vulnerability management program, meaning, it looks like scanning, scoring, ticketing, and patching, They kind of realized that they need to rebuild this and they they need to change, let's say, next quarter. What would what would be the first thing they need to change according to you? Yeah. Maxime, I go back to that beginning question of making sure that continuous is a part of their process. I know a lot of us say, hey. We've got a continuous methodology, but it it contains time frames of weeks to months, especially when we start looking at critical infrastructure, OT scenarios. Right? We don't have that luxury anymore, but we do have new tools in our tool bag. Right? Where in the past, you know, we we really struggle to kind of auto patch things. Right? Because we were breaking too many things. We've all heard the stories of credit card machines going down in every store, during a holiday weekend. Right? That cannot happen. But in order to truly be in the age of AI where we are at today, we need to be able to move to a much quicker detection and a much, much faster remediation. We've done this, Maxime, inside of the CICD pipeline and AppSec for a very long time. So when I say we have new tools in our tool bags, we have AI harnesses now. We can create an AI harness combined with a bunch of skills that do help us do the remediation, but also all of the validation. In the CICD pipeline, the coding, We had unit tests, and we could we knew right away when we broke something. When it comes to vulnerability management, we haven't had that tooling, but we do now. So when we put that in place, we can move into that continuous process of CTIM much much faster and much better with the security that we're looking for. Yeah. So the technology is there. So this is not a faraway tree. One more for you, David. So, a typical metric when the old world is number of vulnerabilities close, like, to demand your success. What would be a new metric, like, some some metric that would kind of prove that the shift is working, that you're not operating in the old work? Yeah. I I I think some of the old metrics are still gonna apply here. Maxine, I'll I'll say that first. We we don't, just kinda wipe the board clean and and start scoring the game differently. I think, they're still going to look at the total number of risks. They're going to see all of it readjust across how they report it because, again, now some of the criticals are no longer criticals, and and they're gonna ship down into medium and lows based on the CTEM framework. But we do need to pay attention to more of the medium and lows now with the new chaining, attacks that that are, being talked about today. So we wanna obviously make sure that we've identified the kill chains, and we're breaking those down. But, really, what the the game is, from from a a a sort of a, let's zoom in type of a lens on the entire process. It's still MTTR. Right? Mean Time to remediation. But it's also putting an emphasis on detection. How fast did did it take us to detect that issue? And then from there, how long did it take us to get into the operational window? Meaning, the, put it in front of the humans in the loop that need to make that, decision to be able to communicate that as a a, priority one. This is the 1% that we need to, focus on today. And so, again, old metrics still still matter and, a lot of the, the new shift has been now focusing on the process and and understanding if we are getting a signal from our scanner, over into the operationalizing window, and now we're managing exactly what what how much time it takes us to do that. So, again, multiple different ways to to measure speed here, but that is really where you need to close down and and kind of, shrink that window. And most of it, we have to look at ourselves, our program, how we're operating today, and our tooling, and we need to figure out how to shrink all of that together. I like that you ended with speed, and this allows me, like, to to give a clean close to this conversation because I think there's three things that we can walk away with. When you said speed, essentially, what you're saying is that the exposure window has collapsed, and it's not coming back like so any program built in the old fashioned way built on monthly batch cycles is will be structurally behind. That's one key takeaway. The second thing that I learned today is that prioritization has to be based on multiple factors like business impact, reachability, exploitability, the full context because the volume as such is no longer workable. And the third thing, going back to your point of our shift to zero, I think the durable advantage that you have or that we have, as defenders is that we can build that complete context. We can practice. We can learn from our own environment, which is the one thing that attackers will never be able to copy. And it's that negative time, all that learning that you can do that allows you to shift to zero. Thank you so much, Bennett. Thank you so much, David. I think it was a really, interesting conversation, and I'm gonna let our audience walk away with a few, content pieces that they can access on our website or download. There's there's a unified vulnerability management playbook that kinda gives you that short term transition, but also the longer term objectives of making the shift, to this new approach. We also built a cool vulnerability detection comparison page so you can see how armies from service now compares to the more traditional vulnerability scanners. I hope this was useful. Again, if we haven't addressed all of your questions today, we'll definitely get back to you, later. But for today, thank you so much for joining, and talk to you soon.