Supercharge Your Access Control Capabilities With a New Approach

Hello everyone. Welcome to today's webinar, Supercharge Your Access Control Capabilities with a New Approach. My name is Nitish Deshpande and I'm a Research Analyst at KuppingerCole Analysts. And today I'm joined by Brian Iverson, Chief Product Officer at Tuebora. In today's webinar, we will take a look at the different types of access controls in the context of IGA. And also look at how we can combine some of these access controls for better compliance and minimizing risks. Before we begin, here are some housekeeping notes. You all are centrally muted.

We are controlling this audio and so you don't need to mute or unmute yourself during the webinar. We are running a few polls during the webinar to keep it more interactive. So I would like to encourage everyone to take part in these polls. And we will discuss the results of these polls during the Q&A session. The Q&A session will take place towards the end of the webinar. But you can enter questions at any time using the C-Event Control Panel. We will do our best to answer as many questions as possible during this Q&A session.

And finally, we are recording this webinar and the recording presentation deck will be made available for download in the coming days. Here's the agenda for today's webinar. We'll start with an overview of all kinds of access controls in terms of IGA. And then we will move on to Brian's part where he will tell us how you can combine the best of policy-based access control and role-based access control to reduce risk and maximize compliance. And finally, the discussion of the poll results in the Q&A session. I want to begin this webinar with the first poll of the webinar.

And it is, how is managing access for identities done in your organization? Is it A, attribute-based access control?

Is it B, role-based access control? Or is it C, policy-based access control? I would again encourage everyone to please take part in this poll. And really looking forward to seeing the results of this poll during the Q&A session. Thank you.

Now, let's begin with the role-based access control. If you're talking about different kinds of access controls, RBAC is in the past. It provides access permissions assigned on predefined roles, different levels of access based on different role hierarchy. It is scalable to meet growing users and roles, but that is also one of its challenges, because if it gets too many roles, it can get complicated. Policies are driven by role definition, so all users with the same role will have the same access rights. And it is suited for organizations with predefined job roles.

But roles are complex, and that is always a disadvantage or challenge, you can say. The role model is a very complex and not a simple concept. And has many challenges, so it's a very cumbersome model. And so that's why we need to first see how a role can be designed. And there are two ways in which we can design a role. And they are first based on the efficiency, versus the next one is based on the risk. If you look at the diagram in the middle of the slide, you can see that this is based on two factors. That is the complexity of the organization and the frequency of the appearance of roles.

The more complex the organization and the higher the frequency of role appearance, it gets risky, but it's worthwhile. So let's first take a look at the efficiency-based approach for designing a role. In this approach, a small number of roles is taken into consideration. Fewer roles means less effort is put into design, and also it means faster implementation of the overall process. It also minimizes the number of residuals and smaller number of contacts to the reduction of reconciliation and validation efforts. But the efficiency-based approach also has its disadvantages.

As we are focusing more on keeping it lean and fewer roles and keeping it a simple design, there is disregard for some complex capabilities such as least privilege and possibly separation of duties. And thus this can often be inadequate from a regulatory and audit point of view. So the next approach is the risk-based approach. This one deals with large number of differentiated roles. And unlike the efficiency-based approach, this one takes into consideration the more complicated capabilities, such as least privilege and the separation of duties.

The effort for maintenance and daily use of a role is also quite lower in this approach. Also, the sense of responsibility among the contact persons is significantly higher. And finally, it enables the mapping of the functional organization structure. But there are some disadvantages for the risk-based approach as well. With the higher degree of differentiation results, it all results in significantly higher overall design and maintenance effort.

Thus, it can be extremely time-consuming for implementation. Also, large number of roles require more functional contact persons. The importance of role design has its own disadvantages and advantages. Frequently occurring business functions with low or medium complexity obviously promise best result-to-effort ratios. Those functions are most commonly found at the lower end of the traditional enterprise pyramid where operational functions are located. This year is clearly a good starting point for role engineering.

The nearer the role is towards the headquarters and the more he moves up towards the corporate hierarchy, the more difficult the tasks become. A portfolio may serve as a good guideline for who is looking at the starting point for role engineering. In terms of RBAC, there is a vertical authorization structure with three different levels. And actually it's four layers if you include the permissions. So it's permissions, entitlements, IT roles, and business roles. What these are and how these combine is a very complex scenario which you see in this slide.

At the bottom, you have the permissions layer which is functions and authorizations within the application if necessary. Several hierarchy levels are also in one application. The next is the interface level which is the entitlements level. This one is one-to-one mirroring of application rights. It focuses on technicality and activity of the roles.

However, there is no enrichment of further information given in this level. But it purely serves as a link between IAM and applications.

Next up, if you go ahead, is the IT roles. It's the mapping of applications and of system-specific functional functions. In this layer, there is enrichment with relevant additional information such as prescription, owner, SOD criteria, and so on. Requestability also depends on the role model. And IT owners usually are in this layer.

Finally, at the top, you have the business owners and the business roles. These are oriented to organizational positions, cross-application functionality, range of services, task area, and corporate function are some of the areas which they focus on. As you can see, it's a very complex model. And having a leaner model is beneficial which can also be used for mover or lever processes.

However, if we use birthright entitlements, then at Krupinger it will be believed. Theoretically, you can assign 80-90% of entitlements using attributes. And in terms of IGA, there are a lot of attributes. That brings us to the next access control, that is attribute-based access control. ABAC can be called as a predecessor of policy-based access control. ABAC kind of merges with policy-based access control and in the end brings you together in IGA where policies allow full permissions. If you look at the ABAC flow diagram, you have three types of attributes.

You have the user attributes, resource attributes, and the environment attributes. And these information relate to the policy decision point which uses the dynamic and contextual awareness from the policy information point to make a decision whether to approve access or reject access. Attribute-based access control is again fine-grained and provides a lot of control over your attributes. It is scalable but again it can become complex with too many attributes being used for evaluation. Thus we need to now move towards policies. So policies are at the core of IGA.

It has been challenging in IGA to handle static entitlements. Static entitlements are root cause of the need for roles and decertifications and for fulfilling the principle of least privilege.

Until now, the process for policy-based access in IGA involved building a role model, onboarding a user, and granting initial entitlements. Policies are at the core of it and they are everywhere and they will be everywhere. They are in identity and access management as well as in other domains such as firewall or even normal day-to-day activities. And policies are defined by four different components. You have the user that is the subject. Then the user requesting access which is the action to a specific application as the object.

And the context which could be something like location from where the user is trying to access or the user's profile. So policies allow for better roles and less recertification. You can derive these roles and recertification from policies. So all you need to do is recertify these policies instead of manually recertifying many roles. Also automatic static entitlements is also available via policies. You can derive static entitlements from policies and then you can just keep on updating them when the policies change. Next is adaptive authentication.

We are already using this for risk and context-based authentication. And you also have dynamic authorization where you enforce policy-based access management with runtime decisions. And then finally it's about enforcing Zero Trust. Policies are at the core of Zero Trust architecture document 800207 if you have seen that one. So policies are the core of the IAM and the foundation of everything we are doing here. And that's why policy-based access control is a critical cybersecurity component of organizations.

It allows centralized policy management, consistency across organization, real-time decision-making, even more fine-grained access control, and ease of integration. This diagram you see here is a traditional authorization model where the user requests access to a policy enforcement point, which is then related to the policy decision point which extracts information from the policy admin point, policy information point to make the decision whether the user can access the resource.

However, there is now a new normal that is the cloud-native policy-based access control architecture. In this one, the user requests access to a resource component. This could be an application, database, physical access. Then there's an API and could be a service mesh type of situation that sends a JSON query to open policy agent. We have a JSON data store and a Rego policy store. Rego code defines the policies we are using. Open policy agent takes the policies and takes the data with policy store and data store, and then decides whether access can be allowed or not.

Thus, policies in the context of IGA can have a lot of advantages. Policy-based provisioning is a critical aspect of the modern IGA platform. Policies are easier to review if the lifecycle management is strong. All the machines need to do is review the policies instead of manually reviewing entitlement for each user. Automation is another advantage you can save from policies. You can assign theoretically 80 to 90 percent of author entitlements and reduce workload using automation. But in reality, what we are seeing is that it's more at the 50 to 60 percent right now in the current scenario.

You can also reduce access reviews as focus is now shifted more towards high-privileged access requests rather than the low-privileged ones which will be automatically automated. And finally, it's about reducing complexity. We want to wrap these policies around leaner roles. But there's also a side to feedback which kind of is necessary. If you have too many conditions, too many policies for the machines to evaluate, it gets more complex. So there is no perfect approach as of right now. So there will always be at least advantage with whichever access control you're trying to go for.

But if you combine any one of the two access control models, then there is possibility of increasing compliance and minimizing the risks. I would like to now ask Brian to join. But before that, his second poll of today's evening is, what is the main reason for implementing or improving access control in your organization?

Is it A, streamlining user access permissions and access management? Is it B, regulatory compliance requirement? Or is it C, improved security? And I'll give you a few seconds to answer this question. Until then, I will ask Brian to join us. Thank you. And my name is Brian Iverson, and I run product for Tubora. I'm grateful for all of you who have decided to join me here on what has turned out to be a rainy morning in the Texas Hill Country.

Today, I'm talking about declarative policy-driven administration. Can I get you to move?

Yes, we did. Okay, good.

Okay, so I think one of the key points here is, and it bubbled to the surface as Ditesh was displaying or was talking, was that we live in two worlds, a world of static authorization and a world of dynamic authorization. So when you're talking about things like ABAC and PBAC, you're really talking about dynamic authorization, where you have some type of a policy agent sitting in the critical path between your users and the applications or the data that they're accessing.

And then you have the world of static authorization, which is really where all the decisions that have been made ahead of time, and we're just sort of recording those decisions and executing on those decisions at runtime. So all the hard decisions are made at admin time, and the easy decisions are made at runtime. And really, I think fundamentally, this is because authorization is about trade-offs. Applications typically require a mix of authorization types, ranging from coarse to fine-grained. So does your organization.

Static authorization, which is typically associated with RBAC, is great for coarse-grained authorization because it's cheap and fast. Dynamic authorization, typically associated with ABAC or PBAC, is best suited for fine-grained authorization because it can be efficient administratively, but it comes at the cost of performance and complexity. This diagram helps illustrate the trade-offs among authorization styles, with the horizontal axis representing the distribution of authorization granularity within an application, and the vertical axis, the relative mix of authorization mechanisms.

Applications with more fine-grained authorization should utilize more dynamic authorization. And if you're designing a new application, it makes sense to introduce dynamic authorization.

However, you must not overdo it. There are trade-offs. Coarse-grained authorization should remain static, while fine-grained authorization can be handled dynamically. Realistically, most authorization mechanisms are chosen for us in the form of commercial software and legacy custom applications. It is hardly feasible for an organization to replace existing authorization models.

So, shifting an application from static to dynamic authorization is rare. IGA exists to help us manage access risk for the long tail of our static authorization legacies. This is what that long tail looks like for most organizations, with applications predominantly relying on static authorization, even where fine-grained authorization may be dominant.

IGA can, and should, reduce the pain of static authorization. That's why it exists. But just because so much static authorization is embedded in your application portfolio for the foreseeable future, it doesn't mean that you're locked into the orthodox RBAC model that far too many imagine. We start with policies in static authorization because that's why we perform authorization. We adjust policies to find the proper balance between risk and efficiency.

Initially, these policies are not precise. They're vague. We need IGA to help make these policies more precise and auditable over time. At its core, static authorization is a tool that can be used to help you manage risk. At its core, static authorization depends on associating accounts with authorization constructs that predominantly take the form of profiles or groups. These differ in terms of directionality. Profiles reference allowed access, while groups reference accounts.

There's a third construct, the role, that combines the characteristics of groups and profiles, providing a means to encapsulate all relevant authorization directives in a single object. This makes roles a lot more flexible, powerful, I guess, yet at the expense of complexity. True roles, however, are not actually that common. Most of the time, we are dealing with groups or profiles and calling them roles, at least within the application space. I tend to prefer to the term permission as shorthand for these authorization constructs.

The first thing we do with IGA when we onboard an IT system is to record in our permission catalog all the accounts and permissions it provides, as well as the relationships among them. IGA tools use roles to represent permissions that we collect due to their flexibility.

Roles, again, we can represent a group or a profile. We don't care much about whether we're dealing with profiles, groups, or roles from an IGA perspective. So what do we need for policy in terms of IGA?

First, we need to answer the question, who has access to what? That's why we faithfully record the observed state of user access in the permission catalog. Fundamentally, we need to distinguish between access that is policy compliant or exceptional. In the absence of policy, all access is exceptional. Our objective is to automate the routine so that our risk management partners, which are frontline business stakeholders, can focus their attention on the exceptional. We want to know which users can have certain access.

We want to know which users could have certain access, and we want to know which users did not have certain access. These are straightforward questions conceptually, but tricky to answer. Being human, we tend to focus more on one of these additional questions than the others.

However, we're in the business of managing access risk, not reducing it. This is an optimization problem.

Clearly, there is risk in users having more access than they need to do their jobs. However, there's also risk in users not having the access they need. When we reduce one side of the risk, we likely increase the other side. The challenge is finding the right balance.

Too often, people involved with IAM forget this. I'm going to briefly talk about the options we have for expressing our policies with IGA.

First, using roles alone. What I visualize here, overly simplified for illustration purposes, is a set of users and permissions organized into three roles. These are the types of roles that might be constructed through role mining across the enterprise, where the roles are determined based on clusters of users that share certain sets of permissions. These can be thought of as middle-out roles. The most common critique of this model is the prospect of role explosion. But that's nothing. I wouldn't worry about that.

These roles merely represent the state of access policies, or even worse, coincidences at a point in time. They aren't anchored well.

Thus, it's difficult to establish ownership and proper governance. Stages such as shifting policies likely require re-engineering.

In fact, periodic role re-engineering, at least annually, is practically guaranteed. These types of roles are low leverage, high volatility, and high ceremony. The worst combination. I think next to role explosion, these problems are much greater. Although similar, this diagram depicts a more top-down approach to role management that is also popular. A key objective here is to avoid role explosion in two ways. Restricting users' role membership to a single role, ideally, or possibly a small handful in some cases.

Then establishing roles, role boundaries, on organizational units, such as departments, reporting hierarchies, or, worst of all, job codes. IAM teams address this artificial role scarcity by piling permissions into multiple roles as needed. At the most ridiculous extreme, a permission that every user is entitled to can be restricted to a single role. IAM teams address this artificial role scarcity by piling permissions into multiple roles as needed. At the most ridiculous extreme, a permission that every user needs would be referenced by every departmental role.

A role hierarchy may be established to seemingly alleviate this problem, but such hierarchies generally make things worse. Governance is improved somewhat here because it is easier to establish ownership, perhaps managers for workgroup-based roles. Although that's a bad idea. The main issue is going to be inflexibility here. You're stuck with a limited role structure that can't adequately express users' actual access needs. These turn out to be low leverage and high ceremony roles as well, almost as bad as middle-out roles.

Come on, move. Okay. Trying to solve a policy problem with roles alone will lead to pain and failure. That's why RBAC has a bad reputation. Unfortunately, when people think about RBAC, they somehow imagine that roles are the only tools available. This is a cartoon version of RBAC. We can and should still use roles as they help bundle together cohesive sets of permissions. But real policies are needed to connect our roles with users. Imagine creating a policy that references users from this or that department or this or that location.

What's more important here is we can do something that is terribly difficult using roles alone, targeting users based on intersections of multiple characteristics. Deploying policies in this way satisfies a tried-and-true authorization principle, to establish policies in proximity with the resource to be protected. We crave stability, not volatility, in our anchors. Resources tend to be stable and offer opportunities for tremendous leverage. If you have a role that should be assigned to everyone, you can express that with a single policy object tied to that role.

We need policies to be precise, executable, auditable, and declarative. All our policy objectives can be expressed with four types of policies. Eligibility policies are foundational, allowing you to identify the users who are eligible to be associated with certain access. Not eligible? You can't have it. No exceptions. Become ineligible? You lose the access. Approval policies operate primarily with access requests, specifying additional resource-specific approvals required for associated access. Attachment and detachment policies work together to handle what might be called birthright access.

Any access can be a birthright for any subset of users as specified by the attachment policy. More importantly, such birthright access can be removed when the attachment policy no longer applies to a given user. For example, say that you decide certain access should be assigned to all users in a certain department. Not only do these users get the access without needing to request it, but the access should be removed automatically, or could be, based on the detachment policy when a user leaves the department. Eligibility policies override all other policies.

Requests for access when the recipient is ineligible cannot be approved. An attachment policy might mandate that a user be assigned access, but if it's not allowed by the eligibility policy, it doesn't happen. This works to simplify attachment and approval policies so they don't need to cover contingencies addressed by the eligibility policy. This makes policies more auditable overall. IGA is often characterized as ERP for security, so let's lean into that analogy.

In finance and accounting, the real world of bank accounts, loans, and other financial instruments is represented by assets and liabilities. Equity is merely the difference between them. For any non-trivial organization, even a family, this financial side of the house can be complex. We can't manage our day-to-day business with the finance side alone because we lack necessary context.

Thus, organizations use accounting abstractions, primarily in the form of income and expenses, to provide that context. Most transactions on the finance side are instigated by corresponding transactions on the accounting side. To allow management to exercise control over the business without worrying about the intricacies of the finance side, goals are set for income and budgets for expenses. This allows organizations to run smoothly and manage their financial risks. IGA should provide organizations with an analogous setup for managing their access risks.

On one side, the IT side, we have representations of the real world of user access, represented by IT systems that provide accounts, resources, and permissions. This can be complex, more complex than is reasonable for most business users. The other side is business-oriented, represented by abstractions such as applications, identities, entitlements, and teams. These are constructed in ways to make them legible to business stakeholders, largely to contextualize or mask the complexity on the IT side.

In both models, the right side represents the observed state of the real world in technical terms, while the left side represents the abstracted business world to better capture, you know, to better capture the intent behind transactions. Thus, for IGA, we make important distinctions between applications on the business side and IT systems on the IT side, identities on the business side and accounts on the IT side, entitlements and teams on the business side, and resources and permissions on the IT side. Another analogy can help.

The permission catalog exists for the IT side, while the entitlement catalog exists for the business side of IGA. If we're talking about a lounge, the permission catalog contains the raw materials from which we construct cocktails, and the entitlement catalog contains the menu items, prices, and recipes. As a customer, I only care about the menu, and I expect that the recipe is known to the bartender so my cocktail can be assembled as expected. It would be inconvenient for me to communicate my desire for a cocktail by specifying everything in the recipe.

Very few customers will know the exact recipe anyway. It's even better that when I walk into the bar or the lounge, the bartender recognizes me and has my drink ready when I sit down. Think about entitlements and teams in the entitlement catalog as serving similar purposes as profiles and groups. Both entitlements and teams are implemented as roles, but we use them differently to fulfill our management and control objectives. Doing so helps keep us sane, honest, and consistent. Understanding the distinctions between entitlements and teams and using them is important.

Understanding the distinctions between entitlements and teams and using them correctly help us avoid making a mess of the entitlement catalog. Entitlements bundle cohesive sets of permissions and are intended to be business-friendly, exposing user access to something like a user's role or objective with respect to an application. Entitlements can be, and usually are, assembled through role mining. To avoid the problems of middle-out and top-down roles, however, entitlements are formed within application boundaries, which makes them easier to govern, requiring less ceremony.

These are the focal points for policy-driven administration. Teams group identities that share a certain characteristic. For example, there might be a set of teams representing departments, another set of teams representing locations, and yet more teams representing other organizational dimensions.

Typically, users will be members of only one team for each dimension. Although teams can be organized as hierarchies within a dimension to represent different levels of granularity. For example, for locations, you might have regional band and then maybe a national band, and then within that, maybe various cities as locations. Just imagine that as a way to help make location more legible to policy. It is certainly possible but not advisable to get by without teams. We could simply reference attribute values and entitlements policies directly. Here's why that would be a bad idea.

First, referencing attribute values makes those policies fragile and less legible. Multiple policies will likely reference the same attribute values, so these references would be scattered across your entitlement catalog. What if the meaning of the attribute value changes? You would need to update multiple policies to address this change. This is fraught with the potential for errors and mistakes and might be a change control nightmare. These problems are addressed if we create abstractions in the form of teams to represent attribute values we wish to reference in entitlement policies.

Yes, the policies for these teams will reference attribute values, but we only need to make each reference once. This reduces volatility in our entitlement catalog. An additional benefit of teams is that they insulate us from discontinuities in attributes we may receive from HR. What if we have multiple HR systems? We can normalize the meaning of different attribute values through teams. We can make up for bad data or lagging data updates by directly assigning identities to teams. The whole point here is, with HR, data is never pristine.

We like to think of that as a problem, but really, it's reality. We should be able to move forward even if data is missing or bad from HR. Fortunately, policy-driven administration is measurable, so we can conceive of it as a metric-driven optimization problem. We want to maximize leverage while minimizing volatility and ceremony. I throw governance to the side here because it's not directly measurable. Leverage means doing more with less effort. We increase leverage by bundling permissions into entitlements and applying attachment policies.

We measure this as the combined impact of compression from bundling and policies. Volatility measures the likelihood of changes to entitlements and teams in response to exogenous events. Proper anchoring and avoiding adhocracy is the best way to minimize volatility, as well as avoiding direct references to attribute values in our policies. Ceremony measures friction when making changes to the entitlement catalog. Various stakeholders, especially permission owners, may be required to approve changes to entitlement structure or policies.

If our entitlements bundle permissions for multiple IT systems, this increases the amount of ceremony to publish changes. We minimize this by properly constructing entitlements within application boundaries. We can also minimize this by requiring less ceremony in general, but a lot of the time, that comes with the cost of the organization.

So, governance can be understood to mean making good decisions about risk. Ultimately, this means putting the right people into positions to make, well, putting people into the right positions to make decisions about access risk. We see three classes of participants in this narrative. We have Mark, team manager, Betty, an application owner, and Dexter, an asset or IT system owner. I'm using here the stock photos that we use for our personas when doing design work.

Anyway, in most organizations, Betty is underutilized, while Mark and Dexter are overutilized. In fact, poor Dexter is asked to do much of what Betty should be doing. And we ask Mark to take on almost all of the responsibility and all risk management responsibilities, despite him not understanding the intricacies of the applications his team members need to use. What is it that Betty should be doing? She should be shaping the application's entitlements so users can request them, and managers can, and so that managers can understand what they are approving and reviewing.

She could be managing policies so that the right people get access when they need it, and that access is removed when users no longer need it. Essentially, Betty should be making the high-stakes decisions that balance access risks to maximize realization of business value for her application. Mark and Dexter are supporting characters, not the lead. Some will claim that Betty does not exist in their organizations. Not only does she exist, but she is likely frustrated with the IAM team. There's a lot of affinity within IAM with IT rather than the business.

She wants her application to successfully deliver value for the organization. This means giving risk-appropriate access to the right users at the right times to achieve business objectives. She does not want to expose the organization to unnecessary risks. That would be a career-limiting move. Modeling entitlements and maintaining policies sounds like it requires technical expertise. Are we sure that we can trust Betty with these tasks? We cannot and should not expect Betty to create entitlements and policies out of thin air. We need analytics and machine learning to help her.

Think about it this way. Once the basics of the application are laid out in terms of the IT systems providing accounts, permissions and resources, role-mining algorithms can suggest clusters of permissions and resources to serve as the basis for entitlements. Betty can then work with Dexter to state these suggestions into entitlements, and she or members of her team can then name them and provide additional descriptive contextual metadata.

Once the entitlements are stabilized and populated with initial endowments of users, policies can be suggested to Betty for eligibility, attachment and detachment. She will evaluate these policies based on their impact rather than syntax, so she can make decisions on the relative merits of the alternatives presented to her.

Finally, she monitors her application over time, continually receiving new suggestions for changes to policies when warranted to improve her application's overall leverage. All the time, what she's doing is she's monitoring really three aspects of her application.

Leverage, volatility and ceremony. And that's providing governance, and while providing governance. There's things like reviews and requests that provide users with access and can revoke access, but you get where I'm going with this.

So, with that, I want to leave you with some recommendations. I'm not going to read them off. I don't like reading from slides.

But, you know, basically, you know, there's sort of a life cycle that goes on here. You know, and the key thing to recognize here is when you're talking about role and policy management, this isn't a one-time event. You don't go through and do a big role design. You're going to move application by application. You have some applications that are already onboarded. You're going to move application by application, trying to improve the entitlements that are provided for those applications, associate policies with them and move on.

This is where the application owners come in as a force multiplier, as well as, of course, AI and ML. AI and ML, I can't believe I just said that. And the idea is that this is a critical part of the onboarding of new applications, right? Onboarding IT systems should be separated from the onboarding of applications.

Because, again, an application is a concept that should be meaningful to your users. IT systems aren't meaningful. They're just the raw materials for entitlements. Okay?

So, thanks a lot. I think we can move on to questions right now. I can hand it back to Nitesh.

Thanks, Brian. You can already see the results of the first poll question, which was, how is managing access for identities done in the organization? And 63% of them have said it's role-based access control.

Brian, what's your take on this result? To be honest, I'm surprised that the numbers for ABAC or PolicyBAC are that high.

But, you know, I mean, part of this is, you know, definitionally, right? I mean, I think that, you know, if you use attributes and policies, you know, you might consider yourself doing ABAC.

But, you know, and honestly, you know, even with how you were describing it, you know, I have a hard time distinguishing between ABAC and PBAC, to be perfectly honest. You know, I think it's, I mean, I'll put my opinion out there. I think it's more of a marketing thing because ABAC really never caught on. And so let's call it policy-based administration and see if that can pick up, you know, sort of like, you know, new label on old bottle of wine.

But, yeah, you know, I mean, roles are with us, right? I mean, they exist. Static authorization is the long tail of the legacy. And so it's with us, you know, within our applications. I think that most applications are using static authorization almost exclusively.

And, you know, to the extent that they're having to do fine-grained authorization, vast majority, 90%, are probably still hard-coding those policies in the business logic of the application rather than externalizing it and allowing those policies to be adapted, you know, using something like, you know, a policy engine, you know, a policy decision point. Right. Perfect. We can maybe take a look at the results of the next poll question, please.

Oh, perfect. There you go.

So it was, what is the main reason for implementing or improving access control in your organization? And 50% have said it's for improving security while the other two options are almost equally split.

So, Brian, do you think this is the right approach that everyone's going for? Yeah, I mean, I guess I, you know, I mean, maybe I'm jaded here, but I see a lot of organizations are probably excessively compliance-driven, audit-driven.

You know, when I, you know, when I encounter, I mean, you know, I mean, I encounter a lot of stupid things that people do and usually, you know, in the realm of identity governance administration, whether it's like reviewing all access or having excessive levels of approval or things like that, you know, you know, things that really don't improve security. Why are they doing it?

Well, because the auditors said so. Well, I'm sorry. Auditors are knuckleheads. Okay. And this is where, you know, I mean, you know, this is where IAM sometimes gets themselves behind the eight ball here is by not taking a, you know, a risk-focused approach to managing user access and being assertive and pointing out how, you know, you're really, you know, you're focused on managing risk and managing both sides of the risk.

You know, you really put yourself in a position where you have to respond to the auditors rather than talking to the auditors in their language, which is risk. And auditors, you know, when it comes to IAM, they don't really understand what's going on. So what they're going to do is rather than critique existing controls, they're going to pile additional controls on, which, you know, really just does nothing but increase costs and provide no benefits.

In fact, it probably provides harm. Now, we have a few poll questions, a few questions from our audience. So I'll just quickly go through those questions and we can discuss about them. So there's one more here.

It says, you talked about role-based access control but then seemed to avoid the use of the word role in your examples. Can you explain why?

Well, I mentioned it once, that RBAC has a bad reputation. People hate RBAC. People think that RBAC has failed. I will hear from people saying that, you know, we were thinking of doing RBAC, but we heard that ABAC is the next hot thing or PBAC is the next hot thing. So we think we're going to skip RBAC and move on. And honestly, you know, when I think about roles, and RBAC, you know, honestly, the cartoon version, I mentioned a cartoon version of RBAC, you know, it deserves its bad name.

I mean, if all you're going to do, because ultimately we're in the business of, you know, when an auditor says, do this or do that, or, you know, auditor is yelling at you, it's sort of like a baby, right? You know, they can't tell you exactly what's wrong or exactly what they want. So they're just going to yell and they're just going to pile on controls.

You know, and what they're really saying to you, though, is your policies suck. And so what we're, you know, you know, what everything that we're doing is about policies. It's not an alternative.

And, but roles are important as vehicles I prefer to use the term entitlements because ultimately what you want to turn, what you want to create within your IGA tool is the currency with which you move access around, with which, you know, you add access and remove access from users. And so, you know, I don't like to use the word role partly because I'm from Minnesota. And so when I say the word role and rule, people get confused.

And so, you know, and so, you know, entitlement is, it doesn't exactly roll off the tongue, but you know what? People understand what I mean when I'm talking about that.

And then, you know, I can use the word rule or policy interchangeably and hopefully people don't get too confused. Got it. Okay. There's one more question.

It says, what role does behavioral analytics play in all of this? Oh, okay.

So, behavior. So, you know, within the behavioral, well, first off, okay. It can play an important role in helping you to form, you know, in constructing your entitlements and, you know, deciding what permissions to put in an entitlement. The issue that you face often though, honestly, is the data that you have available for behavioral analytics is extremely coarse grained. It is extremely rare for you to find, to get data from an application down to the permission level.

You know, whether it's, you know, whether a group's being referenced in an access control decision, you know, those types of things. I mean, you know, you can get that from SAP pretty well. And if you look at SOD controls monitoring, they put that information to great use in helping you to address SOD conflicts with, you know, in some cases without really having to change, you know, business structure or, you know, or upset the, you know, existing business processes. That's great. But if all the data you have is like whether the account was used or not, there's not a lot of value there.

You know, and unfortunately, I've seen some organizations try to go all in on, you know, the use of this behavioral data almost as a policy input itself to the extent where, you know, I mean, you know, like, you know, over the last five, 10 years, use it or lose it has taken, you know, has torn through financial services, right? And so, you know, we have this idea that, you know, we're going to revoke access if you haven't used it, right?

And, you know, even going so far as, you know, banks spending tons of money, ridiculous amounts of money to force their applications to report usage information, you know, about whether users are logging in or not to the application. And then applying these policies, you know, ridiculously to the point where, you know, they make the lives of their users absolutely miserable for what is a negligible at best and probably harmful risk, you know, risk management approach.

So, yeah, I mean, you know, I mean, it can play some role as you're looking at, you know, whether to include a permission in, well, do the users actually use this permission? Maybe we shouldn't include this permission in the role even though, or in the entitlement. I'm sorry I said that after the previous question.

You know, maybe we shouldn't include this permission in the entitlement because the users haven't been using it. Maybe we haven't cleaned up access or whatever.

But, you know, honestly, day to day, over time, if a user hasn't used access, I don't view that as a risk, or at least not a risk that's worthy of giving up some of the benefits that you get from bundling. And the efficiency and the policy clarity that you get from that.

So, you know, I tend to think that behavioral analytics can sometimes be more, you know, be a slippery slope unless, you know, and I said this up front, unless you can actually get the good stuff, right? Which is the actual usage of permissions within applications.

Thanks, Brian. There's one question. You mentioned that correct data from HR was not that important. Why? Without the I, there would be no IGA.

So, can you elaborate on this question? Well, okay.

HR is, the relationship between HR and I, and this is something I've, this is a hard lesson I've learned over the years, right? It's more of a frenemy type of relationship, right?

That, you know, HR likes to put a lot of restrictions around the access to their data, you know, for various reasons. Part of it is I think that they, you know, they think that their data is so pristine that they don't want anyone to mess it up. The reality is when you start to dig into it, that data is pretty darn bad.

And so, you know, in reality, I think that IGA over time actually knows more about the people in the organization than HR does. And, you know, I mean, HR is an important source of events and it's an important partner, right? But you can't trust it entirely.

And so, therefore, you know, a good IAM leader is actually a scout for where the data really is about people. I mean, you know, it's still uncommon for HR to cover, you know, contingent employees. And those are becoming a bigger part of the workforce. IAM ends up taking on a lot more responsibility.

So, you know, I mean, the way I look at it is this. And I hear this from a lot of IAM leaders is, well, our data from HR is bad. So we're going to focus, you know, so what we need, you know, before we can do anything useful, we need to force HR to fix their data.

Listen, bad data is part of the bargain you get with HR. You need to work on, you know, you need to figure out ways to work around that bad data.

In fact, you need to be, you know, you can't just blindly trust the data that you get from HR. You need to be actively monitoring it and making sure that it, you know, and monitor the integrity of that data.

You know, trust but verify, so to speak. And yeah, you could provide feedback. It might get fixed. It might not get fixed from HR. If you look at IAM leaders as having a limited amount of political capital within an organization, listen, I'm not going to spend my political capital trying to fix HR. I'm going to spend my political capital making IAM help the organization manage its access risk. And so that's why I say that is, you know, I see too many people just sort of, you know, pick up their toys and go home when they find out the HR data is bad.

And I think that's just a dereliction of duty from an IAM perspective. Thanks, Brian. Hopefully that answers the question.

Next is, it says, I think I understand what you mean about roles being better than attributes, but it seems like a lot of extrovert. Could you please elaborate?

Oh, yeah, sure. Okay. Attributes, so again, attributes are, you know, and in this concept, I'm really talking about teams. I probably should have labeled that slide a little bit different in teams, right? It's not a lot of extra work, though, you know, when you think about it, right?

I mean, you know, like something like, you know, you have a department attribute, right? Well, or, you know, like our cost center, right? All of those values mean something. They have a name associated with them or something like that. There's a way to make them more legible by creating teams for them.

And so, and you map that. And then, from a policy perspective, right, instead of referencing this attribute value, like 000100039 or something like that, right?

Which, I mean, you know, if you want to make sense of it, you have to have like a translation table available to you or something like that, right? Instead, what you do is you reference that team instead. It also gives you flexibility because now I can temporarily add someone to that team if I want them to be, you know, if I want the access they have to be as if they were part of that team. We can leverage the policies that we have at the entitlement level to do their magic from an attachment policy and then eventually a detachment policy.

You know, it basically gives us another level of indirection. You know, it makes the organization, I mean, again, this is about declarative, you know, what I tend to call declarative identity governance administration is that, you know, we want the tool to behave in the way that we think that the business operates, right?

You know, we want it to react to business changes rather than, you know, have this idea of where we have these events that trigger workflows and all that type of stuff like that. You know, anytime you find yourself overly thinking about workflow and this and that, you know, you're getting into imperative identity governance and administration territory, which is, you know, I mean, it works.

Yeah, but it's really difficult. So, you know, plus the other side of that is trying to maintain these policies, right?

You know, I'd rather refer to the finance department and know that if the attribute ever changes, the attribute that means finance department ever changes, I can still refer to that in my policy rather than having, you know, like, you know, a hundred different references to department 0010939 or whatever I said before and then having to do search and replace through all my policies when that attribute value changes and they do change. And then, but also I, you know, I'm not going to, you know, again, I mentioned earlier, right? That's a change management nightmare.

But also, you know, you have people who, you know, when you're using the raw attribute values, you have people who do evil things in their policies like regular expressions, you know, to pick off part of the attribute value so they can select multiple values without having to, you know, put together a bunch of strings. So it really makes your policies more reliable. Perfect. We just have one minute left. So this will be our last question. What differentiates your solution versus other IGA solutions? We have just one minute left, so it can be quick.

Well, I would say that, I'll just use the words declarative and imperative. I think that in many cases, Identity Governance Administration, you know, has been built and so, you know, there's this excessive workflow focus.

Workflow, workflow, workflow. When in reality, what we want is a more declarative approach, and that's policies. We want to be able to understand what our policies are rather than having to look at the behavior of a workflow. So what do we want to happen? And we want to describe that rather than describing how something happens. Perfect. Thank you so much, Brian, for your time. This was a really nice insight into this webinar. And thank you, everyone, who joined this webinar. You can download the slide deck and the recording in the coming days once you make it available. Thank you.