Good morning everyone. Thank you, Warwick. You already covered half of the subjects I want to cover in my keynote in the minutes, so that helps me going a bit faster.
Yes, I think Warwick touched the point. We don't have a shortage of tools. Usually our challenge is to have the right tools in place, and that's a security issue. So we needed the tools that really match our risks, that help us mitigating our risks.
And we, we need to keep the number of tools in an, at a level where we can handle it also from a, from a cost perspective. So on the other hand, we all notice this situation. There's an incident, worst case in our organization, maybe in a a peer organization or it's something that becomes very prominent in the breast. And then there's the call from someone from a sea level saying, Can this happen to us?
Or what do we do about that? And then we entered the headless chicken mode running around uncontrolled and trust, acquiring some new tool to, to solve the problem.
So the first question is, why should we assess this? Why should we assess our portfolio? There are many, many, many aspects and some of them are more why we should go down, why we should add things.
So it's, it's, it's a bit of a mix. So we have always, even in cyber security, we have cost pressure. So we need to think about where do we spend our money best? We have regulatory requirements, which may mean we need something in addition to cover some of these requirements.
Ideally, we don't, don't only cover the regulatory requirement, but ideally we get better in security, which is a very different thing to keep in mind. So checklist compliance doesn't mitigate security risks, at least not necessarily.
We have currently a lot of things around supply chain risk. We need to do specifically when you're supplier, you're, your large customers might request you to do certain things in security. So this might drive the need to invest in some parts of security.
We have new attack vector, so we need to have the right tool in place also for different types of attackers for changing attack targets. So how are they coming in, what are they looking for? So we see more things happening around the entire OT space. For instance, operational technology these days, and this will become worse, no doubt about that.
And, and when we look at OT security, then this is sometimes still bit even more major field than IT security, also even more complex to admit. I I would possibly phrase it more interesting, more challenging.
We, we see new technologies, yes, and some of them are definitely useful, some of them are a bit over promising, but we have these too many tools, too many technologies, you know, alone understanding what does, which type of technology, what does this bus mean, what does this bus mean?
Does it really help me? Is a challenge. We have the skill gap, so having the people in place that really can make value out of the tools.
So, so many of you might have, might have some experience with seem tools, so security information in event management. And the big challenge, this is getting better and, and with SOAR and, and new types of technologies and managed services, we, we really are creating more value out of it. But the big challenge always was, especially in the early days, you had a tool for analytics, but then you need to set up all this rule sets, et cetera. This is challenging. And we see the managed services evolution, which helps us to say, okay, maybe we don't need all the tools in our own organization.
Let's trust someone with this XDR mdr, so as a service solution, do the stuff for us or do at least vital parts for us.
So we need to review it. And it is complex. This is something, and this is definitely not complete, but this is something which is a result of a bit of an exercise we did with the Analyst team a while ago where we trust listed all the acronyms and then thought about how are these things related, what does overlap cetera? And this is the craft of out of that.
So, and as I've said, it's constantly getting more complex. So there are too many tools, there are too many technologies out there, no doubt about it.
So how, how do we assess this? I think this is the important question. My perspective is there's no doubt about we need to assess it. How do we do it and where should we focus on? So what does, what do we need in a, in a good sort of a good portfolio of cybersecurity tools?
The one thing is it must cover the known and the unknown. And in many of my, my presentations, I use a pyramid, which is split into three parts at the bottom, there's the white part. This is the known part, this is the known and good part correctly.
So why at the top, the dry of the triangle, there's the black one, this is the known and bad part, which is not really problematic. If you know that something is bad, and if you can identify it, then we should be able to defend to protect. So the problem is the gray area in between the unknown, the things that are happening where we don't know is this good or bad and we need technology for both, for known and for unknown. This is part of what we should look at when we build our portfolio. We need something that helps us understand the attack surface.
So today we, we come on talk about a tech service management with vulnerability management as part of it, very important aspect. We need to look at not only protect, so you all know in this cycle and all of our s of that, surely it is about not only being able to protect and to detect and to respond, but also to recover. So we always need to think about continuity and recovery because we will be hit.
It's not, we may be hit, we will be hit by cyber attacks sometimes and we need to be able to recover to keep our business alive. And there are a lot of things that can go wrong.
So, so I just recently discussed with a customer about business impact and when, when you take just the, the, the, the, the stock and the automated systems that randomly put some stuff into the stock, if they don't work, then your entire production doesn't work. It must be built for change. So nothing that aesthetic, but the world is changing, attacks are changing, so we need to be ready for that. Risk oriented, very important. And this is a discussion that that really drives me sometimes crazy when when someone then says, Oh, but that is not secure enough.
There is no 100% security.
Most of you might have seen the movie Illuminati with the eyeball lying on the floor. So there are always measures to bypass security. A bit drastic, I know, but true. And for me it's important that we get better and that we understand where are the biggest risk and that we tackle the biggest risk that we always think in risks and it must be layered. So NIST cyclist layered zero trust is about layered security, about identity wise, network system, application data, software layered security, multiple layers of protection. So this is what we need to do.
And when we assess we need to to use methodologies. I don't, I don't have the time to go into detail on such technologies, but we need to use, use standard message methodologies and technologies. We need to use standard message. So we are Analyst analysts strongly believe, inspire and scatters and, and I believe that these are really valuable tools if used in the right way.
So understanding, for instance, if you use your technologies and you create a a scatter metrics, which, okay, one axis I have the sort of high TCO to low TCO on the ir I have the level of risk mitigation, low risk mitigation to higher risk mitigation. Ideally you construct it always in a way that the upper right edge the best tools are. So you need to, to do the managements right, But then you could bring in the various tools and look at, so what do they cost over time and how much do they help to help in mitigating my risks?
And creating such perspectives helps you to get to gain clarity about the value of different tools. You can do that in multiple ways. There quite a number of access you can use. You can distinguish between the, the must have and the should have and the nice to have tools.
So this is a bit the way I do it and you can't do the same surely for comparing tools for when you compare technologies. Starting with a spider usually is the better way where you say, okay, I have whatever, 8, 9, 10 axis like, like usability, like certain technical functions, et cetera.
Like the integration to what you already have, like the the skills. Do you have the skills in place and if you do that and and then measure two or three or four options against each other, then, then you get a very good picture, very good understanding and graphics like spon scatters help and visualizing and visualizing is really something which is important and also more helpful and better to understand than trust and excellent, truly you can do the long RFI thing, but that is probably more the next step when you then go into detail and say, okay, what do I really select?
So you need methods and you need to really roughly thoroughly analyze the various types of technologies you have and also to understand where your gaps are. And so what should be the outcome of that and how do you also work and think about gaps. So what to achieve there, There's another angle you need to take from my perspective. And that is saying, okay, where, where do I need to to be? Where do I want to be? And that is this more, more holistic, holistic perspective. You can do that in different ways.
You can trust create one page put in this cycle or something that looks a bit like the, this cycle beaten four or five or six or seven stages. And then you say, which technologies around that for every phase do you have or do you, first of do you have? And if you then identify, oh there are parts of the this cycle where I don't have something in place, then you know, okay, there's appear to be some gaps in what you are doing.
If you have areas where you have not enough room on your one slide to to bring in all the technologies you have in a, in a readable manner, then you also have some some indicator of okay, there's something to change. So regardless of which cycle you take, I think having something also in place as what is your security portfolio, security architecture, your security fabric is very important. And so like we created the identity fabric a couple of years ago, you should consider creating something like your security fabric.
So what is the fabric that helps you in protecting all of your environments, which provides all these services you need to keep your world as secure as possible to mitigate risks. The best way this is done something you compliment by more, more architectural dims. But as I've said, starting around the, the core elements of, of such cycles, like the cycle or the one we, we are showing here is a good starting point to understand by relatively complete the other way to do it.
And we do that in in different areas.
We, we have created a couple of reference architectures like for identity, like for cybersecurity. You can and should also do some exercise around this reference architecture. So this is something when, when I, when I look at advisory and when we work with customers, then one of the things we very commonly do is walking through such reference architectures and the first thing which is a, I think a very important outcome is understanding which elements sort of exist and this is a living thing. This changes exist in cyber security or in identity today.
And discussing is this relevant for the organization and does it already exist? And if you then just do that exercise and say, okay, these are the various buildings blocks within that and you rate it against where does the organization stand on a radar? Usually do a scale from zero to 10 and how relevant is it for the purpose of that organization on that same scale?
Then you again can, can create a wonderful metrics out of that which helps you to understand where are your biggest gaps and your biggest needs. So if it's there and important, it's fine in such a metrics.
If it's important not there, then it's where you should focus on. If it's there and not important, you should consider retiring, etc.
So yes, I know retiring security technologies is a tricky thing because there's always this fear of if you are retired and something goes wrong, then I'm in trouble. No doubt. So it needs to be well justified and explained that the risks are understood and are covered by other technologies or that there are just other things to do. So working with that, with such technologies really helps you in doing such an assessment.
Such, such an assessment is at the end of the day, it's nothing you do in an hour, but it's also nothing that should take you month.
It is something which is an exercise that can be done in a relatively fast way and it should be done to understand where to put your focus on where to put your emphasis on and then moving forward and, and and sort of giving a good structure, putting all of that in a good structure. So even why we talk about tools assessment, it's not just tools.
Yes, you need to have for these cycles, you need to have the right tools in place like for, for identification, risk management and asset management. Yes. Whom of you does have a asset management that really tells which devices, which software, et cetera are in place?
Not so many, Yes, more hands going up. The point is surely you can't protect what you don't know. Very simple rule.
So assets, asset management software, bill of materials, all these things are essential. You need tools to detect, to protect, to respond and recover, recover, recover and to continuously improve. But you also need the processes and you need the people and not just the, the security geeks. You need the management, you need the board communication, you need everything. You need to set this up in a, a well land manner and you need to evolve here. So there I trust reason that the plan build, run, improve is, is totally outdated.
I'm not exactly sure, but because even in agile trial, at the end of the day we, we do it, we do trust in very short cycles plan and build and run and improve. So in agile the cycle lengths is going down, but at the end of the day it's still that we, we have this.
And I think when we put it a bit in a different way and say for strategy then this is really more long term the targets, the alignment, dissemination into the organization. The evolution for, for architecture, it's a more stable thing for, for implementing it.
We go more into agile trial, but at the end it's always following these stages down to operations. So we should think about what do we need at which level so that we have a defined strategy for security, a stable architecture and a relatively stable set of tools that we continuously involve and that we operate in a well thought out manner or let operate and manage services in such a manner. This is I think what needs to be done that helps you then finally in creating your cybersecurity fabric where you need them to select it to.
We have everything in places you truly know as Analyst to support you, but in the interest of time, I'll leave it here and say thank you to you for listening to me early in the morning. Thank you.
Thanks Martin. We do have one question online here. What difference do you see in tool selection for cyber versus business applications? And then there's a kind of a second question is how do you handle lock in risks?
Okay, both very, very good, great questions at the end. A tool selection follows always from my perspective, the same approach. You need to understand the segment, what you're looking for at end. Do a long list, short list, RFI tested, implemented. So from a structure there's not that much difference. Different tools, different part, different questions, but the way you do it should bera the same. Sometimes for cybersecurity you might be driven by this headless check mode thing and need to do it very fast or panic mode. We could also call it for the second question around lock in.
In the interest of time, very fast, I think you need to understand whether a lock in risk and how it looks like and then it's just decision thing. You need to decide about what is the price I, what is the alternative. So if I go for that which is not logging, I might have higher integration costs and other challenges or, or as additional license costs, et cetera. For the login decision, I might say, okay, I am, it's hard to get out. Always think about your exit plan a bit, at least from the very beginning, but make it a clear decision. I think this is the most important thing.
The biggest problem is log in, is that you end in in a log in scenario without being aware of it. If you're aware of it, you can handle it.
Okay, thanks Martin. We are at time, so another round of applause for Martin please.
