- Now, in this Lesson 19.5,
we're gonna focus in on access control and authorization.
Now, access control is a security process
that enables organizations to manage,
well, who's authorized to access data and resources
and what they're allowed to do.
Now, physical access control
focuses on facilities, equipment, devices, and paper,
where logical access control focuses on systems,
applications, and data.
Now, what's so interesting over the last couple of years
is that we've really seen an access control convergence,
a convergence of information security
and physical security controls,
because they really do have the same primary objective,
which is to protect organizational assets and personnel.
Now, often there's a a really significant overlap
in the technologies and in controls.
And an example would be an access card
that's used to both enter a building
and to log into the network.
So there's this emerging convergence model
that we talked about earlier on
when we talked about physical security
that really demands communication and coordination
between the two disciplines.
And in a best case scenario, the departments participate
in the same management and reporting structure.
So let's talk about rights and permissions.
You know, it's interesting.
So often, the terms rights and permissions
are are used interchangeably, but they're not the same.
So what is rights?
Well, rights are entitlements granted to users
that determine their level of control
and access within a system.
So for example, change system time, or create a user,
or to be able to install software.
Permissions are specific authorizations
and define what a user can do
with specific files, directories, or system resources.
So for example, read, write, delete, modify.
Those are all examples of permissions.
Now, two other concepts
that really relate to rights and permissions,
and we've talked about both these already,
so this should be a refresher,
is least privilege and authorization creep.
It's a reminder that least privilege,
the principle of least privilege
refers to assigning the minimal rights and permissions
needed to accomplish a task.
Why?
Because we really wanna have as small footprint as possible,
'cause we know that an exploit is going to execute
in the security context of the locally logged in user.
And then authorization creep is the accumulation
of access rights and permissions over time,
and we talked about that in an earlier lesson,
that as we move through an organization,
we might acquire new rights and permissions,
but we haven't been relieved
of our older rights and permissions.
And sometimes for very good reasons originally, right?
It might be because we're training our replacement
or we're covering both jobs for a while.
But it's important
that we are always looking at those change requests,
we audit those change requests,
and say, "Wait a minute.
They've moved on.
They no longer need those rights and permissions,"
so that we don't end up with authorization creep.
Another really important
access control principle or approach
is dual control and separation of duties.
Now, dual control requires more than one subject or key
to complete a specific task.
Here's an example.
Let's say in a bank, we wanna open the vault,
so we need two employees to come to the vault.
They each have a key.
Each put their key in and turn it, right?
They're doing the same thing, put a key in and turning it,
or maybe it's not a physical key,
maybe it's biometric or maybe they have to put in a code,
but they're doing the same thing, right?
We need two of them there, right?
In order to complete that specific task.
Well, separation of duties
implies breaking a task into separate processes,
so no one subject is in complete control
or has overriding decision making power.
And we talked about that one earlier,
but let me give you the example that we shared before.
We talked about what if my organization
paid vendors with wire transfers?
I wanted to make sure
that no one was being paid fraudulently.
Well, let's say I have user A
who can log into the payment program
and just set up the vendor.
That's all they can do.
User two, when they log in, they can't set up a new vendor.
All they can do is set up a payment for an existing vendor.
They can just set up the payment,
can't create one, can't authorize it.
User three logs in.
They can't create a new vendor, they can't set up a payment.
The only thing they can do
is authorize a payment to go out the door.
So we've separated that payment cycle into those three tasks
of creating the vendor, creating the payment,
and authorizing the payment
as those separate processes
so that no one subject is in complete control
or has overriding decision making power.
Now, authorization is the process
of granting subjects access to objects.
Subjects are active entities, right?
They're generally in the form of a person, like you and I,
processes or devices that cause information
to flow among objects or change the system state.
Objects are passive entities,
often referred to as a resource,
that contain or receive information or instructions.
Now, authorization can be static, meaning it's hard-coded,
or it can be dynamic,
meaning that it is influenced by situational factors.
There are six authorization models
you need to be familiar with,
mandatory, known as MAC, discretionary, known as DAC,
role-based, RBAC,
rule-based, attribute-based, ABAC, and risk-based.
So let's go through these.
In a mandatory access control model,
access is based on the relationship
between the subject's clearance and their need to know
and the object's classification.
So way back when, when we were talking about classification,
we said that we classify
either by criticality or by sensitivity
and that we assign clearance levels to our subjects, right?
That's a level of trust.
So the relationship is based on the subject's clearance
plus need to know and the object's classification level.
So let's say someone has a secret clearance.
That means that they could access secret data,
but not everything that's marked secret, right?
They also have to have a bonafide need to know.
And DAC is the polar opposite of MAC.
In DAC environment or a discretionary environment,
access is determined by the data owner.
So the data owner gets to say
who can have rights, who can have permissions.
Totally on the data owner.
In role-based or RBAC,
access is based on the subject's assigned roles.
So subjects are put into roles and roles are given access.
And sometimes RBAC is referred to as non-discretionary.
Why non-discretionary?
Well, because what happens
is that the owner of the data or the system can say,
"Okay, these roles can access my system or my data,
but they don't have any say over who gets put in the roles."
So they can say,
"Yes, these roles can have these rights and permissions,
but they don't get to say who is in the roles themselves."
So based on the subject's assigned roles.
Then rule-based is based on compliance
with an established set of rules.
Generally rules don't care who the subject is.
They're just a whole set of rules,
and the best example would be a firewall, right?
So firewall rules are based on source IP
and destination IP and protocol
to have to comply with those rules.
And we come to one that you might be less familiar with,
which is a really interesting and emerging one
called attribute-based access control, or ABAC.
In ABAC, access is determined
by a combination of attributes,
subject attributes, object attributes,
rules, and environmental conditions,
and we're gonna dig right into that one in just a sec.
And then lastly, we have risk-based,
which is another emerging authorization model,
and that's influenced by dynamic factors
and contextual data analytics.
And we're gonna look a little bit closer
at that one as well.
So MAC, DAC, RBAC, rule-based, ABAC, and risk-based.
Make sure that you can identify
all of these authorization models.
Now, ABAC stands for attribute-based access control.
It's a logical access control model
that controls access to objects by evaluating rules
against the attributes of the subject and the object
as well as operations and the environment.
Now, ABAC supports very complex Boolean rule sets
that can evaluate just tons of different attributes,
and the policies that can be implemented in an ABAC model
are limited only by the degree imposed
by the computational language that you're using
and the available attributes themselves.
Now, an example of an access control framework
that is consistent with ABAC
is Extensible Access Control Markup Language.
There's that word extensible, right?
Remember the extensible said that we can modify,
we can freely modify something,
but without changing sort of the the underlying basis,
and I said that often when you see the word extensible,
it will be abbreviated with an X, so XACML.
So here's an illustration of ABAC.
This illustration actually comes from a NIST,
National Institute of Standards and Technology publication.
It's NIST SP 800-162, all about ABAC.
So if you wanna learn more about ABAC,
would be a great resource for you.
But we've got our subject
and our subject requests access to the object,
and so the access control mechanism says,
"Okay, well let's look at the subject attributes,
let's look at the object attributes,
let's look at the environmental conditions
and any other rules in order to compute a decision."
And if everything is good,
they're allowed to access that object,
and if not, well, they won't be allowed to.
But I think this is a really nice visual on how ABAC works,
and again, I would encourage you to go out
and look at the NIST publication
if you wanna learn more about ABAC.
So next I wanna share with you some risk triggers,
and these are actually risk triggers
that are from the Microsoft Cloud environment.
Now, often, risk triggers are layered
with another type of authorization model.
So let's look at four risk triggers.
Anonymous IP address, unfamiliar sign-in properties,
atypical travel, and impossible travel.
Anonymous IP address indicates a sign-in
from an anonymous IP address, just like it sounds.
Now that might be fine, but that might be suspicious, right?
Why would you be coming in from an anonymous IP address?
Again, it might be a legitimate reason,
but worth exploring to get more information there.
Unfamiliar sign-in properties consider past sign-in history
to identify non-familiar properties.
Now, examples of properties
would be your operating system or your browser level.
Now, atypical travel identifies two sign-ins
originating from geographically distant locations
where at least one of the locations is atypical,
given past behavior.
So if you normally sign in from San Francisco,
and the next day, you're signing in from New York,
well, that's atypical, right?
You're usually in San Francisco.
Now, could it be perfectly legitimate?
Sure, you might be coming through a VPN,
but you know, they're too geographically distant locations
where at least one of those is atypical.
And then we get impossible travel.
Impossible travel identifies two user activities
originating from geographically distant locations
within a timeframe shorter than it would take
to travel between the locations.
So at noon, right?
If I logged in from London, England,
and you know, 10 minutes later,
I'm logging in from Sydney, Australia,
it's like, well, I can't get from London to Sydney
in 10 minutes, right?
No matter how much I might want to, I can't do that.
That's impossible travel.
So again, that's going to be a risk-based trigger
to say we need to get more information.
And could it be legit?
Sure, it could once again be maybe a VPN, right?
So we're showing those different IP addresses
when in fact maybe I haven't moved at all.
So it's not necessarily
that it's always going to be wrong or always a stopper,
but it is a trigger to get additional information.
And that, my friends, brings us to a three-second challenge.
Five challenge questions, three seconds each.
You know how to do it.
Accumulation of access rights,
permissions, and privileges over time.
One, two, three.
That's authorization creep.
Number two, requiring more than one subject or key
to complete a specific task.
One, two, three.
That's dual control.
That was the example I gave you of the two bank employees
going to open up the vault.
Number three, a minimum set of permissions
needed to perform a task.
One, two, three.
And that's gonna be least privilege.
Number four,
access is based on the subject's assigned roles.
This is an easy one.
One, two, three.
Well, that must be role-based access control or RBAC.
And lastly number five,
breaking a task into separate processes
so no one subject is in complete control.
That's the example I gave you about paying our vendors.
One, two, three.
And that's separation of duties.
Well, that brings us to a security in action.
This one's about fraudulent activity and access controls.
The accounting department wires funds
to suppliers all around the world,
and it's critical that only authorized personnel
have the authority to initiate and release a transfer.
Now, several controls were put in place
for the online wire transfer application,
including IP address restrictions
and biometric authentication.
But much to everybody's surprise, during a financial audit,
it was discovered that the CFO, the chief financial officer,
had been making fraudulent wire transfers.
So what access controls
would have reduced the opportunity for fraud?
I know you know this answer right away,
but go ahead and put me on pause, jot down some notes,
and come back, and we'll talk about access controls.
Well, access controls that could be considered
include dual control and separation of duties.
Now, implementing dual control
would require two or more employees to collude, right?
So you'd need two employees to do the same task,
and they would have to collude,
which would significantly reduce
the probability of fraudulent actions.
Implementing separation of duties would break the task down
into distinct processes
so that no one subject is in complete control
or has overriding decision making power.
So those would really be your options,
dual control or separation of duties.
Now in this situation, for sure, separation of duties
would be more operationally efficient, right?
Dual control for major activities like this
doesn't usually make sense,
because then I have to have two employees
who are effectively sitting together side by side,
doing the same job, right?
But by breaking the task into separate processes,
and I can separate them out,
two people, three people, four people, five people,
as many people as I need.
Much more operationally efficient,
and the more people I have,
the more I have reduced the probability
of collusion and fraud.
So in this case,
I would probably go with separation of duties,
but thinking through these options
and then be able to help implement them,
that's security in action.
Wow, another big word cloud.
Again, make sure that you understand all these terms
and that you can speak to all of them, right?
'Cause they're all fair game for the exam.
So do that before you move on,
and once you're comfortable and confident,
move on to the next lesson, and I'll see you there.