- In this lesson, 16.2, we're gonna be looking
at vulnerability response and remediation,
starting out with,
how do we find those vulnerabilities in our environment?
Well, generally, vulnerabilities are identified
through vulnerability scanning.
Vulnerability scanning is an automated activity
that relies on a database of known vulnerabilities,
such as the CVE and the NVD,
the National Vulnerability Database,
designed to identify vulnerabilities
in the target environment.
Now, when you do vulnerability scanning,
they can be internal or external facing
and they can be credentialed or non-credentialed.
What does that mean?
So internal means that we do it inside our network.
External facing means we do it
from outside of our network looking in.
And then, credentialed or non-credentialed
is really are we logging in or not?
So usually there are a couple
of different ways to approach this, right?
We could do it non-credentialed.
Now why would you do a non-credentialed
to run a scan in your network?
Because that would tell you what somebody
who didn't have access to authenticate
to your network would see.
You might want to do a credentialed
as an ordinary user or standard user that would say,
"Okay, someone who just has sort
of standard permissions and rights, what would they see?"
And then, as an administrator, or a superuser,
or root user, if you run it,
then you really, really get to dive deep
and get all of the details.
So credentialed or non-credentialed,
or at various levels of credentialed,
internal or external facing.
Now that's what we do on our network,
but we can really apply the same idea
to our web applications.
So web application vulnerability scanners
are specialized automated tools
used to identify vulnerabilities in websites
and in other web-based applications.
Now web application scanners
are gonna look for common types of flaws,
such as cross-site scripting,
SQL injection, command injection,
and directory path traversal.
Now this category of tools is frequently referred
to as our Dynamic Application Security Testing, or DAST.
To learn more about web app vulnerability scanning,
I suggest that you go out to owasp.org.
Now OWASP is a nonprofit organization of developers,
and coders, and webmasters who really care
about web and mobile security.
And there's a host of great information there,
including learning about vulnerability scanning tools.
So you can go out to owasp.org, owasp.org.
You can just search at that point
for vulnerability scanning tools,
or you can follow the link that you see on the screen.
Your vulnerability scanners and your web app scanners
are going to make decisions about what's normal or abnormal,
what's expected or not expected.
And their decisions are really gonna fall
into one of four buckets,
true positive, false positive,
true negative, or false negative,
just like when we talked about devices.
So as a refresher, a true positive is when normal
or expected activity is correctly identified, that's good.
A false positive is when normal or expected activity
is incorrectly identified as abnormal or unexpected.
Now that's problematic, where everything's fine,
but the system comes back and says,
"No, you're missing that patch,"
or "there's abnormal activity,"
and now you have to spend time researching something
that's really not a problem at all.
So everything's okay, but there's time and effort
involved in troubleshooting and resolving that issue,
so it's problematic.
A true negative where abnormal or unexpected activity
is correctly identified.
That's very good.
And a false negative is when abnormal or unexpected activity
is incorrectly identified as normal or expected.
So that's when there's something wrong,
there's something missing.
You know, there's something going on there,
but the system's coming back and saying,
"Nope, everything's cool."
That's dangerous.
So true positive, good.
False positive, problematic.
True negative, good.
And a false negative, very, very dangerous.
Now in addition to just doing plain old
vulnerability scanning,
we may also do assessments.
And in those assessments
we will be looking for vulnerabilities.
There are three primary types of assessments,
system configuration assessments,
vulnerability assessments, and penetration testing,
all of these actually incorporate vulnerability scanning.
Now the objective of a system configuration assessment
is to identify issues related to security configurations,
baseline variations, compliance, and nonconformance
with industry standards and recommendations.
So very often here we're looking for exposures, right?
And the goal is to find them and report them out.
A vulnerability assessment is used to identify
host attributes and common vulnerabilities and exposures.
Again, find and report.
And the objective of a penetration test
is to evaluate the security of a target
by identifying and providing either proof of concept
of the flaws and vulnerabilities
or by performing compromise exploitation.
And later on, we'll have a whole lesson, actually two,
on penetration testing.
But the goal here is find,
exploit, and report.
Now vulnerability analysis focuses on analyzing the results
of our vulnerability scans, our vulnerability assessments,
and the curated threat intelligence
to assess the risks associated
with identified vulnerabilities.
Now the process includes determining the potential impact,
the likelihood of exploitation,
and the overall risk posed by each vulnerability.
'Cause a vulnerability, remember, is a weakness,
but not all weaknesses are equal
and won't all have the same impact in your organization.
So vulnerability severity levels are used to classify
and prioritize vulnerabilities
based on their potential impact and risk.
Now vulnerability analysis helps
us to prioritize our remediation efforts based on severity
and the criticality of the vulnerabilities.
Now, generally, we put vulnerabilities
into three severity levels, critical high severity,
medium severity, and low severity.
So how do we define those?
Well, high severity vulnerabilities
have the potential to create significant harm or damage.
Now high severity vulnerabilities
generally require immediate attention
and remediation to prevent exploitation
and minimize potential impact.
Medium severity vulnerabilities
could result in adverse consequence.
Now remediation of medium severity vulnerabilities
should be prioritized
based on the potential impact to the organization.
And then, lastly, we have low severity vulnerabilities.
Now low severity vulnerabilities may have limited impact
or maybe they're just harder to exploit.
Low severity vulnerabilities should be remediated
as part of your ongoing vulnerability management efforts.
So critical or high, let's get on them right away.
Medium, we're gonna prioritize 'em based on impact.
Low, as we go through our vulnerability management program
we will be addressing them.
Now one of the primary ways
we address a vulnerability is by patching.
Patch management is the process of identifying,
acquiring, installing, and verifying patches,
also referred to as updates.
Security patches are designed
to correct security vulnerabilities.
And timely deployment of a security patch
reduces the likelihood of exploitation.
Now the time from when an exploit first becomes active
to when the number of vulnerable systems,
because they've been patched,
shrink to an insignificant number
is known as the Window of Vulnerability.
But you can bet during that window
our adversaries are looking hard for those systems
to exploit any of them that have not been patched.
So we wanna get on patching just as soon as we can.
Now there are different classifications of patching.
Again, not all patches are equal.
We have critical updates, definition updates,
driver updates, feature packs, security updates,
service packs, update rollups and updates.
A critical update provides fixes that target
critical non-security related.
A definition update provides updates
to viruses and definition files.
A driver update provides software components
that control or regulate a device.
Feature packs provide new product or functionality
for the next product release.
Our security updates provide a fix
for product-specific, security-related vulnerabilities.
Now that will be by classification,
so in inside security updates
you will see that critical,
you know, high, medium, low severity.
But I just don't want you to confuse
that between our critical update and our security update.
A critical update, generally that term when you see it used,
is providing a fix for a critical non-security.
But inside security updates,
you may once again see the term critical,
because that's how the security updates
are being classified.
And then, we have service packs,
provides a cumulative set of security updates,
hot fixes, critical updates, and design change features.
Update rollups provide a cumulative set of security updates,
critical updates, and hot fixes,
and other updates in one package.
And, lastly, updates, which seems to be a term
we keep using over and over again,
provides fixes that address non-critical,
non-security related bugs.
So lots of different patch or update classifications.
There are several challenges
inherent in the patch management process.
Maybe for some reason you can't get a patch
installed right away.
Maybe you haven't reached a maintenance window yet.
Maybe there's a system
that really needs a patch in your environment,
but you don't manage it,
it's managed by a vendor.
So in all of those situations
if there is going to be a delay,
particularly a delay of a critical patch,
a critical security patch,
that should be a evaluated
considering the organization's risk tolerance
and definitely brought to management's attention.
You don't wanna keep that a secret.
So what are some of the activities
that we engage in in patch management?
Well, we have to think about confirmation, right?
Is this patch applicable?
Do we really need it?
We have to determine the prioritization
of applying that patch.
And then, what the timing's going to be,
when we're going to apply it, as well as testing.
Do we wanna test it in a lab first?
Do we wanna test it on a subset of users?
Or do we just wanna blast it out
because it's such a significant patch?
What is gonna be our patch management approach?
Are we gonna do an automated,
or manual, or a hybrid approach?
How are we going to get access to either unmanaged devices,
meaning the ones that we don't manage perhaps,
or we don't own in our environment,
or mobile devices, those are on the road,
or remote devices,
those that might be at a work-at-home location
or in remote locations?
We always have to be mindful
of potential unintended consequences.
There certainly have been patches
that have been put on that have caused corruption,
or have caused, you know, a system to fail,
or get, you know, a blue screen of death.
Certainly that happens,
so we also wanna make sure that we know how to roll back
in case we have any unintentional consequences
how we could possibly remove or roll back.
But, you know, inherent sometimes in rolling back
there are some issues as well.
So, you know, patch management
isn't as easy as it sounds, right?
It's not like, "Okay, put that patch.
One and done, you're good."
There's a lot to consider in doing patch management.
And that, my friends, brings us to a three-second challenge.
Five challenge questions, three seconds each.
Here it goes.
Automated tools used to look
for vulnerabilities and exposures.
One, two, three.
That's gonna be a vulnerability scanner.
Number two, when abnormal or unexpected activity
is incorrectly identified,
this is that dangerous state.
One, two, three.
That's gonna be a false negative.
Number three, testing that can be described
as fine, exploit,
and proof of concept or compromise exploit, and report.
What kind of testing is that?
One, two, three.
It's gonna be penetration testing.
Number four, severity level that indicates the potential
to cause significant harm or damage.
One, two, three.
That's high severity or critical.
And number five, provides a cumulative set
of security updates, hot fixes, critical updates,
updates and design changes or features.
One, two, three.
And that's a service pack.
That brings us to a security in action,
and this one's about vulnerability scanning.
Your organization hired a third party
to conduct authenticated
and non-authenticated vulnerability scanning,
authenticated and non-authenticated.
There are several discrepancies between the two scans.
Now the consultant noted
that there were several false positives
and false negatives in both scans.
But she commented that,
"Well, since they're false, nothing to worry about."
Well, you've been asked to explain the difference
between the scan approaches and how to interpret
the false positives and the false negatives.
So authenticated and non-authenticated,
which is just really another way,
so authenticated and non-authenticated,
which is just another way of saying
credentialed and non-credentialed.
So two different ways to do the scan.
And it turns out that there's a whole bunch
of false positives and false negatives,
but your consultant says, "Eh, they're false.
Don't worry about them.
Nothing to worry about."
You've been asked to explain the difference
between those two scan approaches
and how to interpret false positives and false negatives.
So go ahead and put me on pause,
write down your explanation and come on back.
The difference is, is that unauthenticated scans
allow for access
based on the logged-in user's rights and permissions.
An unauthenticated scan can examine
only publicly visible information
and is unable to provide more detailed information
about the assets.
And we talked about doing a unauthenticated
or non-credentialed scan,
because that would be what maybe a stranger would see,
someone who's not authorized to be on your network would see
if they were able to connect and run that scan.
Where an authenticated or credentialed scan
is based on the user's rights and permissions
what will be reported back.
Now false reporting should always be taken seriously.
False positives, remember, are when normal activity
is incorrectly identified as abnormal.
But, you know, we still have to figure it out, right?
Why did we get that response?
Now false negatives is when abnormal activity
is incorrectly identified as normal,
and that should never be ignored
because that's going to be dangerous.
Now here's one of the problems,
how do you know you have a false negative,
because the system hasn't come back
and said this is a false negative?
So it's really a matter
of also looking at your threat intelligence
and other information that you might have to figure out,
does that vulnerability actually exist?
And being able to do that, my friends,
is definitely security in action.
It's a big word cloud.
You know what to do.
Make sure that you're comfortable and confident
with all of these terms, right?
You understand what they mean and how to apply them.
And when you're ready, head on over to our quiz.
I'll see you there.