Sustainable Vulnerability Management: Case Study by KuppingerCole

Good morning to the third day of the Cybersecurity Leadership Summit live from Berlin. You are here in technical track number one. This is the Wilhelm room, so it's not Caroline. Hopefully some more people will join us. There's some topic with the agenda. Obviously in this track we will talk about vulnerability management. We will talk about a panel about best practices for security automation. Then we have also a cool session that needs to be announced at least in the agenda, which means we will extend the panel a little bit.

I think Donnie and the others we have enough to discuss with each other and that's a much more interesting part then. And we have a presentation about security automation in iot OT about strategies and how to manage technical depth. That is what you can expect in this room. For the online attendees, if you have any kind of questions, just feel free to use the chat function on the KC Live platform. There you have the option to raise your question.

And for the on-site attendees, feel free, just raise your hand and give me just a second because we need a microphone, otherwise the online attendees cannot hear your question. And as always on keeping a call events Casey live or hybrid, we have a short part for asking your questions at the end of each session. So with that, I would like to in choose and invite Zil H from Deut group on stage at least virtually good mornings. How are you? Good morning, Christopher. Thank you. Thanks for having me. Great.

So you and I will now talk about vulnerability management and how to achieve sustainable vulnerability management. It's an case study together with the Deutsche group and keeping a call and I'm really looking forward to share our experience that we had together when starting to investigate how to improve a vulnerability management system for enterprise organizations.

Okay, so back to the slides. Usually presentation starts within why you always ask yourself why do I need something like a vulnerability management? I mean for you as in security expert at the conference, it's quite simple because there are so many attackers that try to get access to your system, to your data that want to harm you.

I just added some specific slides about ransomware attacks because that's the most popular thing and typical way that attackers do by using zero days and vulnerabilities in organizations just to share again some important feedback or insights, how critical attacks can be. And I think the first number is pretty, pretty interesting If you pay a ransom to an black mailer once you purchase something like an like a frequent return of the attacker. So 50 to 80% pay at least twice because the attackers come back.

Even if you close one vulnerability, they will find another one and ask you again for a lot of bitcoins. I mean Bitcoin is since there was yesterday in the evening, a crash a little bit cheaper. But doesn't matter that we are talking about a lot of money. A lot of money means one of the biggest ransoms that have been paid in the past are $40 million in Bitcoins. It was in 2021 by an financial corporation. So that's really a lot of money. And even if you are paying the, this does not automatically mean okay, I get access to my data.

No, sometimes you pay and in average 30% pay and even lose some data or all their data. And this is talking about an enterprise, really a critical topic. So we have to talk about how to deal with the vulnerabilities that our organizations have, how to handle them efficiently, how to bring our IT departments, our IT organizations to enable them to work efficiently in closing those security gaps. Before I hand over to zil, a short definition of what is a vulnerability. Vulnerability is at the end weakness or a flaw in an IT organization infrastructure and can be used to gain privileged access.

We had multiple presentations on this cybersecurity leadership leadership summit or one in the past about how attackers start with phishing tech then get the first access, run some scripts and then easily bring some administrative user to log to that to that he's logging onto your machine. And then he had the privileged access for an enterprise domain or enter domain admin at all, which is honestly really critical and a known vulnerability in organizations. But this is something we have to deal with. And with that I would hand over to usbi.

Just gimme a short hint when I have to switch to the next slide. Here we go. Thanks Christopher and sure I will do. So I think one of the biggest questions is what is the challenge that we are taking on here? I think it's all about the risk an organization is facing. So Christopher just alluded on what a vulnerability is and of course we have to make sure that we are in a good security posture, but as you all know, there's no 100% security. So we have to make it as much as difficult for an attacker to use these kind of vulnerabilities.

And therefore it is very important to build up a target operating model that allows us to address these kind of risks that are coming up when facing vulnerabilities. Moving on to the next slides, we would like to give you a little bit of more information in how that could look like. So that is just one possibility how to approach it, but hopefully it gives you some food for thought and how this could look like for for an organization.

So on the one hand side I said the root cause anyways is that we want to look at the risk for an organization and how can we make a good security posture in order to detect and later prevent the organization from ETUs coming in. And of course there's different kind of topics here. On the one side of course we need technology, technology to address the risk that we have identified in the first place. And obviously there's a number of tools out there in the market.

So we have to be sure that we know what are our use cases, what do we need to address in order to find the right tools to handle our vulnerabilities for the assets that we have deployed in our environment. And then another topic is around the stakeholders actually who is it? Then once we have identified vulnerabilities, who has to fix those? Who has to follow up? It's probably a different team that takes governance view on making sure that they are getting processed.

So it's really all around identifying the stakeholders and then talking through who has the responsibility in which face on handling these vulnerabilities. And then of course one of a very important questions when we're talking about technology. If you turn on such a scanner, you might be facing quite a large if not huge number of vulnerabilities that are going to be identified and we'll see later that of course many of those will be vulnerabilities but they could be false positives as well.

So if you are in front of the mountain, because you're facing a lot of potential vulnerabilities in the first place, you need to come up with a strategy to identify where to begin, what's the most important one which poses the most risk to the organization. And that's where prioritization comes into the view. Now looking at all these points, it is really key to have a mature process that really handles this end to end.

And I think you've heard end to end in various technical processes already, but I think in particular for vulnerabilities, in order to address them and make sure that they get remediated, the end to end process is really key here. Now what can help us to find a good prioritization? So on the next slide we have come up with something that is known in the market where it's called the common vulnerability scoring system.

And in order to be able to come up with like a strategy on what to do first, the CVSs score is a method that is known in the market that is used to supply a qualitative measure of severity. It helps you to understand by default from experience from the market what you could do first.

And of course you would not apply it one to one to your organization because your organization might have specific needs, but that is a basis that you can adopt to your organization in order then to understand which assets, which crown jewels are most important to you and how you want to then classify it accordingly to the standards that's known in the market. And of course it's not only about this has to be done first and this has to be a second, but also giving yourself then based on this information, a timeframe on how quickly you are going to address those.

So as that, if you look here at the CVSs score, which you can break down into numbers, there's the criteria from critical up to low and you have to define for your organization what that means, how quickly you wanna address the according category. Now on the one inside we've now looked into a method how you can slice and dice and divide and conquer your vulnerabilities. On the other hand is then a question, how do you put this part into the overall end to end process? And looking into the solution, we can move one step further and breaking that further down into two main bullet points.

So on the one inside we already touched on the topic on vulnerability sources. So looking at this, we said already that there's a number of tools out there to scan for vulnerabilities. So that is an automated process where based on a golden source where you say this is my library information, this is where I have stored all my assets, I link it to my scanner and then I get all the vulnerabilities. But it does not have to be always an automated source where you use technology.

It can also be a process where someone manually is looking at something and that goes more into the direction as an example, like penetration testing or you could gather intelligence out of the market and then you have a sock and a third team that provides this information to you. In a second step there is the processing layer. So once you have deployed the technology, you connected that with your golden source and your assets and you obtain the information you need to handle the outcome, which are obviously the vulnerabilities.

And that's why we already looked at the CVSs score and the timeframes and that's like the second big box that you see here, the vulnerability processing layer where we will dive into in the following to see what actually do we need to do what, what is it about, how we handle it? And I think that brings together the points that we had previously around stakeholders prioritization and then handling it until the end. And for that I think we can dive one more deeper into the process and look in how how an example of this could look like.

So on the next slide, what you just saw on the left hand side was the vulnerability sources. That's actually now broken down one layer deeper where you can see on the one end side you can deploy vulnerability scanners based on what your organization needs. You might have different kind of assets that you want to look at, but there's also a possibility that you might be developing source code by yourself. So that might also be a source of information that you wanna make sure that you're not introducing vulnerabilities, enhanced risks to the organization.

And I think I mentioned the penetration testing as one of the examples for human interactions. And another one could be the security feeds. So when in the past for example, there was information becoming available on on cases like lock forge, that would come through threat intelligence in the first place. And that's just one example that you could consider here. And of course that's the situation that I also mentioned previously. You wanna give yourself timeframes in which you wanna handle these kind of vulnerabilities.

Some of them may be very urgent and then you want to jump directly in remediating them right away because they're so urgent or you have more time and then you can put it through a managed process and that's where the definition of the severity and the timeframes are very important so that you can then either again also when it comes out of an automated tool, immediately handle it. Or in the best case of course you remediate the findings.

So for example, you apply a patch or if for whatever reason you cannot hold your timelines that you have defined by yourself, then you also need to manage the situation. Of course that does not leave you away from handling it in terms of setting up a remediation action like patching or decommissioning an asset if it's no longer needed. But in case you cannot hold up the timelines then of course you have to handle the risk accordingly to make sure that you're looking at it.

And I think I mentioned briefly the false positives pre previously because if you turn on technology it will not all be 100% findings of vulnerabilities. That also falls positives because you have to configure technology in a certain way for your organization and not every scanner may understand that in the first place. So you have to go through fine tuning process and by that I would hand back to Christopher to give you more insight into the details of the one or the other of this process. Perfect, thank you very much.

Okay, so maybe one slide back on this slide. In the vulnerability management layer, how how we named it or processing layer, you see different processes and I think they are really, really relevant. If you think about your overall organization and the multiple scanning sources, the tools manual or automatically stuff which mentioned you don't, you need some process to enable your IT teams that they can work on these vulnerabilities efficiently. Efficiently means.

On the one hand the prioritization stuff we saw on the slide about the CVSs score, which is just an example, there are also other options outside to do something like in prioritization. But the challenge is for sure you need to do this over all your IT assets and all the related stuff. That's the challenge. I would like to jump a little bit deeper into the sync engine which is responsible to collect from those data sources, vulnerability sources, the the the list of vulnerabilities and I don't know who have used where was the typical vulnerability scanner. They do really a good job.

They deliver you so many information, so many low, medium, high and critical vulnerabilities that it's almost impossible to do this manually, especially if you have multiple scanners. So if you have a single tool, okay, there are options, some tools to deliver also some capabilities here. But building the overall vulnerability process layer, this is really the challenge. And in this process diagram I will dive deeper into two specific tops but topics. But at the end you have at the top the vulnerability is a false positive.

So you need an option for your for the importer to define something as in false positive automatically. This could be something which an IT asset owner defined at the beginning as in false positive. So it's something like an information or an I specific IT asset is going to be shut down in two weeks. Then you don't necessarily need to install a medium or even in high vulnerability, same the start timeline overdue process.

Usually depending on the criticality, often vulnerability you decide how much time you give your IT teams to fix something and we are talking about something between few hours up to months or even years really depending on the criticality. So let's jump in a little bit deeper. What is essential if you import something and identify potential really critical vulnerabilities. So we defined this in the example, this was on the slide stability shared the CVSs score greater or equal 9.6, then everything needs to follow an immediate vulnerability process.

And this immediate vulnerability process is something we will talk later on, but you cannot automatically define that something is really an action that needs to be done immediately. There are many variables that need to be or attributes that need to be covered here and have had a look at it. So this is really an important thing but this is something you should do always when importing data within your vulnerability processing layer. And this can be from an API scheduled database query up to writing down some information from and pen testing report.

So this is really something you need to design properly. And on the other hand we have the the assigning to the responsible people. Yesterday in in one of the panels was the Caesars. We talked about difficulties or challenges and having a good asset management, a good repository, know your assets, know the responsibility is key, but we also know the truth. In bigger organizations you have sometimes not 100% quality of the data here. And this is something you need to cover.

I mean in the best case you identify your IT asset, you identify the owner from an repository, that's great, but you need something like a fallback process which could be for instance the asset group owner or department lead of specific IT area, something like that. This is something you have to have in your mind. The next process is the remediation process. So usually if an IT team, IT service provider gets assigned a potential vulnerability, he needs to verify this manually in some case and he needs to decide what design a process what, how he will work on that remediation.

Which means will I do this now in two weeks, in two months, in 20 years? Or is it a false positive for instance? This is really something that is relevant. So at the beginning the IT asset owner or the escalated assigned person is checking, is this a vulnerability and emergency or an immediate vulnerability or not?

If so, it must be handed over to a specific process that is taking care of such escalated potential highly critical processes. This is something you need to be aware. Really the next step is checking false positive. That is what I already mentioned. And with that you can then work on the remediation but work on the remediation could be a longer time period as well.

You can design a strategy if it's a simple server update on Microsoft machines, you can decide it's done with with the windows service update server, windows server update services that way and schedulers define the design that and that's it. The tricky part here is you need to decide when is a ticket closed? I mean the scanners do their job, they scan, they scan, they scan, they deliver the result as a vulnerability. Then you have an vulnerability processing layer that says okay, there is a vulnerability. So what did we do? We designed a process that is checking.

If the asset owner says okay this vulnerability is closed, then within the next importer it is checked if the vulnerability is there or not. And you also need to be aware we are talking about it, sometimes it is not available so if it's a critical one, maybe it makes sense to check this after second or third vulnerability scan as well. And with that similar, I think the slide is again yours. Thanks Christopher.

Yeah, I think you pointed out the three main things to consider when building up such a process. And of course it will look differently in every organization because it has to feed the the ME to meet individual needs of an organization. But I think that is something what we can share as an experience. So I think we talked about the timeline over due process.

So once you have defined for your organization how quickly you wanna address the certain vulnerabilities, then you might end up in a situation where even though it was planned to remediate them in a certain timeframe, you run over this timeframe and then automatically this needs to trigger another process that makes sure that this is now alerted and escalated, that we are leaving the defined timeframe. And that is then where the ticket was not closed and it's now triggered to be in the process of being managed appropriately.

Of course again it means that at the end and remediation or a decommissioning or a similar action is required but nevertheless we have to handle the situation of being overdue And that is to in the one inside a proven extension to make sure that you have still a managed plan, how you wanna address it, but you also govern the situation in asking for an exception and then addressing the risk accordingly that it's locked and it's made sure that it's not just hanging around as a pending ticket but it comes up, it's escalated and it's being addressed accordingly.

The other topic which I think we touched a couple of times is the false positive process. And of course you don't want to specify a process where someone could just say, Oh I just put everything on false positives and then I make my life very easy. But then of course the security posture for the organization is not met. So it has to be assured that this is a governed process as well.

And in order to do so, it's also necessary to go through an approval process so that you make sure that it's not just claimed as a potential false positives but someone is doing a counter check and then it can be accordingly closed. And I think what we also discussed, and I have this example of luck for J at the beginning, I think it's really key also to have this emergency validation process.

So where you check is it so urgent that it cannot wait to go through a managed process where I have different options how to address it, but I have to immediately give that into my organization's IT security incident management process. So that could be run by sock search any similar part of the organization, but I, I think that's really pretty key to the process to make sure if you identify something very severe that you have an extra process that addresses this particular situation.

I think as we're coming more closer to the end of the presentation, we would like to share some learnings that we try to present today in today's presentation to you. So on the one end side, it's really key to understand what to do first. So as said, turning on a technical tool might reveal a large if not even huge number of vulnerabilities. And here it's really key for prioritization and that's where standardized methods can help an organization. But the learning is also that it's not just applying the mass one by one, you have to adopt it to your organization.

And that again goes back to the risk that I mentioned a couple of time at the beginning of the presentation because the risk and the use cases for your particular organization, that's really the key and that's where you have to build upon the CVSs is not just taking out, putting it in and then you're good to go. It's a solid basis. It's definitely something that helps an organization but it's something that you have to build upon.

The other thing that we touched on is around the golden source, which is really, really an important topic because all the technical tools can Only work just a short hint. We have to look at the time a little bit. Thank you. Sure I do. So I said the the golden source is a key topic and you have to ensure quality for that one as well. So I think that ties into point number two and three. And then as said, you don't wanna wait for the critical cases. So that's what I elaborated on the previous case. That is the emergency pitching. That is really key if you, if you face such a situation.

And by that I will turn back to Christopher. This was pretty fast, thank you very much for these learnings here. But we have two great questions from the audience and I will, I think we need the time to ask them. So really quick to the closing slide. Where to start with your vulnerability management program. I mean you have to start and introduce a vulnerability management program. That's the first phase. Then know your risk, think about the risks and have a proper understanding of your assets.

And then step by step going forward to implement such a process like we shared in some cases it was for sure simplified. The truth is just a little bit more complex than simple process flows. But I think this is really the idea was to share you the direction what we did and the shorthand release this week to research documents by one of our colleagues. We have vulnerability management, how to do it right, where do I start as an advisory note, Really great content. And we also have a leadership brief about why vulnerability management is a strategic investment even if you are not regulated.

And with that before going over to the question part, thank you very much stability for sharing the thoughts about vulnerability management, your experience and what we did. Thank you. Thank you.

Okay, perfect. So I mentioned two great questions. The first one is absolutely for usability, what management level is involved in your escalation? If vulnerability is not resolved timely, what consequences do you have in such cases? I think that goes up to all levels because it's really important for the overall organization. So I would say that goes up to the board as well. I think escalations in terms like there's multiple levels of or of escalations and I, I think there's different definitions of what an escalation is.

I think on the one side you start on an operational level where I mentioned the different kind of support groups before the stakeholders that really have to look after the assets. So it's like on an operational level we would reach out to them to make them aware that something for example, gets overdue. And if we are not seeing the attraction for whatever reason, that could be technical challenge, that could be other challenges. Then we have managed governance board we where we can go and and escalate that further to raise the attention to the next level.

So that's kind of the different kind of escalations that we're doing. And then of course there is the follow up in particular by looking at that. That goes along with the three lines of defense model. Perfect, thank you. And the other one, I will answer it by myself quickly. A critical vulnerability might have a limited effect on uncritical assets. Why don't you cover this aspect in your process? CVSs is only evaluating the vulnerability itself. Absolutely true. But coming back to the point, you need a proper asset management, you need a definition what isn't critical and uncritical asset.

And if you have this information for sure you can use it. But Sorry to add to that Christopher, I think that is also key to understand that CVSs is not to be applied just only, you need to add additional information into this logic. And I think that brings it together. Like if you have an asset that might not be a key asset or it might not be even externally internet facing, then of course this is a different situation. Then you have something looking to the outside world. Exactly. Perfect. Then again, thank you very much and have a good day. Thank you on.