A vulnerability is a weakness in a particular system.
This could be an operating system, and application,
or any other type of system.
You can think of a vulnerability as your system
having an open window.
If someone wanted to crawl through the window,
they would have access to your system.
Many times, these vulnerabilities
are either never discovered or discovered many years
after the release of a particular piece of software.
That's because these vulnerabilities
can show themselves in many different ways.
For example, you might have a data injection vulnerability.
Maybe the authentication process to log into the operating
system is flawed and someone can circumvent the existing
username and password.
Perhaps, there's an easy way to gain access to data
that was not originally known.
Or perhaps, the security of the system is simply misconfigured,
and you're allowing guests to have full access rather than
no access.
This means that the operating systems and applications
that we use every day might have a vulnerability inside of them,
but we just haven't found it yet.
But researchers know that if they
can find one of those vulnerabilities,
they can provide that to the manufacturer.
And then they can close these particular vulnerabilities
before they become a problem.
The attackers, however, would like
to find these vulnerabilities so that they can, then,
take advantage of those vulnerabilities and gain access
to data or information that normally they
would not have access to.
If an attacker does find a vulnerability
and starts taking advantage of that previously unknown access
to our systems, we refer to this as a zero-day attack.
This means that we've never had notice
that this particular vulnerability existed.
It's never been reported.
It's never been identified before.
But suddenly, people are gaining access to our systems,
and we don't have any way to immediately patch it.
Although most of these zero day-attacks
are patched very quickly, there may also be workarounds or ways
to mitigate against these types of problems.
Details on the attack types can usually be found in the CVE.
This is the Common Vulnerabilities and Exposures
database.
You can find a list of these CVEs at cve.mitre.org.
By themselves, a vulnerability isn't something to worry about.
It's only once somebody exploits that vulnerability
that it becomes an issue.
And the thing or person that is taking
advantage of that vulnerability is a threat.
These threats may be intentional,
like an attacker trying to find a vulnerability in an operating
system.
Or a threat could be something accidental.
You could have a fire or a flood in your data center.
When we think about threats to a vulnerability,
we're usually thinking about someone
who is a third party to the organization trying
to gain access to our own private information.
So we could have a server or device
that might have a vulnerability inside of it.
And the person who's trying to exploit that vulnerability
is a threat agent.
You'll sometimes see the terms threat agents taking a threat
action to be able to take advantage
of that vulnerability.
Whether this is an accidental threat
or an intentional threat, the result
is always a lack of security.
Our systems might become unavailable,
or an attacker might gain access to our private data.
One very common threat in our organizations
are the threats on the inside.
These insider threats are the people that currently
work in our organization.
And that's why zero trust and things like least privilege
become very important.
And we'll talk about those concepts in this video.
Whenever you walk into a building as an employee,
you, naturally, have more access to systems
than if you are someone who's on the outside.
And you'll find that many organizations will
have specific processes and procedures in order
to keep their data safe.
If you have someone on the inside,
though, that has additional access to this data
and they take advantage of that access,
then you could have a harm to your reputation.
Because your security is not as strong as it could be.
Your systems might become unavailable.
Or information that you thought was secure and confidential
is now made available to the world.
One of the challenges for the security professional
is trying to keep track of where all these vulnerabilities might
be and how to protect against those vulnerabilities
when they're found.
One way to do this is by using central databases,
where we can consolidate all of those vulnerabilities
to one point.
One common database is the CVE, or Common Vulnerabilities
and Exposures database.
This is a constantly updated database
that's provided by the US Department of Homeland Security
and Cybersecurity and Infrastructure Security
Agency of the United States.
Another good database to choose from
is the NVD, or the US National Vulnerability Database.
This is a summary of those CVEs that's
also sponsored by DHS and CISA.
You'll find that the CVE list will give you
a broad overview of these vulnerabilities,
and then you can drill down into details from the NVD.
The NVD even provides a way to score
the severity of the particular vulnerabilities,
so you can identify if a vulnerability happens
to be a lower priority than something that's
much more critical.
This means if you're looking at a vulnerability
and it has the highest score of 10,
which is identified as a critical vulnerability
in the NVD database, then you might
want to address this particular problem as a higher priority.
Having a vulnerability on a system, by itself,
doesn't create any loss of data or outage
to a particular system.
It's only when someone takes advantage of that vulnerability
that those things occur.
We refer to that as an exploit.
Someone who takes control of a system or gains access to data
through the use of one of these vulnerabilities
is taking advantage of an exploit.
There are many different ways to exploit a vulnerability.
And in this series, we'll look at a number of these methods.
But regardless of the method that's used,
the ultimate result is the attacker gaining access
to your private resources.
We mentioned earlier that one way
to protect against insider threats
is through the use of least privilege.
This is a concept where we would define rights and permissions
for a user that are specific to their particular job role
and don't go outside the scope of what they
need to do on a daily basis.
This means that we need to configure every user's account
to have the least amount of privilege
to be able to perform their particular role.
This means that applications should only
run with the specific privileges required
to run that particular app and that users should only
have access to the data that they need
to perform their job function.
If you've ever walked into an organization and everybody
is running with administrative privileges,
then they're not taking advantage of least privilege.
You want to be able to limit someone's access
to the operating system and the data, which,
in turn, should limit the scope of a potential attack.
One way to provide this least privilege in an operating
system is through the use of role-based access control,
or RBAC.
This is usually associated with your particular job role.
So in your organization, you might
be a manager, a director, a vice president,
or you might be a project manager.
And we would assign particular rights and permissions
based on that role.
So if you are a manager, you have a certain level
of rights and permissions.
If you're a project manager, you'll
have a different set of rights and permissions.
In many operating systems, you can
provide this role-based access control
through the use of Groups.
For example, if you work in shipping and receiving,
we might add you to the shipping and receiving group.
This means that you would have rights
to be able to use the shipping software
and perform your daily job functions.
If you're the manager of the shipping and receiving team,
then we might put you in a manager's group, which
might give you access to review all of the logs
and create reports for all of your shipments.
This provides a clear separation because the people
doing the shipping and receiving wouldn't have access
to the reports.
You'd have to be a manager and someone in the manager's group
to be able to have that role-based access control.
In recent years, we've even improved
on this idea of access control to create zero trust.
In many organizations, you may find
that once you're on the inside of the network,
that there are very few security controls,
and you might have the ability to move
between many different systems that aren't necessarily
part of your job function.
With zero trust, we take a harsher approach
to security, where every single user has to be trusted
to gain access to a system.
This means that we would lock down
access for every user, every process, and every device,
so that only people that are verified
would have access to those resources.
This, effectively, means that on the network
no one is trusted until you provide
the proper authentication.
So you might go through multifactor authentication.
There might be encryption, additional system permissions
in an operating system, and anything else that can provide
additional security controls.
This also implies that we're going
to create reports and constantly monitor all of these systems
to ensure that our zero trust model is secure.