Zero Trust: Now Is the Time and PBAC Is Key

Welcome everyone to our cold webinar. Zero trust. Now is the time and feedback or policy-based access controls is key. This webinar is supported by plain ID. The speakers today are gal SK she's co-founder and CPO at plain ID me Martin around principle Analyst, a call. And today we want to put our focus on how to, to make zero trust. Really a reality. I think over the past two years, there a lot of talks about what zero trust means, etcetera. But right now I think it's time to really make it work in practice.

And when looking at how to make serial trust work in practice, then we must discuss the role of policies and policies based access controls. In this context, in this webinar, I'll talk about, I go to the agenda in a minute. I'll talk about more, the concepts behind that, and we dive way deeper into the details. But before we start trust a little bit of housekeeping information, so we have a couple of up and a little bit of information. We have a couple of upcoming events and I'd like to highlight two. One is a virtual event. We will run and on March 23rd on the topic of zero trust.

So it's called siring in on zero trust. And it's really about again, how to make zero trust reality. And the other event I'd like to highlight is our flagship event, which is European. I don't think cloud conference 2022, that which were run in Berlin May 10th to thirteens, but you also can try and online. So if we have both options, it'll be a fully high. You should not miss these events from out keeping perspective. There's not much to do, to say we are controlling audios. We don't have to care about that. We have a Q and a session.

If you have any questions, just enter them into the questions area in go to webinar control panel. Usually the right hand side of your screen, we are recording the webinar. We will provide the recording and the slide X for you.

And last, not least we will run a few polls and to be precise, we run two poles. And the first one we will do just right now, and for that first poll, I'm interested in your sort of your, your main identity management identity security topics you're looking at in 2022. And I'd like to add, provide your, your perspective on, so let's get this poll started about which of these themes is most relevant to you.

So is it, and I am blueprint for modernizing the legacy I am. Is it really trust? Is it delivering or supporting it an agile? It multi-cloud multi hybrid. Is it trust in time access or MFA and password? So what are you priorities? So please provide your insights. I lift is open for another 10 to 15 seconds. The more answers we have, the better it is. So please join that. Paul Paul. Okay. I think we can then close the poll. Thank you for participating.

We'll pick up the results later on during our Q and a session and with, without do, let's have a look at the agenda and dive into the of today's webinar. So I look at the role of policy based access and zero trust. Then we'll really talk about how to make this work, how to make policy based access control, work into zero trust context. And then as I've said, we have a discussion at Q a and what I, what I, as I really like to ask you is if you have any questions, enter them and we can pick them up. The more questions, the better it is.

So I, I want to start the point, which has to do a lot and nothing with zero trust, so to speak, which is, but which is a starting point for this theme of policy based access, because I believe it goes even beyond zero trust. It is something we, we need to think about in a dynamic in an agile world. And I think when, when we, when we think zero trust, when we think security, when we think whatever else we, we must always consider, we are not in an age anymore where we think about a few servers and workloads that are running fixed on certain servers.

But we are talking about an environment where we have a agile development, where we have an agile operations. We have DevOps and we sync in workloads. We sync in stuff. We run in the cloud where we have a high level of elasticity.

Where, where, where, where, where virtual systems, so to speak, where containers, power up and down. And this is that static anymore. As it has been on the other hand, we need to be good in everything we do in security for our digital business, because, and in the digital service software is the differentiator for the vast majority of businesses. There can be software built into things and devices that can be a digital service that interacts via an app or even via I'm browser is the customer and consumer, and this needs to be secure.

So the digital child in most organizations are in is really about business models, new business models, new product services and competition. So we need to compete for that. We need the digital service, where we bring in our intellectual property, which are about our unique selling purposes, which help us to differentiate. These are developed in a very different way and operate at a very different way than in the past. So agility is key. We need to be fast, but it also needs to be highly available. So we need to deliver it the right way and we need to secure it.

If the services fail, we are in trouble. If we don't manage to get a user on board the right way, we are in trouble. So the customer churn the attack, resilience, the security are essential, and this is where we need to be really, really good. This is why zero trust is so important. Cause it is about dealing with this agile world, delivering security to this agile world. And in that I come to that in the next slide policies play a central, a vital role. And only if we deliver a good digital experience, which is secure and differ, differentiates us in the competition, we will succeed.

And if we do it right, we can deliver the time to value having an T for delivering secure digital service on time. And I strongly believe there's no way to do that without policy based access controls.

So having, having said this, what is the challenge? The challenges that the world has become. And I mentioned it to a certain extent already, the world has become way more complex. We're talking about multi-cloud multi.

It, it is very rare that organizations have a sort of monolithic single cloud environment. Reality is we still have a lot of stuff that runs on premises. We might even get some stuff back when you look at edge computing, auto trends, and we have multiple clouds to deal with. So we have servers and then VMs and public clouds and private clouds and edge computing. And it's getting more and more and we have more and more devices and things and other stuff to deal with. And we need to, to deal with applications storage.

So storage as a resource data, as a resource services, cetera, I expect heterogene and complexity to grow. And so we must think about how can we better handle that? How can we deliver agility at cost in a controlled and compliant manner secure? How can we combine all that, that trades offs, but combine it doing everything right. And what I believe is that manual administration does the right way. Everything is code is something where we need to be very careful. If the codes generated from something like policies, yes.

If it's about coding or writing configuration files, then we should be very careful because developers usually are not the infrastructure experts, infrastructure experts usually are not developers. Identity people also usually are not the ones who are really at the coding or a configuration file writing side. So we need to be careful, but can we do it with policy based automation?

Yes, we can. We need to understand for that to do that. We need to understand our it environment. We need to have data about how this looks like all these different elements I've thrown on the upper left hand. Part of this graphic. We clearly should bring in a little bit of AI. We can automate based on policies, the configuration, the access, everything, and policy based access control is one element of what happens here based on policies where we say, we know what we have. We have the policies and we use these policies and deny things.

Policies, policies are easy to describe. Everyone can describe policy. My employees in my department are allowed to perform these or these business tasks that the policy and this can be pronounced well in, in natural language can be described and a firewall policy from the structural looks. It looks similarly. So it's not really something which is different from use case do use case. So I think we have a few common denominators to get, get a CRI on what we are doing.

The one is policies, the other identities and resources at the end, it's about policies controlling, which identities of humans of non-humans have access can do. What is resources, subjects, actions, objects. You also could call it doesn't stand standard way of policies. So beat things, beat humans, non that are using whichever device, our humans they're coming via whichever network they need access to resources. This is where we need to, to think about how can be secure that. And in a dynamic actual world, we can't do that in a static manner anymore. We only can do it when we follow.

And when we support this agility and the key is policy policy based access control. So we brought up a concept.

We, we unwed this in September. We will find quite a lot of information from 2021 about what we call year in dynamic resource and Thailand access management. So there's a lot to be found in the web. So I don't want to go too much into detail, but the basic idea of that is to deliver a security that secures all types of workloads across all types of deployment models.

And so the center of this graphic, the part does is really about supporting the, the security operations, the automated response by analyzing what is happening by managing the identity and the access, including what others call key for, for cloud infrastructure, entitlement management. But we are talking about a hybrid world. And so it's modern cloud body access governance and the policy management enforcement, these things together really form an approach that helps us to, to understand what is happening to control it, to manage it.

Wire policies based on a set of information we have about all the identities and all the resources or all the subjects and all the objects and the policies that used to, to define which actions are allowed. There are various aspects to considerate for the implementation. And I don't want to go too much into detail here. The basic idea is to say, we need an approach that helps us to control our environment, to control the security based on policy at multiple places. This is where zero trust also comes in. So we don't trust. We always verify the highly automated manner.

And this is for, to my, my strong belief. The only way we can successfully deal is challenges like control, like lease privilege enforcement in our highly volatile, highly dynamic environments of today. Multi-cloud multi. And when we then go to zero trust, I just wanna bring up one graphic, which is from the N you'll see the link to the document where it originates from.

So the N then the, the document or standard 800 slash 207, looking at how they see the, the core logic components of the trust and this data, plane and control plane have to do a lot of things, have to do a lot with what I trust talked about. And they have specifically to do a lot with policies. When you look at a center of this graphic and you see the policy decision point with a policy engine, a policy administrator, and you see the policy enforcement point, which is about subjects accessing resources or objects, or that take my, my nomenclature for before identities to resources.

It is exactly this and this policy based access control value, use policies to control who can do what, which reserves is when you take them this definition, it's at a very core of the policy based of zero trust. So this is really where these things come together. And I think you see the logic behind what, I'm, what I'm saying. And we also see this in this context, this evolution towards more trust and time access saying, we don't have standing privileges, but we decide on run time. And I could argue this isn't not new, right. I tend to say, you know, let's go back to 1976.

You know what happened in 1976, amongst a lot of other things, IBM released R F the resource access control facility and system where which provided in fact, some level of policy based access control for accesses of identities to resources in a really somewhat different way. We would do it today. But the idea is not new and decisions were made at runtime.

When we, one of our biggest challenges we have is we have a ton of standing privileges and standing privileges. So the ACLS, the exit control list, windows file server, or whatever else, the most, most entitlements in the SAP system, they are how to manage. We spend a lot of time with doing so. We spent a lot of time with managing standing privileges and trying to get it Ted. And we have this re-certification stuff. They re-certification campaigns. And honestly, I've, I've never met a single single organization worldwide.

And I've talked with so many that said, Hey, recertification is a really a cool stuff. My departmental management really love it. They're waiting for the next recertification campaign.

No, I've never seen that. And I will never see that.

I assume, because it's that really fun. It's a tedious task. So policies are way easier because people can't describe policies and based on policies and policy based access control, we can't grant access when it's needed trust and time and result standing privileges. So it is about a user sending a request to an authentication or authorization system, whereas the policy engine. So this is the policy decision point policy enforcement points before accessing a service.

And it could be that even, even entitlements, if required are then provision the deprovision audit medically, or that just credentials like ephemeral certificates. So where short lift certificates are provided, there are various ways to do that. But at end, it's always about saying, I have these policies that say, okay, Martin gets access or not. And these are enforced at run time. And then Martin gets access or not. If I change the policy, then the next second, the next millisecond and the next nanosecond Martin doesn't have success anymore.

Clearly we also need a governance for policies, but that's policies are easy to describe, easy to understand. And that really helps. And this is really the message I'd like to spread. We need to think more about policies because policy based access control policy based automation is the key work and the, the essential sort of component that will help us. And that can help us to deal with the volatility and complexity of today's it environments, because we can't live, we can't handle aesthetic controls in a dynamic world. That doesn't make sense.

So we need to look closer at that because this is the key as this describes for zero trust. With that before I hand over to Dell, I'd like to bring up a second more generic question, which is about how, how did your budget change for 2020 to 2021 significant growth slide growth versus remaining stable, or will decrease looking forward to your answers? Okay. I think we can then close that.

Paul, thank you. And with that, I hand over to gal for her part, usually goes more into the concrete details about how to do that, how to make it work, Alice, your turn. Thank you, Martin. And thank you for having me in this webinar. And so I'm gal from plain idea co-founder and the chief innovation and product officer. And I'm going to speak with you about how feedback is so important for your zero trust implementation. So just to follow up on what Martin said, I want to kind of sum up what are the fundamentals for zero trust implementation? That's those are not my words.

I think you can find those, the list of fundamentals for zero trust spoken by many of those who are leading the area. But basically this is a very good list that represent what you should be looking for. First of all, default deny to start with nothing is approved, unless said so. And how is it said so only by policies access by policy only.

We'll see, in a, as we speak through the remaining of this webinar, we see, we will see what is the policy and how it enables that concept. So we start with a default deny and we provide access by the policy. We provide access to what so everything for data, for workloads, users, whatever, right, whatever needs to access, whatever needs to gain a control needs to be evolved by the policies, obviously that supports the list, privilege, access concept.

So to begin with you don't have access, but when you want to access, when you are trying to access, then the policy determines if this is a permit or not two other fundamentals, which are not going to be discussed in this webinar of, of course, security monitoring and the risk based verification, which are also important for zero trust. Okay? So let's start access by policy only. What is a policy I want to touch about that? I think a policies are widely used, widely spoken by many, many of the vendors in the market. And what's important to understand is policy is a tool.

It's a method to manage something. You can have policies that manage your authentication process. You can have policies to manage all types of processes, but here we want to focus on policies for access control and authorization. So let's see what that means, what those policies would bring. What is the value of those policies and what can they consider?

So, first of all, your access control policy would look at the identity who is the identity that is trying to do the access, right? The identity can be an employee. The identity can be an external user, a consumer, a partner, whatever the identity can also be a system account. The identity is any digital identity that operates within your digital landscape. That would be the identity. Then what the identity is trying to access. That would be the resource, right? The identity is trying to access an application. The identity is trying to access a medical or whatever other application resource.

So that is also considered what the identity is trying to access then. Well, the identity is accessing from what device is that from his mobile, maybe from a work station at the office at home. That also that also needs to be considered as part of the policy adding to that are any environmental conditions like what is the day, all time of access, location, geographical location, the, the identity is trying to access form. Any of those should also be considered as part of the decision. All of those are then checked against the policies.

Sometimes you have additional compliance controls that you want to add into the mix and together they would, they would result in the dynamic access decision. Now what's important to understand this all happened at the time of access. It's not predetermined, it's not reset. It's not something which you define in the application repository, but rather at the time of access, the decision is being made. We speak more about what decision is made, how decision can be made, and how do you actually implement that in your technology stack.

But first of all, it's important to understand that the decision is not fully determined, but rather it is calculated at the time of access based on different sources of data. Now let's touch a bit more on those sources of data, what influences the access decision. And this is really the fundamentals of the policy based access control approach. Policy based access control speaks about answering the question of who can do what on what, and when, right? This is the very basic answer, connecting your identities to the digital assets by answering this fundamental question.

Now let's dive a bit more into that question and understand what supports the decision. So, first of all, we have the identities, the who part of the question, like I said before, identities can be your internal identities. Your employees can be your external identities, whether those are partners, consumers, whatever, right? This fits very well into your workforce identity and access management program or into your cm program. Whatever the method is a method that supports any type of identity. Also internal, I also system accounts.

So whatever digital identity, now we need to support the identity with data. So what data supports the identity?

Well, the answer is whatever we know about the identity, your identities can be managed maybe in an IDP, maybe in an IGA system, repositories system, other systems that manage identity data. So a well defined policy based access control solution would be able to pull that data from different sources that are available to determine the level of, to determine who the identity is. And what else we know about the identity. For example, you might want to use certification level of an identity to support your decision.

So it's not only about who the identity is and what, what we know from organizational perspective about the identity, but any, but also any additional supporting information about the identity that can be of use as part of the decision. Okay. So this would be the first part from technology perspective. We are now speaking about ability to pull the data from using from different sources using maybe rest APIs, using any standards in the market like scheme, like elder, like sequel, whatever, right?

That that's what you should be looking for because it's important to support the decision, eh, with the available data about the identities. Next is the, what, what the identity is trying to access. So the identity can try, can be trying to access an application. And we're seeing a second that it's not enough, but the identity eventually within the application is trying to access data, application resources, whatever. So maybe the iden, the, maybe the identity is a doctor and the doctor is trying to access medical records, right?

So your, what the subject would be, sorry, the object would be the medical record. The identity is trying to access.

Now, what do we know about this medical record? We know maybe the patient, it belongs to, we know the level of classification. We know if the doctor is responsible for the patient. So therefore he can see the medical record. Maybe the doctor is not, is not responsible for this patient, so he should not be able to see the medical record.

So again, any supporting data is important, any supporting data for the, what is important in order to make the decision. And last is the when. So when is a very general term that includes many conditions you can put on top of that access. For example, what is the level of authentication the user has gone through where the user is working from the user is working from the UK, the us, maybe from some other place we need to take all of that into account. So you can see that eventually the path to making the decision is based on those pieces of data.

You know, about who the identity is, what the identity is trying to access and any environmental conditions which you should consider. This is policy based access control. This is what policy based access control speaks about. Making a decision about access and authorization at the time of access, based on the data we know about both the identity and both the identity is trying to access. Let me give you some examples. Okay. So some examples for policies.

So one, I gave ladies a doctor can access only his patient records. This is a policy spoken in a native language, right? So this policy would then be translated to different enforcement options, which we will speak about another sample of a policy, a bank, a clerk can only access account records. If he has gone through a multifactor authentication.

Again, we are looking at the identity, the bank clerk, what they can access account records in his, in his branch only, but with a condition of a multifactor authentication. Okay, we see some more samples as we continue.

This, this will be now. So this is P a. Now I want to now speak about the access and authorization flow and how feedback plays into play in, in, in that, in that flow also to highlight the connection between authentication and authorization. Okay. And what is the part of each? So here we have an identity and the identity eventually needs to access all kinds of digital assets, like data services, applications, whatever, right? That's the objective. In order for this identity to go through the path of accessing, he would probably need some sort of a access point, like computer mobile, whatever.

Maybe there have some network constraints as well, right? To go through this process. Then there is an application, the entry to access the digital asset and potentially some other level of controls that indicate the, that, that are protecting the services, the data, and the application objects.

Now, in order to go through that journey, you need to answer first, all who you are, who is the identity, right? Then you need to answer, what can you see and do for this identity? We need to know who the identity is after that, that is sorted out. Then what can you see and do? So who you are, this is the task for your identity management and authentication. Your IDP identity provider would probably handle that part of the question. The second part, that's where the authorization policy comes into play, play. What can you see? What can you do after you have authenticated?

Now there needs to be a decision of what you can see and what you can do. This is the part of your authorization policy. It works together with your identity provider in order to provide the full set of, of controls.

Now, please note those controls are course the flow path from all the way from the identity to the asset. It's not enough to stop at any one point. It is very common today to talk about zero trust network access. But that means that your zero trust stops at the network level. And as you can say, it's not enough. You need to go all the way and implement your zero trust up to the data resource up to the service, up to whatever application object you are enabling access to zero trust needs to be implemented all the way, and the decision needs to be consistent.

And that's where policy based access control comes into play. It provides one that consistency, and second, it enables you to implement the controls, also detail into your application and services and data. So if we look at that for more of a conceptual flow, initially, you are the user, sorry, the user is untrusted. And in order to, for the user to be trusted, so they would have access to the data application APIs. And so on. There needs to be a decision. This is another presentation of the diagram melting was showing before. Okay.

It's a very, it's very aligned with the needs publication around zero trust in order to go to, to move from untrusted to trusted, there needs to be a decision decision, which is governed, which is managed by a central policy management solution. Okay. And that would be your control plan for the decision making.

And again, that is true for any type of identity, any type of resource, and you can't stop just the gate. It's not enough to stop at the network level. You actually need to go all the way in to protect the actual data, resources, APIs, applications. And so on.

Again, we are going to see the solutions for that. So just to complete that part in order to achieve a complete and was robust zero trust framework access should be enforced in all levels in the network level, in the application level and within the application as well, all levels or layers of access should get the same control. And the way to do that is by implementing a policy based approach, a policy based approach, a policy based solution that provides consistency across all those layers of access network application. And within the application.

Now let's go and see a bit of the architecture, right? How are you going to implement that? What are the ways and best practices to support what I was just saying? Okay. So first of all, this is a high level diagram, obviously. And on the left side, you can see your security or IM layer where you typically would have your IDP identity provider. You would have your authorization solution recommended enforced by policies, and you have the auditing, any type of auditing and, and logging mechanisms in place.

So, as, as we are saying here in, in, in this webinar, having a policy based authorization solution is crucial to support your zero trust initiative. So that would include the management, the decision. And so all other, all other parts of the, so all other parts of, so the, the, the decision, the management and the administration of the policies now, what this slide shows, what these slides demonstrate is how decision and enforcement is touching all those layers have spoken about before.

So let's start with the network layer network layer typically speaks of as any zero trust network access type of solution, maybe VPN your, any gateway that you have at this level, typically they would be connected to your IDP, right? So you want your identities, you, you want your network clear to be identity aware. So the way to do that is to connect to the IDP, your policy, your policy solution can be also connected to the IDP in order to make the decision of what the user can access. I do have a use case, which I'm going to, to specifically speak about this type of solution at the end.

So I'll touch about that in more, in a few minutes. Anyway, you can see that by defining the policies and connecting the policy decision to your IDP, the IDP would then use those decisions in order to provide the light level of controls. Also to the network layer. Second layer would be your application layer, and there you have web applications, maybe API gateways.

And also on that part, I tell the application, receive the set of authorization from the IDP, or it can consume directly form your policy solution using SDKs APIs, rest APIs, whatever the, again, the objective is to provide consistent decisions across all the technology spec. There are different options there as well. API gateways, if you choose to control your APIs using the API gateway, which is obviously the common way, again, you can choose to manage access decisions, those authorizations access and authorizations for API using a plugin to your P gateway.

That means that the access decisions are controlled by the central policy management. And then the last part is whatever happens within the application, whether those are microservices and data for each of them, there is again a touchpoint, whether it is cycle for microservices, whether it's a cycle type of solution for your data services or a, an intercept for your data gateway, but they are all aligned with the central policy management that you have in place.

Eh, so again, this is just high level to show how policies can be tied to all levels of your technology spec, to all levels of your architecture, application, APIs, microservices, and data. And I would like to touch just as in demonstration to touch more on the APIs, so on the microservices. So I'm going to dive a bit into that just before we'll see the microservice type of use case. I want to explain about authorization question and answer. Okay. I think it's very common to understand authorization as a yes, no answer. Right?

So a type of use case, can a user see an asset, or can you use a see this record? The answer is yes. No. Okay.

So, so that's like the very, very basic scenario of authorization, but eh, what you should know is that it's not the only one, your policy solution policy based access control solution should be able to support also more advanced use cases and not just denial type of use case. So the second use case is what we call a user access token asking about a more broader question. What can user a, what can user a do? And the answer would be a list of list of assets, list of functions. The user is entitled to see the user is entitled to do. Okay.

So, so that would be your second option. The third one asking the same question back. So I don't want to ask just about the user. I want to ask about the asset, which the user is accessing and then get list of all identities that can access this asset. And lastly, lastly, the last question, I think it's very important. It's we call this policy resolution, and this would be a question about data. What are the filtering on data for this user?

Now, the idea here is to add the relevant, if you would, we can call it like the well close on your sequel query. Why, why do you need that? The idea is to provide consistent answers to the same policies for the different technology deployment patterns. Let me just give an example. I know it was a bit long sentence, but an example, right? So going back to the first policy I spoke of a doctor can access only his patient records, right? So the doctor would access the Porwal, the medical Porwal and now he was trying to access a, a single patient record in this case. Pattern.

Number one would be good for him because we can ask for the doctor, ask for the specific medical record and get a yes, no answer. But if the doctor is now trying to see a list of all patients, for example, then maybe number two is the better option for him.

Again, it would be aligned with the same policy, but that's a more efficient pattern. Now let's say the same doctor is trying to submit a report, a report that would go and get all the different medical records of all this patient. So we can't start doing a yes, no answer here. We can't also, we can't also do a list of in this case, we need a data filtering response, and that would be pattern number four. So your policy would support the different deployment patterns you want to enforce across your technology stack. And that's how you typically do this. This would do this with microservices.

I'm currently showing an example of, but that's aligned with any service mesh, which is out there incoming traffic would typically be intercepted by some sort of proxying in this case, ENVO the request is then reelected to the PDP, to the cycle. So cycle PDP, which would make a decision whether to let the transaction move forward or to be blocked. There are more advanced options here, which I don't have the time to touch. So I won't do them now, but just know your options in order to fully implement zero trust, you need to go into the application.

You need to touch the, you need to, so you need the ability to control all the application assets, your data assets, whatever the application is exposing. You need to do that also on your API level, on your microservices level and on the data level in order for zero 12, to be fully aligned with what you want to achieve. And there are, eh, methods, eh, best practices, how to do that. This is an example for microservices. It's very common. I can share that. We see a lot of interest in this type of pattern today with the customers we are speaking with.

And I'm just going to end my part with the case study of one of our customers. So the idea was to support access to a sensitive applications, and the control was done through some kind of a VPN type of solution. And obviously the players are an IDP and the policy manager and flow is as follows. First of all, there was a police setting. So we connected the policy manager to the VPN solution, where we had access. We had visibility to all the URLs, which are exposed. Then whenever the user is trying to access the application, the obviously the VPN would redirect the request to the IDP.

The IDP would then consult plain ID to get a decision. That decision is calculated real time. What the user is trying to access. What is the level of access response is sent back to the IDP. The token is in the reached with the relevant information, which then permits the access, very fine link to the sensitive application. So this use case shows how IDP plays with policy manager and together with the control in this case, it's the VPN type of a application. And I believe out of time, Thank you for, for these insights and all the details you've provided.

We directly will go into the final part of our, of today's webinar. Since the Q and a session we have side of the two poles. We have some results. We also have quite, quite a number of questions in the interest of time. I would ask you to come up with concise answers. And the first question I'd like to touch is what do you think about central versus distributed policy decision points in terms of availability and performance? I think this is a standard question. I remember I've got these questions back in the days of XML. Yeah. Already. So what is your take on that?

Yeah, so I'm a strong supporter of central management management decision needs to be distributed because decision needs to be as close as possible to the application to wherever you are doing. The enforcement reformance is crucial.

So that's, that's my, that's my recommendation. You do need the central management, right? Because you need the ability to, to control your decisions across your technology spec in a central way, you need a visibility. You need investigation on investigation capabilities, Martin, you spoke before about the ability to audit and to be compliant with your regulations.

The only way you can do that is by centralizing management, but your solution, the, the P solution should be able to manage that the policies in one place, this review them to the different decision and enforcement options, because those would be aligned with the technology that you are currently using, whether it's, you know, data, microservices, whatever. Okay, thank you. Before we can go to the next question, I, I just wanna quickly show the results of our first poll.

And I think for, for webinar that has a zero trust focus, but also when I look at where things are evolving into your Indians industry, it's not a big surprise that making zero trust reality. So going from conceptual perspective to concrete implementations has got by far the, the most responses and, and some of these aspects like providing trust and time access and replacing, standing privileges and delivering policy based access controls for, for hybrid infrastructures are closely related to that.

I I'm a little bit bit astonished about the low number for implementing F MFA and past less authentication, because we also see this as a very, very, very odd scene, but okay. And clearly a lot, still have to deal a lot of things with modernizing. I am to just share these, these results here, but with that, just going to the next question, and I think we can pick one more, one or two more questions. The next question I have here, you had a zero layer slide and with some sort of an architecture, how do you deal with multiple IDPs?

Well, that's, that's easy when you have, when you have your policy in place, right? Because the policy is tied to multiple identity sources. If that's the way your architecture is structured, then your policy solution should be able to connect to the different identity sources and make the decision according to whatever is being accessed. That's very common, especially in, you know, when you have also multi-cloud environment, when you are organizations that went through a acquisitions and so on, you have multiple IDPs.

That's, that's fine. That's the situation which you are at the whole idea of a policy solution is that it can map to your identity sources to your asset sources and use those in order to make the decision. It doesn't change your architecture, it supports your architecture. Okay. One more question. I have a couple, couple to choose from here. Maybe that one is a very interesting one. How can plain ID work in contract with Microsoft Azure and, and Azure active directory or, or does replace the feedback capabilities that are already in Azure ad? So what is your play with F RD?

Yeah, so absolutely. We're not replacing nothing in Azure ad. I think it is aligned with, and I'll explain a second. Okay. Feedback is a method of management.

Now, the question is what are you managing in U D and in other solutions as well, you have the concept of a policy. You have a concept of a policy that enables you to manage your authentication process that enables you to manage group assignment, which I believe this is the case with Azure ID and plain ID comes into play on top of that.

I mean, if that's what you chose to use, then that means you are doing group assignment or assignment using, you know, attribute of identities. It doesn't take you all the way to your, you know, APIs, Michael services data. So the idea is to walk with what you chose to use and add that missing layer on top of that, to support your APIs, to support your microservices, your data, and so on.

Okay, thank you. Before we come to the end, I also want to share the result of the second pole with you, which are about the budget grows or budget changes for, for identity management, identity security. And it's interesting to see that, that for 57% of the, it depends that Paul, they see a slide or significant growth and yeah, as I 40% also see very stable.

So very, very few really see a decrease here. And I think it's corresponds well. What was for what you're seeing in the industry at end and security budgets really are in increasing, which is clearly good thing for the industry. So we still have a few open questions here.

I, we will hand over these to gal for following up directly on these questions. Thank you very much for being so active in this webinar for answering these questions.

So I say, thank you to you. Thank you very much for participating this call webinar and hope to you have your soon back in one of our upcoming other webinars or events. Thank you. Thank You.