- Welcome to Lesson 19:
Given a Scenario,
Implement and Maintain Identity and Access Management.
In this Lesson 19.1,
we're gonna focus in on identity and access management,
also known as IAM.
Now, your identity is who you say you are.
I say I'm Siri Green.
Identity proofing is the process
of verifying and validating an individual's claimed identity
to establish their trustworthiness
and to ensure that they are who they say they are.
Now, identity proofing involves confirming the authenticity
and the accuracy of personal information
provided by an individual during the account registration
or during the user onboarding process.
Now, that might be a driver's license,
that might be a passport.
Think of all the ways that we identify ourselves
within the physical world.
Identity proofing is also a component
of fraud and identity theft prevention.
And in some cases,
identity proofing may be a compliance requirement.
Now, identity and access management, known as IAM,
is a business process.
It's the business process of enabling the right individuals
to access the right resources
at the right time for the right reasons.
Now, IAM functions include provisioning,
educating, auditing, and deprovisioning.
Now, provisioning is a process
of creating and managing digital identities.
Deprovisioning is the process
of removing and deleting digital identities.
Now, IAM functions take place
throughout the entire employee lifecycle,
and we're gonna be taking a look at that in just a moment.
Now, IAM functions
are very, very much a shared responsibility,
shared by managers, owners, HR, IT,
physical security, information security, and audit.
So let's take a big picture look at the identity lifecycle.
Someone is coming into your company.
Now, I used the term employee earlier,
and they're probably an employee,
but they could be a consultant or contractor
that's placed in your organization.
So we have phase one,
and that's when someone is first joining your organization.
So we're going through the onboarding process,
the account request,
the user agreement, and credential management.
In phase two, this is where they have authorization
to access different resources.
This is where the actual assignment
of rights and permissions happen,
and of course,
we're going to continue with our user training.
In phase three, this is the bulk of the identity lifecycle.
This is where someone is in your organization.
They may stay at the same job for a very long time,
or they may change roles, so there may be change requests,
and this is where auditing is going to take place,
user account auditing and user access auditing,
as well as we're gonna continue
right down the path of our user training.
And then lastly,
we get to the end of the identity lifecycle,
and this is when
someone is going to be leaving your organization.
So they're terminating, could be friendly or unfriendly,
and we're going to offboard them,
and we're going to have to do all of the activities
to kind of reclaim any access that we had had given to them.
So we're gonna go a little bit deeper
into each one of these phases,
phase one, phase two, phase three, and phase four.
So in phase one, we said the key tasks were onboarding,
account request, user agreement, and credential management,
so what does that all mean?
Well, first, we have an account creation request.
We've brought somebody into our organization
and we have to say we need accounts for them,
and that request may come from HR
or it may come from a business unit.
Then there are going to be user agreements
that need to be signed
before they have access to our systems.
Probably an acceptable use policy agreement,
and perhaps an NDA Confidentiality agreement,
and we'll talk more about both of those agreements
a little bit later on.
User accounts are created
and group or role membership is established.
What groups do they need to be in
or what roles do they need to be in?
Credentials will be assigned
and security clearance, if appropriate,
and then authentication assets will be distributed.
Now, that could be a token, a smart card, a certificate,
could be biometric enrollment.
And then we're gonna have orientation training.
Now, orientation training will go hand in hand
with these user agreements,
so they understand what they're signing
and what the expectations are.
But in my experience,
orientation training doesn't stick with anybody.
First couple of days that somebody's on a job,
they're really just busy
kind of remembering everybody's name
and where the restrooms are,
and figuring out when payday is.
So what you tell someone during orientation,
never assume that they're gonna remember.
Then we get into phase two
in our key tasks for authorization,
assignment of rights and permissions
and user training again.
Now, authorization is going to be granted
by a data or resource owners,
or in some cases,
we'll have to have need to know being established.
Now, rights and permissions are assigned
by the data or the resource custodian.
Remember, custodians are those who manage,
monitor, implement, advise, educate,
but the custodians aren't making the decisions
about rights and permissions, right?
Rights and permissions came from the data or resource owner,
or in terms of need to know,
if you were in a MAC environment.
And then we're gonna continue with our user training,
and here we're gonna wanna repeat
everything we said in orientation,
plus, we're really going to wanna get them to understand
our security and privacy requirements and expectations.
So then we get to phase three,
and our key tasks are user account auditing,
user access auditing, change request submissions,
change request auditing, and user training.
So in this phase,
this is where user accounts are going to be audited
to make sure they're still valid.
Do they still need to have an account
for that particular operating system or application?
And we're not just looking internally or on premises,
we're also looking at do they still need the account
at a business partner,
or do they still need the account
in a cloud-based application?
Now, if someone hasn't logged in for a long period of time
and we were looking through the accounts,
we would refer to that as a stale account.
Now, in addition to looking at do they need an account,
we're also gonna say,
do they need to be a member of a particular group still?
Do they need to be part of a role, right?
Do they still need these same access permissions?
And we wanna do this on a regular basis,
generally at least an annual basis.
Now, user access is also auditing.
Now, what we're looking at here
is what someone has permissions to do,
but perhaps shouldn't be doing.
Let me give you a couple of examples.
So perhaps someone is streaming movies during the day,
and what we notice
is that they're chewing up a lot of bandwidth.
Now, they had permission to go to the internet,
but certainly not to be streaming movies
and to be chewing up bandwidth.
Another example would be in a hospital.
On a hospital floor, all the clinicians have access
to the patient records that are on that floor.
That's important for emergency reasons,
but perhaps there's a policy at the hospital
that says if a patient is a family member or marked as VIP,
you can't access a record or shouldn't access a record
unless you're involved in direct care.
So we could be looking for things like that.
Did you access a record that you shouldn't have?
Now, change requests are going to be submitted
all during the identity lifecycle
'cause people move from one job to another
or they need a different set of permissions.
So those change requests are going to be audited as well.
And then we're gonna continue with our user training.
Now, user training really falls into one of three buckets,
education, training, and awareness,
and in the security world, we refer to that as SETA,
Security Education Training and Awareness.
And in our very last lesson in this course,
we're gonna dive deep into what do we mean by SETA,
Security Education and Training?
But for now, really just keep in mind
that we wanna continue educating and training
and having our users aware,
contextually aware of security threats.
Let's talk a little bit more about change requests.
Now, change requests are the formal process
to request, to revoke, or modify access
when a user's status changes
through transfer, resignation, or termination.
So transfer to a new job, they leave, they terminate.
Authorization creep's an interesting concept.
Authorization creep is the accumulation
of unnecessary rights and permissions over time.
Now, why do we have authorization creep?
Promotions, lateral moves, cross-training,
and temporary coverage
all contribute to authorization creep,
and it happens because people move from one job to another,
and very often, when they move to a new job,
they need their new rights and permissions,
but maybe they're still covering the old job
or maybe they're training their replacement,
so they get the new job and the new rights and permissions,
but they still have the old rights and permissions,
and then no one goes back
and gets rid of those old rights and permissions,
and that continues on and on and on.
And that's where the change request auditing comes in,
and says, "Okay, we can see
you gave them the new rights and permissions,
but oh, look,
you didn't take away the old rights and permissions."
So we're really trying not to have authorization creep.
Now we get to phase four, and that's our termination.
That's when somebody
is going to be leaving our organization.
That could be friendly or an unfriendly.
It could be they could be being fired, they could resign,
they could be being laid off.
You know, it could be just time to go,
so it's termination.
And offboarding is the process
of having them sort of leave our organization.
Now, termination tasks include reclaiming physical assets,
like a smartphone,
and access control assets, like a token,
disabling and removing accounts and access,
both internal and external,
and I can't stress external enough.
We have to remember that we need to disable those accounts
or delete those accounts
at partners and everywhere in the cloud
where they may have an account
associated with our organization.
We want to archive any documents they had,
maybe archive their email so that we have them later on.
And then off-boarding tasks include
reassigning file and folder permissions and ownership.
We're going to probably do an exit interview,
and at the very least, what we should be doing
is reminding users of any agreements
that extend beyond employment.
So for example, confidentiality
or non-disclosure agreement, an NDA,
very often will extend beyond the employment period.
It will go on for X number of years.
So those are the four phases in the identity lifecycle.
That, my friends, brings us to a three-second challenge.
Five challenge questions, three seconds each.
You know what to do.
Challenge question one,
the process of creating and managing digital identities.
One, two, three.
That's gonna be provisioning.
Number two, confirming the authenticity and the accuracy
of the personal information provided by an individual.
One, two, three.
It's identity proofing.
Number three, an account that's no longer being used.
What's that called?
One, two, three.
That's a stale account.
Number four, the accumulation
of unnecessary rights and permissions over time.
One, two, three.
That's gonna be authorization creep.
And number five, when management validates
that rights and permissions assignments are correct.
You know, I don't think I gave you this term,
so I'm gonna give it to you now.
We wanna make sure that on an a regular basis,
maybe an annual basis, that management is saying,
"Yes, those rights and permissions are correct."
That process is called recertification
or access attestation.
So recertification or access attestation.
Now you have it.
So let's do a security-in-action together.
This is about IAM auditing.
Now, a member of the Human Resources staff was terminated
because he accessed management payroll records
and then bragged about it.
Now, obviously this is a violation of trust.
Management faulted the HR Director for her lack of oversight
and charged her with cleaning up this mess.
Now, her first response was to bring in an audit team
to review payroll application accessibility.
And she's come to you and said,
"Can you help me define the audit scope?
In other words,
what do I need the auditors to be looking at?"
So the question to you is, what did you include?
So quick recap, we had a member of the HR staff.
They were terminated
because they accessed management payroll records
and then for some reason decided to brag about it.
So HR Director gets blamed.
She brings in audit, good idea, right,
to review the payroll application accessibility,
but she wants to make sure
that everything that should be included is included,
and comes to you for advice.
What are you gonna include?
Go ahead and put me on pause, think about that,
jot down some notes, and then come back,
and we'll go through the audit scope.
Well, the audit focus really needs to be
on who can access the payroll application,
what they can do, including data exfiltration,
and what they are doing.
So really three parts there, right?
Who has rights to access it, what they can do,
so including, right,
being able to maybe save things to an Excel file, right?
Save payroll records to an Excel file
and then maybe exfiltrate that,
and then what they really are doing.
Those are the three components.
Now, the audit scope should include
who has explicit and implicit access
and their assigned permissions.
So implicit and explicit.
Either we've assigned it to them directly
or they have an assignment
because they are part of a group or they are in a role,
and what their assigned permissions are.
And we wanna look back over a specific period of time.
We also wanna look at change histories,
so what's been granted and removed,
and has that been done correctly?
We wanna look at the activity.
How are they using the application?
What are they actually doing?
So we just do an activity sample over time
and a review of past events.
So if there's any suspicion, a review of past events,
and that would be awesome if there's any logs available,
to be able to go back and see what they've done over time.
Now, if this application can log,
and there haven't been any logs to date,
this is a great time to start logging.
And that would be the audit scope
to try to figure out what's going on
and try to prevent this from happening again in the future
by having the right
or having the correct rights and permissions.
Doing that, my friends, security-in-action.
There's your word cloud.
You know what to do.
When you're ready, I'll see you the next lesson.