Yeah. Yep. Okay. Good morning everybody. My name is . I am he, the product management team at Ion. Devin is a European company, which has been in the market for more than 20 years and provides an AIM suite capable of addressing both access and single cell and identity governance and administration for any kind of users, devices, or applications that can be proposed as OnPrem manager service or as a service. And we have an international presence with customers all over the world. Thank you.
Thank you. Hey everybody. I'm gal, I'm the C own the of Plain idea and the co-founder Plain idea, as you probably know, is the authorization company. We actually pushed p a policy-based access control to the market. So certainly the right topic for us.
Okay, so my name is Koser. I'm currently with a small startup called slash id, but before that I have time from Tyra and Matics where I've seen something between 50 and hundred feedback project going into production or not going into production. And we can talk why.
Hey, my name is Haw from TAs. I'm working on a product strategy and policy-based authorizations is one of the three key pillars of our product strategy. And on a small personal note, I was, I, I met Bobak in, in the, in the conference, one of the pioneers in the policy-based access. And we remembered that it was actually 10 years ago that they certified as a, as a solutions engineer for acumatic. So that's what I did in the last 10 years.
You could ask him for a new t-shirt. Yeah.
I'm Brian Iverson. I run product for Tu Bora. We are primarily an identity governance administration vendor. So I'm, I'm gonna be approaching this, this topic more from the administration side than from the access enforcement side. And I think that's an important distinction that we'll wanna make as we go through and discuss this topic as we, as we move along. Before joining tabora, I spent three years running strategy for Bank of America IAM strategy that is, and then also spent years covering the identity governance administration market at Gartner.
Hi everyone. I'm Alan Alan Foster, most recently from, for Rock. I haven't worked there now for, I dunno, 14 months. And I'm enjoying myself thoroughly, not doing anything prior to that. I've been involved in access control for years and years and years, and we, we are looking at it now. I first started this all off with the Netscape LDAP server. It's gonna solve all of our identity problems. If you want to talk about it, I'll talk about the directory server and we've been doing it for 30 years since then. So all about access.
Okay, very good. So
I'll start off by presenting a question. If one of you would like to or indicate to answer the question, just let me know by raising your, your hand and we'll go from there. So just to help level set the audience who may not be aware of policy-based access controls, what does it, how does it differ from other types of access controls? Yep, go ahead.
Thank you. Well, after all, we did push that to the market. So appropriate question. So policy-based access control is a method to manage authorizations. That's what it is. It's a method of management. Now it comes after a long series of other methods starting with ACL's access control list was, you know, back, back then still used in some systems, obviously was not efficient enough. Then role based access control, right? So where you manage roles still there, still needed, I don't think we can get rid of all that easily attribute based access control, which basically looked at the attributes of both identities and what identities are trying to access the digital asset and define the relationship between the two based on eh policies, but then policy based access control. So what's the difference? Many people are saying this is just a marketing term, right? And what's the difference between policy based attribute, attribute based and all the rest the things that we need. In my view, policy-based access control enables you to include business processes to manage authorizations efficiently, including both attributes and roles. Authorizations are not just technology authorizations are also processes as you very much well know that. And that's the notion of policy-based access control, how you manage, how you decide, and how you enforce.
Okay, thank you. Is anybody else?
Sure, I'll dive in. All
Right. It's all yours.
Not I, and I don't disagree with everything that you've said on that, but the, one of the ways that I would differentiate them is when we look at access control decisions, are we looking at who you are or what you are and the, the acls and things like that were very good about who you were, right? It, it was you that had access to this thing and if you didn't have it anymore, somebody had to go in and change that, right? Policy is more around setting a policy for how it gets done. We need to know who the identity is, but the access is not tied to the identity. It's tied to things we know about the identity. And so we can now have an easy to describe policy that we can say only people over 21 can get a drink that's tied to your identity, but it's not tied to say, and by the way, this should be a rule. Alan can get a drink. Right.
Okay, thank you. I'll ask one or two more questions and then we'll go to what the audience is asking. So how does policy-based access control improve security and compliance?
I can also answer that. So eventually we need, security is all about enabling access to the right resources at the right time to the identities that's, that's secure in my opinion. Security controls are there to enable not to block, by the way. And policy just does just that. Policy based access control defines the right connections between your identities to your assets, to your data assets, right? In, in, and if you enforce those policies, that's how you get your security organized in, in an efficient way. Otherwise, how else would you, would you manage who can access what? So that's, that's the core component of any security initiative. Additionally, you all here today, people in the industry talking about identity first, identity aware, zero trust, right? All of those notions. What do, what does that mean? It means that if your identity is at the core of your security program, that means you need to consider identity at each and every point. When identity access through a device, a network, an application goes through the application to application resources, data, and how that is managed policy-based access control. That's the way which you manage that,
Please. Okay. First of all, all these policies, more or less already exist in the code, but they're hard coded in applications. And that's the thing that we are fixing now. We are moving them out to a different PDP or what you, what you can call it. And the beauty with that is that you report on it, you can change the policies and you can lifecycle policies because by having them in the code, if you want to change a policy, it comes new regulation, you need to change it in 50 places in your code. And there are these edge cases, RBAC will still be the right choice for 80% of your decisions, but for the edge cases, the fine grained, you can't have arrb, you can't have a role that defines if you work in an insurance company, you crash your car, you file a claim and it ends up in your queue, you're not allowed to touch that. You can't do that by our bank. You need to have a policy. And that policy today is hard coded in the application, but you want to lift that out so you can live cycle it outside, and you're important outside. You can show it to your auditors outside. That's what feedback is for me.
So you're saying it's easier to manage?
Absolutely.
Okay. So we'll go to the general, did you have something on the end or?
I was just wanted to complete her answer that multifactor authentication and contextual authentication is something that can even be added and improve the security level that you were talking about.
All right. Was there one more?
Yeah. And for, for me, the, the big revolution with this is that authorizations now turn into something very dynamic. Something that you do at runtime rather than just something that you do like months before, before the transaction. And why do we need it is that we also do not, we all say identity first for sure, but in the long run, the identity will kind of get hidden in the cloud because we do not want to share too much identity data anymore. And it'll turn out that the transaction will be authorized maybe even without knowing all the details of the identity. And then you do need a runtime, dynamic authorization decision on a transaction rather than an on an identity. So we bring authorizations from identity centric to transaction or resource centric.
All right. Yeah,
I'll just, I'll just have to sort of throw a little cold water on all this talk right? A little bit because I mean, honestly, we, first off, we have the long tail of the legacy. I mean, when you're talking about authorizations at the application level, you know, you're talking, you know, you're about, about custom applications and you know, a lot of this stuff about policy based authentication. There's a few issues with it. Number one is performance, right? That, you know, when we talk about like static auth, static authorization within applications very fast, very efficient. Whereas dynamic authorization offloading the authorization decisions to an external service, orders of magnitude slower. And so, you know, and, and so when we're talking about how are we, we're gonna do this is it's not an either or, you're gonna be using the, you're gonna be using your, your course grain for, I mean, for course grain authorization.
Most of the time you're gonna be using static authorization because it's performant. And, and it's something that's done very, very frequently within the application. And then for fine grained, authentic authorization, more sensitive transactions, more in, in a more dynamic environment, more dynamic business environment. Yeah, you want to use some dynamic things, but again, your developers have to adopt this. And that's probably been one of the biggest issues in terms of, of, of making the move to, you know, honestly, I don't see a whole lot of difference between a back and p back. I view it more as a, as a, as as just, you know, a branding thing, a marketing thing, you know, so, you know,
So let, let me, so let go ahead me. Just respond to some of that. Okay. Please. First of all, I understand performance as a topic. I don't think performance is an issue with externalizing authorizations. By the way, runtime authorizations, dynamic authorization doesn't mean just runtime at and every call today, the technology has evolved so much. There are different patterns for actually to support dynamic authorization. That includes also log in time authorization. It includes authorization at the transaction level or at the application level, or at, even at the data level. Actually it creates more efficiency. Efficiency in many, many cases. Just think about your typical application Porwal that needs to access data and includes all that logic of who can see which data just in the code. You need to recode that over and over again. You need to include that in your calculation path. Really doesn't make sense to do that anymore, eh? So just know the multiple patterns. Security is a concern. I agree with you, but it also has solutions today. Much more advanced solutions. Just last comment, also agree, eh, static authorizations are not going away, but the combination of the both, the balance is going to be more towards dynamic authorization because they in increase efficiency and security.
And I just say the one thing is that my experience working with application developers in this space is finding that balance is really hard and, and, and it's easy to make some really big mistakes.
Yep. I wanna comment on one thing you said about the legacy application. Cause what I've seen in the project retrofit payback or a back to a legacy application, avoid at all cost. Yes. Yeah. It's like, oh no, it's like open heart surgery. You do it if you need to, but avoid at all costs because it is costly. Most product fails around significant, everybody look for new build, look for cloud native, look for microservices and build it right from the beginning when you're building your new services. That's my advice.
Okay. Everyone, I'm, I'm gonna throw water on it as well. All
Right. Rebuttal.
I think that the one thing that policy-based authorizations really give us is an ability to understand what the authorizations are and to simplify it. And that's where the security comes from. There's absolutely no reason you cannot do static authorizations based on a policy, right? Right. Policy is a way for your developers to understand who is and not gonna be allowed to access some resource. And it's the ways that we can say, oh, only employees can do it. That's a policy, right? And that way we understand it rather than, oh, there's some magic group of people who have something set in the directory server that lets them do this, right? It, it becomes opaque and we don't understand what it is. And so policy forces us to actually say, what are the decisions we need to make? How the actual runtime piece happens doesn't really matter, right? It, it can be a complex runtime thing run or a static authorization, but it needs to be based on what the policy is.
I,
I'll throw one more thing because, you know, we're getting into the administration context, which is where, you know, policies, working with policies is a lot more, is, is incredibly important in the administration space for those applications that rely on static assignment of permissions to accounts. And so that's where we, we, we tend to talk about, you know, in the absence of, in the absence of policy, all access is exceptional. And so when you're talking about things like access certification, fatigue, you know, and just in general the administrative and procedural bloat that comes with identity governments administration, in most cases, it's mostly because of the lack of policies. Either, you know, either from a technology perspective, you haven't established the foundation to allow yourself to use policies well, or you just haven't gone through and thought about what your policies are. And if you can't distinguish between access that's been granted based on policy and access that's been granted based on re request, your, you're, you know, it, you're gonna have to treat all access as exceptional, which means you can't reduce the load of your access certifications. And also, I mean, honestly, why are the auditors yelling at you? The auditors are yelling at you because your policies suck. And so now is the answer to do exactly what the auditors tell you? No, because they don't know what they're doing. They're knuckleheads. Okay. But it, but it it, it should be a signal that you have to work on your policies and, and that happens at multiple levels when you're talking about administra, you know, identity administration, identity governance administration.
Okay. So just as a follow up, I just want to emphasize policy-based access control, that's not just for developers. Yes. The initial use cases were mostly around development and providing tools for the developers to manage that and use that in an efficient way. Today, again, the industry has devolved, for example, in plane id, we have the notion of ready to use authorizers, which are ready to use components. Let's say you want to manage access to your snowflake, right? That can't be done in runtime, not really. It needs to be a policy, a well-managed policy, which is coordinated with your other technology stack, but it needs to be managed in Snowflake, right? It's not runtime, it's, we can talk about what that is. So there are options out there. Technology has involved, industry has evolved, and policy based, in my opinion, is a way to manage it provides efficiency. And to touch on that last point of certification, part of the challenge we have today, because we are managing so many roles, is that we need to approve them and reapprove them and reapprove them over and over and over again. Just think about managing all that in a well-defined policy, reducing the amounts of decisions of those roles you need to manage. So policies are a way to manage both your roles, both your attributes for developers and for your other courts applications.
Okay.
Just
Just to add Yes, go ahead. Your common for
Water if you want.
So I, I, I agree that, that the good definition of the policy is key to be able to manage the system and maybe for, for lacking this good definition, we have the recertification campaigns, but another way of looking the thing is why the system is no intelligent enough to indicate what's going wrong. But maybe if every time that somebody is requesting an access that the peers has, why don't propose to automatically assign these access or un enrich our given role Exactly.
Based on a policy
Based, based on the user activity and based on, on, on what is going. So the system learning about it can't hear
What you're saying. The fact of the room. Can you speak up please? I can't hear what you're saying in the back of the room.
Wasn't good enough. That
Much better? Yeah. Okay. Ellen,
I just had one last thing. One more point on on what we were just saying there around access certification. Can you hear me? Access the ACCESS certification has exactly the same problems that was actually brought up earlier on around acls. It's because we are looking at who you are, not what you can do. And the reason we have to go through the certifications is because we have to keep our ACLS up to date. Essentially. It's, it's, it's taking us back into the dark ages. The policy enables us to keep looking at what that person should be able to do and not have to keep going back to certify it. Yeah.
But the dark, but the dark Ages is about 90% of our application portfolio.
But
We gotta Yeah, but that means that you are using the principle that the policies will define. And I think that from a governance's point of view, you need to verify that what it has been defined is respected on the target system. Typically we call that reconciliation and what has been defined, does it meet business needs? Does it really cover to the business needs? If this is perfect, then I agree certification combines makes no sense, but I think that we are not defining a hundred percent accurate policy from the beginning.
Sure. And we can fix that. But the, the other side of that one is how people actually get access with certifications is probably considerably worse. Because I know I'm guilty of doing access certifications by saying yes, yes, yes, yes, yes, yes, yes, yes, yes. Thank you. Move to the next one. So if there's absolutely no diligence done on certifications other than Yeah, I said yes and I signed the form, it's not any better than a bad policy.
That's what I was saying at the beginning. If you combine symbolic ie, or machine learning to these certification campaigns, that will make be more accurate and improving the system itself.
All right. So I would like to get to one last question before we go to the audience. Let fight, go for it. So the, the title of the, the panel, there was roles and re recertification in there. How does policy-based access controls improve that versus the traditional way we do it today?
That's like a softball for me, isn't it? Yeah,
I mean, I mean, you're just up there for me, John. Okay,
Well, okay, well, I can say we will never get out recertification because it's not owned about security. Well, when I start my work as manager, okay, I have a few vacations I need to sign off.
You might wanna get a little,
Is this not working? No,
It's working now. Now we could hear it. Yeah.
Okay. So exactly like Anna said, you start today with approving a couple of vacation, a couple of people who wants to access to some system and you more or less approve them. And that will continue because access to system is just not, security is cost as well, because if you have access, it drives license cost. So that will continue. So it's two part of the recertification and the cost or license part will not go away. And the other thing is, if we move everything to policies and attributes, the main attribute for policies are robes. So we still need to reciprocate that one. You're still,
You're stealing it.
So if we'll never go away, we will have even more is my view. So, and the question is, how come we get the quality up when we do ROY certifications? That's what we're gonna look at.
Okay. So I believe that policies would improve the certification process over time. Yes, it would take time. It's not, it's not immediate. So today the majority of certification process is a lot of rubber stamping, right? We need to approve those access that users have. We don't always understand why they have it. Policies are not just showing the way to manage the authorizations or the connections to the identities, to whatever entitlement they have. They also provide the reasoning why you have that, that type of access. So that's another benefit of the policies. Placing policies in addition to roles there not replacing roles, absolutely agree. But in addition to roles provide you better management and also understanding of the why that is there, why access is there. I spoke, I believe it was a month ago with some of the big firms that are responsible for auditing.
And the, the, the discussion was around can policies support your certification process? Would you as an auditor agree to use policies? Because they provide a different visibility, right? They define the visibility of the why accesses there, not necessarily looking at the identity and seeing his current static roles, but understanding the logic of the access. And she was saying, yes, absolutely. She's the person responsible for auditing in that large big four companies. And we, she, she also indicated what she needs. Yes, you need to certify the roles associated with the identity because that's something you are giving the identity and you need to certify that. But combining that with the policy provides more efficiency and understanding of the full access the user has in place.
So I'm just gonna fundamentally say roles make attributes legible. They actually allow you to use attributes and policies. They're, they're, you know, basically they, they, you know, in, in back when we were talking about attribute based access control, you're, you're, your best attributes are gonna be your roles in many respects. Because number one, an attribute is a very, very unstable piece of information to base an access decision on. You want to have an abstraction there because do you want to be digging around in all these different policies when you're, when when HR changes, you know, how, how departments are lined up? No, you don't wanna do a search and replace within all of your policies. You want to have these, these, these, these abstractions sitting there basically business roles helping you to identify, you know, what is the meaning of this? Not just what's the value of this attribute?
Well, what's the meaning, what's the context around this attribute value? Plus, that also gives you an opportunity to better manage assignment of people to certain roles because now you're not entirely dependent on attributes and having to go back to these authoritative sources. You can get, you can get that discretion into there as well. But you know, when we're talking about like, are we gonna, you know, is this policy based access? I mean gonna replace certification? Well, no, we're gonna have to certify policies, we have to review policies periodically, you know, that's the whole purpose. But the whole, but what we wanna do, and this is the whole, this is the foundation of auditing people, right? Is that what does internal audit exist? Internal audit exists to make sure that people are following the organization's policies. If you don't have policies, that makes the auditor's job a lot harder because they have to basically infer policies and do a lot of evaluation.
You know, I mean, a lot of sampling, a lot of review to try to make sure that, you know, there's no fraud, because that's ultimately what you're trying to, trying to prevent with policies is fraud. And so by having policies, you actually help your auditors because anything that's policy compliant, yeah, you might do a little bit of sampling just to make sure that the stuff that falls under the policy compliant label actually is policy compliant. But that allows you to focus your attention on the things that aren't policy compliant, that were approved as exceptions. So you can better identify and, you know, and and, and really narrow down your, your work. And so that's one of the things about this is, and especially in the administration sense, right? The purpose of policies is to help you distinguish between access that's granted as, as you were talking about there provides context to or intent behind access. This access is allowed based on policy. That should be the end of the question, hon, honestly. And then it allows you to focus on the access that's not a sign based on policy. And then you want to have incentives in the organization to tilt the balance of access toward policy-driven access and away from exceptional access.
Go ahead.
A go. No, you grabbed the mic first. Go for it. Yeah,
No, we, we shouldn't forget that roles is an invention from it. And still a lot of people do not understand the concept of a role, right? I'm currently working on a, on a, on a blue collar use case, and it's very difficult to explain people that actually work as a mechanic in a, in, in, in, in a, in a, in a garage, in a, in a dealer shop, in, in a car repair shop to explain them what the role is. And so we have to find different concepts that feed information to policies. And another concept could be like relationships because people know what the relationship is. People are familiar in dealing with relationships in their social networks. And so how do I relate to a company? How do I relate to a data asset? How do I relate to a transaction? Is is a language that is much more easy to understand, which then can feed policies that enforce certain actions. And so we have to get rid of the concept of a roll. So stop,
I was gonna throw in on the roll thing too, then you can come back in. So access control is a long ongoing process and it's not a sequence of steps and we don't have some new thing to fix it. Everything that we are dealing with is trying to make things simpler. Roles is simpler, simply a way that we looked at it to try and abstract away users. We didn't want to keep a list of 120 users in our head to give them access to every application. And we said, okay, that's it. People can get access, let's group those into a, an easy to manage moniker. Not realizing of course, that that was going to lead to 125,000 roles and we had no idea what they did. But that's the sort of different problem we run into. It's really just an, a simplification to think on letter thi lesser things policy gives us another way to try and simplify it. And in many cases, as we've said, roles or groups of users works, we have roles that we all implicitly understand internal users and external users. That's conceptually a role and it's very clear that we know what that is. And if that's all we need, then we use that. Otherwise we need to get more specific on where the policy is and the policy gets us to understand what the process is in order to give authorization, right? And, and it just makes, it gives us another way of looking at that problem.
I I, I would like to complete what you say because I completely agree with you say, and I think that those roles, when we talk about access, the information needs to be complete with attributes linked to the user that will be used by the application itself to define what this user can do. So it's the combination for me, the combination of both roles and a based access control, which complete, which provide right policy for access.
I absolutely agree with you that there's the rules are going to be there. They're not going away because you need to somehow define what HR doesn't know or other systems do not know. However, we also need to remember that roles have just a single dimension and that's not good enough for many, many systems. Just think about a simple example, right? You are a developer, so you get a lot of a developer, but you are walking in multiple projects. In others you do not. What do you do? How do you solve that with role? So I'm sure many of you have faced that problem. What did you do? You started defining dev slash project one, dev slash project two. That's how we get to role explosion policy solves that. You don't need all those weird combinations of of roles and that's why policies are needed. And again, the question is not roles or policies. Both are needed. Both are there policies just makes the management much more efficient. They provide the reasoning for the access together. Hopefully they would simplify our lives. All
Right. Only one or two more comments. We like, we like to react to the comment because I I cannot agree. I mean no,
I gotta, I I I I I gotta
Absolutely impossible say a doctor or a nursery is a nursery, I agree, but depending if she's working in urgent is, or another section in the hospital may require different permissions. So the, the fine gain or the, the final permission which is assigned to this person is based on the combination role and organization where this job is performed. By using that, then we assign the right, the right conditions. You don't Yes. Policy only policy. No, no, no, no, no, no. The the airbag model allows you to do that. That's what,
But, but, but I think we, we are missing, we're missing the most important thing. The policies are already there. It's not something win by now. The policies are either there hard coded in the application as is, it's the legacy or they are in FS and binders that all companies has policies they need to adhere to. What we are talking about is taking these policies, put them into code to lifecycle and report on them, but the policies are already there and we need to live by the policies. This is just doing more efficient way of adhering to these policies. That's what we're talking about. Not policies or not policies.
Policies, yeah. And ultimately, yeah, we need to make policies legible. I'm gonna, I'm gonna just throw, I mean, I'm gonna, I want to establish a little bit of precision around the terminology when we talk about roles because a lot of people will mix up things, but you know, I mean, roles are simply just an object, right? That has a list of users and a list of entitlements or permissions or whatever you want to call them, right? I mean, they're, they're, they're, they're, they're that there, there's groups which are just a u list of users and nothing else. And then there's profiles with just, which is just a list of permissions or entitlements and not a list of users. And so you ha you have this basic thing, roles are very versatile things and the problem with roles and a and the problem that a lot of people have with roles is that most people use them incorrectly.
And so when we start talking about this stuff about, you know, getting, you know, creating these more and more fine-grained and roles, you know, I can't tell you if you have more than, you know, if you know, you tell me how many roles you have in how many users you have. I can't tell you based just on that, whether you have an effective role management process or not. I gotta know how you're conceiving of your roles. Are you thinking in terms of having roles that help you to organize your entitlements, to make your, your administrative surface area more manageable, like compressing your administrative surface area? That's fantastic. That's what you should be doing. Are you using roles to help you to organize your business entities such as organization? I mean as departments and locations and things like that, that's fantastic as well. Or are you using roles to create things around like departments and so you create these departmental roles and then pile all the access into those in, into those roles.
That's you're screwing up if you're doing that. And that's the whole, and and, and most people, the intuitive approach to doing role management will lead you down the wrong path because people think we're just gonna do it at a department level first. No, that, you know, if, if, if you say that you think you're managing your risk, but actually you're just creating a disaster for yourself, that's gonna, you know, that, that, that's, that's gonna cost you down the road. So there are right ways and there are wrong ways to do role management. Most organizations do it incorrectly, unfortunately, because the intuitive approach leads you down to down a dark alley. And that's where I think roles get a bad name. Also, the vendors, they don't really guide you on how to do it, right? So they just give you a, they just give you a tool and say, go do whatever you want.
Okay, so we have about five minutes left. I want to give the audience a chance to ask a question. So Alejandro will moderate that.
Speaker 11 00:36:39 Well, there's like 14 questions online, but I don't think we'll have time. Maybe I can just provide one question that has plenty of votes and maybe just one of you can answer and then I'll give the mic to anyone in the audience. So the first question is, can you give an example of an authorization decision that cannot be implemented by attributes based access control, but can be implemented by policy based access control?
Okay, so I don't think, I don't think that's, I would just say like attribute based access control is a method of using attributes to make a decision. The decisions are not different in policy based access control, policy-based access control provides a layer of management for those attribute definitions. It also includes your roles. So the decisions are the same. The decisions, there are four decisions you need to be aware of. Four decisions traditionally, by the way, the initial standards for attribute based task access control. Zamal probably some of you know, that supported at the beginning just permit deny. Today we know there is permit deny, entitlement resolution, user resolution and policy resolution. So all of those needs to be supported. Policy based access control enables you to manage that, to govern those decision. It enables you to combine those attributes, the technical part of the policy to c to provide those decisions. So I wouldn't say there are different decisions, it's just
Sure. I'll give you one. I I can throw several of them in. You've got a policy where you are only allowed to buy hardware in your home country. How do you enforce that someone cannot do that while they're traveling at eic? Yeah, right. It, it's, it's, it, there is no attribute that says you're traveling at eic, so how do you, I'm allowed to buy the hardware. I'm qualified, my identity says I can do it. It's hardware that's approved for me. Microphone, sorry, again, I get told the microphone, right? That's, that's an example of a kind of decision where you've gotta go outside of the scope and look at a policy involved.
Speaker 11 00:38:59 Okay, maybe we have just time for one more question.
Speaker 13 00:39:09 I'd like the panel's advice on a particular question that I, I have, so I'm, I'm operating in the mission critical systems arena defense, that sort of environment. Can you give your view on the use of dynamic role-based access control where in effect, based on an activity that's happened, let's say a brigade combat team's just been hit and hit by a, a, a Russian missile and now what you've got is you've got a whole bunch of other people who now need a whole range of dynamic roles and entitlements accessed oh, sorry, generated in order for them to continue the battle. So that's what I'm calling, well I think it's generally accepted now, dynamic role-based access control, which is in effect put in place by policies, a policy which says in the event this happens, I need to dynamically create a, a new person with these roles. And how do we achieve that?
Yeah, I So so what you're referring to is kind of practical laws policies, right? So if certain conditions happen, then you basically activate a separate set of rules or policies and that totally makes sense. And so I I I do see in, in the industry actually also a link between policies and events. You've got stands like KS E where you actually have events that can happen that can be distributed amongst systems and these events, combining that with, with policies actually should be able to implement the type of use cases that you refer to.
Speaker 11 00:40:48 Yeah, it actually has been solved by agencies you're talking about, but I'm not allowed to talk about that. Yeah, I think we,
We have that is, it's, it's a very standard problem in the dod right in, in the us and in in that issue, what you end up having to have is policies controlling the, the author, the authoritative source. Because you can no longer rely on centralized identity management. You have to rely on field based identity management and you have to have a policy as to when you can allow that.
Speaker 11 00:41:19 Sorry. But we have to wrap up and jump to the next session. I encourage you to talk to the panelists after round of applause.
