In this lesson, we're here to discuss
some of the various security principles
that are crucial to securing our networks and systems.
The first foundational security principle
we need to discuss is least privilege.
Now, the principle
of least privilege is pretty straightforward.
It states that whenever the user's performing a job function
or an administrative task, they should do that while using
the lowest level of permissions or privileges needed
in order for them to complete their job.
So as a network or system administrator,
if you're going to be able to do a function
as a regular user, then you should.
Now, if you need to do something as an administrator,
then you need to log in as an administrator.
Whenever I log into my computer to check my email,
for example, I'm going to do that using my user account,
which has no administrative permissions.
But if I need to install a piece of software
or change some kind of configuration setting,
then I'm going to log in as the root
or administrative user so that I have all the accesses
and permissions that I need to make those changes.
This principle of least privilege extends
past the different types of accounts we use
with our given users.
It also applies to things like designing our systems
and networks, because we need to design them
with the concept of least privilege in mind as well.
For example, if you're installing
some new Internet of things devices like LED lights
that are going to connect to your network
and allow them to be remotely controlled through automation,
you also need to make sure you're using
the principle of least privilege here as well.
Should these IoT devices have access
to every system or service on your network?
Of course not.
Instead, these devices likely only need to have
one or two ports open, that way they can communicate,
and they may need to have access to the internet
to receive firmware updates, and that's okay too.
But they shouldn't have access to any of your file servers,
your web servers, or your printers.
So using the principle of least privilege,
we could isolate these devices into their own screen subnet
or VLAN, and then we can tightly control access into
and out of that VLAN to ensure that only those users
and applications that have an absolute need to communicate
with these IoT devices can.
Now, the second foundational security principle
we need to cover is known as role-based access.
There are several methods of conducting access control
in a network such as DAC, MAC and RBAC.
DAC, or discretionary access control is
an access control method where access is determined
by the owner of that resource.
This is discretionary, so for every file
or folder on your shared drive, the owner
who created it will assign the permission levels
to other users on the system.
The owner is going to be the one who decides who can read,
write, and run these different types
of files on that file server.
Discretionary access control is commonly used
because you have very granular control to be able to decide
who has access to things that a user has created,
and because the person who created makes those decisions,
they are the most knowledgeable on this area.
There are two big challenges, though, when you use DAC.
The first is that every object
on the system has to have an owner,
because if there's no owner,
then nobody would know who has the right permissions to it
because the owner is the one who sets those permissions.
The second problem is that you need to make sure
that each owner determines the access rights
and permissions for each of those objects.
So if I'm the owner of a file
and I never set permissions on it,
this means that nobody's going to have access
to be able to read that file.
And if I set those permissions too tightly,
then I would be keeping people out
who may need to have access.
Or if I set them up too loosely, everyone can now access it
and read the contents of that file,
eliminating my confidentiality and security.
So the owner here really has a lot of control.
In corporate or enterprise systems,
this can be really dangerous,
and you have to think about it
if you really want to be using a discretionary model
or one of our other choices.
Now, our second model is what's known as MAC,
or mandatory access control.
MAC goes to the other extreme.
With MAC, or mandatory access control,
we have an access control policy
where the computer system gets to decide
who has access to what objects.
So how does the computer do this?
Well, with discretionary access control,
you the owner were able to choose who got permissions,
but in MAC, the computer's going to do that for you,
and it does this through data labels.
In MAC, data labels are going to create this trust level
for all subjects and all objects
so that every person out there gets a label
with their associated trust level.
If we have a high trust level, a medium trust level,
or a low trust level for them,
then each data object gets a label as well,
as either high, medium, or low trust,
and then we just compare the labels
to determine if somebody should be granted
or denied access to a particular object.
So how does this really work in the real world?
Well, the most common use
of mandatory access control is in the military,
and they'd use this with their high security systems.
So if you've ever seen a war movie at any time in your life,
you've probably seen the words top secret
on some kind of document.
Well, there's really four levels of documentation
inside the military content.
They have unclassified, confidential,
secret, and top secret levels.
Now, each person in the military is also assigned
a clearance level that tells them
what they're allowed to see.
So maybe the private only gets to see
confidential information,
but the colonel gets to see top secret information,
and the captain only gets to see
secret information, and so on.
Now, each person here has a label associated with them.
This is their clearance,
and this also gets associated with their account.
Now, all the documents are also going to be labeled
with whatever they're classified as,
so they're either unclassified, confidential,
secret, or top secret.
Now, when a person wants to read a document,
their label of their user account is going to be checked
against the documents label.
If your label is at or above the level
of that clearance document,
you're going to be able to read it.
If not, you're going to be denied access.
Now, this makes a lot of sense,
because if you have a top secret clearance,
you should be able to read top secret documents,
but you should also be able to read secret,
confidential, and unclassified documents,
because top secret is a higher level than these other three.
But if you have a confidential clearance,
you would be denied access to secret and top secret data,
because those are higher classifications
than the clearance you hold.
Now, in a MAC system, they're going to add another piece
of information though as well.
This is that if you want to access something,
you need to not just meet the minimum levels for it,
but you also need to have what's known as a need to know.
So for example, let's say we have two military members,
we have an Army person and a Navy person,
and they both have a top secret clearance.
Now, I have this particular document
that's about a Navy operation.
In this case, the Army guy doesn't need to know
about what's going on there,
because he's not in the Navy
and doesn't need to have access to this information.
He doesn't have a need to know.
So even though he has the clearance level of top secret,
he doesn't have a need to know,
and therefore he shouldn't have access.
Now with MAC, these labels can be very in-depth,
and they can get very, very complicated.
This is why MAC is not used in most enterprise networks,
and observed only for highly classified information
within military systems.
Now, the third type of access we have is known as RBAC,
or role-based access control.
Now, role-based access control is an access model
that's controlled by the system like MAC,
but instead of using labels, it's going to focus on a set
of permissions instead of an individual's permissions.
Now, we don't have to actually label
each individual person on every single file.
Instead, we're going to assign roles to these files,
and then we're going to assign roles to these people.
The way I like to think about this is that we create roles
for each job function, and then we assign roles
for each person's permissions to that particular object.
For example, let's say you go into your company,
and there's a sales department,
a human resource department, and an IT department.
Now we have these three departments sitting here.
Do the sales people need to have access
to the human resources people's files?
Probably not.
Now, does the human resource people need
to have access to the salespeople's files?
Probably not again, right?
Does the IT person need to have access to everybody's file?
Probably, if they're going to be doing all the data backups
and maintenance and things like that, right?
So essentially, what we're going to do is create
these different groups, and then these groups are going to get
a set of permissions, and those are going to be applied
to the different files and folders.
When we do this, we add or remove people into the roles
instead of onto those particular files.
By using role-based access controls,
we are going to be using a best practice
inside of the cybersecurity industry.
Now, if I have a file on the shared drive,
and you see that Jason was added to it individually,
you would flag this as a bad practice
because we're not using role-based access,
and instead we're using discretionary access control.
Now, in role-based access control,
we're instead going to have an owner's group
instead of an individual person.
We're also going to have an admin group,
and we're going to have an IT group,
and we're going to a sales group, and we're going to put
all the people who have the same type of job
and the same functions into the same type of group.
This makes it much easier to control our permissions
based around the concept of least privilege,
because we're relating it to the permissions required
to actually do your job.
Always ask yourself, what is the role of the person
that is going to be using this file?
Based on that, assign them to the right group
with the right permissions
that are going to do that thing using those job functions.
Let me give you a great example of this.
There's a role-based group called power users
inside of a Windows system.
Now, power users are people who aren't a normal user,
but they're also not a normal administrator either.
They're somewhere in the middle, for example,
an administrator might have full access
to do whatever they want on a system,
whereas a user might only be able to operate the programs
that currently exist,
but they can't make configuration changes
like changing the time or adding a printer.
Well, a power user has a little bit more permissions
than a regular user,
and they could do things like changing the time
or adding a printer to the network,
but they don't have full administrative rights
like an administrator would.
So we could put different users into that power users group,
and they'll be able to inherit those permissions
and be able to do just those functions that are necessary
to add things like printers
or make minor system changes like the time.