Let's take a look at Access Controls Concepts,
the terminology and how we look at access and define access controls.
Access is based on a relationship.
We have an entity,
we could call it a subject which could be a person or even a process,
and we have an object,
the entity that is attempting to be reached, or we could say this very often,
it could be something like a file, a database,
a system, a network, a building, memory.
All of these are objects that some subject for some
reason wants to be able to access.
So we have to set aside what are the rules we would use to allow that access.
We put in some type of mediation device to determine whether or
not that access is appropriate and should be allowed, should that
person be allowed in this building, for example.
The determination of whether or not the person should be granted access is
really the determination and decision of the asset owner,
the person who owns the system, the application,
the network or the building, whatever the object is.
The asset owner determines the access rules.
We could put these in, for example, an access control list,
a list that says what access should be granted to various
subjects or entities requiring or requesting access.
The mediation device will then refer to those rules to determine
whether or not those subjects should be allowed that access and
enforce the decision of the asset owner.
It would also log that event,
so we have a record of who requested access and whether or
not that access was granted and perhaps what the person
even did once they had access.
So the key concepts looking at access control start with separation of duties.
We want a person to be able to execute various tasks,
but we also want to prevent problems like fraud,
for example, or mistakes.
So very often,
we'll have a series of different steps for this transaction to go through and
each of those steps should be executed by a different person.
For example, a person can submit an expense form.
Hey, I incurred this expense on behalf of the organization.
They submit that, but somebody else has to approve it,
that's separation of duties,
and separation of duties allows us to try to catch any
mistakes that could have been made.
Least privilege is an important concept.
That says we'll only give a person the level of access
they need in order to do their job.
We won't grant them a high level of access when really all they
needed to be able to do was read the information,
not modify it, create, or delete it.
We also have a similar concept very much related to least privilege,
but not the same, known as need to know.
Need to know says will we even let a person be aware
of a certain piece of information?
We could hide, for example, a credit card number.
We see this all the time.
We'll only show the last four digits,
the least significant part of the credit card number because the average person
doesn't need to see what the entire credit card number is.
And by hiding that credit card number,
that means that person who can't see it could not
misuse that information either.
So when we look at access control,
these are three core concepts we want to review.
In the case of separation of duties, also known as segregation of duties,
we can enforce this through things like mutual exclusivity.
Going back to our example of submitting an expense form. If
you submit the expense form, you can't approve it,
but you may have the right to approve expenses for somebody else,
but not for your own.
Those two tasks of submission and approval are mutually exclusive,
or we often call it mutex.
We also have the idea of dual control.
It takes two people to perform a certain task.
Maybe the safe in the bank has two combination locks.
Some people know the top combination, other people know the bottom,
and both of them have to work in order for that safe to be opened.
We set up roles.
One person has this role and they can do certain tasks,
but somebody else is the one who then would do the subsequent task.
Nobody controls the entire process.
The problem is if people work together.
This is something we would call collusion.
Even though we had separation of duties,
the person who has approved the expenses colluded with the
person submitting the expenses and allowed a fraudulent
expense form to go through.
One of the ways we can break that up is something we call job rotation.
That means that when I submit expenses,
I don't necessarily know who will be the person approving them today.
That could be somebody different at different times,
so that tries to break up that collusion that could otherwise happen.
We also see this very much in the financial sector.
If I'm a loans officer at a bank or a manager of a branch,
I'm required in many countries to take what's called a mandatory vacation.
For several weeks every year, I must go on vacation,
and during that time period,
I'm not able to access anything at that bank either
electronically or physically, except my own account.
So somebody else will handle my work for those two weeks and maybe they will
find if there is something that was fraudulent in my activity.
This all starts with identification,
identifying the entities that are trying to get access
to that system, network, or building,
and we say that people should have a unique identifier.
We shouldn't all be using the account called administrator, for example.
And very often, we use unique identifiers such as an account number,
an employee number, a customer number, some type of government issued identifier,
a passport number for example,
or an email address is used by many systems today because
these are all unique to an individual,
whereas something like a name is often not unique.
There could be a number of people that actually have the same name.
Another thing we often do is we use things then like a user identifier or we
call it a user ID or a process ID as a unique identifier for,
for example,
a person trying to do something or a process that
is trying to write to a system.
The idea of proofing or validating that you are the
rightful owner of that identity is important.
Maybe this is through a secret question.
We've seen this very often with things like a password
or what's your mother's maiden name.
Those are what we often call cognitive or knowledge‑based passwords.
The challenge, of course, is when a person forgets their
password and it needs to be reset.
We want to make sure that we only reset it for the
correct owner of that identity.
A person sometimes is able to modify their permissions.
They're able to ask for something and the system will automatically say yes.
You should be entitled to have that.
But before I give it to you, please enter in your password.
You see this quite often on a computer system.
You try to download some new software,
it comes back and says you're trying to change the configuration of the system,
I need you to enter in an administrator‑level password in order to do that.
They prove that you are the rightful person to be able to make that change.
Identification should be, as we said, unique.
Why?
So that we know who did something.
It's not that one person of a group, but we have accountability.
It should not be shared,
especially with high level types of identifiers, but we should
ensure that we have a secure registration process.
Not just anybody should be able to create a high‑level
account or a privileged account on our system.
This is where you've often seen when you go to a website,
you have this CAPTCHA or you have some type of other way to
recognize that you're not some type of a robot or some type of a
script that's running to try to create accounts.
Very often if I want to have an employee account or even a privileged account,
it must be approved by a manager who says yes,
this person should have that access.