Building a successful vulnerability management service concept

Welcome everyone, and thanks for having us today and being interested in our presentation. We would like to now take an organizational view on the topic of vulnerability management. As you have seen, there are different kind of stakeholders in this.

Now, from the perspective of vulnerability management, we are looking at it from a service perspective and that's what we want to present to you today. As we had already some kind of introduction already on the topic. I think we can keep it rather short on the introduction to vulnerability management itself. But from our point of view, it's a service that we want to provide to the larger organization and we take a look end to end to it in the sense we've already heard about CVEs, which have an important role from our perspective. There's also the part, how do you detect it?

There's scanner technology involved, there is manual processes involved. You wanna somehow govern it to understand, okay, what do I do first? Because if you turn on scanners for example, there's a lot coming through and then processes to the end to understand, okay, what actually should I do to really close it out? How do I make sure that the patch really gets to the end? And that is kind of what we want to look at today from the service kind of perspective. So as mentioned before, for us what is really important in mid to a large organization, there's a lot of teams involved here.

It's not just one team that does it all, which would be easy if you have everything under your control, but it's kind of different teams that need to take a certain task. And I think that is what we want to highlight with the end-to-end, it's not like you have a process and you provide a certain piece to it. You have to make sure that the whole concept is delivered because at the end, your customer is not interested to speak with five teams.

The customer who wants to have his business risk addressed wants to make sure that at the end the service is delivered and he doesn't need to speak to many, many people. And the security posture of the company is on a higher level. So That's where a lot of organization set some rules out. How do we want to take care of our security, including our security posture. And this is building then the basis for us to say, okay, if these are our requirements, how do we take that further down? How do we implement this? What are then the details that we have to look into?

So that's where you have a certain information security framework where you define your rules or your control requirements, and then you travel that further down into your documents so that you have different kind of explanation what, what are your processes, what, what are the controls that you have to implement? So, and we'll take a further look into how that looks in more detail at a later slide. So obviously I talked before that you can do it on a manual basis.

So that's for example, where you have penetration tests, you have red teaming going on, you have threat hunting, but you also have the different kind of scanner technology. And in these days there's also a particular situation where one technology is not covering just one topic, but several. So you also have to put that into perspective of the overall organization. So now what are the key points that we should consider here? Cool.

So hi, Nicole and I come from the operations team, so I hope to bring some, some of the insight from my side as well. So the way how we perceive the vulnerability management, at least on our side, is it's a set of kind of sub-services that can be either managed by one team or by several units, which kind of makes it very important to have actually a very well-defined target operating model together with roles and responsibilities that SIM level will talk about a bit later. And I would maybe reflect on the presentation that we heard earlier and actually have a very similar point.

It's very important when we have some vulnerabilities that we find to actually assist them based not only on the vulnerability itself but also on the asset and on the path that they can be used to exploit some of the important assets that we might have in our in infrastructure. I think you can go to the next one, right, for the centralization. So what are the other keys to the items to consider? Now we are thinking about centralized vulnerable management that bring several benefits.

Well, apart from the obvious costs saving by using the economy of scale, it's also the, let's say centralized unit with all the expertise within the company. So we would kind of have the skills, the knowledge, and could serve as, as a single point of contact for everyone who has some concerns or wants to secure their systems and right, the automation and API.

Yeah, that's something I would want to also reflect on the presentation before I see. We are very much aligned. So the API and the programmable access and the automation itself play a very key role in our operations because with the, especially with the cloud and the increasing the scope, it's important to automate everything because manual way that we worked with before is just no longer an option. So the automation, the API and the capabilities of the AP, I definitely play a key role within all our processes. Right.

So I already mentioned that there's usually an information security framework that sets the rule, kind of the law for a company on how you do security. That's where you get the control requirements. But actually what are the co control requirements? Where do you get that from as an organization? So I think it's a mixture. That's what we brought to you today.

On the one hand side, of course there's certain legislation, the regulator tells you certain things that you have to comply to and audit, but of course there's different kind of standards on an international and national level that you have to fulfill. So an organization has to address that to their needs and what they have to fulfill. For example, if you are a company with a critical infrastructure, then tis might be relevant for you. So the requirements may be very different to you being a rather small company, not having some critical infrastructure included.

So there's different kind of levels that you can apply. And that also depends on, on, for example, how you define your crown jewels. We would also add that of course, if you have people working in a team on a specific topic, they have the subject matter expertise. So it's not just going through a document from the legislation saying, okay, you need to comply to this line.

It's also, okay, we have the experience over the years, what puts an additional layoff security to us. Of course there's also some kind of market evaluation that that plays into us.

I, I think that's connected to the subject matter expertise. And besides the security or security, in a lot of cases it's also connected to data privacy because that's kind of playing hand in hand together for the compliance requirements. I think that's something that you always have to really look carefully after because of, of course compliance is very important and there's a lot of requirements, but we have to distinguish what are really compliance requirements in the scope of security and which are separated compliance requirements.

And then usually I think for the security requirements, there is the theoretical part. So what are the requirements that are given to you? But there's also the practical parts. Not always do we have a technology that addresses all our scenarios, and that's where information security risks comes into the play. How much is an organization accepting the risk to not address something because the value in putting the tense tool on top and closing a small gap is really reasonable. I think we as technology people tend to in a lot of time, put really a lot of effort to close everything out.

But I think that's also the balance that you have to take when you look at what are really our requirements, what are we addressing in the, in the first place. And then when I say customer feedback, that's of course in our case internal feedback that we get from our, from our business that is asking for certain services. And that might also play into our control requirements. I think the topic that most of you have come a lot of times across is the target operating model.

And I think that has been put out many, many times and it's not the easiest to define I think in a lot of projects that at some point been put out and taking a long while. So from my experience, I, I used to take a very pragmatic approach and break it down to people, process, technology, governance. And I already had someone asking me why we put rules in here. That's just from experience that from various topic we had always something that we would take out.

And going back to vulnerability management, that's for example here where we would consider more on the rules, which we define as the score. So we heard already if you turn on a technology to scan for vulnerabilities, you might end up in a huge number of vulnerabilities at the first place and then you need to work it through. So you really need to define your rules, what you're looking for, and then in the second step give yourself some rules in how much, how fast you want to address this.

Because there is unfortunately no market number that you have to do react in this many hours on this vulnerability because I think it also depends on how you set yourself up in your organization. So from that perspective, I think at the cyber revolution summit, I already went a little bit into the processes, but I think that's where I mentioned already you have on the one hand side tools that you can apply.

On the other hand you have manual processes and then at the end, out of each process you have vulnerabilities that either you have to address immediately because they are so critical that you directly have to take action or you have something as just mentioned, you get a whole bunch and then you have to distinguish what do I do directly or what can I shift a little bit? Because the risk of the organization is probably not so high, like another vulnerability that has come out. So that's kind of rounded the process.

And once you have done this pre-assessment, then you can forward that into your remediation process and make sure that the patching actually takes place for certain examples. In terms of people, I think that's where you usually look in two larger organizations into the three lines of defense model. So you have the first line that in our ca case provides the service. You have the second line that puts out the, that puts out the security requirements, the IS framework.

And then you have in the third line audit, that takes a look at both lines and how they are delivering against that in terms of governance, besides the score that you have to consider.

There's also the point, how do you report how good or you bet you're doing on your service in terms of vulnerabilities, like I have a lot of vulnerabilities being identified through my scanners or through my manual processes, but how do I report to senior management that I'm doing good or bad on my security posture because I'm actually able to follow up on remediating those or I'm not following the timelines that I have set to myself and how quickly I have to act to those.

So that's something that, for example, you have to mature in KPIs for the organization, how you want to report on that one and then accordingly escalate if you cannot keep up with the rules that you have set to yourself. So in terms of vulnerability management, I think again, mid to large organizations a lot of times face the journey to the cloud. And that's where I would hand over to my colleague because I think that's where a lot of us are looking at the current situation, how we can transfer this service to the next level, which will be cloud.

Yeah, I kind of just wanted to also bring our experiences with this because well many other companies, we are also on the journey and well, there are some difficulties that we encountered on the way. So one of the ways how to handle vulnerability management in the cloud that we let's say tried out at the beginning is to use the tools that we use on premises, I mean natural kind of approach where we felt terribly. So we figured out that some of the applications that we have do not really cope with the dynamic environment that we have in the cloud.

So either being different asset types, we have some ephemeral devices that just pop up and disappear even before we can detect it. And even as far as the detection goes, not everything is really accessible to our vulnerability scanners, which is why we looked into other approaches is, well one of them would be to use some cloud specialized tool. We've been on many presentations, so I assume you've, you've already heard of some and that one would that one definitely help with the whole process of vulnerability management?

So from the identification, classification and the actual remediation, again in together with the API and the automation, we're actually able to increase the, the, the, the security posture that we have improve it a lot. Now, most of the products that we have in addition are software as a service based, meaning the skillset of the people also trying change this on our side can now focus more on delivering the service itself rather than on managing the underlying infrastructure, which is definitely helping us out to deliver better service. Alright.

I mean I know we're running short on time, so let me keep the, the rest rather short to allow maybe one or two questions. So I think a crucial part to a service concept is then also a service catalog, making it visible to your customers, even if it's in our case, internal customers, what actually are we delivering? Because you can break that maybe down vulnerability management, you may define as one big service, but as said before, you can even classify that deeper and then say, okay, penetration testing is probably a different service.

Like red teaming is probably a different service than providing you scanners. But at the end what's counting is what is falling out and how you handle it. And that's probably the same approach for each of these processes. Now I think for the service catalog, what I mentioned at the very beginning, you don't want to talk to 10 people. You want to have the individual, you want to have an individual contact that you can go to.

That might be a ticket system, that might be an email address where you can place your request and then you kick off the process if there's any kind of request that needs to be fulfilled. So in terms of time and yeah, summarizing, I think vulnerability management as such, and we heard that in in previous presentation is a topic that's out there for quite a long time and the service concept itself I think is also there for, for quite some time.

But now there's the challenge again to bring the both worlds together because we're facing more and more technologies that are moving so quick that we have to really get an understanding on what are the security capabilities that we need to put forward to address our portfolio. You saw the, the example with cloud, that's, that's one point to make and I think that kind of wraps it up for today. So we would open up for questions in case there are any great.