You're listening to the identity of the center podcast, this is
the 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 of the
center podcast, I'm Jeff and that's Jim.
Hmm. Hey, Jeff, how's it going?
That's a bad yourself. Good.
Good, you know, I feel like a big complainer.
We always one of our favorite inside jokes is, oh, you bet
sounds like a personal problem. Well, I've got good weather
problems, right? I'm I'm sitting here
complaining, because his mid-40s, and the rain has
finally stopped. It has been rainy and, and cool,
and have the United. It's is under some kind of
blizzard warning or digging out us know.
I know you're in Chicago, you haven't had the best, whether it
has been difficult. So, you know, I think for a
large swath of the United States over the last several weeks and
yeah, Chicago has been pretty snowy.
I think. I think we're close to setting a
record for like number of consecutive days with, with
measurable snowfall at least in the Chicago area, which is where
I'm at. So, you know, and then obviously
our friends down in Texas are certainly having some struggles
with Power issues. So for those who are listening,
it is Friday, February, 19th as Jim and I are sitting here kind
of talking about this. So if you want to look back in
the and The Archives of the internet, right?
You can probably kind of figure out what was going on in the
world back then but yeah it the weather has been challenging but
I am hopeful. I'm seeing above freezing
temperatures on the radar and on the forecast as soon as maybe
even this weekend or maybe next week, always plan a trip down to
Cancún. I don't think anybody will
protest outside for your house. Old, man.
Oh, was that, that's not what you meant by the power issues,
in Texas. Oh, you meant something else.
Sorry we usually don't go there on this show.
We usually don't get political but yes, that that was not a
good look for a certain individual and the the Texas
political Spectrum, which is put that way.
So what I'm going to talk about today I'd like to talk about
role-based access control and all things associated.
What do you think of that? I think that as a gigantic can
of worms and I think we you 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's a lot of, you know,
different competing directions that maybe things want to go in
from a role perspective, right? You've got role-based Access
Control, you've got attribute based Access Control, you've got
policy based Access Control. There's a lot of acronyms and
we're going to get into that today.
So I think what we want to kind of start off with the Is, you
know, this is our thoughts and how you get started to eat this
elephant, one bite at a time because it is, certainly a tends
to be a rather large project for a lot of organizations.
And a lot of times you are starting from, maybe not the
best from a data quality perspective.
And you may have to, you know, have a lot of kind of push and
pull to kind of get things up hill.
Yeah, I mean it's what complication topic the most for
me is that there's not a industry standard definition
like we, if you ask somebody who's As in, there's a I am
practitioner. What is multi-factor
authentication mean? You get the same answer every
time. You ask somebody what a role is
you get a different answer every time and that's because a couple
things from an organizational standpoint.
We talk about roles differently application, even within an
organization, you might have application teams talking about
roles within their applications and then you talk to the.
I am team or the active directory Gene and they're
talking about roles that. Totally different level.
And then from an authentication, side of the house or this is an
identity management side of the house, whether that you're using
roles to drive provisioning to apps, or you're interpreting
those roles at the time of authentication to confer access.
And I think we had a an episode one of our original episodes
back when we used to do a lot of Jeff Jeff and Jim episodes where
we talked about kind of some of the most Confusing terms and
identity access management and roles was probably number one.
Yeah, that that highly liberal use of the word roles.
You know, can certainly complicate the way that things
get defined. So we're going to dive into it
here and I think it's probably important before we get too far
along. Here is really when we're going
to talk about role-based access control or our back is that
we're really focusing on the provisioning side of things not
necessarily the authentication side of things because like
There are sometimes some definition of roles being
assigned at the authentication level.
What we're really talking about provisioning and really more
authorizations. So why don't we dive right into
it? And why don't we start with what
is a rule Jim Murray. And so I'd say like if we're to
give it a dictionary definition, it's really 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. So there's a couple elements
there one is that it's a grouping of access rights and
it's assigned to people or it could be to non-human account.
So maybe people isn't the right term, it's identities, but it
confers access. Right?
So the point of putting a roll together is to bundle access and
so when we talk about Even Frameworks.
We look at that. It has an access pattern.
Yes, or no, right. That's an important piece of.
There's not an access pattern around a roll.
Then there's not much sense in developing a roll.
Yeah. And I think one of the ways that
I've heard it described in the past that I kind of like it
really, it maybe oversimplifies it, but I think it's okay for
this conversation is think of roles as a bundle of sticks.
Right? Each stick kind of has its own,
maybe unique properties, and you might pick up and have different
bundles of sticks. And you might have just one
stick in your bundle, right? But, you know, each of those
things, could essentially be an entitlement and that bundle ends
up becoming what we kind of refer to commonly as a roll.
So now that we kind of set the stage of what is a roll, why
would someone who want to go down this?
This hellscape that it's sometimes be of setting up
access rules for their organization.
When I think about roles, I generally, think of, you know,
the kind of the framework that You think about this is there's
two types of roles and we're going to use some terms, right?
And some of these terms are used or not used by different vendors
organizations, but the two main ones for me, our Birthright
roles and requestable roles. And when you think about
Birthright rolls, the idea is that you can automatically
assign access to a person based on something about them.
Some attribute about that person they're an employee.
They work for a certain department or they work in a
certain Certain location. Usually this is going 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 it's data-driven that they are all this
classification and because of that they should have this
access and that whole process can be automated.
However, request will roles are something that we don't have
that that driver of some attribute.
That's going to say whether or not the person should have
access and is ultimately a bundle that bundle Sticks that
we want to make available and it's for convenience sake.
And so having that bundle of sticks.
Now, somebody in 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 non-person identity.
You know the more you try to narrow size these definitions
the more it just sounds like a bunch of words so I'm probably
going to stick to more the simple definition but If you
have a request for roles 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 that bundle is our.
You're either going to tie it back to some job function or
maybe to a job overall. Yeah, I think you know, maybe
let's stick with the bundle of sticks concept here is, you
know, if you think you're on you're walking around and you
know whatever Village and when you're born you're given a
bundle of sticks, right? That's just what you get, that's
a Birthright roll. It could be, you know, whatever
that little sticks might look like and then maybe you go to,
you know, 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, right? So that would be more of the
requestable role. So maybe we can, you know, that
maybe a little again, little bit too simple, but I kind of like
it, at least for the purpose of this conversation.
And, you know, it's important to mention the business look like
he just did because it's Very difficult to do rolls 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's going to approve them,
right? How do you make things that are?
You know, appropriate for the business to understand because
really at the end of the day, it's the businesses data and
it's the businesses rolls it. And by extension, the identity
access management team or technologies that are associated
with that team are there to kind of Port the business and to make
them make help them make more informed decisions.
So 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 year long or multi-year projects depending on
how complex the access Matrix might look like within an
organization. So, that's something to
certainly consider as part of this is not easy.
And that's okay, right? We mentioned, it's an elephant.
You got to start eating, that elephant, one bite at a time.
And this is this, these are some ideas.
On how we want to get started on that contrast.
What that, 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, and they're looking at, you know, a list of groups are,
you know, 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 and if
you're reviewing and you don't understand, you're probably not
going to start removing access that you don't understand what
it actually is and since we have your employee, not have the
access that they need to perform their job.
So what ends up happening is that people rubber-stamp during
the access Requests and reviews. So that's a place that roles can
be. Very valuable, especially roles
of gun. Right?
Are you name them in a way? That makes sense.
You write descriptions descriptions should tie back to
what, you know, what access this role confers and you have owners
of those roles so they can do roll reviews effectively.
So we've talked a little bit about our back or role-based
Access Control. What does that mean?
I think we For my money, when I talk about our back, it's the
overall process of role management and how roles Drive
the access that people get. So it's, it's looking at it from
kind of a 360-degree perspective from how you get the rolls, how
those roles help Drive access, how people interact with those
roles. Again.
Like we've been talking about its kind of we touched on a lot
of the different aspects of what makes a good role and it's
something Thing that the business can understand, they
can assign to people. And then those roles really
become the basis. For the assignment of who gets
access to what what would you add to that?
You pretty much covered everything.
You know I think if we go back to the bundle of sticks,
role-based access control is, how do you create that bundle of
sticks, right? 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, right?
And this is an area that that does take some finesse.
This is more of a this is not necessarily technology problem.
This is more of a business process and trying to make sure
that you convert the Active Directory Group that is labeled,
you know, I T Dash PR D Dash, you know, a PP 004, you know,
translates into something that actually makes sense.
Oh right, that is the server or the application that controls
the cafeteria. You.
All right. So being able to make that
translation and put that in front of people to have them
make those informed decisions. As we're really role-based
access control and the Frameworks that go around it.
I think make the most sense, I know we've also talked a little
about a back or attribute based Access Control.
How is that different from role-based Access Control?
One of the things we said early on is, we're going to focus more
on the provisioning side. And so I think we're talking
about a back. In provisioning, we're talking a
lot about that. Birthrate automation of access
accounts where I really see a back as where I see
organizations using it as more on the authentication side.
In other words, applications are being given rather than here's
the access to person has a given profile information about a
person with a lot of attributes and that the applications that
can then interpret those attributes.
However, they see fit in other words.
The the decision point is that the application in terms of what
access those attributes confer. So very much like, you know,
policy-driven again, kind of on the provisioning side of the
house I think is really the interpretation of those
attributes for automating the provisioning of access.
Yeah, I think you hit it right there.
You know sometimes a back is also known as P back or policy
based Access Control. It's more of a runtime or Time
assignment of access. What's interesting to me is that
it really kind of layers on top potentially of role-based Access
Control right if you're driving data into the application?
Say, you know, here is Jeff and he's 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 determining, you
know, in a more real time based on the With indication the
authorization streams, what I should have access to versus
something that I've always had access to, which might be, you
know, that role that kind of 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 put people in
these roles Versus you just handing the data to the
application and the application is deciding what access that
person should have based on those roles and so.
But in both cases, you're centralizing that authorization
data there is a scenario also where applications are
completely doing their own authorization Management Group
managing, enrollment or whatever you want to call.
You want to call it or they call it.
What I think is, that's usually a very early.
Maturity step. That's where you have a lot of
applications that kind of grown up on their own.
And maybe you've done kind of a level 1 integration, where
you're doing single sign-on between the application.
But you haven't really started to pull the authorization out of
apps and manage it at least manage the data centrally.
And so, that's kind of a, you know, step two or Phase 2 in
kind of centralized in your applications, is that
centralized management of offer. Relation.
But Jeff, my could I mean one thing I wanted to do earlier was
my little rant as in my rent, goes back to when we talk about,
what is our back, right? And kind of, how do you get that
bundle of sticks? And you know, that the two
methodologies that have gotten the most thought are around role
mining. So kind of the Starting with the
data and kind of building roles that way and roll engineering.
So kind of the top down approach in other words, a business
saying, you know, we need to roll that does X, Y, and Z and
then kind of building a roll around then and, you know, my
ran, I'll just, you know, put it in black and white terms.
I think role my role. My name doesn't provide a lot of
value at least when I've seen it in and, you know, I'm sure this
will get a lot of heat of. We had a forum where people who
just a winner. Stupid.
You know, we got in so much value out of it, but, you know,
when I've seen examples of role mining working, it's, you know,
taking that data that you have about users entitlements and it
saying looks like you've got an access pattern here that 80% of
the people in this department have why not give that access to
a hundred percent of people? And so my thinking is because we
don't want to give people access that they don't need, right?
It's funny. Percent of the people don't have
that role. That they're not banging on our
door saying, we need that roll. Why would you create that
rolling? Give that access to those 20% of
the people. What are your thoughts on that?
I mean, principle of least privilege.
Every time you 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. So I don't see why you would
want to give anyone access that they don't need.
Let's take a couple parts here. I want to get into this because
that was literally next question was are back and compete against
that concept of least. Privilege.
They are competing Concepts. So what we're, you know, we're
talking with folks, you know, and having these kind of
conversations, it's okay, you know, we want to be more
role-based and oh, by the way, we have this policy that says,
you know, we're least privilege. Okay.
Well, which is it because if you're assigning roles that have
access has two things that people don't need, then you're
violating the concept of least privilege and that's usually
kind of a thinking machine. When we're talking customers
and, and kind of thinking, okay, well, house is actually going to
work. And I think this kind of goes
back to the whole roll mining on the roll engineering exercise as
well. Because I do see some value in
the role mining but I don't see and I see the value of the Roll
engineering and I think that they're most effective when
they're done together. If you're trying to do one or
the other, I think it's a lot more difficult to see the True
Value out of it because The way I see it is, you know 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 inventory.
So the mining is, you know, you're going it out into this,
you know, this this mind and down into the shaft and you're
trying to find, you know, the different nuggets of gold ore
and those gold or might be different entitlements within
the application. It's great that you found them.
But what do you do about it? And I think that's where roll
engineering comes in, is okay. 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, right?
Or do we leave this as a raw material for some other purpose?
So I see the role mining more as a Recon effort.
Let's figure out what's out there which is good right?
You want to know? Because if you're trying to
protect an application and you don't protect you Applicant, you
know, the rights that allow edit access to a database table and
things go Haywire. That's not going to be good
either. So you kind of have to know both
and then the engineering comes from working with the
businesses. They okay.
Let's talk about what are we going to give access to people
and then does that, how does that work with these privileged?
And the concept of rules because there certainly is a lot of
risk-based decisions that. I think that can be made there
around, you know, let's, let's take the cafeteria menu for
example. We really care if everyone has
access to that, you know, maybe it was not granted and it's a
certain people, maybe it was a mistake or maybe it's a new app
that just didn't get back filled to two people who were here
before the app, right? Probably not right.
The risk is low. Do we really care for having
chicken on Friday or, you know, or ribs or whatever?
Maybe you know, that's okay. But if there are more sensitive
accesses then yeah you probably do care and maybe the role that
you thought would be good for For an entire team or a
department, needs to be split up because you want to keep with
that, you know, concept of least privilege.
So I think there are I think there's value in the role
Engineering in the mining and the mining isn't just finding
the applications, right? It's also or the entitlements
that it can also be what do the people have?
And I see that as just an intelligence report that comes
back to eventually someone in the engineering side of things
whether it's the role owner, the role developer, you know,
whatever it might be, whatever persons handling that Say okay.
Yeah. Jim and Geoff, both have this
access, but General Jin has this other access but Jeff doesn't is
that appropriate? Maybe it is.
Maybe it isn't. Right.
And I think, you know, whatever the differences are comes down
to risk. If it's because Jim can knows
that we're having chicken on Friday and Jeff walks into the
cafeteria, you know, back in the day when we could actually go
into into buildings. You know, any surprise when the
menu comes up, maybe that's a risk were willing to accept or
maybe I'm just really picky eater and I need to have Have
the menu in front of me before, I'm going to waste my time
walking down the cafeteria, just to find out, we're having the
same old thing. So, that's how I kind of look at
it. You know, between the two, I
think, if you take a real philosophical approach, that's
probably not the right approach, right?
It's good. Value out of doing a data
mining. And, you know, we use the
cafeteria menu example because Nobody cares, right?
Everybody has access to the cafeteria menu.
Like, no one, no one should care anyway.
But they're, you know, made me think of a few things.
One was I saw a really good presentation and then we'll know
who attributed to, but it got into have access management,
fatigue managers getting so many requests for Access that
eventually just started rubber-stamping because they
didn't have have time to think about it.
You know, we're all busy during the day.
We're doing our job. Then you layer on all this kind
of red tape. But if you really boil that down
to only send a question to the approver, when it's actually
something that is worthy of an actual review, then you can get
to the point where you actually have deep thought put into it.
So you never asked about the cafeteria menu, but you always
ask about access to sap or whatever.
The financial system are and then it's, you have to decide
everything in between whether or not that requires somebody to
review that approval. Another thought I've run into
overtime is with least privilege applying that to privileged
access menu. So it's kind of the same concept
around assigning. What is the risk to the access?
And that's an area where roles can be very valuable, right?
Because You know, if you have, I think philosophically speaking
anyway, you should have fewer rolls than you have
entitlements, right? Yeah, ideas.
Should be you're bundling those sticks and you're not creating
more bundles of sticks actually, there were sticks.
So, if you can get to that smaller number, it becomes an
exercise that is more feasible. In terms of actually assigning a
risk value. Something that can be used to
determine what are the Operator controls around that, around
that access you touched on the design, their right a little bit
around. You know, what are these bundles
look like? How does someone get started
designing roles or going down? The are back or a back path for
their organizations? Well, I think it's, I think it's
probably like a lot of I am things and you have to look at
trying to get your low-hanging fruit first.
Great. As I always think about with our
back, is you start talking about?
Are back with people. I tend to think, people think
it's all or nothing, right? You're either doing everything
through our back here, doing nothing through our back and
when you see organizations that are actually on the are back
path, they usually never have to finish line right there.
Doing a lot of things with our bag and where I think
organizations to get the most value is the things that they
can automate. So it's that Birthright access
getting someone started on day one so that they Whatever it is
80% of the access that they need in order to do their job and
then beyond that, it's now you have to start getting into the
tougher stuff. So building those roles that are
around functional teams or functional jobs within the
organization and tying off the access, and it really requires
somebody with expertise on what is the access that you need in
order to make that successful. Successful.
And so you need to pull in people from the business and
really where I think I am teams and it teams should spend their
time. There is with the business units
that really want to step to the table and invest the time to do
this. So in other words, if somebody's
going to play along, you're going to get a lot further than
if you feel like you're dragging them into it and there you're
making them do something that they don't want to do.
I think, And those other groups that are not participating.
You see this success as being bred by the teams that are
participating, they'll want to participate as well.
So that's kind of I think the approach is think big but know
that you have to kind of 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, you know, first work with
the teams that really see the value and are willing to invest
their time into making this successful.
Yeah, I like the The concept of starting big and starting micro,
you know, maybe it's macro micro so, right?
When I say that what I mean, is, you know, let's figure out.
Are you an employee, right? It's kind of a basic decision.
Maybe your, maybe an employee. Maybe you're a contract or maybe
you're a vendor or an intern, you know, whatever.
Maybe start with those giant rolls 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 edit that maybe it is the
cafeteria schedule, right? Maybe it's a company intranet
site, something like that. So you start with these very
broad roles and that's okay because you got to start
somewhere and then I like to start by dogfooding rolls with
my own team. So 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 kind of refine the
process before I go to the next area, right?
Another business unit other team Etc.
And I would certainly start with teams that are friendly to, you
know, this this process. It's a lot easier with a willing
partner, that's for sure. And knowing that, you know,
you're there to try and help it and that there are going to be
pain points, right? 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 macro micro type of way.
I like that approach personally because I think You don't push
off the value. That might that you might be
getting by trying to design a whole bunch of rolls at the
department level. You can get value out of our the
employer their contractor, right?
That could be enough to make a difference.
And you can say all employees, when they on board, they get an
active directory account with these two adgroups and this
Office 365 or Microsoft 365 license.
That might be, you know, a good enough win to solve a couple of
pain points, maybe from an onboarding perspective, right?
It shows that you have Have some capability to get this done for
right? So you start to build
confidence, he organization and that, you know, the money and
the time that's being invested into this is working.
So I think that is, you know, a big part of it.
And then, you basically make a circle bigger from there or you
make the circle smaller from there, depending which angle
you're approaching from. And you can do both at the same
time, you know, with with the proper, you know, management
around how you'd like that to work.
I think I really like your house of growing.
Your own dog food. I think that works really well
with the And your, whatever your I am group or some small
contained group, I would say that I key generally is one of
the hardest departments to take on in terms of Designing roles
for, you know, system administrators database
administrator. That's where I'd like becomes
almost impossible and so you might feel like you're swimming
Upstream. If if you start with it, other
departments can be more stable HR.
Finance things like that because they those roles generally tend
to not change as much overtime as some someone and I can do or
be as cost in that group. Yeah, that's the point.
I think, you know, IIT is this is probably the hardest.
And if you can start with something simple, write your
ear, again, showing the values sooner rather than trying to
tackle the really hard stuff, right?
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? And, you know, it's okay, I
think to not have a role for every single thing that's out
there. That's just, that's the real is,
you know, the realistic way to a kind of approach.
This is different teams, different organizations,
different business units, different geographies.
Those will all play into whether or not a are back.
Model makes sense. Right?
You may have a more mature role based access control for certain
teams on a less mature in other areas.
Using the console we've kind of talked about, maybe it really
only has An employee role. Whereas, you know, Finance maybe
has an employee role and a finance role.
And you know what accounts, receivable World, write
something like that and I think that's okay.
You just have to be able to manage it effectively and know.
And when no one know when and where to pick your battles I
would say. One other thought I was having
is we were talking about something like finance and we
think about, you know, Erp systems a lot of times they'll
already have a complex role structure.
Then the Erp system. And so I think as an I am
practitioner when you're looking to do, Enterprise are back, you
have to kind of set what your scope is.
I think is a dangerous place to you know, 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 but you know, so I think that's an important point and
the other thing I was going Going to say is just that, you
know, I think finances really good place to start because
that's where you're also going to find a lot of segregation of
Duties types issues and the IGA platforms that can really, you
know, identity governance and administration platforms that
can tend to help build our back models and manage our back.
They do a pretty good job generally speaking in terms of
identifying segregation of Duties and then baking those
into the access request. Access review process.
So kind of get a double benefit if you focus on on that area and
you're able to roll in s0 D 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 you know Erp and finance apps, things like that.
And that's usually where we see relatively decent if not good.
You know, controls around what the roles do because there is
some you know, more judicious. Thinking around who should have
access to what in a financial systems.
Those sorts of things where we see a lot of organizations, kind
of fall down is cross application, ssds.
So they may be really good at managing sap and, you know,
having the appropriate checks and balances there.
But where the challenge comes in is if you have, you know, across
different applications. So maybe not only are you an
administrator in sap. Maybe you're also an
administrator on this other application.
That is kind of outside the purview of finance.
That makes a toxic combination, you know, something.
Introduces more risk to a certain process, you know,
things like that. So this is I think also an area
where there is the potential to leverage roles and the different
axis controls. Once you're aware them to say,
hey we have more visibility now of what people have access to
and what they can do. Not only within a system but
across systems. Does that make sense?
Do we want to keep that going or do we need to think of A control
to, you know, address that I think when we have these
conversations it's one other thing that has everyone who's
listening these to keep in mind is that, you know, we try to
make it as generic advice, right?
Or a generic copy. They were talking about, but
especially when it comes to, like roll management at the
segregation of Duties within Erp system, it's going to be a lot
different for 500 person, organization versus a 50,000
person organization and You know, he's going to have to take
the advice and then kind of feed it in as one data point, but I'm
sure either way are our fellow. I am practitioners out there.
They become expert at doing within their organization and
kind of are able to take these data points.
It's something where we're really talking here around, kind
of like guiding principles. And how do we, how do we move
forward with this? It is very hard to do.
You know, I said it before, these are generally at least a
year, multi-year long projects to do.
The mining right, finds the entitlements, and then figure
out. What do they do?
Do they make sense? How are we going to, you know,
construct, those bundles of sticks, right?
Those sorts of things. So, it is difficult and it is
something that can be done, but don't get, you know, don't get
to, I think Lost In The Weeds if especially if you can start to
address some of the macro type of roll situations.
So maybe we should talk a little bit about some of the guiding
principles for role management that we've kind of Talked about,
you know, around here in this conversation but also maybe 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 confirm more than one small piece of access.
So the Moores used the more people applies to the better.
The role is Is what are some of your thoughts are?
Yeah, I like to keep it simple, right?
Don't create roles unless you need them.
Gets it's the same thing. As you know, don't create an
active directory group, you don't need it.
Don't create, you know, any type of entitlement you're just
creating more work for no reason.
So, take a look at the way things are constructed and
figure out if you actually need to spend the time doing it.
And maybe, you know, if one person has this access and they
use it, you know so infrequently.
Maybe it does make sense to leave out of a roll and make it
more, you know, on demand. Requestable or however, you kind
of like to work through that. So I think that makes sense,
right? What about a framework.
So we've talked a little bit about Birthright and requestable
roles, and I feel like that's a pretty good framework to kind of
start with when it comes to getting started with, how do you
want to, you know, figure out which bundles of sticks, you
want to create and how they're going to be constructed.
Maybe we can, we can talk a little about that, right?
Yeah. I mean, I think a framework
means a way of thinking about, About a problem and something
that is reusable and solvable. So to me, it's setting yourself
up with a series of questions that you can ask about, you
know, as kind of a workflow almost of questions you would
ask yourself in terms of building roll, is it a good
Earth re-roll? That's what you would want,
ideally, right? Because I think you want to
automate access where possible if not.
Can you make a good requestable roll?
And if not does Even make sense to have as a role.
So, kind of questions you get, as yourself are, can I define
the user type? So if we're using the example of
interns, yes, I can, you know, interns are distinct group of
people does an authentic authentication or authoritative
Source exist for that user type. So maybe in our HR System we
have in turn as it goes ignition.
If we do, we can still go down that path.
That it could be A, you know, we could still be going down the
path of having a birth very role.
If it's not in the in the authoritative Source like the
work they system or the HR System, then it would have to be
a request Will Roll, right? There's no way to automate the
idea that somebody is is in that grouping.
Another question would be kind of defining entitlement pattern
or access pattern. So in other words do interns
actually have to you know, access the same Soup of data
across all the entire intern population or do those is there
some subset of data within the organization that they do all
need access to? And then is the membership
volatile. So example, I'm going to give
here is that I worked with an organization that they would
change their cost centers very frequently.
And so even though it seemed like at one point your cost
center could be used, it was coming from an authoritative
Source. It did Define some access
patterns because if you're in a certain Cost centers.
It kind of meant that you needed access to certain things.
However, it was volatile it change so often for people as
they did. These re organizations that it
actually did not make a good roll.
So if the interns hype is usually not volatile, right?
People are yes they're interns and then they can move on to
something else or leave the organization but they're not
switching different types of in Terms all the time.
If they are then it would potentially As qualified as, you
know, potential birth re-roll, that to me is what the framework
is all about is being able to kind of walk yourself through a
questionnaire and being able to determine whether or not you're
creating a birth rate role of requestable roll or you know
that population doesn't make for a pretty good roll.
Yeah. I think you touched on a couple
of important things there and especially around data quality
and coming from HR and other authoritative sources like
workday sap, Oracle etcetera. Is, you know, a lot of these
access decisions are going to be driven by the quality, and the
timeliness of the data in those systems.
So 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, and from in, from when right, if someone
gets loaded into work day, the day of their higher that might
not be a good spot to drive automation from a Birthright,
real perspective to maybe that you know, things end up being
more of a request. Double role because you don't
have the data in the time that you need it to be most
effective. So I think that's something that
also kind of consider, you know, any talk about automation,
right? And I think 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, you know, create a role and it has the
wrong access it and they just gave it to everybody and put
your organization at risk. Yeah.
There's something else there with the The, the automation
pieces, typically organizations are getting that data from an HR
System, right? So those HR processes get bound
to your prophecies for assigning access, right?
So there is some some governance required there and that kind of
also comes down to how stable that that data is right?
If it's being changed. If you know, you're trying to
drive access off of something that you know, the Code or job
code. There's job codes wind up
changing every couple of years. You could, you know, create
Havoc. Yeah.
Absolutely. It's got to be.
This is where the tight integration between HR and I am
really kind of hits the most because it's okay to make those
changes. What's not okay, is to not let
the, I am team know and those changes are being made because
that certainly affects me a lot of things down the stream.
So you had a good relationship with HR HR, It Whatever the
right, you know, term is for your organization and where that
Authoritative data is coming from makes sense, and maybe it's
not HR, right? Maybe contractors or vendors are
managed by Finance team or maybe they're not being managed at
all. See it a lot, too.
So trying to design around those types of issues, you know, 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
what is the overall rule strategy?
That's right. So I think, you know, we've
covered quite a bit today and it, you know, there's some other
things that we probably could probably touch on, you know, you
want to have measurable. Results when it comes to that
you don't want to create rules that are unnecessary, right?
Keeping it simple making sure that their roles are easily
understood. So using plain language to
describe what the role is and what it does, you know, that'll
help people not only request it but also approve it and
hopefully that you get out of the rubber stamping situation
where, you know, a manager or whoever is responsible for the
access. You know.
Just says yeah, it's okay because of apathy, they don't
care or because of fear, right? There may be afraid to take away
something because someone can't do their job and it ends up to
become a, you know, 3M call on a Saturday or something like that.
I think you also think about the fact that you know, 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. Yapping, The Inheritance is a
strategy that if a lot you don't want to break the chain, right?
So if someone owns a role and they lead the organization, My
basic philosophy is okay that person's manager should now
become the owner of that role on the till they tell me who is
going to do it instead of them. So that way you don't have this
role hanging out there that doesn't have an owner or has a
gap, you know, in some way, whether it's approval structure,
whatever. So I think being able to come up
with, you know, 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 know, you keep that link
between the two things in place. Yeah.
And you mentioned something about Measurable.
I think 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 a little kid, like groups, they have owners
that they have descriptions, that are, are usable, you know,
you can use that to make sure that you're closing the Gap.
But then also, as you've really gotten a head of steam around
using rolls, how many rolls are, you know, how many, People
belong in a roller. How often is that role assigned?
What you find, if you have low use of a roll, it's probably one
that you want to reach out to the business.
Say hey, do you still need this right?
See that you're not using it very often or there's only one
member of the role is just you know, is this something that's
worth us? Investing our time into having a
role like this? Maybe it is, maybe it isn't.
But that that's where that data can potentially, you know, use
Is metrics. Don't only have to be to
communicate out to the organization and hey this is
what a, what a great job we're doing.
But also having those metrics to do a better job of managing
yourself. Yep.
Fulfilling that role accessed rewrite.
Sometimes you got to do some pruning and that's healthy and a
way to keep it, you know, manageable.
So I totally agree with that. We've been going on for quite a
while here, role-based access control and, 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 I think the technology
side of this is really the identity governance and
administrator IGA space. And so, you know, if you're kind
of looking to do additional research, one thing I would also
say when it comes to roles, right?
Taking it from this philosophical discussion that
we've had today and turning it into something that's going to
be very tangible and restart using specific terms of me
specific. Things is your To adopt
technology. I recommend that if you're going
to adopt that technology that you try to adopt the practices
and best practices built into that technology, IGA is the
space that typically does role management.
And so I just wanted to point that out.
That if you go down the route of say, implementing a cell Point
type system, they have definitions on what roles are
business, roles, application roles things like that.
Use that terminology try to adhere to their best practices
as well because if not you're going to kind of be swimming
Upstream. Yeah that's a good point.
You know you buy a lot of these Technologies not only for the
technology itself but the process that comes with it,
right? And this is what those
Technologies. Do sale points, avian clear sky,
a whole bunch of these other IGA players.
They have a process that they follow and generally it works
otherwise their application will work.
So you want to try and stay within the bounds of that and
try it. I decided to adopt those those
processes into your business so that you're not having to get
into this world of customization and exceptions.
And, you know, all the kind of things that come out of using
technology in a way that it wasn't meant to be used, which
you certainly want to try and avoid as much as possible.
Yeah. All right.
Well, I think that's a pretty good spot that maybe we can
leave it for this week. I feel could cover a lot of
ground, on our back, a back P back and I'll bunch of other
acronyms. I'm sure that we threw in there
as well, so don't forget that you can, you know, Visit us on
the web at identity at the center.com you can see us on
Twitter at idac podcast. 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 and identity
at the center.com.