Podcast 81 | RBAC With Jim and Jeff

You’re listening to the Identity at the Center podcast. This is a show that talks about identity and access management, and making sure you know who has access to what. Let’s get started.

Welcome to the Identity at the Center podcast. I’m Jeff and that’s Jim. What are we going to talk about today?

I’d like to talk role-based access control and all things associated. What do you think of that?

I think of that as a gigantic can of worms, and, I think we should do it, because roles are something that we hear a lot from our clients as something that they want to get into, and it can be a little bit confusing, sometimes, because there are a lot of different competing directions that things want to go in from a role perspective. You’ve got role-based access control. You’ve got attribute-based access control. You’ve got policy-based access control. There are a lot of acronyms, and we’re going to get into that today. What we want to start off with is, this is our thoughts on how you get started to eat this elephant one bite at a time, because it tends to be a rather large project for a lot of organizations, and a lot of times, you are starting from not the best from a data-quality perspective, and you may have to have a lot of push and pull to get things uphill.

What complicates the topic most for me is that there’s not an industry-standard definition. If you ask somebody who’s an IAM practitioner, “What does multifactor authentication mean?” you get the same answer every time. When you ask somebody what a role is, you get a different answer every time, and that’s because of a couple of things: From an organization standpoint, we talk about roles differently. Even, within an organization, you might have application teams talking about roles within their applications, and then you talk to the IAM team or the Active Directory team, and they’re talking about roles at totally different level. Then, from an authentication side of the house versus an identity management side of the house, whether you’re using roles to drive provisioning to apps or you’re interpreting those roles at the time of authentication to confer access. We had an episode, one of our original episodes, back when we used to do a lot of Jeff-and-Jim episodes, where we talk about some of the most confusing terms in identity access management and roles.

That highly liberal use of the word roles can certainly complicate the way that things get defined, so we’re going to dive into it here. It’s important, before we get too far along here — what we’re going to talk about is role-based access control, or RBAC. We’re really focusing on the provisioning side of things, not necessarily the authentication side of things, because, like you said, there are sometimes some definitions of roles being assigned at the occasional level. What we’re really talking about is provisioning and more authorization, so why don’t we dive right into it, and why don’t we start with, “What is a role, Jim?”

If we were to give it a dictionary definition, it’s the collection of one or more entitlements, or groups, bundled together and assigned to one or more people in order to confer access to a system. There are a couple of elements there. One is that it’s a grouping of access rights, and it’s assigned to people, or it could be to nonhuman accounts. So, maybe people isn’t the right term as identity, but it confers access. The point of putting a role together is to bundle access. When we talk about even frameworks, we look at, it has an access pattern — yes or no. That’s an important piece. If there’s not an access pattern around a role, then there’s not much sense in developing a role.

One of the ways I have heard it described in the past that I like is — it really oversimplifies it, but it’s OK for this conversation - think of roles as a bundle of sticks. Each stick has its own unique properties, and you might pick up and have different bundles of sticks, and you might have just one stick in your bundle. Each of those things could, essentially, be entitlement, and that bundle ends up becoming what we would refer to commonly as a role.

Now that we have set the stage of what is a role, why would someone want to go down this hellscape, which it can sometimes be, of setting up access roles for their organization?

When I think about roles, I generally think of the framework that there are two types of roles. We’re going to use some terms, and some of these terms are used, or not used, by different vendors or organizations, but the two main ones, for me, are birthright roles and requestable roles. When you think about birthright roles, the idea is that you can automatically assign access to a person based on something about them, some attribute about that person or an employee: they work for a certain department, or they work in a certain location. Usually, just to go and to be an attribute that is stored on their profile, whether that’s in the HR system or something that’s maintained outside the HR system but is data-driven — that they are of this classification, and because of that, they should have this access, and that whole process can be automated.

However, requestable roles are something that we don’t have that driver of some attribute that’s going to say whether the person should have access, as, ultimately, that bundle of sticks that we want to make available — it’s for convenience’s sake. So, having that bundle of sticks now somebody, ideally, in the business is going to have to either request or approve or both that access for a person or for, like we said, a nonperson identity.

The more you try to genericize these definitions, the more it just sounds like a bunch of words. I’m going to just stick to more of the simple definition, but if you have a requestable role and that bundle of sticks that you’re going to give to a person, you’re doing it in a way that the business can understand what that bundle is. Are you either going to tie it back to some job function or, maybe, to a job overall?

Let’s stick with the bundle-of-sticks concept here: If you’re walking around in whatever village, and when you’re born, you’re given a bundle of sticks. That’s just what you get. That’s a birthright role. It could be whatever that bundle of sticks might look like, and then you go to the shop inside your village, and you see a bunch of different bundles of sticks sitting behind the counter, and you say to the shopkeeper, “Hey, I want that bundle of sticks.” That would be more of the requestable role. That may be, again, too simple, but I like it, at least, for the purpose of this conversation.

It’s important to mention the business, like you just did, because it’s very difficult to do roles, and it’s compounded if you do not have the business involvement as part of the definition of what those roles look like, who can have them, who is going to approve them, how do you make things that are appropriate for the business to understand, because it’s the business’s data and it’s the business’s roles. IT and, by extension, the identity and access management team or technologies that are associated with that team are there to support the business, and to help them make more informed decisions.

It’s important to understand that this is not an easy task. It is something that a lot of organizations struggle with. They are usually yearlong or multiyear projects, depending on how complex the access matrix might look like within an organization. That’s something to certainly consider as part of this. It’s not easy, and that’s OK. We mentioned it’s an elephant. You’ve got to start eating that elephant one bite a time, and these are some ideas on how we want to get started on that.

Contrast what we just talked about with the organization that doesn’t have roles, and they really struggle to get identity and access management into a good place where the business can make informed decisions about who should have access to what. They’re looking at a list of groups or entitlements that are not put in plain English and not tied back to business functions, for example. It’s hard for them to decide who should get the access, and then, part of doing role management effectively is reviewing roles, reviewing the access that people have on a periodic basis.

If you’re reviewing it, and you don’t understand, you’re probably not going to start removing access if you don’t understand what it actually is, and since your employee does not have the access that they need to perform their job, what ends up happening is that people rubber-stamp during the access requests and reviews. That’s the place that roles can be very valuable — especially if roles have been done right, where you name them in a way that makes sense, you write descriptions. Descriptions should tie back to what access this role confers, and you have owners of those roles so they can do role reviews effectively.

We’ve talked a little bit about RBAC, or role-base access control. What does that mean?

When we’re talking about RBAC, it’s the overall process of role management and how roles drive the access that people get. It’s looking at it from a 360-degree perspective, from how you get the roles to how those roles help drive access to how people interact with those roles. Again, like we’ve been talking about it, we touched on a lot of the different aspects of what makes a good role, and it’s something that the business can understand. They can assign to people, and then, those roles, become the basis for the assignment of who gets access to what. What would you add to that?

You pretty much covered everything. If we go back to the bundle of sticks, role-based access control is, how do you create that bundle of sticks? Which sticks are going to go into the bundle, and does that bundle make sense? Do the owners of those individual sticks agree to become part of that bundle? This is an area that does take some finesse. This is not necessarily a technology problem. This is more of a business process and trying to make sure that you convert the Active Directory group that is labeled IT-PRD-APP004 translates into something that actually makes sense: “Oh, right — that is the server or the application that controls the cafeteria menu.” Being able to make that translation, and put that in front of people to have them make those informed decisions, is where role-based access control and the frameworks that go around it make the most sense. I know we’ve also talked about ABAC, or attribute-based access control. How is that different from role-based access control?

One of the things we said earlier on is, we’re going to focus on the provisioning side. So, when we’re talking about ABAC and provisioning, we’re talking a lot about that birthright automation of access accounts. Where I see organizations using it is more on the authentication side. In other words, applications are being given. Rather than “Here is the access the person has,” they’re given profile information about a person with lot of attributes, and the applications can then interpret those attributes however they see fit. In other words, the decision point is at the application in terms of what access those attributes confer. So, very much like policy-driven — again, on the provisioning side of the house is the interpretation of these attributes for automating the provisioning of access.

Yes. I think you hit it right there. Sometimes, ABAC is also known as PBAC, or policy-based access control. It’s more of a run-time or real-time assignment of access. What’s interesting, to me, is that it layers on top, potentially, of a role-based access control. If you’re driving data into the application — say, “Here is Jeff, and he is in Chicago” — that attribute of me being in Chicago may actually map back to a role within the application, but it’s not being granted to me ahead of time because the application is determining in more real time, based on the authentication and the authorization streams, what I should have access to versus something that I have always had access to, which might be that role that sits behind it.

I think what’s similar in both concepts is that you have centralized management of that data, which is going to ultimately drive the access. In role-based, you’re determining what data drives people to be in what roles, and then you’re telling the applications to put people in these roles versus you’re just handing the data to the application. The application is deciding what access that person should have based on those roles. But in both cases, you’re centralizing that authorization data. There’s a scenario, also, where applications are completely doing their own authorization management, approved management, role management — whatever you want to call it or they call it.

That’s usually a very early maturity step. That’s where you have a lot of applications that have grown up on their own, and maybe you’ve done a level-one integration where you’re doing single sign-on between the applications, but you haven’t really started to pull the authorization out of the apps and manage it — at least manage the data centrally. That’s step two, or phase two, in centralizing your applications — that centralized management with authorization.

Jeff, if I could, one thing I wanted to do earlier was my little rant. My rant goes back to when we talked about what RBAC is. How do you get that bundle of sticks? The two methodologies that have gotten the most thought are around role mining — starting with the data and building roles that way, and role engineering: the top-down approach. In other words, the business is saying, “We need a role that does x, y and z” and then building a role around that.

My rant — I’ll put it in black-and-white terms — is, I think role mining doesn’t provide a lot of value, at least, when I’ve seen it. And I’m sure this would get a lot of heat if we had a forum where people would just say, “You’re stupid — we’ve gotten so much value out of it,” but when I’ve seen examples of role mining working, it’s taking that data that you have about users and entitlements and saying, “It looks like you’ve got an access pattern here that 80% of the people in this department have. Why not give that access to 100% of people?”

My thinking is, because we don’t want to give people access that they don’t need, if 20% of people don’t have that role — they’re not banging on our door, saying, “We need that role”— why would you create that role and give that access to this 20% of the people? What are your thoughts on that? Principle of least privilege — every time we go into an organization, it seems like, let’s say, 90% of the time, they’ve got a principle of least privilege baked into their policies and standards around information security. I don’t see why you would want to give anyone access that they don’t need.

Let’s take a couple of parts here. I want to get into this, because that was literally my next question: RBAC and that concept of least privilege — they are competing concepts. When we’re talking with folks, and having this kind of conversations, it’s “We want to be more role-based — and, oh, by the way, we have this policy that says, ‘We’re least privileged.’” OK. Well, which is it? If you’re assigning roles that have accesses to things that people don’t need, then you’re violating the concept of least privilege. That’s usually a thinking moment when we’re talking to customers and thinking, “How is this actually going to work?”

This goes back to the whole role-mining and role-engineering exercise as well, because I do see some value in the role mining, and I see the value of the role engineering, and I think that they’re most effective when they’re done together. If you’re trying to do one or the other, it’s a lot more difficult to see the true value, because the way I see it is, role mining is basically digging deep into these applications or systems, trying to figure out what are all the different access rights that could be in place for that application and then, basically, just coming up with an inventory.

So, the mining is, you’re going out into this mine and down into the shaft, and you’re trying to find the different nuggets of gold ore, and those gold ores might be the different entitlements within the application. It’s great that you found them, but what do you do about it? I think that’s where role engineering comes in: “Now that you know what those nuggets are, what are we going to do about it? Do we take this gold and refine it down to this purpose, or do we leave this as a raw material for some other purpose?”

I see the role mining more as a recon effort — let’s figure out what’s out there — which is good. You want to know, because if you’re trying to protect an application, and you don’t protect the rights that allow added access to a database table, and things go haywire, that’s not going to be good either. You have to know both, and then the engineering comes from working with the business and saying, “Let’s talk about whether we’re going to give access to people” and then, “How does that work with least privilege and the concept of roles?” because there certainly are a lot of risk-based decisions that can be made around — let’s take the cafeteria menu, for example: Do we really care if everyone has access to that? Maybe it was not granted to certain people, maybe it was a mistake or maybe it’s a new app that just didn’t get back-filled to the people who were here before the app — probably not. The risk is low. Do we really care if we’re having chicken on Friday, or ribs or whatever it may be? That’s OK, but if there are more sensitive accesses, then, yes, you probably do care, and maybe the role that you thought would be good for an entire team or department needs to be split up because you want to keep with that concept of least privilege.

I think there’s value in the role engineering and the mining, and the mining isn’t just finding the application or the entitlements. It can also be “What do the people have?” And I see that as an intelligence report that comes back to, eventually, someone in the engineering side of things, whether it’s the role owner, the role developer — whatever it might be, whatever person is handling that — to say, “Oh, OK, yes. Jim and Jeff both have this access, but Jim has this other access, but Jeff doesn’t.” Is that appropriate? Maybe it is, maybe it isn’t.

Whatever the differences are comes down to risk. If it’s because Jim knows that we’re having chicken on Friday, and Jeff walks into the cafeteria — back in the day when we could actually go into buildings — and is surprised when the menu comes up, maybe that’s the risk we’re willing to accept, or maybe I’m just really a picky eater, and I need to have the menu in front of me before I’m going to waste my time walking in the cafeteria just to find out we’re having the same old thing. That’s how I look at it between the two.

I think, if we take a really philosophical approach, it’s probably not the right approach. Get value out of doing data mining — and we used the cafeteria-menu example because nobody cares. Everybody has access to the cafeteria menu — no one should care, anyway. But it made me think of a few things. One was, I saw a really good presentation. I don’t even remember who to attribute it to, but it got into access management fatigue — managers getting so many requests for access that eventually, they started rubber-stamping because they didn’t have time to think about it.

We’re all busy during the day. We’re doing our job, and then you layer on all of this red tape, but if you boil that down to “Only send the question to the approver when it’s something that is worthy of an actual review,” then you can get to the point where you have deep thought put into it. You never ask about the cafeteria menu, but you always ask about access to SAP or whatever the financial system is, then you have to decide everything in between, whether that requires somebody to review that approval.

Another thought I’ve run into over time is with least privilege, applying that to privilege-access managers. It’s the same concept around assigning what is the risk to the access. In that scenario, where roles can be very valuable, because if you have — philosophically speaking, anyway — you should have fewer roles than you have entitlements. The idea should be, you’re bundling those sticks, and you’re not creating more bundles of sticks than there were sticks. If you can get to that smaller number, it becomes an exercise that is more feasible in terms of assigning a risk value, something that can be used to determine what the appropriate controls are around that access.

You touched on the design there a little bit around “What do these bundles look like?” How does someone get started designing roles, or going down the RBAC or ABAC path for their organization?

It’s probably like a lot of IAM things, and you have to look at trying to get your low-hanging fruit first. So, I always think about what RBAC is. We started talking about RBAC with people. I tend to think people think it’s all or nothing: You’re either doing everything through RBAC, or you’re doing nothing through RBAC. When you see organizations that are on the RBAC path, they usually are never on the finish line. They’re doing a lot of things with RBAC, and where I think organizations should get the most value is the things that they can automate: that birthright access, getting someone started on day one so that they have whatever it is — 80% of the access they need in order to do their job.

Then, beyond that, now you have to start getting into the tougher stuff, building those roles that are around functional teams, or functional jobs, within the organization and tying off the access. It really requires somebody with expertise on what is the access that you need in order to make that successful, and so you need to pull in people from the business. And where IAM teams and IT teams should spend their time is with the business units that really want to set the table, and invest the time to do this. In other words, if somebody is going to play along, you’re going to get a lot further than if they feel like you’re dragging them into it and you’re making them do something that they don’t want to do.

When those other groups that are not participating see the success that’s being bred by the teams that are participating, they’ll want to participate as well. That’s the approach: Think big, but know that you have to start small, and where you start is with the low-hanging fruit, stuff you can automate from. And then, when it gets into the tougher stuff, first, work with the teams that really see the value and are willing to invest their time into making this successful.

Yes. I like the concept of starting big and starting micro. I know — it’s macro-micro, so when I say that, what I mean is, “Let’s figure it out. Are you an employee?” It’s a basic decision. Maybe you’re an employee, maybe you’re a contractor, maybe you’re a vendor or an intern. Whatever you may be, start with those giant roles that you can answer relatively easily, and try to figure out if there are things that are in common that all employees get. Maybe it’s VPN access — great. Now, you’ve got something you can add to that. Maybe it is the cafeteria schedule, maybe it’s a company intranet site or something like that. You start with this very broad role, and that’s OK, because you’ve got to start somewhere.

Then, I like to start by dogfooding roles with my own team. What I mean by that is designing roles for my own organization and seeing what works, what doesn’t work, so that I can really refine the process before I go to the next area — another business unit, another team, etc. I would certainly start with teams that are friendly to this process. It’s a lot easier with a willing partner, that’s for sure, and knowing that you’re there to try to help it and that there are going to be pain points: Let’s figure it out together.

But the idea is to, at some point, roll this out to the rest of the organization, and being able to design those roles, and figure it out from a micro-micro type of way. I like that approach, because you don’t push off the value that you might be getting by trying to design a whole bunch of roles at the department level. You can get value out of “Are they an employee or a contractor?” That could be enough to make a difference. If they can say all employees, when they onboard, get an Active Directory account with these two AD groups and this Office 365 or Microsoft 365 license, that might be a good enough win to solve a couple of pain points from an onboarding perspective.

It shows that you have some capability to get this done. You start to build confidence in the organization: The money and the time that’s being invested into this is working. I think that is a big part of it, and then you make a circle bigger from there, or you make the circle smaller from there, depending on which angle you’re approaching from. You can do both at the same time with the proper management of how you’d like that to work.

I like your concept around dog food. I think that works really well within the IAM group or some small, contained group. I would say that IT, generally, is one of the hardest departments to pick on in terms of designing roles for system administrators, database administrators. That’s where it becomes almost impossible. You might feel like you’re swimming upstream if you start with IT. Other departments can be more stable — HR, finance, things like that — because those roles generally tend to not change as much over time as someone in IT.

Yes. That’s an excellent point. IT is probably the hardest. If you start with something simple, you’re, again, showing the value sooner rather than trying to tackle the really hard stuff. Get the 80% that will get value out of the stuff that you do know, and then either punt, or figure out later down the road how you’re going to handle the rest. It’s OK to not have a role for every single thing that’s out there. The realistic way to approach this is different teams, different organizations, different business units and different geographies. Those will all play into whether a RBAC model makes sense.

You may have a more mature role-based access control for certain teams and a less mature in other areas. Use the concept we’ve talked about. Maybe IT only has an employee role, whereas finance has an employee role and a finance role and an accounts receivable role — something like that. I think that’s OK. You just have to be able to manage it effectively and know when and where to pick your battles.

One other thought I was having as we’re talking about something like finance and we think about ERP systems, a lot of times, they already have the complex role structure within the ERP system, and so, as an IAM practitioner, when you’re looking to do enterprise RBAC, you have to set where your scope is. It is a dangerous place to volunteer that you’re going to go into the application to solve the role needs within the app. You have to start with an expectation that the app has good enough application-level roles. That’s an important point.

Finance is a really good place to start, because that’s where you’re also going to find a lot of segregation-of-duties-type issues, and the IGA platforms that can really — identity governance and administration platforms that can tend to help build RBAC models and manage RBAC — they do a pretty good job, generally speaking, in terms of identifying segregation of duties and then baking those into the access request and access review process. You get a double benefit if you focus on that area and you’re able to roll in SAP as part of role management.

I’m glad you mentioned segregation of duties, because that’s something that we definitely see a lot, especially in ERP, in finance apps and things like that. That’s usually where we see relatively decent, if not good, controls around what the roles do, because there is some more judicious thinking around who should have access to what in the financial systems, those sorts of things.

Where we see a lot of organizations fall down is cross-application SoDs. They may be really good at managing SAP and having the appropriate checks and balances there, but where the challenge comes in is, if you have across different applications, not only are you an administrator in SAP, maybe you’re also an administrator on this other application that is outside the purview of finance that makes a toxic combination — introduces more risk to a certain process, and things like that. This is also an area where there is the potential to leverage roles and the different access controls. Once you’re aware of them to say, “We have more visibility now of what people have access to, and what they can do not only within the system but across systems,” does that make sense? Do we want to keep that going, or do we need to think about a control to address that?

When we have these conversations, one other thing that everyone who is listening needs to keep in mind is that we try to make this generic advice, or a generic topic that we’re talking about. But especially, when it comes to role management and segregation of duties within the ERP system, it’s going to be a lot different for a 500-person organization versus a 50,000-person organization, and you have to take the advice and then feed it in as one data point. But I’m sure either way, our fellow IAM practitioners out there become expert at doing it within their organization, and they are able to take these data points.

It’s something where we are talking here around guiding principles and how do we move forward with this? It is very hard to do. I said it before. These are, generally, at least a year-, multiyear-long projects to do the mining — find the entitlement — and then figure out what they do. Do they make sense? How are we going to construct those bundles of sticks? Those sorts of things. It is difficult, and it is something that can be done, but don’t get too lost in the weeds — especially as you start to address some of the macro-type of role situations. Maybe, we should talk a little bit about some of the guiding principles for role management that we’ve talked about around here in this conversation, but also some more things we haven’t mentioned yet. Maybe we can start with, what makes a good role versus not a good role?

One of the things there is, a good role is going to be used a lot. The business is going to understand what it does, and it’s going to apply to more than one person. It’s going to confer more than one small piece of access. The more it’s used — the more people it applies to — the better the role is. What are some of your thoughts there?

I like to keep it simple. Don’t create roles unless you need them. It’s the same thing as “Don’t create an Active Directory group if you don’t need it.” Don’t create any type of entitlement. You’re just creating more work for no reason. Take a look at the way things are constructed, and figure out if you actually need to spend the time doing it. And if one person has this access, and they use it so infrequently, maybe it does make sense to leave out a role and make it more on-demand or requestable or however you like to work through that. I think that makes sense.

Right.

What about a framework? We’ve talked a little bit about birthright and requestable roles, and I feel like that’s a pretty good framework to start with when it comes to getting started with “How do you want to figure out which bundles of sticks you want to create and how they’re going to be constructed?” Maybe we can talk a little bit about that.

A framework means a way of thinking about a problem, and something that’s reusable and solvable. To me, it’s setting yourself up with a series of questions that you can ask about a workflow, almost, of questions you would ask yourself in terms of building a role: Is it a good birthright role? That’s what you would want, ideally, because you want to automate access where possible. If not, can it make a good requestable role, and, if not, does it even make sense to have as a role?

The kinds of questions you can ask yourself are “Can I define the user type?” If we’re using the example of interns, yes, I can. Interns are a distinct group of people. Does an authentication, or authoritative source, exist for that user type? So, in our HR system, we have intern as a designation. If we do, we could simply go down the path of having a birthright role. If it’s not in the authoritative source, like the Workday system or the HR system, then it would have to be a requestable role. There’s no way to automate the idea that somebody is in that grouping.

Another question would be trying to define an entirely different pattern or access pattern. In other words, do interns actually have to access the same types of data across the entire intern population, or is there some subset of data within the organization that they do all need access to, and then, is the membership volatile?

The example I’m going to give here is, I worked with an organization that would change their call centers very frequently. So, even though it seemed like, at one point, a call center could be used if it was coming from an authoritative source, it did define some access patterns, because if you’re in certain call centers, it meant that you needed access to certain things. However, it was volatile. It changed so often for people as they did these reorganizations that it did not make a good role. The intern type is usually not volatile, yes, they’re interns, and then they can move onto something else or leave the organization, but they’re not switching different types of interns all the time. If they are, then it would potentially disqualify it as a potential birthright role. That, to me, is what the framework is all about: being able to walk yourself through a questionnaire, and being able to determine whether you’re creating a birthright role or a requestable role, or the population doesn’t make for a pretty good role.

I think you touched on a couple of important things there, especially around data quality and coming from HR and other authoritative sources like Workday, SAP, Oracle, etc.: a lot of these access decisions are going to be driven by the quality and the timeliness of the data in those systems. That’s something that you also want to take into consideration when you’re talking about how these roles are going to be constructed, and then, where is the data going to come from, and when?

If someone gets loaded into Workday the day of their hire, that might not be a good spot to drive automation from a birthright role perspective, too. Things end up being more of a requestable role, because you don’t have the data in the time that you need it to be most effective. That’s something to also consider if we’re talking about automation. This is something that you grow into. You don’t want to automate all the things all the time. You probably want to pick where you get the biggest bang, and where you feel the most comfortable and safe from a maturity standpoint to be able to assign access in an automated fashion. You don’t want to create a role that has the wrong access in it, and then you just give it to everybody and put your organization at risk.

Yes. There’s something else there with the automation pieces. Typically, organizations are getting that data from an HR system. Those HR processes get bound to your processes for assigning access, so there is some governance required there. That also comes down to how stable that data is — if it’s being changed, if you’re trying to drive access off of the department code or job code — and if those job codes wind up changing every couple of years, you could create havoc.

This is where the tight integration between HR and IAM hits the most, because it’s OK to make those changes. What’s not OK is to not let the IAM team know that those changes are being made, because that certainly affects a lot of things down the stream. Having a good relationship with HR or IT — whatever the right term is for your organization and where that authoritative data is coming from — makes sense, and maybe it’s not HR. Maybe contractors or vendors are managed by the finance team, or maybe they’re not being managed at all. We see that a lot, too. So, trying to design around those types of issues, we’re not going to have the answer right here in this conversation, but at least bring it up so that it can be addressed as part of the overall role strategy.

That’s right.

We’ve covered quite a bit today. There are some other things that we could probably touch on. You want to have measurable results when it comes to that. You don’t want to create roles that are unnecessary — keeping it simple, making sure that the roles are easily understood. Using plain language to describe what the role is and what it does will help people not only request it but also approve it, and, hopefully, you get out of the rubber-stamping situation where a manager, or whoever is responsible for the access, just says, “Yes, it’s OK” — because of apathy, they don’t care or because of fear. They’re afraid to take away something, because someone can’t do their job, and it ends up becoming a 3 a.m. call on a Saturday, or something like that.

We also have to think about the fact that people retire and leave the organization over time. Other people are going to inherit that ownership of roles, and they need to be able to inherit them and understand what they do.

The inheritance is a strategy that I like a lot. You don’t want to break the chain. If someone owns a role and they leave the organization, my basic philosophy is, that person’s manager should now become the owner of that role until they tell me who is going to do it instead of them. That way, you don’t have this role hanging out there that doesn’t have an owner, or has a gap in some way, whether it’s approval structure or whatever. Being able to come up with standard processes around that doesn’t mean that they permanently own it, but someone has to own it, and you want to make sure that you keep that link between the two things in place.

You mentioned something about measurable. That can be using some measures or some metrics as you’re rolling out roles to know how many roles have owners, or even if you’re looking like groups, they have owners, and they have descriptions that are usable. You can use that to make sure that you’re closing the gap. But, then, as you’ve gotten a head of steam around using roles, how many people belong in a role, or how often is that role assigned? What if you find that you have low use of a role? It’s probably one that you wanted to reach out to the business, and say, “Hey, do you still need this role? I can see that you’re not using it very often. There’s only one member of the role. Is this something worth us investing our time in having a role like this?” Maybe it is, maybe it isn’t, but that’s where that data can — metrics don’t only have to be to communicate out to the organization, “Hey, what a great job we’re doing.” It’s also having those metrics to do a better job of managing it yourself.

Yes, for building that role access tree. Sometimes you’ve got to do some printing, and that’s healthy, in a way, to keep it manageable. I totally agree with that.

We’ve been going on for quite a while here around role-based access control and other things around it. Is there anything that you want to bring up before we decide to call it for this week?

We did talk a little bit about it, but the technology side of this is really the identity governance and administration, or IGA, space. And so, if you’re looking to do additional research, when it comes to roles, taking it from this philosophical discussion that we’ve had today and turning it into something that’s going to be very tangible, and we start using specific terms to mean specific things, is, if you’re going to adopt technology, I recommend that if you’re going to adopt that technology, that you try to adopt the practices, the best practices, built into that technology. IGA is the space that typically does role management. If you go down the route of, say, implementing a SailPoint-type system, they have definitions on what roles are — business roles, application roles and things like that — so use that terminology, and try to adhere to their best practices as well, because if not, you’re going to be swimming upstream.

Yes, that’s a good point. You buy a lot of these technologies not only for the technology itself but also for the process that comes with it. This is what those technologies do — SailPoint, Saviynt, Clear Sky, a whole bunch of these other IGA players. They have a process that they follow, and, generally, it works. Otherwise, their application won’t work. You want to try to stay within the bounds of that and, like you said, adopt those processes into your business so that you’re not having to get into this world of customization and exceptions, and all the things that come out of using technology in a way that wasn’t meant to be used, which you certainly want to try to avoid as much as possible.

Yes.

All right. Well, I think, that’s a pretty good spot that we can leave it for this week. I feel that we covered a lot of ground on RBAC, ABAC, PBAC and a bunch of other acronyms, I’m sure, that we threw in there as well.

Don’t forget that you can visit us on the web at IdentityattheCenter.com. You can see us on Twitter @IDACPodcast, and, with that, we’re going to go ahead and talk with you all in the next one. Thanks for listening.

Thanks for listening to the Identity at the Center podcast. If you like what you heard, don’t forget to subscribe, and visit us on the web at IdentityattheCenter.com.