Identity and access management or
IAM is probably a term you're familiar with by now.
Even if you haven't had experience with it in your cybersecurity career,
you probably set up multi factor authentication for various accounts.
Or you simply use single sign on or to simplify your account access
or use biometrics instead of a password to log into your device.
Beyond these simple
IAM topics,
there are a lot more complex enterprise
considerations like privileged access management or PM
and cloud access security brokers or C
SBS
in the realm of cybersecurity.
You'll need to know these systems inside and out in order to securely set up your
accounts for users to ensure no one has access to something they're not supposed to.
Identity and access management or
IAM are different access controls designed
to secure your enterprise environment.
You have to remember that we need to identify
every user that comes in contact with our environment.
This means identification of the specific user or group of users we
want to know and annotate the person that is accessing our environment,
first name, last name and maybe an employee identification.
This all applies into the identification model of access control.
We also want to authenticate it just because some says they are,
someone else doesn't necessarily mean that they are who
they are.
What I mean by this is by authenticating
the identification we're going through and verifying they are
exactly who they say they are and that they
have the privileges associated with that specific user.
This comes into play with authorization.
Once we've identified them, we've authenticated or validated them.
We're now authorizing them to use
aspects of our enterprise environment.
Maybe that's just accessing Microsoft word for a word
document or the browser to scour the internet,
but it could also be authorization to gain certain permissions
within our enterprise environment like accessing the firewall to reconfigure it
or touching on a server and redoing a web page.
All of this comes into confines of access,
security management or identity and access management within A I
multifactor authentication is the design around the idea
that having a simple username and password is
just not enough to gain access to our
system by using ma or two factor authentication.
Two fa we combine the simple knowledge portion with other aspects of your identity.
We know that there's password lists out there that literally
have thousands of different passwords that are well known to Attackers
and we need to identify those passwords and make sure that they're not
part of our normal password list that we allow users to utilize.
However, there's no way we can grab every single one of them.
First off,
we understand that users will often use something that
they know or reuse a password in general.
This often comes into play with simple words, like do
123 or even password.
We know that the most commonly used password out there right now is 123456.
So we need to not only stop that type of password, but we need to add on to that
or even if a user's password has been taken advantage of or known by a malicious
actor that the password by itself is not going to give the entry into our systems.
This is where multifactor authentic
authentication comes into play.
We need to know something, you know,
this is a password or a pin number that you've identified and usually pretty common
something you have.
This could be a telephone or a pin code that's transmitted to you via
text.
This could be a token that you utilize.
It could be any number of things,
but it's usually where we're providing data via out of band to the user themselves,
usually via a mobile device or a token.
There's something you are, this is biometric fingerprint, iris scan, maybe
recognition
somewhere you are,
maybe we only identify that your user is authorized to access the systems
from a specific city or an IP address associated with that user.
For instance,
when I was in Phoenix, Arizona,
I would have to log in from Phoenix.
Anytime I went out of the Phoenix Metropolitan area,
the system would pick it up and go.
No,
you're not allowed to access into our system because
you are not where we expect you to be.
And then there's something you do.
Well, this is very limited in scope with technology nowadays,
this is usually attributed to something like typing out your password and the key
functions that you actually type it in or how you sign your name.
It's the action of doing something on the keyboard or
with a pin code that allows the system to go.
Yes,
you normally type your password in this function or at this speed with this pause.
This is something that you do
that articulates that articulates multifactor authentication,
single sign on is the idea that I have an enterprise environment that I
only want you to have one complex password that you have to memorize.
Usually this password is very vast and usually encompasses
anywhere from 18 to 24 characters with special characters,
capital letters,
lower case letters and you get the gambit numbers included
with a single sign on in my enterprise environment,
you sign on once, meaning that your password doesn't have to be changed very often.
But you gain a plethora of tools to utilize within my enterprise environment.
Meaning you have access to your email,
you have access to systems or capabilities within the enterprise environment,
you access sharepoint,
you have access to different operations or departments
that you would normally come into contact with.
The single sign on aspect really provides us a secure password
because it can make it very complex and very lengthy.
But you don't have to
memorize it every single time.
Nor do you have to come up with 12 different passwords for 12 different systems.
Now,
single sign on is really used within
an enterprise environment or an employee aspect,
meaning we're not going to do what most people call single sign
on which is a Federated signon within a Federated sign on.
I can use my
Google password or Facebook access,
different websites or applications across different organizations.
Single sign on is specific to the organization which you work for Federated Signon
would be utilizing like Google to access
different websites or something like Amazon passwords,
access, maybe your Facebook account along with your led
account versus your ego.
All of this is cross organizational within a Federated signon atmosphere
access management or Pam is the idea of
having the framework involved in minimal accounts,
meaning I have privileged accounts or administrative accounts
across my functional areas.
And I want to minimize the number of
people that actually have access to those permission.
This will be something like if I have an administrator
that usually does a lot of my server work,
I don't want to have every it person in my staff,
being able to access all the server infrastructure and
being able to change the configuration by providing minimal accounts
to minimal unique users that I can understand and
track exactly what's going on within those different aspects.
Meaning if
Joe over there is accessing a server with
a privileged account to change the configuration files,
I can quickly identify that Joe is the one doing it,
which is going to stop the number of available accounts in order to hack or gain
to gain access by malicious users by having minimal accounts.
I'm shortcoming or preventing
access to militia users.
I want to make sure that my accounts are unique in nature.
I don't want Joe Bob and Steve to all use the same account.
I want each one to have a unique account to
access the different features on the same server irregardless.
If they have the same permissions,
they need to have different unique accounts so that
I can properly track and monitor what they're doing.
We want to elevate those accounts on a case by case basis.
Meaning let's say that Joe over there normally has
access to chief configuration files instead of a server,
but only a subset of servers.
However, he wants access to change the configuration for a top level server.
If I want to give access to that privileges for that specific top level server,
I'm going to elevate his permissions for a short term basis
because he needs to configure that specific server.
Once he's done, we're going to lower those permissions. So we can't access it again.
This is done by a case by case basis
depending on what the user is trying to accomplish.
We want to make sure that we can log and monitor
all those users and we want to enforce a multifactor authentication.
Imagine if you will a user that has privileged access and
only has to log in remotely with the username and password,
they can make their password even very complex.
But as soon as a malicious actor gets a hold of it,
they can really cause some havoc within our
internal system by implementing a multifactor authentication.
On top of that, we've better secured our systems all the way around
understanding that username and passwords are probably the weakest form of
authentication in our enterprise environment
leads us to something called passwordless
authentication.
This is the idea that we're not going to have something, you know,
as a major point of authentication for the identity management of A
I,
we're going to authenticate utilizing different aspects
like biometric authentication or security token.
So mixing something you are with something you have
and making that our two factor authentication or multi
factor
authentication, we're getting rid of complete something, you know,
when it comes to authenticating the different users on our systems,
we want to provide unique links as well.
What I mean by that is,
let's say that you log into a system for the first time using a username and password.
Now, I just said we're not going to
username and password.
However, you log in with the username and password.
It smss you a link which you then click on that
link that you clicked on is now something you have.
You
set you the link via phone,
you then log in via a second authentication methodology like biometrics.
So well, actually, what we've really done is we've said you have to
youre user name, password,
you have to have the device which is something you have.
And then you have to provide a biometric authentication,
meaning that you've done three forms of authentication, something you know,
something you have and something you are.
We want to make sure that regardless
of the passwordless authentication that we're utilizing,
we're using
band authentication,
meaning that when we enter that username and password,
you're not providing authentication on the same web page if I log into a system
and then it says, oh, you've logged in,
let's send you directly to that website that's in band authentication.
We're providing you the link just by logging in
by using an S MS text messages to your mobile device.
We provided an out of band authentication,
meaning it's gone a different route than your initial input
cloud access security broker or CASB
allows us to detect visibility our user.
I need to be able to see who what and when they
are doing the actions that they're doing within a virtual environment,
I need to be able to see and then potentially
block or constrain those authorizations on a case by case
basis.
Which means if I have a user that's trying to log in being
the weekend and that user is permitted to access during the weekend,
I can constrain those services.
I can also stop them.
Say if they're normally working from 8 to 5,
I can make sure that we not only monitor them but
that we can constrain their usage after 5 p.m. In sale,
say 730 ami can go through that process of visibility
by monitoring the users and what they have access to.
I can also do threat protection.
This allows us to detect and potentially block
malware or insider threats from compromised accounts.
We want to use this feature for intrusive detection
and protection of the system of your cloud services.
We want to do is data security.
Data security identifies whether it is a regulated environment or whether
it's not regulated and it identifies the protection mechanisms within our
cloud environment to ensure that customer
information or future product releases are constrained
and that intellectual property is actually secure
going through that data security prospect.
Think of the same way you would secure data on a regular server.
We want to encrypt it and we want to make sure that
users are only authorized to access
that information if they're actually authorized
with a compliance.
We want to make sure that our cloud infrastructure
is regulated to conform to our regulated requirements,
whether it's HPA
or Fer
or even GDPR.
We want to make sure that we're maintaining that
aspect of security and compliance infrastructure within our.
We ought to remember to do it on our on premise environment,
but we ought to forget it in our cloud environment.
You have to remember that both are the same side of
the same coin and that we have to provide the client
infrastructure regardless of where the data is based or regardless of
whether it's in a virtual environment or an on prem environment.
Throughout this episode, we've identified identity and access management.
IAM, we've talked about Multifactor authentication in detail,
some SSO and federation.
When it comes to sign on processes,
we've also identified uh privileged access management,
passwordless authentication.
And of course,
cloud access security broker,
we defined how these different tools and different
technologies allow us to secure our different environments,
whether it's an on prem environment or in
a cloud environment and ensure that security curtails right
at the beginning or the forefront of what
we're trying to establish within our enterprise environment.