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've 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 a device.
Beyond these simple IAM topics, there are a lot more complex enterprise considerations like privileged
access management or Pam and Cloud Access Security Brokers, or Casbs and 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 slides into the identification model of access control.
We also want to authenticate that just because someone says they are someone else doesn't necessarily
mean that they are who they say 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 are now authorizing them to use different 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 this comes into confines of access security management or identity and access management.
Within IAM.
Multi-factor authentication is the designed around the idea that having a simple username and password
is just not enough to gain access into our system by using MFA or two factor authentication.
Toofar, 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 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 dog, one, two, three, 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.
For 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 gain an entry into our systems.
This is where multi-factor authentication authentication comes into play.
When you 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 SMS text.
This could be a token that you utilize.
It can 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 biometrics, a fingerprint, iris scan, maybe facial recognition some where 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 stipulates 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, lowercase letters, and you get the gamut, 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 different systems or capabilities within the enterprise
environment.
You can access SharePoint.
You have access to different operations or departments that you would normally come into contact with.
This 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 re 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 sign on within a federated
sign on.
I can use, like my Google password or Facebook to access different websites or applications across
different organizations.
Single sign on is specific to the organization in which you work for Federated Sinai would be utilizing,
like Google to access different websites or something like Amazon passwords to access maybe your Facebook
account along with your LinkedIn account versus your email.
All of this is cross-organisational within a federated sign on atmosphere.
Privileged 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 permissions.
This would 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 be able to change the configurations, but providing minimal accounts to minimal unique users,
then 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 malicious to gain access by malicious users.
By having minimal accounts.
I'm shortcoming or preventing access to malicious 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 change configuration files inside of a
server, but only a subset of servers.
However, he wants to access the change in configuration for a top level server.
If I wanted 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 he 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 multi-factor 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 the malicious actor gets Ahold of it,
they can really cause some havoc within our eternal system by implementing a multi-factor 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 Aim.
We're going to authenticate utilizing different aspects like biometric authentication or security token.
So we're 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 into 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 use the username and password.
However, if you log in with the username and password, it smses you a link, which you then click
on.
That click link that you clicked on is now something you have.
You at least sent you the link via phone.
You then log in via a second authentication methodology like biometrics.
So in complexity, what we've really done is we've said you have to know your username and 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 out-of-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 SMS text messages to your mobile device.
We've 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 of our users.
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 isn't 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:00 pm and still say 7:30 a.m..
I 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 a malware or insider threats from compromised accounts.
We want to use this feature for intrusion detection and protection of the system of your cloud services.
We want to use data security.
Data security identifies whether the regulated environment or whether it's not regulated, and it identifies
different 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 truly authorized within compliance.
We want to make sure that our cloud infrastructure is regulated to conform to our regulated requirements,
whether it's PCI, DSS, or HIPAA or FERPA or even GDPR.
We want to make sure that we're maintaining that aspect of security and compliance infrastructure within
our cloud environment.
We often remember to do it on our on premise environment, but we often forget it in our cloud environment.
You have to remember that both are on the same side of the same coin, and that we have to provide that
compliant infrastructure regardless of where the data is being stored, 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 SSL and federation when it comes to sign
on processes.
We've also identified 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.