Let's take a look at logical access controls as part of the Access
Controls Concepts for the Certified in Cybersecurity course.
We looked at the concepts and theory behind access control at the beginning,
what we're trying to do with least privilege and need to know,
and to make sure that only authorized users can perform authorized functions.
We then implemented a lot of these access control concepts in a
physical environment using physical access controls,
but now let's look at how we implement them through logical access controls.
Logical are often known as technical access controls.
These are access controls that we implement or build into our various systems,
networks, applications using some type of technology.
We're all very familiar with these, we encounter them everyday.
A password, for example,
that I have to enter to get onto a system is a type
of a technical access control.
We also have controls that determine whether or not I can even get on a
network through things like a network access controller,
and when I want to connect to a wireless,
sure there are some wirelesses that are completely open,
you can just log in without any type of a password or ID,
but many other times that wireless requires us to know the correct key
to be able to log on to that wireless access point.
That's a type of logical access control that determines
whether or not I'm allowed to use that service.
A very good example is a firewall.
We put a firewall on our network to protect network
traffic from one network to another, and that firewall is an access control,
you could call it a gateway.
It can control what traffic is allowed through and prohibit
other types of unwanted or undesirable traffic.
So what I'm going to put in some type of an access control.
I need to have a justification for what rules I'll put in place,
and this often comes down to what we'll call logical access theory.
Theory is based on two primary types of access control,
discretionary access control or mandatory access control.
So when I put a firewall in, for example,
I'm very often putting in a type of discretionary access control.
It's by far the most common type of access control methodology
or theory we are using and what this allows us to do is set the
rules or permissions by the owner.
The owner can say what traffic should be allowed and what shouldn't.
And let's say, for example, if I have access,
I could even grant that access to somebody else,
I can delegate that access.
So discretionary is used in a lot of our systems to enforce
access control rules according to the decision made by or at
the discretion of the owner, and we have this,
so we're all familiar with this.
We can put, for example,
a password on our computer system, and you could share your password,
though, I don't recommend it, with somebody else.
You could grant somebody else access to your system as long as you
have administrator or owner‑level privileges.
And the idea, of course,
with this is that it's a common yet very practical and
usable form of access control, but we have something else
and that is mandatory access control.
This was defined already back in the 1970s,
especially for high security, such as military types of systems.
It's very expensive to implement and maintain,
and it requires a few things that were not required by discretionary.
Discretionary access control could have labels and separation of duties,
but it was not mandated or not required.
However, in a mandatory access control world, it is.
So we have a number of access control models that
are based on this ACF2 top secret, for example,
and these types of implementations are then used to ensure that
access is only granted as mandated by the policy,
even the owner cannot circumvent the policy that says no
such people should not have access.
So that's why, in fact,
it was originally called mandatory access control
because it was mandated by policy.
So in this case, access would only be granted if the owner said yes,
you can have access and that was in compliance or in
agreement with the policy as well.
When I'm granted access according to a mandatory access control world,
I cannot delegate or grant that access to somebody else.
So those were the two theories,
but we are now going to implement access control through a
number of different common methods. For example,
rule‑based access control, role‑based access control,
attribute‑based access control,
and temporal access control are implementations of the
theories of either discretionary or mandatory,
and each of these implementations, such as role‑based is a good example.
Role‑based was originally mandatory, but for most cases today,
it's discretionary.
So what it is,
it's a way to implement according to either discretionary or mandatory world.
The implementation can be of either theoretical model.
Let's look at what role‑based access control does.
We look at individuals and what that individual's job
responsibilities and job position are.
What we do then is we create a job role so that everybody that
has that same type of job fits into that role or that category
and all get the same access.
It's a cost‑effective way to implement the ideas of such need to know.
If you don't need to see it, you can't see it,
it's not part of the permissions granted to your role,
for example.
One of the advantages of a role‑based, or RBAC,
system is that it works really well in a large enterprise
where you've got a lot of business units,
you have a lot of people with similar job responsibilities,
and if you have a lot of turnover, say in a call center.
All I have to do to grant a person access is make them a member of that role
and they then inherit all of the access granted to that role.
When a person leaves,
I just remove them from that role and all of their access is taken away.
So this is something we see very commonly implemented,
but like with anything else, it requires careful management and keep it correct,
for example.
The next one is rule‑based access control.
This is where we have a set of rules, for example,
a person is standing at the doorway to a large event,
and if I want to get into that large event,
I need to have then my name on the list.
There is a list of rules that says who's allowed and
nobody else would be allowed in.
So we could say, in this case,
what we've implemented is a way to ensure that we have a
whitelist or we could say here a list that shows what is
permitted and everything else is excluded.
The other, of course, could be the opposite.
We have a person that stands at the door and watches
people come in and everybody can go in,
except a person whose name is on that list.
We've seen this, for example,
in a casino where certain people are prohibited from entering that casino,
and if they showed up at the door, the guard would say no sorry,
your name is on my blacklist here, you're not permitted to enter.
So the list can be either whitelisting, what's allowed,
or blacklisting, what's not allowed, and the idea,
of course, with the rule‑based is I can be very granular or very specific.
I can say exactly to a low level what should be allowed or what should not
be allowed or else I could even do it at a higher level.
You take, for example, a firewall.
A firewall can have a rule that says you can not go to this site and that
applies to everybody or it could have a situation that says yes,
these people are allowed certain things,
but others aren't.
So rules can be adjusted according to what is,
should we say, best for the interests of the organization,
and we put in a lot of rule‑based access controls,
but if I have thousands of users and I have to set
up different rules for each one,
that can be an awful lot of an administrative nightmare as well.
The next is ABAC, attribute‑based access control.
What this does is it adds another layer of access control.
We show a person using a proximity card to try to get into a room,
and that proximity card is based on certain rules that say whether
or not that person is allowed to enter or not,
but we could add in a second rule and that is yes,
you're allowed to enter,
but only at this time of day. If you try to get into
that room at 2:00 in the morning, you would not be allowed to,
so that is where we're adding a further condition.
You're allowed to enter, but only under these attributes or conditions.
This allows a lot of flexibility.
We can turn around and grant a person access,
but only under certain circumstances and restricted at other times,
it's not just an either/or decision.
The decision is quite often based on maybe the
clearance or attribute of the subject.
Do you have secret clearance and then you might be able to see this or maybe
you have to have top secret clearance in order to see this.
So it looks at the attribute of the subject,
but it also looks at the attribute of the object.
What is the classification of the object?
Is this a secret document?
A top secret document?
A public document?
And so, a person's clearance, if they only have secret,
would then not allow them access to an application or an
object which was classified as top secret,
so we look at those attributes in order to manage those access permissions.
As we said,
we could also base it on things like environment and things like time so that a
person can only access the system if they are in the office,
they can't access it remotely.
Sensitive data could only be accessed under certain conditions.
So this sets up those formal relationships or rules that allow our
access permissions to be even more exact and precise.