Implementing Zero Trust Principles: Crafting Your Cybersecurity Fabric

Welcome to the workshop, part of the cyberevolution. So this time we only have 90 minutes. So for those of you who knows the KuppingerCole or in general the workshops at our conferences, usually they last three to four hours, which is very intensive, also helps a lot to understand the topic. But we thought this time we limit it to 90 minutes to give you more or less the insight. But no worries, we will also talk a lot about the collaborative part. So really the hands-on character, that's the idea of today as well. My name is Christopher Schütze.

I'm on the one hand responsible for the KuppingerCole information security. So our own security part, but also as well for our cyber security strategy around events, research and advisory.

And today, Alexei, my colleague, you can introduce yourself. Yes. Hello and welcome. My name is Alexei Balaganski. I'm lead analyst and also coincidentally the chief technology officer at KuppingerCole. So nice to have so many people here and I hope more people are watching us online. So let's just dive into it.

Yeah, good point with the online people. If you have any kind of question, feel free to use the chat function on the KC live platform. I frequently try to check those questions and answer it as well. And for the online attendees, if you have any kind of, for the on-site attendees, if you have any question, just raise your hand.

Important, we need the microphone, otherwise the online attendees cannot understand your question. Alexei will walk around, I will walk around. That's the most important part. Okay. So there is some delay.

Okay, obviously not, but maybe I start to explain at least what I try to share the agenda for today. Perfect. Thank you. So as we start at nine o'clock, we will have a first introduction into Zero Trust in a nutshell. That's the topic for today. So crafting your cybersecurity fabric by using the principles of Zero Trust. And then the second part is, what is a good Zero Trust strategy? I don't know who of you already started to do something within the organization. Where are you in the part of the journey? What is your understanding?

There are different opinions or multiple opinions to phrase it that way around. That's what we see if we do advisory for customers. And then the most interesting part I think is more or less, we plan one hour for that, talking about how to really do it. We show the framework that we use by the Department of Defense of the United States as a foundation, the core reference architecture and the fabric, and basically how we approach. If you want to implement the Zero Trust principle, where do you start based on use cases and things like that? That's the idea for today.

And then more or less, we have 10 minutes for summary, closing and next steps. Yeah, that's the plan. But whenever you have a question, raise your hand. This format really lives from interaction, not me here being your teacher like at school. Christopher, by the way, not just any question, if you disagree with anything, you just have a great idea to share. This whole format is supposed to be as interactive as possible. Exactly. So also for the last row, if you want, please also feel free to move one row up in the first or second, whatever. Usually we do not.

We also come back to you if you want to ask questions, like in school. Okay. Maybe Alexei, you start with Zero Trust in a nutshell.

First, we have some slides at the beginning, but only for the common understanding. Basically, just a really quick refresher, like why this whole thing exists.

I mean, probably the biggest reason, the biggest kind of appeal of Zero Trust as an idea is it's so simple. Like, I don't know, Christianity has 10 commandments, Zero Trust has only one. Never trust, always verify. It's so easy to grasp even by non-technical people. So everyone wants to have it somehow. And every time we are approached by a company that wants to implement Zero Trust, we always have to repeat the same story.

Yes, it's not a product, it's an architecture, it's not just a technology, it goes beyond tech because you have to change your processes and your environments, whatever. You have to deal not just with a specific part of your IT, like not just networks, not just data or anything. You have to cover everything, ideally, and that's a journey. And finally, yes, Zero Trust is not just done for the sake of it. It has very tangible business benefits, and some of those are quick wins, like VPN replacement. Others may be more strategic and long-term, but the ultimate goal is not to become Zero Trust.

The ultimate goal is to become more productive and secure. So yes, again, we don't have to go through all of those basic tenets of Zero Trust.

Yes, nothing happens without first making an informed decision. Is the agent trying to access a resource, the one who he really is, or it really is? Do they have the right access permissions? Is the access channel properly secured? And of course, like strong authentication or policy-based access, least privileged principle enforcement, this all kind of automatically belongs to the whole idea of Zero Trust.

And finally, I think that a lot of people forget is everything has to be monitored because without having this dynamic real-time context of everything that's going on in the environment, you just cannot make those decisions properly. So this is basically the entirety of Zero Trust in a nutshell. This is how you're supposed to build it.

But again, it translates to a lot of non-technology and more like process and strategic questions. How do I do it? Where do I apply it? Where do I start? How do I continue? And Christopher, I think this is like a slide that our advisory department has developed over years, maybe. So maybe you could just dive a little bit deeper into the analogy.

Basically, just a few words about maybe first question to the audience in general. Are you a beginner in Zero Trust or did you already do something in that direction? Maybe beginners raise their hand. So we have two and a half. The others, medium or expert?

Medium, medium. And guru? No. I would never say that.

Okay, perfect. So we have a good mixture. Then I spent some words on that slide. Usually that's what Alexei already mentioned with the real-time context data, we have different types in the organization. You have the user, you have the device you use, you have the network you use. So this device, I use that device in the network, in a separate network of the conference to access the streaming application and share my data. That's basically the idea. And here is a lot of information used that can be used for verification.

Am I authenticate against the devices, the device authenticated against the network, and so on and so on. And that's basically the idea behind that picture. Everything goes into some kind of policies, understanding data, allowing or more or less going in the direction of preventing access unless it's verified. And that's more or less the idea of Zero Trust and of this slide in that context. And the next slide then goes more in the technology perspective. So I talked about user, device, and things like that.

And we as technical people, I'm usually also more on the technical side, you have a lot of applications or services running to do something like that. You have on the network level, you have a CM system for collecting logging information. You have maybe a CASB implemented. You have some kind of traffic management to optimization. Same applies for identity and access management. You have maybe some kind of monitoring. You have IGA.

For sure, you should have something like multi-factor conditional access, whatever in that direction. And the endpoint, you know your endpoints. In the best case, they are also managed. You have some health state of your endpoint devices. So not only the computer, also mobile device, smartwatch, whatever you have within the organization. And then the thing from an experience perspective, data. You have data. We have a lot of data. The challenge is what kind of data is it? Is it a database? Is it a query? Is it a confidential strategy? How is this identified, classified?

Who is responsible for data also applies for all the topic. And that is basically the foundation. And this slide is for confusing as well. I hope I... So Christopher, basically, you just want to say that zero trust is everything. Yeah. So when people come to us and say, where do we buy zero trust? The first answer is you cannot. The second answer is you probably have a lot of bits already, and you just have to recombine them properly. I guess this is the real messaging of this slide. Exactly. That question was already asked. So we can... Any questions so far?

Or anyone who says no, that's stupid. That's completely the opposite of my understanding. No. Come in. Yeah. Please verify yourself. Otherwise... We will be watching you. Perfect. So welcome to the session. We just started with a brief introduction into zero trust, and we will now start with the second chapter, talking about good zero trust strategy.

So here, I like to call this entire... Can you hear me all right? Yeah. So I like to call this entire strategic approach to zero trust Feng Shui of IT. Because just like the actual Chinese philosophy of it, you really don't have to build a new house to make it Feng Shui compatible. You just have to rearrange your furniture, put in a plant in the corner, and maybe just add some lighting, and somehow you are in harmony now. The same should be applied to zero trust as well, right? Because you don't have to rip and replace your existing infrastructure.

You just have to make it compatible with those strategic tenets somehow. And this is exactly what we are going to be talking about today.

Yeah, and as mentioned at the beginning, we usually used in the past a lot the Department of Defense approach here. The paper is also linked here. So the slides can be downloaded on the KC Live platform afterwards for sure. Usually I recommend only coping a call documents, but this is for sure, this is also a good document. It's a good foundation to work with it. Because it gives you some kind of framework and common understanding how to implement that really.

So again, we can see the five pillars, user, device, network, application. What changed, and this is also covered in our cyber security reference architecture, is the topic visibility and automation orchestration. And that is really an important part, which differs from the DOD approach to some other existing approaches. Because the key more or less is having the common understanding, the real-time context data and be able to do something like that. It's not sufficient.

I mean, it's a starting point having a central policy decision point or enforcement point. But you also need the data to verify for your policy and you need your policy as well. And that's, we know that from starting with defining roles, business roles, whatever, that was a nightmare. And if you do it wrong, it also gets a nightmare with policies as well. Then you just move the problem or make it a bit more complex. And that's really the key thing of a right initiative. Have the right prerequisites and see what to build out of that.

And by the way, Christopher, the word policy you mentioned, it seems like everyone's talking about policies now, but people have really different understanding what it even supposed to mean. For some, policy basically is a set of rules like firewall configuration file for others. And I think I share this approach more. A policy is only a policy when it's declarative. You do not have to learn a special language, ideally. You do not have to run any code to define a policy.

And it's then through automation, it somehow translates into the actual decisions and enforcement controls, whatever you name it. So maybe this is something which we should focus on a little bit later, if the audience has interest. Yeah.

Basically, question. Is any one of you already in the path to define policies on a certain level? Or are you still on the phase where you set the foundation for something like zero trust? Do some of you have a policy decision point implemented? No? Okay. And that's not a surprise, honestly. We talked to many organizations and that's more or less the level.

I mean, probably all of or many of you have something from Microsoft and conditional access. That's one part of the cake, but does it cover everything?

I mean, basically, most of those stuff starts with the device and the user and not with the data and all the other stuff. You can do as well, but you need some prerequisites. By the way, again, this is both down to the definition.

Like, KubeioCore is a small company. We have how many, like 70 people in total? And we already have too many policies, too many policy enforcement and policy management points. I imagine that any larger company would probably struggle even further. So it's not that you do not have policies. You probably don't even know you have them somewhere. Any question here?

Ah, sorry. Microphone. That point that you just made was effectively what my colleague and I were just discussing, is that we're a relatively small organization. So we have policies. They're just not necessarily written down. So at first thought, you don't even realize that you have policies. And we actually have more policies for other people than we do internally. So it's always a good idea to write that down and codify your policies to make sure everyone's on the same page. Okay. Thank you. That's definitely true. And thank you, Alexei, for this extension of definition of policy.

I mean, I created for the company all the policies based for the ISO and TSAC certification. And I mean, it's just written down. The enforcement point may be sometimes missing on a technical base. But at least on a beautiful Word document or PDF, there's a lot of definition and policy. And I mean, if you want to implement always never trust, always verify, that's one policy. Then nobody can work. But you have zero trust. Congratulations. Okay. So any other question here or remarks? Okay.

This slide will be our main slide within the next 60 minutes, basically, because the idea is to go through that framework, more or less. Again, we have the five core pillars, user, device, network, system, app, data, and the two others, visibility and analytics, and automation and orchestration. And you can see here multiple items that are relevant on a certain – maybe I have a pointer here. That's easier. Perfect. Okay. Things like the foundation, user inventory. If I don't know my users, how can I decide anything? Same with device and so on.

And that is – we will come to that in the next chapter is the idea, really, to talk with you, go through that and discuss. Because what I always realize if we use that slide, it starts with what is a user inventory? Is it an LDAP inventory or is it a full-blown IGA solution? Depends. That's Matthias Reinhardt, if you know him, his favorite answer, if he presents something. That's a colleague of mine.

Yeah, that's basically the idea. With that slide, we will come back to it later. And yeah.

On my end, I would say we can jump into the next chapter, if there is no further question, that we really have more time to discuss on some hands-on stuff. Everything clear so far? Perfect. Yeah.

So, basically, I use this slide in different variations multiple times now, and I would repeat again. Zero trust has to have a set of minimal requirements. If you do not have them, it just never works. It doesn't even make sense to begin. And those requirements are obviously identities. As Christopher just said, if you do not know your users, if you do not know your – well, users are not the only kind of identity. If you do not know your services, applications, clients, whatever, how can you even manage access for them? Always ability is another one.

It can be a seam, it can be a network monitoring solution, it can be a combination of multiple things. But, well, you have to have a basic context to make those decisions. And finally, you have to have at least some kind of policy management, enforcement, and again kind of monitoring solution. With those two formal ones, most companies probably, hopefully, do not have to struggle. And those are the prerequisites for any other kind of IT as well. Policy controls is something we probably have to discuss in more detail later. Perfect.

Then, that was just in time, by the way. It's 9.20.

Usually, when we start to discuss with companies, with people about how can I implement zero trust, what do I need, what is my right to zero trust strategy, I start with the question, what do you want to achieve? What is the core message? What is your use? We use the word use case. I know you could also call it user story. It's not the full agile defined thing here. It's more like, what do I want to achieve? So for instance, like typical use case, I want to have my external or my visitors to access the wireless LAN and to access the internet. That's a very basic thing.

But I can also say, I want to have my people work from anywhere accessing non-critical applications. And then it's starting to getting complex. And we prepared three use cases, but I would also ask you a bit about what is your biggest pain point or where would you start with zero trust if you get maybe from your senior management?

Okay, I was at that conference. They said zero trust makes everything perfect. Let's do that. And by the way, let's do zero trust is not a valid use case. That wasn't the intention. Any ideas or any suggestions? My name is Taras. You said that starting with zero trust, you have to define your users at least. In case of IoT device, which let's say works standalone, is the user is always a human or how would you define a user? It can be also a human that interacts with the device, or it can be also a standalone device which doesn't need a human interaction.

This really depends on the type of your organization. If you are a company that is highly into IoT stuff, mainly developing any new stuff for the end customers here needs a highly secure development process and all of that, maybe you start with kind of that use case and include your IoT devices as well as an identity if they work in that way. If you are like coping a call, we mainly use office applications. We have our back ends and stuff like that.

For us, this is for a starting point too complex. So usually the idea of the zero trust journey is to start with your biggest pain point and also be a bit careful. That is what I want to achieve in this discussion as well. Which one is realistic? If you would take this use case, we need to verify, do we have an inventory of the IoT devices, responsible persons, some kind of classification of the things and do we need to include them? What do they access and so on?

Then yes, sure. But this depends really on the main purpose of your organization. If you are just a typical analyst company, a company that is working with office stuff, produces documents, knowledge, papers, PowerPoints, whatever, that is another starting point. If you are developing software, this is again something else. Then you have repositories, you have Git comments, whatever you use, API end points and things like that. In any case, you are absolutely right. Even if we somehow managed to set users, of course we meant any kind of identity.

The point again is that whatever you want to manage, whatever you want to enforce zero trust upon, it has to be already somehow, it has to have strong identities. If you don't have them yet, like for IoT use cases, a lot of companies are still struggling. Now there are crutches or workaround solutions based on proxy architectures or the age, whatever. There are a lot of interesting solutions available on the market now, but we can dive into those as well. Thank you. To build on the previous commenter's question about identity, when I look at identity, I kind of look at it in three buckets.

There's natural persons, where you're either dealing with your employees or your customers. You then deal with the next bucket of what I would call organizational identifiers. They're particularly relevant when you get into supply chain and trade. Then I think the third and more challenging is not only IoT, but more importantly, when you get into AI instances where machines spin up for milliseconds, they're there and then they're gone.

There, the inventory is less of, do you still have it or did it exist? When did it exist? What did it do from an accountability and an audibility standpoint?

To me, when I look at strong identity, those are the three buckets. As far as a use case or a user journey, maybe we can look at something that is more supply chain oriented, where you're dealing with a couple of those different things and perhaps less with IoT, which could be involved, but potentially maybe we can use something with GS1, G10s, GLNs, and stuff like that as part of the use case. What I would also like to add, also in terms of strong identity, but in general, first, what is zero trust? What is not allowed is forbidden. Then what are the typical use cases?

What are the critical applications? First, we need to define this and work use case by use case and see what they actually need, because we cannot do everything at once, the complicated slide what you saw. We need first to define what we actually need and what are the common use cases. Perfect remark, Ivan. That is exactly the idea, or maybe a bit differently. Take the use case and see what we need for that use case from this beautiful, full-blown whatever.

This helps you to build more or less than you identify maybe with, if you're more IoT focused company or more office-based company, then you have different schemes and then you see items. All of these different points, there are sub-items, and at the end, you build something like a prioritization, where do I need to start, what do I need first, or everything in parallel and that things. Then you have your journey to zero trust. Any other use case idea, or any concrete use case ideas? Maybe those guys in the last row? Anyone? Or the people that joined us a bit late? Or you?

I don't necessarily want to suggest a use case, but maybe a scenario within whatever use case we go with. I'd like to touch on what it would take to build out a policy for addressing some of the more advanced cyber security threats, because I find in common practice a lot of times even governments don't necessarily know what they're doing or care when it comes to reporting a zero-day vulnerability or something like that. What would be involved in writing policies for more advanced scenarios like that? So you mean more the policy definition part? Ivan?

And just another remark from me, you at the beginning said we need to use what we have and to rearrange it. So I think to complete the scenario, we must agree on what we have, what is given, so that we can use it. So maybe this is also a way to think, well, what do we have actually on tools and mechanisms already which can implement zero trust? Exactly. I think this is where we're coming to this whole Fabric topic.

Yeah, sure. That's why I added it. Okay.

Just for, as we prepared also three use cases, but we can build for sure something around IoT as well. Alexei, you rephrased this a bit. Maybe then you can explain it.

Well, again, this is more like a set of ideas where we could start digging into. I mean, everyone has different priorities, but these are just kind of things which range from really low-hanging fruits, like, for example, VPN replacement.

Everyone needs that now, especially, I mean, probably not as much anymore after the end of the COVID lockdown, but it's still a really critical topic which can be really easily solved like in many companies, like really the only thing you need is a credit card and maybe like an hour to define your first policies, or we can go all the other end and just talk about like ransomware prevention and stuff like that, or regulatory compliance. Policies are much more sophisticated in terms of defining those policies.

It might not even translate into fancy technology solutions in the end, but again, it all depends on your requirements, your use cases, or your risks and so on. This is where we really need your input, like where do we want to start? Yeah. My idea would be from my end, I would love to, usually this workshop takes eight hours, so we need to speed up a bit from that idea. I really want to share the methodology and also the challenges that we have.

I would suggest that we, on the one hand, use a more easy use case, like maybe the external user wants to access non-critical data from work from home, something like that as a foundation, and then we do a second one IoT-based. Could you maybe phrase exactly what you want to achieve? And always think not the most complex one, as the time is a bit limited. My company is manufacturer of a medical device, and I'm responsible for some predictive preventive maintenance module, and also cyber security for all this stuff.

So it all involves a gateway with a SIM card, so with internet connection, there's a cloud, some data collection to the cloud, some data analysis. So basically, all these three parts on your slide applies to my case, I would say. So you don't need to talk anything specific about IoT, we can just go for your slides. I just call it IoT because my part works standalone, so there is a human user working with this medical device, but my part is standalone and is kind of considered as IoT device.

So to build on this healthcare, and I'm coming from the same aspect as well, with GS1 and some of the others, with certain medical devices, they need unique identifiers, particularly when they're implanted into the individuals, there are certain national requirements with regard to serialization. I think the thing that potentially makes this a little more IoT and complex and perhaps fun is what happens when, let's say, we're talking about a pacemaker that's being implanted into a human, and that potentially has code that may need to be updated.

Who do we want updating that code when there's potentially a zero-day vulnerability? So does that make it fun, or did we go too deep into the weeds as far as complexity? I'll give it back to you. That's a really interesting use case, and I don't know if I would rely only on zero-trust here. I would say no.

I mean, that's something where I would prefer something like a cable, even if it's difficult. I mean, technically, a cable is also a kind of a policy decision control, right? It's more like remote updating, whatever. That's something I'm struggling with. That's a really cool use case. I also have a lot of something like that in my mind, but I think from a complexity perspective, that's a bit too deep into, or that's very too specific. That's more point. But I got your point. We can look a bit at the IoT stuff when we have a look at the framework and go through that one use case.

So if no one has the real one cool use case besides the two, some more basic stuff, I would suggest that we take this one, or anyone disagrees and says, no, that's too boring. I want to go. Maybe you keep the microphone here. Hi. I just had a brief joke. The cable to the pacemaker is the network access protocol in this scenario. Do you want to say something about these slides, Alexei? It depends on which one of those would be more applicable for your use case. Yeah.

I think, yeah. Maybe. Okay. So I wrote down the use case. Internal user, sorry for my writing, wants to access non-critical application from home. So the typical remote work. Is that working? Yes. Do we want also to write what prerequisites we have? What we... We can do this now, yeah. Because I think this is really, really interesting to know where we start. Because right now we have only the goal, but we don't know where we start from. Exactly. First thing is a little bit to visualize what does this mean on a technical base. So laser pointer. And identity is... No. That's more the talk.

That's a different picture. Yeah. So basically the identity, by using an endpoint, there should be a policy due to the home network, the open network, so the internet, company network, VPN, whatever, accessing an application. That is more the target picture we want to achieve, but that's another slide. So I think it makes more sense really to talk about prerequisites in that thing. I think you were asking in the question, what is an internal user? What does this define? Things like that. Okay. So internal user, I would say that's you as a full-time employee.

You have maybe redefined that you have in Microsoft. No brands. You have an account in your corporate network and can access data.

That is, I would say, the prerequisite for the normal boring user. Non-critical application. What's a typical non-critical application? What's the most boring application you have in your house? Salesforce? That's a technical guy. If you would ask sales guys from us, they would say no, that's the most important one. Let's call it... I would propose somewhere you can book your holidays or times. Travel booking. Let's call it travel booking application. That's a good thing. So...

It's interesting that you word it in terms of critical versus non-critical because a lot of vulnerabilities in architecture like this can sneak in when you think a use case isn't critical. So it's almost a catch-22. That was for a reason. Okay. Anything else from home?

I mean, that's clear. Somewhere not in the company corporate network. Current state, as we all know, is working via VPN and all that stuff. But that's not zero trust as we would expect. Okay. Now the plan is to really go through the most important topics here to show you a little bit what is relevant here. But I need to change the view. Does this work? I think if I click here, it's also... So that's more or less the maximum. Okay. So for that use case, what kind of user inventory do we need? Anything special?

So regarding to your normal company, what would you assume is relevant here as a user inventory? As we are talking about the normal employee. Something like... But that's a tricky question, right?

Because, I mean, the whole idea was stated in the beginning. You have to reuse what you already have. You probably already have something like Active Directory, right? So what's wrong with Active Directory? Nothing. Is it sufficient? That's the question.

Well, normal users can also have different roles and permissions. So if you have normal users, some normal users may have read-only access. Some can submit some data. Some may have read-only access, but only for non-sensitive data, for example. Some can see everything. Some can see only data. I don't know, assign it for their user role, region, whatever else. So everything has to be defined. So when I start to think about what is normal user, I immediately have like a lot of different cases when it may be already too complicated. When I would not call it already a normal user.

How would you call it? I mean, it is just very generic. When I define it for my application, I have to be careful to call it in such a generic way because I have a lot of granular things to be defined for these users.

Okay, I fully got your point, and that's basically what very often happens. Maybe we can call the user Alice. Alice is working in the sales department.

No, it was Eve. Eve is a bad guy. Yeah. Back to studies.

Okay, so back to the framework. For that use case, I need some kind of framework where I can define roles, permissions per user. That is the foundation that I need. On that level, we are thinking. So I need some kind of inventory, whether it's Active Directory, Azure Active Directory, a mixture of that or any other LDAP system. That's the foundation. And that is something I need. I need to assign some kind of attributes, whatever that helps me to identify whether Alice can access travel booking application.

Alexei, anything you want to add? You're looking like that. No. He's two microphones. That's cool.

Okay, so based on that framework, what we then do usually is, I know that's on a high level, but time is limited, as mentioned, we would mark that as a required thing. And no surprise, user inventory is the foundation for everything. If I don't know my users, I cannot do anything. And then it gets a bit more interesting regarding conditional access. That's more or less the wording of Microsoft, by the way, here. But it means I can define specific rules for access flows.

So something you would say you would need for such a use case or not, you need the capability to decide that someone can access from home via a specific network. Most definitely. This is the first gate to actually see if there is a risk of intrusion because of the location, because of the times, and so on. And you can calculate the risks.

So this is, for me, the first prerequisite to actually not only see who is coming in, but actually rate this risk and also be able to block him in real time in a really worst-case scenario, like disable his account and so on because the probability of him being hacked is very big. Exactly. And maybe we're not at this point yet, but it would also depend partially on user behavior, where if they're booking a trip to New York City versus some exotic location, that is probably not typical travel for the company in this specific scenario.

That's a good use case, but that's a very deep-dive use case because, on the one hand, you mentioned user behavior is more the way I act using the website or using the computer, keystroke, distance, whatever. And what you mentioned was more on the data level than doing like that. And that's one of the most challenging parts here. But definitely true. So if you want to achieve the highest level, if someone is doing something like he never did before...

By the way, there will be a presentation regarding the topic how you detect uncommon behavior on requesting or buying something in an online shop tomorrow by Sebastian Flesinger. Just some advertisement here. By the way, Christopher, probably a silly question from my side. A much more reasonable use case here would be a normal user should not be allowed to book really expensive travel documents, right?

Like, suppose normal employee up to, I don't know, $2,000. Where would you put it?

Like, is it conditional? It's not conditional user access.

No, no, no, definitely not. This depends. This kind of analytics is then on a system level or on data level. Depends a bit on the application and whether you use it then in a central policy decision point.

Yeah, but that's the point. From a business perspective, it is a policy, definitely. But where would you craft such a policy? So maybe on the policy level, Bob, who's in sales or marketing, they could book their own travel, but Lloyd, who's janitorial services or something like that, he or she should clearly not be booking travel. People that are plant maintenance or stuff like that. So I think that's where the user access would come in within their company. Yeah. So it depends a bit on the application that you use. Where are permissions defined and on what level?

So usually if you have such business application, you have some kind of rights management within the application, maybe approval workflows and definitions like Christopher's allowed to only travel second class in Deutsche Bahn or whatever. At least not third. Yeah. So conditional access from its foundation is an important thing to need something to implement like that. Because if I want to use the at home thing here, this could be some kind of definition that I use here. So it's not the corporate network, so the user can access but only to non-critical applications.

Multi-factor relevant for that use case? What do you think? There is no right answer, but that's why I'm asking you. We are talking about a non-critical travel booking application. Is there the requirement for a step up authentication? The fact that we've authorized, we've agreed that up to $2,000 could be spent.

I think, you know, what is the threshold? And for some companies, maybe that is something that would require multi-factor. And another question is always, yeah, I mean, from the business perspective, maybe not. But a security guy would come over and say, absolutely, we require MFA now everywhere, even for Gmail or whatever. Ivan? And maybe a small remark.

Okay, now we are starting with the non-critical application, but we do not say we want to implement policies on a more general level. So we must think way ahead, and we must think, okay, maybe the next application would be this one and that one. And latest on the further application, we are going to require multi-factor authentication. So better implement it now when we have time instead of implement it later when we need it, but maybe we have more limited resources. So make a strategic approach here.

From the general approach, I would disagree in that case because the idea is really to cover that use case. But from a strategic perspective, you are right. And the idea by using this use case approach is really to get the target picture after you went through three, four, five of your core use cases, and then you get exactly the result. So what I usually do in that case, and that is what I did here as well, I marked it yellow that it is partially covered to use it. Privileged access management. Any kind of relevance in that case? Maybe the right side here.

What you could do here, coming back to Alexei's scenario with the limited price, privileged access management is not only limited to technical privileges. It's also business-critical stuff. Like within the application, I want to book a first-class ticket, something like that. That could be something like a privileged thing here. But I would say for that use case... But where would you place delegated activities? I'm a big boss. I want my secretary to book a travel package for me. Would that be privileged access management as well?

No, no, no. That's, I think, in the... I don't know what the abbreviation exactly means, but I think that's part of the last point, the Ecom platforms here. Or you put it in user inventory as normal delegate stuff. But that is then a very specific use case, and another use case, more or less. I want to have my assistants to book me my travels. And we are here only covering the internal. And that's exactly what happens and why this workshop can take a long, but it really helps to clarify within the organization, what do I need and what is my understanding?

Besides from my C-level who mentioned, I heard about Zero Trust, let's do that. And then really breaking it down into what do we need, and the next step is then, we will only highly cover that, but what do I need and what do I have here? So now this is wish concert. I need to have that, that, that, that. But then the second slide would be, what do I have? And then I have the gap. And even if I have something, like maybe conditional access does not mean that I have the right policies and things implemented to build really the journey towards Zero Trust.

Okay, so for the time being, I would keep that red. We don't need it at least for this use case. Identity Federation and user credentialing. Internal user. We said it's Active Directory. It's an on-premise application. Do we need that? It's typically included in a lot of identity applications anyway. So even though it might not be explicitly, you might not think of it as federated identity, it typically is in the background. No one disagrees. I would say it's partially needed on a certain level because if you then have Azure Active Directory or RDS or whatever, we are in that universe.

Behavioral contextual ID and biometrics. Think about your iPhone using to book a business trip or your Android phone.

If, for example, your authentication mechanism was a passkey as defined by the new standards, your secure element chip on your iPhone would utilize your biometric authentication to trigger a signature to your servers. In a way, you are using biometrics. That is a good point. I would love to have some other opinions.

Typically, if you open your MacBook, or no MacBook is not doing that, your Surface, Windows computer, whatever, there is face detection and authentication. Then you're usually locked in. Is this something you trust, you accept? Is this part of the whole Zero Trust thing or do I then have access to the device?

I mean, for sure, the newer technologies are not like taking a picture and unlocking the device. It's a bit more 3D detection. But do you believe that or trust? Do you trust? That's the question.

Yeah, but I mean, in the moment where we marked conditional user access as green, behavioral, it's basically the same thing. We are analyzing the behavior. It's about the way of using that information for authentication.

Well, at the end, this is an outer device, so I would separate it from this. I think we are again going into these deeper terminology discussions.

Like, what do you understand under conditional user access? Some would say, we have it. We can totally look at your IP and see if you're coming from China. So this is it. Or we can allow you access before 8 p.m., but not after. I would argue, for me, conditional user access is something slightly more sophisticated, as you just mentioned. It should be at the very least based on behavioral profiling and maybe on biometrics and other sophisticated stuff. Like face identification. I think you need to do it at the moment of booking and not at the moment of entering, opening the device, right?

There might be an hour difference between the time you open a device and the time you do the booking, and the computer or device may change hands in that time frame. So it's not enough that you identify the device at the time you open it. You need a specific identification for the application and for the actions you take in the application. And that's why I would say it's at least partially covered because if you open your device, you identify with a four-digit PIN, whatever is possible here, or with your face, your fingerprint, then you have an active session.

And if you have SSO or whatever, you authenticate against your, again, non-critical travel booking application, but you're in. And then it's the question, do you trust the initial thing here, and is it relevant for the use case, which is the most important thing here. So I would edit as partially covered or partially needed for that use case. In respect to the time, I would also love to jump into devices and network and system, but I think it's clear from an understanding. To use that framework means I have the use case, and I go through the different things here.

And for every single item here, there's also an additional slide, but I skipped this for the complexity level because then we have, I don't know, 80, 90 different points to discuss. That's a bit much for today. That's why we are on that level. And then you get the picture more. I have prepared as a closing slide, more or less, how does this typically look like, but we are going in that direction. I just feel like if you don't have eight hours to go through all this and kind of work on the nice-to-have level, do you have a different kind of trim, kind of lean methodology?

Do we have to think about must-have capabilities here? Sure.

Basically, the must-haves are marked here for the user. One thing that is more or less also relevant is continuous authentication because you need something like, I want to be authenticated. Do I trust that authentication? Did something happen? Was Eve there? Did something bad? Is the device compromised? Is the session compromised? Something like that. This is also a relevant thing. Maybe I mark it just green, as I said. Least privilege for that use case? No.

I mean, in general, for sure, that's the foundation of everything, but just thinking about that use case, Alex A would argue, maybe you can argue, that to define only second-class travel trips are allowed, that this is already some kind of least privilege or limited thing here. Okay, so device. If you think about Zero Trust, is a device inventory important? Now I want everybody to say yes. That was only this side. Silence means agreement.

Still, how do you deal with bringing your own device then? Do you exclude those, or do you have to cover it somewhere else in this methodology? Perfect. Now we realize our use case is not sufficient or not clearly defined. I did not write down, by a company-managed device or by my iPhone. Good point. You should have added this as well. Maybe for us, to make it easier, it's a company-owned managed device, but this is something you need to have in your mind. Especially, so we was coping a call.

I'm one of the few people that use a MacBook, but we use some very common tools that a company was starting with a big M. New devices, like bring your own device, they are detected and then usually limited. That's what should be implemented for all normal organizations as well. There must be a policy, surprise, of defining what happens, what can I do with my own device. This needs to be done somewhere. This is basically the second part, device detection compliance. You have different scenarios.

I take my own device and connect it to the wireless network within the company, because I know the VPR2 key or whatever, if you allow something like that. If it's managed and it's more or less limited on your credentials, then I know the user, but maybe I just use the LAN. What is that in English? I put in the cable.

Plug, yeah. Internet.

Yeah, the plug was the word I was thinking about. Then you connect it or not. This is still valid in many organizations. Then you need something like, all the new colleagues joined, they forgot to do something, and it's not part of the device management for whatever reason.

You need, in general, and also for the use case, device detection. Do we need device authorization with real-time inspection?

Again, non-critical. I would say the question is, maybe you already have it in place, like a common EDR solution, which has an optional capability. You can actually export the device posture as the input for the rest of your zero-trust architecture. It's a really common scenario, right?

I mean, if you run something like, are we allowed naming names? An EDR vendor starting with a big C, which everyone else is integrating with, or even the one you already mentioned earlier.

I mean, the big M also has some device management capabilities. Why not use them if you already have them?

I mean, that's the strategy by the vendors, by the way. Could you go a little bit more into what you mean by device authorization? Do you mean making sure that your device is really what it says it is, or just checking a MAC address, or what sort of level are you trying to address by this point?

Basically, it's up to you, but it's at least that point. You can identify the MAC address frequently, whether it changed. I hear you should have an agent probably, right? Yeah. Because MAC spoofing is a thing.

I mean, even your iPhone does it. So an agent is probably what most companies would require. Yeah. Should we edit? That's the most typical answer.

And again, probably the step number zero in this diagram should have been, what do we already have which we can reuse? That is usually the next point. I really would love to think about first what do we need for clarification. Okay. Let's speed a bit up here. So patch management, endpoint detection and response, EDPR, XDR. So like monitoring, acting on uncommon things or things that happen that seems to be uncommon. What do you think, Alexei?

Again, it's definitely nice to have, but probably it's not up to technical people to decide for the management. It's a risk they want to accept or not because those tools usually come with a hefty budget.

That's, by the way, a typical internal discussion always. Alexei wants it.

I think, okay, it would be nice. And I have to tell our CIO we need it.

I mean, probably all of you know that. Okay. So nice to have means let's mark it yellow. Yeah. What I would mark as green, I skipped it for no reason, is vulnerability patch management and asset management. You need some kind of device inventory. You need some kind of responsible person, groups, people, whatever for the devices, the owner of the device, so maybe in that case me for the iPhone, whatever, and some kind of health check. I don't know if you frequently read the threat reports and things like that.

From Zoom to Microsoft Office to whatever, all the plug-ins you have on the device, there are so many zero days and vulnerabilities. And that's still if people then have access on a certain level to your network, to the device, where most of the attacks start. And if you are talking about non-critical applications, I mean, you know what is possible in cybersecurity things to do that. So my question, and I apologize, I'm an intellectual property attorney, so bear with me. The mobile device is literally becoming the device by which we authenticate.

And I have seen growing reports of counterfeit devices. Now, in this use case, we're talking about a corporate, so hopefully the company's buying from authorized vendors. But in a bring-your-own-device environment, is this where you would look at potentially someone bringing in a counterfeit phone? This goes beyond just patching of software, but a potentially counterfeit device that could be loaded from malware at the point of sale.

Yes, but it's difficult. So in general, I would not allow mobile non-managed devices from an organization to access anything that is more than non-critical.

Well, as soon as you say that word, basically you automatically imply you have to have asset management, right? Because otherwise, how would you know?

Yeah, exactly. Back to your question. So for doing this on your own device, you need also sometimes some kind of agent. You have Microsoft Endpoint Detection and Protection, for instance, that helps on a certain level. But really, to do the managed devices, the checking, you need the approval of the users to run some kind of agent on the device, which is then limited on a certain level. All other vendors that deliver something like that also have that. But that is then the thing usually the user needs to accept on a certain level, if you want to have that.

I mean, if the risk appetite of your organization is like, okay, I don't care if someone with a maybe compromised device is accessing non-critical applications, I'm fine with that, then you can limit only to things like that. But the more critical information stuff you get, the tighter the monitoring should be here. I would probably suggest marking the one with remote access and MDM as red, because even though they can be good in certain situations, it's certainly not necessary here.

But a lot of times the vendors provide very compromised mobile device management software, and that itself can create a situation where, even though it's intended for an admin, it provides a wide hole in your cybersecurity environment. So for mobile device management, I would mark it yellow. And I would disagree for exactly the reasons to get at least the basic health state of the device.

Well, the agent that you're talking about is separate from mobile device management specifically, because one would allow full remote access, the other just audits for certain software patches and such. Yeah, it depends on the product. As we mentioned, if you disagree, it's yellow.

Okay, so in respect to the time, so network level, I mean, a core element of zero to trust is micro-segmentation. As one gets access to a specific network, it should be as limited and as small as possible. And to get another network segment, you need some kind of authentication, authorization mechanisms to ensure that this is possible. Because the typical people that start with a compromised, whatever, phishing attack starting, credential phishing, access to non-critical device and things like that, then they jump network, network, device, step up, and all that stuff that is possible.

So for sure micro-segmentation is something important. For that non-critical, I mark it as yellow. But for the full picture, it's for sure green. For system and application, the first point, this goes into the non-critical stuff. Application inventory, is that important? Maybe you raise hand. Who of you believes that your organization, you don't have to say the name, has a complete inventory of all applications and define the criticality of the application and the underlying data? The others don't want to vote or do not have it? Okay.

And that's basically the intention why I wrote it down as a non-critical. What is the reason why I know it's a non-critical application? And this goes a bit in the supplier stuff at the beginning. I should have something like a screening or an identification of my new application, of my new web service, of my new cloud service, whatever. Defining what kind of application is this. And then a regular assessment or validation. Is it still non-critical? And then also checking what kind of data is there. A typical use case is that someone in some department says, I have a new fancy tool, I love it.

Can I test it? Yeah, sure. I just use it for test purpose. One year later, I will use this here for that customer with that security strategy. Okay. No. And this is something you need to monitor.

I mean, there's a lot related like detecting potential services, applications, not only internally, also web service-based container and everything you have within your organization. Krzysztof, to be honest, I mean, one of the tenets of Zero Trust, like you have to know what you are protecting. So you need to inventory everything. You already had user and device inventory green, so application absolutely as well. It's dark green. And the same applies to data. Exactly. Monitoring and all that stuff. And data.

And what you realize probably, and that's what we realize every time then we do it, at the beginning everybody says, user inventory, we are fine. Device, we are fine. Application inventory, we are fine. And if you go into data inventory or know what kind of data you have, classification or data governance basically, it usually gets silent. Because that's a stupid topic, by the way.

I mean, the initial intention is like putting a label on a Word document like it's internal. You did this one and 20 reviews and no one knows and no one will ever verify. It's a nightmare to maintain something like that in an organization. Just think about the big financial industry. I don't know where everyone is working here in the room, but the bigger the organization, the more complex is that topic. And it's a nightmare. It's not making fun. Then for sure you have some kind of tools like, okay, there's an ID, passport number inside. It could be critical.

There's something like a credit card number, whatever. I mean, on that topic alone, we could totally make a whole day of a conference probably. And you are very welcome to check our latest research on that topic as well.

So yeah, I mean, there is a lot of tools available. You know, talking about data security platforms and even data security posture management, specifically for like your cloud data. A lot of interesting stuff. It's potentially kind of relevant for Zero Trust as well, but most people don't think that way, which is a shame. Exactly. So a lot of this stuff in data is really relevant. And coming back to the discussion we had earlier about the amount or was it about the booking limitation or something like that where I ask where's responsible?

I mean, depending on the kind of application, typical SAP is not a good example. Salesforce, for instance, for sure you have a certain level of rights management, but do you have an overview of that thing? Is it integrated into a big picture?

I mean, you can do this on a crazy level. If you do the full central approach and have a user, where does Christopher have access on what kind of data and break this down, it's getting crazy. And then even if I need some kind of deputy because I'm sick on vacation, whatever, and someone needs to do my tasks on a certain level, then you should know that. Noah and all of you should also know as well, data is difficult, especially data, enterprise data governance.

For sure there are also tools around that, like DLP things, access control and basic limitations, but most organizations are really working on non-critical application. I mean, you can modify for sure things like not allowed to send sensitive or sensitive as the most critical label, for instance, document as an attachment via mail, but that's just a policy. The problem is basically if you go to the word policy for a second, like a company can institute a very simple policy. Like for example, employees are only allowed to access data of their own, what's called customers, patients, whatever.

How would you do that if you don't know, not just who your employees are, but also who your customers are, where their data is stored, how sensitive the data is. Like if it's a regulated industry like healthcare, it's not just your internal policy, it's automatically something like imposed by the government. How do you apply zero trust on those? Requirements.

So again, it's a topic worthy of a separate full day workshop probably. Exactly. To bring it a bit to an end here, the most important thing is at least that I have a basic control about my data, maybe a specific share where only a specific group of people have access. That's a starting point. Maybe groups within the application accessing or booking or doing specific things, booking in a specific region, whatever. And in general for zero trust, and these things have data encryption and rights management. This is the most important thing here. Ivan? I want to make a small remark.

I mean, the whole use case for me, I mean, normally we have all, let's say, commercial applications for big vendors, like, for example, ACP Concur for travel booking, and then we have roles and rights there. And ACP is certainly not going to change something in the software because our boss decided something. And that's why maybe in terms of access to an application, there should be put, let's say, a concrete end to say, okay, we end here, and from here, these are predefined roles and rights which you might access, and policies, but they are not our responsibility. They are predefined.

They come from the vendor, and that's it. We cannot change them. The problem is that in many, or maybe not in this particular use case, but in many others, especially in the cloud, you are not allowed to say that because even if it's the other vendor who is managing your data, it's still your responsibility anyway. But I cannot define a policy in a lot of cases because the roles and rights are predefined. The vendor has his software sold to a million people, and he's not going to change it for me. I have to live what he offers.

Well, again, look at just how we have this whole thing with sovereign clouds, for example, like AWS or Microsoft or Oracle. They have to build their separate cloud infrastructure for Europe just because of GDPR compliance. And the same, in a way, applies to all soft applications. If you have your data that has to be stored here in Germany, but you want to use Salesforce, well, if Salesforce cannot do that for you, well, you don't use Salesforce. Or you have to invent some kind of workaround, maybe like transparent data encryption gateway or something like that.

And this is also a part of this exercise, if you're probably not for such a non-critical use case we are talking about today, but as soon as you start dealing with real sensitive data, you have to take all this into consideration. Exactly.

Okay, so I think from a process perspective, it should be clear, important hint. So on the one hand, even if it's not coping a call, again, a really good document by the Department of Defense with the explanation and also the next steps, but also the slides will be available with the details then in the attachment part where it gets clearer. I prepared one slide which is more or less an example of how something like that could look like. So we started defining, do I need that for that use case?

If you do this with, I don't know, 5, 6, 7, 8 use cases, you usually get a really good picture about that. And then the part starts where you can go through it. Also on the detailed slide, maybe I show one of them, like one of the detailed slides, like conditional access. If I want to have real good zero trust or starting point, I need rule-based dynamic access or advance any enterprise roles and permissions.

At that level, what you want to achieve, maybe also budget, you can then go through what you have and go through it, what is already covered, what is partially covered, and what is not covered within your organization. And this is just an example about where, for instance, user inventory is fully covered, that is there. The company has a device inventory. They have macro segmentation, the basic stuff, but no micro segmentation. Application inventory, they have something, but not sufficient for all the use cases. They have data labeling and tagging is yellow, as probably for every organization.

At least on a policy level, it is there. No DLP, but needed, and data access control is there. And also the specific use cases, like we need a specific PDP, policy decision point, or log all traffic, things like that, is there. So a CM system, like collecting data from different sources, normal analytics is there, but not for everything. No threat intelligence, no automation, and things like that.

And with this knowledge, so again, you start with a use case, cases, do this exercise, then go into the next slide, see what do I have from the things I need, then you get more or less the level of maturity. And with that level of maturity, you can build out something like a roadmap. That is just a stupid example, like starting with mission and scope definition analysis, and then implement the most important things on a specific timeline. That is the usual outcome here. Coming back to the roadmap. The framework by DoD also covers and helps you a bit, because you have all the different layers.

Can you make it a bit larger? Yes. That is better. I forgot that I was in the wrong view, sorry.

Here, this slide shows for the specific things, like for the user, my Zero Trust target level. This foundation is user inventory, having something like user privilege access, and advanced Zero Trust would be having conditional access, MFA, PUM, identity integration and user credentials, and so on. Using this step-by-step, you get the target picture.

That was, by the way, sorry, the other way around. The target picture for this here to really see what is needed, what do I have, and what do I not have. That is basically the core message here, like breaking it down. With this thing, it even gets a level deeper if you are bored on that level, which is usually enough, believe me. You then can implement a concrete timeline, a plan that helps you in the direction.

Alexei, anything to add here? Again, I have a question. How do you combine this long-term strategic overview with quick wins? Because there are definitely some things which you could implement really quickly. Do you have to fit them all here, or is it something you would use to show your board, for example, that Zero Trust is something tangible? If you want to confuse your board, then you show that slide. But for budgeting, this does not really help.

Really, usually, asking for budget, an extract of this slide, maybe even on a much higher level, is the starting point. Quick wins is a bit difficult, because this really depends on what you have and what you want to achieve to do.

I mean, copying a call is an identity-centric security analyst company, more or less. Surprise, Zero Trust is also starting with the identity on a certain level, also including IoT and that stuff. I think if you have a good starting point with everything around IGA, so the user repository and devices, that is a good starting point. Then you need to start to implement things depending on the use case you want to achieve. So a general answer is not there. Sorry. It depends, as Matthias would say.

I would say just starting the conversation is a good first step, because if your organization is just going about things with no thought about it, then you're going to have a bad time. But when you get everyone thinking about what does a phishing attack mean, what is ransomware, what does all that mean, then at least people can start being aware and maybe you can progress to the point of convincing your board that it's a good investment. Exactly. That is also one point that I added here, mission and scope definition.

I mean, the statement at the beginning that I said, okay, one of the C-level heard about Zero Trust and asked me to do that, it's a bit provocative in that case, but it also helps, and that was the slide Alexei talked about with the ransomware and what you mentioned. It also can go in the direction like, what do I want to achieve?

Okay, ransomware is still one of the most critical things that happens to organizations in 2023. How can I prevent and how can I make my whole organization more secure? How can I deal with people working from home, work from anywhere, whatever? These are the typical use cases.

I mean, this use case, no matter whether it's a non-critical application and from home or from the wireless LAN at Deutsche Bahn or at the airport, that's a typical day we work usually or the people in the business work, like going at the conference. And if you solve problems, make it more feasible or touchable and improve security on the other hand, that's also a good budget argument at the end. Because if you do it right, then it's not more expensive than doing it wrong and paying a lot of ransom in the worst case. Any other question, remarks?

Any opinions about the framework and the approach? May I also say, no, that does not work for me. That is too complex. This is strange. Or maybe for the people that joined later, any feelings about that? How do you translate this to products? Or what do I need to buy to even because that's like the ideal description of what I want to achieve, right? Good question. It was not prepared. I skipped it a little bit in respect to the time. But the idea, you have multiple things you need to do.

I mean, maybe most of you know the identity fabric Kuping et al has. We extended this three years ago also with the cybersecurity fabric. Offer your organization, so no matter whether it's an identity, device, data, application, network, so covering also IT, OT stuff, services around recovery, protect, detect and response. And if you translate this into the concrete capabilities and services, so bundle this stuff, you end with multiple products. That's then the next step. And by the way, when will the next workshop start?

At 10, I guess? Not 11, probably. There is a workshop by Matthias and Christy. They will exactly talk about how to then find the right tool based on that here. Because you end usually really with, okay, I need some kind of capabilities around user inventory lifecycle conditional access, so I need a service for identity lifecycle. And identity lifecycle services then, for instance, one big blown IGA solution or multiple smaller ones or maybe only Azure Active Directory with some Microsoft identity.

And by the way, I think one of the slightly less obvious advantages of this Fabric approach is that sometimes you get multiple capabilities with one purchase, basically. You can apply them across various use cases.

I mean, this whole story about ransomware protection, for example, just by replacing your VPN with a zero-trust network access solution based on that software-defined architecture. I mean, not only you achieve better compliance and productivity for your users, you automatically reduce the mere possibility for hackers to pivot around your network because you do not have any local network anymore. So it's like killing two birds with one stone. And the same applies throughout the entire concept of cybersecurity Fabric.

The free use, recombine, reduce kind of overlaps and duplicate investments as much as possible. Exactly. Okay. We have three minutes left. There are no other questions? No remarks? I would add a remark that when implementing zero-trust maybe one of the initial steps would be if you work in a regulated environment like I do in medical devices and maybe I don't know, financial industry or something like that, how this zero-trust you are going to implement, how it will apply to existing regulations.

I know the cases when big German manufacturers of medical devices failed to get FDA approval in USA, for example, because of lack of cybersecurity. So this is in regulated environments. This is very important step. Definitely. And it depends on the organization, but sometimes the regulatory requirement is the foundation of starting something like zero-trust. And sometimes it's also the other way around that you cover a specific regular. So that would be the best case. You do something and fix before the auditor finds something or the regulative authorities find something.

But most of the time it's the other way around. Helps again to get budget for sure and solve the topics.

I mean, honestly, I'm also more into like I want to have a secure organization and things like that. But sometimes you need arguments for budget to fix it. And sometimes actually the vendors do some of this work for you because their products are already certified. So even if it doesn't automatically translate into your certification, at least it simplifies the whole process a lot. Perfect. And I would say...

Oh, no. I would just end on don't get your budget, spend a million dollars on implementing zero-trust security and then become a victim to having your login credentials be admin and password. So... That was the closing word. Thank you. Okay. So I would say thank you very much. I hope you had some interesting time. You got some insight into the methodology. I'm here the whole conference. If you have any kind of question, ask me, ask Alexei or just reach me out via mail.

Teams, whatever you want. Thank you for participating. Thank you for the interactive. Interaction. And have a good conference. Thank you.