Yeah, thank you very much and welcome to well after long conference day to the very, very exciting topic of zero trust and not generic one, but focusing a little bit on, on the challenges we experienced doing our first zero trust implementations or participating in zero trust initiatives is likely the better, better term to not, to not make the wrong expectations here. And one aspect I really want to highlight today is that zero trust is not just somethings it is doing to make the security better. What sometimes there's a little bit assumption. Yeah. But that we really have to align with the business to find the right priorities to, to get a good understanding. What is the error we have to, to put our efforts on in order to make, to make it successful. Okay. As we are starting early two, three sentence about I, who may not know us, I see is a system integrator.
Who's completely focused on identity and access management, 25 years in the market already 650 employees, mainly in Europe and C us and yeah. And my role as a city of IC is we're making sure that, that we are not just today successful, but going into the right directions to also makes the company successful in the future. Okay. Then, then we start. Yes, we start. Okay. So likely most of you know, about zero trust, therefore just a very, very short, short wrap up about the core idea and then going a little bit into the, into the challenges. So because the idea of zero trust, and that's why I really like that the product is very, very simple, right? We want to make sure that we make the zone of implicit trust, the trust between systems as small as possible. That's a core idea. What are the mechanisms to do that?
Well, we make zone of where we do not have any trust as large as possible. So networks, devices, users. We try to make sure that every single request before accessing the resource is authenticated and authorized. What makes absolutely sense the architecture picture you're taking from, from this you'll likely know that as well is explaining very well. Why we have such a high complexity for such an initiative and why, on the other hand, it's sometimes a little bit over promising. If, if some of maybe also vendors here today saying, okay, we sell you the zero trust solution here, implement our system and you are all set. Unfortunately it's a little bit more difficult than that. And I want to highlight now some, some of the aspects in which we are, well, I will not say struggling, but having much more discussions and, and, and, and much more interactions and, and, and things to work on than, than expected upfront. Yeah.
I think the theory is somehow somehow clear. I don't don't want to go through it as you might have heard to often already. Oh. So I see as font font is missing, it's still happening. It's still happening. A font is missing. Okay. Anyhow, we don't go through all the steps of the evaluation process, just highlighting, highlighting some of these, some of these steps. So what we are doing in such a zero trust approach is bearing up an, an architecture follow, following a pattern. We along for many know for many years in the access management, we have policy decision point who's in charge of deciding whether access is allowed or not. And policy enforcement point, which is, which is enforcing it in front of the application outside of the business logic. Typically not always outside of the, of the middleware. And I said before, it should be very close related to the research.
So what is I, the core ideas idea is that we are not using just this very, very static information in the policy decision point as we did since decades, but are now taking a lot of information into consideration, which comes from the outside world outside from identity access management perspective, like from maybe a device management, giving us insights into compliance status of a, of a device makes absolutely sense. Yeah. JRO device or access. It's simple as that. Right. We'll see that. Or of course we have have policies classifying our data. Yeah. And also we wanna take that into consideration and very, very important, very, very important. The subject itself. Yeah. What rights does it get from an identity management system? Also very static information. Yeah. It has a specific role, therefore it is allowed to access. So now let's talk a little bit about, about the challenges I mentioned the device. Yeah. This, the example was simple and clear, but compliance status of device is, is working good in specific situations. I control the device because the device is owned by the enterprise. Right. And it's, then it's easy.
Maybe, maybe not because we have couple of devices, which maybe are very, very limited or very specific to our, to our cases. Maybe, maybe old system inside the OT, which is somehow not able to be managed by the device management, which comes as part of the identity makers management versus is a system outside. What is about partners external as the supply chains? The supply chain is absolutely critical, but we do not have any control over the devices. So we have to figure out in which situations can we accept what kind of devices and that's something, what typically is not easy to answer just from a security perspective, because you have to understand exactly what is the, the purpose of the business application. Yeah. What is the risk? They will accept what, because there's no other way to deal with it or where medications are possible medications based on zero trust architecture.
Next aspect I want to highlight is yeah. Data access policies and, and the identity management itself roles are very static. Our roles are very static and the goal is to, to use all the dynamic informations. Yeah. Not just from the, from the, from, from the CDM, but also threat information and so on, but who's answering us in which situation are we allowed to let the user with a specific role accessing the resource. Right. We have, we have to bring in the tools, the, the tools to define the policies, but how the policy will exactly look like well has to be decided based on the risk appetite of the person in charge of that resource. Right. And that's also an assumption, which is often, often forgotten and comes up a little bit later while trying to build up all these policies, then the resource, unfortunately also not so static anymore as it was used to be in the past.
Yeah. So what does it take for devs team to bring up new resources? Yeah, it's easy. It's completely in the responsibility of that team. And I have to have to the, have to have the controls in place, but also the, also the tooling, the policies to protect these resources without slowing down the desktops paradigm at all. Right. Because I don't want to be the bottleneck as a identity access management provider, what we were somehow able to well mitigate the problem or to decrease that the effect in the, the past by to be honest, not being so active as a policy enforcement point anymore than it was some years, some years ago by, by, by moving to SIM to, to, to easy to consume protocols and not taking charge of that part anymore in depth. And now we are doing it again in order to build up a zero trust architecture, but we don't want to make the same mistakes again as in the past. And yeah. And now policy decision point policy enforcement point. These are really the core components in zero trust architecture. I think the first, the first thing you really have to realize when building up a zero trust architecture is today. So there will not be just one policy decision point. Of course, we all want to have that. And clearly the vision having the policies in one place, but typically these both are somehow tied together too much.
That's the case and policy enforcement point it's ly clear. That will be a couple of them. Yeah. Based on well, different infrastructure providers based on different protocols with different ecosystems. Yeah. And therefore there will not be that one policy enforcement point in charge in charge of, of everything. And, and this is something that makes them clear that, that of course, efforts to building such a solution will be higher than just bringing in that new, a shiny piece of software. Yeah. So zero trust product. Okay. So lot of, of questions and then the, the most important questions always, okay. What is the right way to start that and to get the ideas and, and insights in how to deal, how to deal with it situation? Because one thing is clear. If we would have unlimited resources, we can build as a complete zero trust architecture for the whole enterprise. Huh. But unfortunately we are limited in time. We're limited in resources. And, and therefore we have to make sure that we are doing that steps, which have the, the, bring us the best, best increased security, decreasing their risk for the enterprise at all. And therefore very, very simple, simple exercise.
It's always not a good idea using a, not standard font in a presentation. Sorry for that. So first, first the business risk, number one, just as an example. Yeah. We have compromised account. Yeah. That's that's what, what, what happens from time to time? Unfortunately. Yeah. But in a business critical system, it's operated on premise in this in a triple a security zone. So something, what we really want, not what, what really must not, not, not happen. The other risk is again, a compromised account. Now it's for an employee in a training app provided as a fuel source service, not closely related to anything else in the enterprise. I think we all agree. It's very likely that that the risks will have a complete different impact. Therefore it makes sense to, don't try to apply exactly the same paradigms on, on these. So let's, let's look at, at the first one, the very, very critical application.
Yeah. Unfortunately, compromise account is, is at least likely can argue. It's almost certain, but I think somebody will, will go below, below that. What is the impact to the organization? Okay. Might, might differ of course, but having in mind, it's in a very critical zone. It can, can be used to, to make a text to other systems and databases and so on. So some something like, like major, maybe not catastrophic, but at least moderate. So what we now do, we, we try to decrease likelihood. You are by introducing MFA. I think that's, that's clear to everybody. So your trust architecture, of course also MFA is a piece of that, but enforcing it also, if you're already on a system within that organizational scope. So the core idea of, of zero trust is not decreasing just the likelihood, but decreasing the impact. That's not so easy to jump to other systems anymore.
Cause I always have to present MFA for example. Yeah. Or I'm in this, I compromise the system, but based on micro segmentation, I'm not able to get out of that anymore. Right. So, so that's, that's, that's the idea, but maybe we still do not feel comfortable with, with that. And then yeah. We have to go for further activities. Yeah. For example, going for strong authentication, which is very, very fishing resistant. Yeah. I think most of us may have the in mind and it was so trivial sending just a couple of push notifications and then someone saying, okay, now, now I just approve. Yeah. To be able to sleep and something like that. Yeah. And so we have to prevent these kind of, of mechanisms, for example, by introducing tokens and introducing hardware, tokens five, two hardware tokens, for example, we all know, okay, it's hardware, it's expensive.
Yeah. The process is to enroll it and so on. I think that somehow clear. So we have to have good idea how to make sure we understand to whom we have to issues a token and who is good enough is what we did via our push notification app, whatever. We'll have a look to that in, in a minute, just to show, to show the difference. Yeah. The training app, first of all, minor impact what we assume based on a, on a breach that's possible to get maybe hands on some, some training data, not nice, but will not, will not cause a lot of, of impact to the organization. And maybe one mitigation, whatever is, is enough to feel very comfortable on that. So what's the, what's the message.
It is for zero trust program. From my perspective, very important that we get a clear understanding what are really the activities we should do first because that's where we can bring real value to the enterprise later on. We can take care of, of these kinds of, of risks as well, but we have to have kind of, of justification for the large investments and they are likely here. And again, this is not a discussion of, so the, the impact especially is, is something where we really need to have the so buy in from the application owners. Yeah. They are the ones who are able to, to make that calculation. Yeah. Okay. Now let's focus a little bit on the expensive activities. Yeah.
They are. The lessons learned, we have to, we have to try to make the numbers of users affected by these very expensive activities, as small as possible that we are really focusing on the users, which have the highest risks, risk, and based on privileges we have in our systems. Yeah. We are doing risk scoring for the most critical identities for well quite a time and definitely understanding what are the highest privileges, privileged users out there, but that's very static information and what's coming up are well innovative companies which have little bit different focus, but can really help to make, to get a better understanding of what are the identities or the systems systems at risk. And I want to show the category, which is focusing from the internal side on the dynamic information. So which are the, what, which accounts are used on these systems right now, where by logging in and analyzing it, analyzing the hash credentials on the, on the systems and getting based on that, a very good understanding about the current use of accounts and on systems by make by, by, by having the perspective of the attacker. Yeah. And, and acting a little bit like going, going down the path from rum system to the other and, and try to get understanding what would be the resource and attacker could access in 1, 2, 3 steps, where can they do privilege escalation and, and bring us in a really difficult position. And again, this then helps us to identify the users of the system. We have to Topen the efforts on doing whatever is, is required to make theming resistant. Yeah.
And then there's a companies focusing just on the external side, not insights, application insights, enterprise, but externally. So accounts of that enterprise affected by breach. Of course, these are not the pass, hopefully not the passwords, which are used within that enterprise, but it gives a very good understanding of what password might be used. But because we all know that entropy for user password is likely not to be too large for two different systems, if he's not using a password manager, of course. So this is something, what, what, what gives us that, that, that understanding what, so what accounts are at risk because at least the user names are, or the email addresses are then now to the, to the outside world. Also getting understanding of what, what kind of applications and resources are available in the internet. Yeah. Based on our domain for our organization and, and this external very dynamic view helps us, helps us again, to understand where, where to put, put the efforts on well, makes the right directions for the next step, implementing the holistic field trust architecture.
Okay. Then let's focus on another topic. This is, again, something we like to use in the discussion with application Analyst to help, to figure out what is the demand for level of authentication assurance, a level of identity assurance they have as again, this is likely something, what, what we cannot just answer as identity experts, right? Because the risk appetite of an application might depends a lot of what is a negative impact of making it more complicated, more expensive and so on. So Chris, the clear we are talking about banking. Yeah. And we are somewhere where some, we are document document based identity proofing was in place and we are talking well, maybe standard passwords for read access, but better going for, for better, for higher level of authentication assurance, eCommerce error may look some, some different, some high value services in which custom customer is willing and able to accept also stronger, stronger authentication activities.
Yeah, of course, new approaches like password loss is always a better way to go, but we all know that we'll take some time until we really have that in place everywhere. And again, this can help to, to figure out together with the business, what is the right, the right value on these dimensions for the specific specific application. Also, it helps us for very difficult discussion. We all talk about conditional access, risk based authentication and so on. So what does it mean if we have these bad signals? Yeah. Like unknown devices, first time users accessing the system with that device, or even things like, like zone hopping, user velocity and so on. If this is something which is, is acceptable, acceptable or not, is not an answer. The enterprise can provides the answer in general, but it's also a little bit, depending on the specific on the specific purpose of the application we are talking about, right.
Maybe we have situations in which switches of, of, of networks are likely VPN wifi, 5g connections and so on, and, and would result in too many, too many wrong alerts about, about zone. Hoping maybe that that blocking access might not be acceptable from, from a, from a business perspective as that impact of damage is too large. Yeah. So our recommendation is here. We have to introduce for an organization specific levels, define them, explain them and giving the application owners a possibility to say, okay, we are in this sector. Huh. Please protect us. Based on that, on that rules, maybe the standard levels of nest are sufficient, but based on our experience, we have to go a little bit more into, into detailed modeling for that. Yeah. Then there's a last topic I would like to talk about. We are, we understand that policies have very, very, even more important role than in the past yeah. Defining policies in the past to allow access to applications. Well, somehow challenging. Yeah. Nobody should assume that in a zero trust architecture with all, all the things we want to achieve by that, by, by, by leveraging the information and all the systems out there will be simpler. Yeah. It will be more complicated. And
Being in a situation in which I have a tool in which I click the new policy for the productive system will not be the right way to manage that. Yeah. We need a life cycle for, for policy management. We need approvals before policies go into production, going to be effective. And we need to have policies which are understandable, maybe also manageable by application owners, which really can, can adapt that based on the specific needs, risk appetite, and not the requirement for very various sophisticated team to build up this policies. And that's, from my perspective, one of the largest challenges when it's about implementing a zero trust architecture, which has really a holistic holistic view on the enterprise and not just covering the new pieces within yeah. Already running in a modern cloud infrastructure, but taking into consideration that we really have a lot of, of legacy it in place, which we have to protect as well. Okay. So that was little bit of our experiences in the, in the, in the first steps of implementing your trust architecture. I hope that you can use some of these information for your initiatives and yeah. If you have any questions, happy to answer them right now,
