Analyst Chat #91: Vulnerability Management

Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth. I'm lead adviser and senior analyst with KuppingerCole analysts. My guest today is Christopher Schütze. He is the director of the practice cybersecurity here at KuppingerCole analysts. Hi Christopher. Good to see you.

Hi, good morning. It is great to have you, it's been quite a time, but finally, we've made it to see each other and to do a, an episode of this podcast, we want to talk about vulnerability management and the process around that. To start with that. What is vulnerability management and why is it so important right now? Why is it vulnerability management so important? So if you have a look at a bigger organization, maybe a regulated one, they have a lot of it assets. They have intra infrastructure devices.

They have a normal mobile devices to have different platforms like AWS, their internal servers. They have a lot of operating systems like a Linux like Microsoft server and all that stuff. And a lot of source code, a lot of automation, a lot of scripts and all that stuff. And on the other hand, there are the attackers. They have zero days, they have exploits, they use things like not installed patches. They use misconfiguration and all that stuff.

And the intention behind a vulnerability management for an organization is to close gaps, which allows potential attackers to get access to your it systems to your assets or at the end to your data, or in the worst case, a very common topic. Also these days is ransomware attacks. So at the end, encrypt all your data, all your things and ask you kindly for a lot of money to get Xs again. And that is the goal of vulnerability management to have a central point where you can identify all the misconfiguration, all the needed patches and all the things you have to fit, Right?

So it's about taking a step back and having a full picture of potential vulnerabilities and how to remediate them as a whole and to have an ongoing process for that. How would such a process look like? How does this management process, how is this implemented within an organization? How does it look like Most important thing? When you start with vulnerability management is know your assets. I mentioned some in, in your previous question, like servers platforms and all that stuff, and this is something you need to be aware of.

You can do this automatically wasn't discovery scan, or in the best case, you already have something like a CMDB all to also maintained with responsibility. And maybe also with some categorized station, like for instance, operating systems, server device infrastructure, or source code. That is really the first thing you need to have. And then based on the CMDB on your database with all your assets, you have to define what is needed to scan what is needed to evaluate it in case of vulnerabilities in general.

So for instance, if it's just an internal networking device without outgoing connection and things like that, if there's an other level of security and vulnerability management needed, then an open API, which is accessible from everywhere. And same as if you use cloud technologies like AWS containers or Lambda functions or something on Azure, which is only accessible via your internal network. And there's no other paths to that asset. And that is an important thing. So discovery is the first thing, and then we call it categorization. And then for sure, you have to define what to do.

So the security assessment, and this is really dependent on the asset. So if you have, for instance, a new implemented application, which is planned to roll out within your organization, it's a little bit bigger, but a bit broader because then you have maybe source code, you have platforms, you have operating systems and maybe also scripts. And therefore you need to define which of these single assets needs to be scanned, but you have to also look at the overall process. So think from one hand on a single asset, but also don't forget the overall process.

And this is usually the red teaming or pen testing, which also allows you to challenge your new asset against attackers, Right? So we know what we have and we know the security status from an assessment. What would then be the next step? I think it should be then about protecting those assets. Yeah. Fixings for sure. First of all, you need to scan your environment. There are existing several tools for containers, for servers, for operating systems, but also for scripts or source code. This is then something you define in security assessment phase.

And you also define how often this must be done. And it also in which stages cause in your organization, because you usually have a development integration environment and the production too, but all with different levels of excess to what other arts assets and then is the phase where you receive usually very long list of potential vulnerabilities. And this is a really challenging thing, because for instance, if you scan a 100 Microsoft servers and each server has something like 200 informations and patches, there's a lot to do.

And this is a big thing here because most of the vulnerabilities can as, and especially if you combine more than one and that typical approach, it becomes really fast, very complex for the corresponding responsible asset owner or it teams. However you call it to fix the things. And therefore we highly recommend to create something like remediation packages. So building bundles of really valuable fixes or reconfigurations specific for a specific server or a set of servers or a set of application.

But therefore you also need to ensure that you pre-filter or evaluate the results of the vulnerability scanners, because often there is just the information about there's a service enabled, but maybe your device isn't connected to the internet. And then it's not an, a real vulnerability or at least a threat or at the end, the risk It's really about prioritization, about applying a risk-based approach there as well.

So to start with the most important vulnerabilities, but if we think of the process of making patches available, I, I think there are often vulnerabilities where no patch is yet available or where applying the patch is not feasible because of downtimes because of restarting the service or just not being able to, to install it for, for, yeah. For business reasons. How do you deal with that? Is this also part of the vulnerability management process? Yes. For sure. The vulnerability management process at all is a big process.

And as you mentioned, there are very often things you cannot fix maybe because of the patch cycles of a system is maybe only once a year or only once a month or something like that. And then you cannot install a highly critical patch immediately. You have to plan it. And that's an important thing. And on the other hand, there are often things which cannot be fixed. Maybe it's a very old mainframe system or whatever, with a very specific where nobody in detail knows, I know this should not happen, but in reality it happens and therefore you need something.

And this is where vulnerability management directly integrates into the it risk management, something like a risk acceptance or a risk register. So you need to be aware of which risks you cannot remediate, and maybe you can remediate them in, in one year or something like that. And that that's really a typical thing for a risk register.

You might need an risk acceptance, maybe just from the it asset owner dependent on the criticality or in the worst case, even of the chief information or chief information security officer, or at least at the chief executive officer really depends on the business impact. Often corresponding risk. Maybe if your main service website is not patchable right now, but you have to install something and then it's an highly business critical risk here, Right?

So we, we, we have also a process for these non fixable vulnerabilities, but what does this imply some times there has to be a process for, for taking care of these vulnerabilities? What would you do with such an accepted risk? One that is identified as not being fixable? How do you deal with that so that it does not get, get lost in the, in the process?

So usually in the risk with just a, you have something like a risk acceptance and some interval after six months, three months, 12 months, depending on the criticality that you have a look at it again, and that is usually how, how to solve it and, or maybe in the phase in between. So if you only can update or patch a system once a year, till the next patch cycle, you have to accept the risk. And this is something you really have to be aware of. Right? So vulnerability management is cyber security, is, is it security at work?

So it's really a large concept and a large process that needs to be executed continuously. So I think we will talk about that topic in the future, even more, but when organizations are looking at a vulnerability management, what would be from your point of view, the first starting points, where to look at, how to prepare for that and how to implement parts of this process to keep going and to get better at cybersecurity.

So as mentioned at the beginning, the most important thing here is your CMDB know your assets, and this is something you also need in that general, it risk management approach, you know, your assets, your, the things which are part of your organization. And depending on how you approach risk management in general, you can start with business processes and then decide which it assets are related to and how critical it is if they are not available available or, or if they, the integrity is in danger or things like that. So this is really the first thing.

Therefore, tools exist to scan your environment, to scan your networks, to scan your public and private networks and all that stuff. And then the next step is to have responsible person for each asset. And usually this is done via having categories like dimensioned infrastructure, device platform, operating system source code, and maybe the concrete items in your organization are deriving the responsibility from the category in a first step. And then you need to define what are the most critical things you need to scan.

So again, the security assessment phase, but more the approach. So do I want to scan against zero days again, not install patches against source code vulnerabilities, misconfigurations all that stuff. Usually I would recommend to start with the most critical things. This might be the Linux server environment or the windows server environment, and then improve step by step. So it's almost impossible to create the perfect process in a single phase. It's more an repeatable process where, which is optimized, which was every step. And that's the most important thing to do.

And to start really with vulnerability management and then as mentioned, don't try to create only patches. If you have a lot of it assets or it asset categories, you should really think and remedy ation packages. And this is a thing you really have to start early with. So maybe bundle with windows or Linux server or also on business processes. Right? So I understand that this is a constantly a continuous improvement process that's going on. So it's really starting with the most important aspects and then getting better over time.

Yeah, I think we will meet again for this topic to learn more about individual aspects today. We had a look at the bigger picture of vulnerability management, just from the helicopter view, what needs to be done, where to start, how to understand what is really to be and how to, to initiate that process. So thank you very much, Christopher, for being my guest today, we will continue this discussion. I'm quite sure. And I'm looking forward to seeing you soon talking about this topic or another related cybersecurity topic as well. Thank you very much.