In this lesson,
we're going to start to examine the idea
of Identity and Access Management.
When I talk about Identity and Access Management,
this is also called IAM.
This is a security process that provides the identification,
authentication, and authorization mechanisms
for users, computers, and other entities to work with
organizational assets like networks,
operating systems, and applications.
Essentially, when you log onto your computer,
you're taking place inside of the IAM process
because you're presenting a username and a password,
and that's going to authenticate you
and that gives you authorization
to certain things within your network.
Now, every unique subject in the organization is identified
and associated with an account.
Now, when I talk about the term
"a unique subject,"
what does that really mean?
Well, a unique subject could be personnel,
it could be endpoints, it could be servers,
it could be softwares, or it could be roles.
When I'm talking about personnel,
this is the most common type of IAM that's defined.
This is people and employees,
those who have user accounts
and log onto the system to do stuff with them.
Now, this is really important
because most computers aren't there just to be a computer.
They're there to get some kind of value from it.
And to get that value from the computer,
you need people to use it.
When my computer is just sitting here,
it's a paperweight.
But when I log onto my computer
and I access the Internet to answer your questions,
I'm providing value.
And that's why personnel are so important in terms of IAM.
Now, another thing you have to think about when you're
talking about personnel with IAM is
that personnel is also a huge risk area
because people write down their usernames
and passwords, and that's a risk.
People log into places carelessly
and let their credentials get out,
and that's a risk.
So these are things you have to think about.
The next area we want to talk about for IAM is endpoints.
Now when we talk about endpoints,
these are desktops and laptops
and tablets and cell phones,
and all of these things are endpoints.
They're devices that people use to gain access to a network
and be able to do their job.
So the personnel is going to have credentials
to log onto the computer,
and that computer is going to have credentials
to log onto the network.
And sometimes those are the same credentials,
but it's still different from an IAM perspective
because the computer has its own set
because it is a unique subject
in the case of IAM.
Now, the next area we're going to talk about is servers.
Now, servers are a little bit different than endpoints.
Endpoints are devices that users are going to log onto,
but servers are sitting in the back,
and a lot of times servers are there from
machine to machine communication.
So each server also is going
to have its own IAM credentials.
These servers might have mission critical systems
and encryption schemes
and other things that are all going on,
and all of that trust
and identity that happens
behind the scenes happens on these servers.
So servers are another big part of IAM.
Another area we have to think about with IAM is software.
Just like servers, there are different applications
that can take and feed requests to and from users,
and that's going to require IAM.
And so software can also be a subject
that has its own unique way.
And usually this is going to be done using certificates like
digital certificates to be able to allow
or disallow a client from doing certain things
with a certain piece of software.
And finally, we have roles.
This is the fifth type of unique subject.
Roles are going to support the identities of various assets
by defining the resources
an asset has permission
to access based on the function
that the asset is going to fulfill.
So when we talk about roles,
these roles can actually be assigned to servers or to people
or to endpoints.
And based on those roles,
they're going to have different permission sets.
Now, the great thing here with roles is
that they're not limited to just people or just servers
or just endpoints or just software.
All of those can be roles.
So while we have those other four categories,
they can all be rolled down into roles
as well if we configure ourself that way.
Now, when you're dealing with roles,
a lot of times we're going to do this inside of Windows
by assigning people to different groups
and then give those groups permissions.
So just keep that in mind when we talk about roles,
that's usually the way things are going to be done.
Now, when we talk about IAM tasks,
there's lots of different tasks that the system is going to do.
Your IAM system is going to contain technical components like
directory services and repositories,
access management tools,
and systems that are going to do auditing
and reporting on ID management capabilities.
All of these things contain tasks that need to be done
for an IAM system to function properly.
Now, in addition to that,
a lot of different things
that might happen as part
of the IAM system is things like creating
and deprovisioning accounts.
So if I'm going to create a new user, that's a creation
or provisioning of an account.
If I'm going to disable or delete a user,
that's deprovisioning.
When we talk about managing accounts,
this includes things like resetting somebody's passwords,
updating their digital certificates,
managing their permissions and their authorizations,
and other things of that nature.
When I talk about auditing accounts,
this is when I start looking at the activity that
that account has done through the different logs
and figure out was that legitimate or not?
This is a big function
inside the cybersecurity analyst role.
You're going to do a lot of account auditing as you go
through those systems,
and this is going to be a big part
of your IAM management.
Another thing we're going to do is evaluate
identity based threats.
Now, what this means is we're going to do a lot
of different things to identify any threats
as a cybersecurity analyst to our IAM systems.
For instance, you might run password checks across your
network to see if there's any weak passwords.
That is evaluating the security
of your identity based threats.
You want to make sure those passwords are strong,
and so an attacker can't break into them.
And the last thing we do is we want to maintain compliance,
and to maintain compliance,
we're going to go through checks and balances,
we're going to go through audits,
and we're going to make sure that we're meeting
the requirements that we have set up
for our system to run securely.
And in the final part of this lesson,
I want to talk about risk.
What risks exist within IAM?
Well, the biggest risk is really the risk caused
by our accounts,
and there are three main types
of accounts that we're going to cover.
There are user accounts,
and these are your standard accounts
that all your users are going to have.
Now, these are the least risky for us
because they just have basic user permissions,
but they are still a risk.
The second type of account
we have are privileged accounts,
and this is even more risky.
The reason it's more risky is
because this type of account has more
permissions. As a privileged account,
this is an administrator,
a root user, or a superuser.
And so they have permission to install software
and uninstall software,
and they can change passwords on other users,
and they can create new accounts
and do all sorts of things,
making it a much more risky area.
So it's an area you want to have additional auditing
and additional compliance checks
to make sure those accounts are safe.
And finally, we have shared accounts.
Now, shared accounts are typically used in small office
home office environments.
You may have one count that everybody uses to log in
to do some certain function.
Now, this is a really dangerous practice
because everybody has that shared password,
and so you lose the ability to audit
who actually did something
because everybody's logging in as that user.
I can't just go to the logs
and say, "Ah, the shared account was on
this system at this time.
They must have done it."
Well, who was the shared account?
It could have been any of 10 different employees.
We don't know.
And so this is another area
that's very risky,
so it's not recommended to use shared accounts.
Instead, you should have people using user accounts
and put them into a role-based permissions group
to allow them to do the functions they need.