Policy-Driven IGA – Why This Approach Produces Better Outcomes

Great. Good afternoon everybody. He's already introduced me. So today what we are gonna talk about is how policies can help organizations make the most pertinent, most timely and quiet accurate decisions. When it comes to identity and access management. I'm going to mostly focus on policies pertaining to provisioning side of things. Obviously, when you think about security and risk management, policies can span whole bunch of areas. So I'm not gonna cover all of that, but mostly focus on the provisioning side of things. So as everybody here is aware, IGA is is a vast space, and there are a lot of interesting problems that people solve. There are challenges and problems that are specific to large enterprises. There are things that are probably local to SMB space, and there are probably some topics that are going to span all organizations irrespective of their size, right? And when you look at an I G S solution, bring it to your environment, obviously you're told, Hey, you need to do this.
You need to get these people involved. This is the first thing you do. This is something that you do down the line, and so on. That's all good, right? But I think we need to pause here and ask the question, Hey, solution, you know, what are you doing for me in terms of decision making other than bringing in automation, right? How are you making my life simpler, right? And if you think about what's out there in terms of the data that you manage, you have HR data, you have raw permissions from applications, you have modeled entitlements, you have access changes that are happening. You have access requests that are flow flowing through, and you have this periodic and even driven certification that people talk about. And if you have deployed any controls, like s UD and stuff, you have remediation actions that you need to take when there are control violations, right?
So there is lot of data out there, and it's important for everybody to come out and ask, Hey, can you make some inferences for me based on all these activities and data that's out there? How often can you make those inferences for me to help me in my decision making? Right? And for a period of time, can you get better at those decision making activities? And the decisions that we are making are applicable to different stakeholders, right? A supervisor makes certain decisions, a, a role or a group owner makes certain decisions, an application owner makes a certain kind of decisions. So can you represent these inferences for me in a way that is in a consumable for me to take things forward? So a lot of interesting things that we want a, a solution to do, and those are the kind of questions we should be asking.
And I'll rest of the conversation. I'll cover, you know, these areas. But first, let's look at how this problem actually manifests. You know, what do people do with regard to policies, provisioning policies today, right? So the, the model is people work with line of business, work with different groups of people. They collate all of these provisioning policies. They put that together, they bring out a solution, and they enter all of that, you know, rules. You know, everybody's aware of the joiner mover lever scenarios in the rules surrounding that. And then, you know, these activities can take sometimes weeks, sometimes month, and even quarters as well, right? And it's just not about, you know, these policies coming together. There are things outside of security and risk management that people don't control. You know, the changes to the business processes within the company. There could be m and a activities that could drive things.
There could be changes to your IT landscape itself in terms of what tools you bring in, what tools you do end of life with. And over a period of time these policies become obsolete. And it's important to take note of this because your whole objective was to bring in some structure into provisioning and structure, into, you know, granting access. And once they become obsolete, you know, a lot of other ripple effects are going to happen. One is suddenly you'll find that there is a complete disconnect between an individual's role and what they need and with what have been given. And there is proliferation and increase in terms of access requests that come into place, right? And yes, you'll have approval process in place, you have tools to do all of that, that's all great, but suddenly there is a spike in, you know, access requests that becomes, you know, a problem.
The other thing that happens is because of these changes, because of these, you know, requests coming in and because of all the manual activities, suddenly you are burdened with, oh, I need to do these access reviews. You know, because there's bloated access that you'll see within the enterprise across the board, and everybody will get more than what they need, even though it's gone through a parole process. Nobody's tracking, you know, what somebody's getting over a period of time, right? And as you can imagine, or or a period of time, what happens is that the larger the organization, the bigger the problem this becomes and it becomes uncontrollable, right? So how do you, you know, manage these things? So what you'll see next is an illustration to talk about what happens during a typical, you know, review process that organizations embrace. So first is you are looking at, you collected your data and you are triggering, you know, a, a review campaign, if you will.
And then you go through different stakeholders performing the review, and you, you kind of feel good about, you know, where things stand in terms of what access people have been going, yes, rubber stamping and this, and that will come into play along the way, but you, you kind of satisfied with what happens and your auditors are happy, your management is happy, and then you'll go back to doing what you do, you know, going through the access request processes and everything else. And suddenly for a period of time, again, you get into a situation where before the, by the time you come to the next service cycle, you find that things are out of control again, right? And you still find that what objectives started with, you know, is, is completely not achieved with this process. So in, in many ways, this whole concept of periodic reviews or incremental reviews are, you know, scheduled reviews.
They're, they're kind of ways to do something, but they're not really achieving what, you know, people intend to do, right? Which is making sure that what access somebody should have is aligned with, you know, what somebody has, you know, in the process, right? So how does policy based model, you know, facilitate solving this problem? So let's look at, you know, the, the pain points that I brought about earlier. So the first in most important thing is, like I was telling earlier, there is lot of data out there. Why don't we mine, why don't we bring in processes, algorithms that can mine what is happening with regard to identities and access out there. So that will tell you the state of the union today, Hey, this is what you are doing with users and their access across various systems, right? And you take this patterns and you, you kind of avoid this process of expecting people to come out with this policy.
Instead, what you're doing is I'm going to jumpstart your activity and I'm going to mind these for you and present it for you, right? And then what happens or a period of time is you don't necessarily think of it as a one-time activity. You keep this process as an ongoing thing so that it's completely aligned with what's happening with regard to all the changes today, right? You're not doing this activity of reviewing what people have only during audit cycles, but on a continuous basis, right? So you, you take corrective actions. You, you take those measures. Next is because you are continuously tracking what is happening, you know, the, the volume of requests will drastically, yes, there are one-offs that come into play where, you know, people need something. There are no specific patterns associated with it. The system will not be able to figure it out.
Yes, you will still continue to do some access requests, and it's not that access request is going to go away, but at least you are tying what is given to people through policies. And anything outside of that, you know, is managed in a timely way. The last part is the, the increase of access grants it thinks being given out of, you know, policy, you know, gets reduced. So you are reducing, you know, the access re reviews that happen by focusing on reviewing of the policies themselves, right? Instead of reviewing, you know, hundreds and thousands of entitlements that are granted to people, why don't you review the policies that have been used to grant that access, right? And anything that is outside of that, you know, we call it as in a non-policy based access. What you do is in that situation, you actually review that non-policy access, just like how you do your, you know, typical, you know, entitlement in a reviews, okay?
So the model basically is telling you that most of the activities that you're going to do are centered around policies and not, you know, triggering around individual entitlement grants or access grants given to people. So you spend more time on the policies because by doing that, you, you sort of have an anchor, you have something to refer to. So if you go and look at, hey, why this person got this access, you have a clear representation of this person Got it. Because of that policy. And, and if it's not best of the policy very clearly, you know, it is annotated to say this is outside of the policy and it is given for this particular reason. So you are focusing on, you know, making sure that things are, you know, managed, you know, through the policy. So how does this process actually work in, in, in the real world, right?
So what you do is when you are starting, you go, you take this in a policy, you know, tool, discovery tool, and then you, you know, launch this and you, you run this within an enterprise. There are no policies out there, let's say, and you don't have a good handle on what access, there is access in that, in that organization. You really don't know if there are people who should have, who should have some access, don't have. So both access, access and an under access visibility is not there. And then you run this process and you discover, so essentially get three buckets of results from, you know, running through this, you know, discovery process. One is it'll give you the mind policies that based on, you know, patterns that are represented today. And the second thing it provides also is it identifies this non-policy access, right?
These are things that the system couldn't figure out, you know, where the, you know, pattern is. And it could be a one-off thing, you know, that, you know, we are seeing. And also, once you have the mind policies, you also see that, hey, I see this policy but only, you know, six out of nine people or somebody have it, but other people don't have it. What do you want to do? Cause it looks like this is something that the person would need. They might not need it now, or they have not thought it now, but this is something that, you know, they would need immediately because people with, you know, similar profiles seem to have it. So it gives you a, a good handle on, you know, that, you know, access gaps as well. And the next is what do you do? You know, remember this is a first time activity.
There is some, you know, involvement in terms of the stakeholders to come and make sure that the policies are all coming together. So what we do is we trigger a policy review. So the policies are sent for review, for to application owners, to entitlement owners, you know, group owners, role owners and so on. And for them to take a look at it and say, this is what, you know, the, the landscape looks like. And we provide inferences along with that as well. It's just not throwing in a bunch of data for them to review. We actually produce a lot of meaningful stats to go with it, you know, with, with the review process itself. And then you also trigger a non-policy access re review tool. This is, think of it as your standard, you know, entitlement review that will give you an idea of, you know, looking at things that are sort of out of band.
And also if you discover that something is not there, again, ask people, Hey, is this something that people should be given? So you do those three reviews, so you get a solid baseline in terms of what should happen within the enterprise. So as I said, this is a one-time activity. So what happens subsequently? Yeah, people might ask, Hey, you know what? There is a lot of, you know, burden of review initially, yes, there is this initial activity pertaining to review that needs to happen, but subsequently in a subsequent discovery run, you are actually looking at only incremental changes, right? So the system will come back and say, Hey, I've discovered the same set of policies before. You don't do anything with regard to that. And if there are some deviations, it says, Hey, you know what? The previous policy is not relevant anymore and you know, here is a new policy that's coming.
You just review that. Or sometimes, you know, some policy is not relevant at all, in which case, you know, it, it kind of ceases to exist. So the the actual activity subsequently is only incremental, you know, from that standpoint, right? Unless you know you have more applications coming on board and you know, are the user base changing. So looking at this, let's go back to the illustration again. So what does this mean? How does this self-learning, you know, discovery tool, what does it do for you, right? So yeah, you go through a review process, it kinda aligns what access should be, you know, given to somebody, you know, with, with what they have. And then given that it is a continuous process in making sure, you know, things are in order, we, we tend to make sure that the deviations are handled as in when the deviations occur.
So you can time it trigger it based on, you know, how often you want this discovery process to be done, you know, across those applications. So, so how does one measure if my policy based approach is working well or not? So it's important to figure out, you know, some metrics and you know, see how, you know, those metrics can help you, right? One is around, you know, coverage so higher the coverage is better because most of the entitlements that you want to grant are going to be based off, you know, the, the policies. And subsequently you also can categorize that to say this is something somebody should have. This is something somebody can have. This is something somebody should have, you know, with, with should not have with some exception, right? And then there is the access, access itself, like I was talking about. There shouldn't be any access, you know, any out of policy that you see, you are taking corrective measures as in when you see it.
And also important to measure the time of the life, of the access access as well, right? How quickly you remediate. It's important for estimator. Similarly, you know, we we we sort of look at even the under access itself, you in terms of how you manage, you know, what, what access gaps people have. So the idea is these metrics will continuously provide you the right kind of visibility and also provides you insight into organization's IG processes. So what are the key takeaways, you know, from this, you know, presentation one is you don't have to bring in all your applications into this. Start with your most critical application HR information and your most critical applications and let the discovery tool bring out the inferences, bring out, you know, what's happening around the access, you know, landscape and track these metrics because with each discovery execution, you know, you should see a pattern of things improving coverage, increasing access, access, you know, reducing under access, you know, you know, being provisioned in a timely manner and get everybody involved who is involved in, in, in this, you know, in this process. And lastly, you know, onboard more applications, you know, using the same mechanism. Thank you. Thank
You Sanjay. There are quite some questions in the chat. It works. So this is good. I've stolen two minutes from, from meters from his presentation so that we can cover at least one or two of those. First question is, can standard IGA solutions differentiate access to be certified on access review? So not doing access review on access provided by policy. So can you really protect these policy assigned access from access access revenue mechanisms?
Yes, we can. Yeah. So the whole idea is the, see the process of access governance, you know, is, is become more of a checkbox for people, right? This is, you know, trying to put some structure around that, right? And to say because of the volume of activities, because of volume of data, you know, we are not paying as much attention to things, so this will actually eliminate, you know, that it's, it's a focused, targeted effort and kind of ensuring, you know, the, the real goal, you know, right. People should be given the right access, right? So yeah,
Exactly. Re-certify what needs to be recert. Correct. Exactly. Okay, second question. At least there's one less, maybe you reach out to Sanjay afterwards with the one that has not been covered yet. Can you explain how this will be different than policy-based access management? Is this p feedback for authorizations? Will there be an overlap? How does it play together with zero trust architectures where you have policies and the authentication process? How does it all play together?
I, I think for the most part it compliments, you know, I think there's, it's a fairly big question, you know, it is over there. So it, it compliments what you know is being represented there. It's not, it does not replace necessarily what is, you know, being talked about there, but it fundamentally is trying to put, like I said, the structure in a way that is more palatable for organizations to manage and, and, you know, get, get, get towards the objectives. Yeah.
Okay. Perfect. Thank you very much again, Sanjay. Thank
You. Thank you.