-: Validation of results.
So, after you've conducted your scan,
you need to validate your results.
Now, why do you need to do that?
Well, because the CVSS scores themselves are helpful,
but they don't tell you the whole story.
It doesn't tell you how this vulnerability
affects your particular system.
In fact, sometimes the scans are gonna show
vulnerabilities that are false positives,
documented exceptions, or informational results,
as well as other things.
And so, we have to use that human element
to go back and look at these scans
and plug our brain in,
and see if they really do affect us and our systems.
The first one we talk about here is false positives.
Sometimes, your scan is gonna report something
that says there's a vulnerability in your system,
and when you go to look, it's not there.
It might say that hey, you don't have
Microsoft 17 dash O one two patched into your system,
and you go look at the system, and it's been patched.
This is called a false positive.
Now, how often this occurs is what we refer to as
a false positive error rate.
Because this is an error, we don't want this to happen.
We want our scanners to detect things that are there,
and not things that aren't there, right,
so we know where we can focus our efforts.
Vulnerabilities can be validated and verified,
so first you need a check if the patch was indeed missing.
You need a check if there was an exploit
that tried to go against erroneous code,
and if it was, that may cause this false positive as well.
And you need to verify your system configurations.
Because sometimes, a mis-configuration
can report as a vulnerability, even though it may not be.
And so again, this is where the human element comes in,
and you have to think about what is and what is not
truly a vulnerability.
Just because a scanner says it's vulnerable
doesn't mean it is.
Now, the next thing we need to look at
is documented exceptions.
Now, what is that?
These are vulnerabilities that do exist on your systems.
And you know about them, and your organization decides,
we're not gonna fix them.
Maybe there was a vulnerability that was just
too costly to fix, or wasn't really a big deal to you guys.
And so, this risk was accepted by management,
and they understand it.
That's okay, we now need to put an exception in our scans
so that they don't scan for those things
in the future, right?
I'll give you a good example.
Let's say that you're scanning to see
if FTP exists on your network, and there's
one server on your network that's still running FTP,
which is an insecure protocol,
but management understands it,
they understand it's there,
they don't wanna spend the money to get rid of it,
and that server inside a trusted area,
boundaried off with a couple of DMZ's, right?
That may be a documented exception,
so maybe we're not going to scan that particular server
for FTP anymore, because we know every time we scan it,
it's gonna come up and flag,
and say hey, you've got FTP running.
I know, I'm running an FTP server, right?
So that's a documented exception.
The next one that we wanna talk about is
informational results.
And informational results really come down to the fact
that not everything reported by your scanner
is really a vulnerability.
Some of them are just for your information.
These are called information, or info, reports
inside of your scan report.
These informational items are things like configurations
that may allow an attacker to perform reconnaissance.
It's not that they're gonna be able to attack you with it,
but they can get a lot of information from you, from it.
So let's see what some of these look like
inside of a scan report.
Here on the screen, you can see
three major categories, right?
You see the orange, which is high.
You see the medium, which is yellow,
and then you see that blue, which is informational.
And if you can read, I know the print's a little tiny here,
but some of the things there are
the Nessus Syn scanner is on the network.
Well yeah, we're using Nessus to do our scanning,
but that's an informational issue.
PHP myAdmin was detected,
and maybe that's something you need to know about.
There's things like wiki detection on there,
WordPress detection.
It's not that it's bad that you're running WordPress,
but you need be aware of it, and maybe this
particular configuration that's reporting back
in a banner grab that says hey, I'm running WordPress.
And that means that an attacker now knows
they can throw WordPress vulnerabilities at you.
And so you may wanna change that,
and not allow that to report back out to an attacker.
That's just some examples of what
an informational result might be.
Now, we take all this stuff and we have to compare it
with other information sources
because just looking at the report, and saying
nope, that's not vulnerable, or yes that is,
is not good enough.
Instead, we're gonna collaborate it with other things.
Like logs from servers, network devices, applications,
and other sources on our network.
We can also check against our
configuration management systems.
If we had an info, for instance, that said
you're running WordPress on server 192 dot
168 dot one dot two, and you look at your
network configuration management system,
and you're not running WordPress at all,
that's something that should be concerning to you, right?
So again, you have to check these things.
And finally, we can check our security information
and event management systems, or SIEMS.
Again, that goes into a collection of all this logging data,
and comparing that versus the vulnerability scan.
There's a reason that we have vulnerability analysts,
like you.
We need somebody to go through and look at the logs,
and compare those to what the scans are saying,
to tell us are we really vulnerable or are we not?
And that's the idea here with the cybersecurity analysts,
is being able to compare that information
as part of the vulnerability management program.
Finally, the other thing you're gonna do
is conduct trend analysis.
And trend analysis is gonna allow you, as the analyst,
to ensure that your vulnerability management programs
are working effectively.
So if you look on the screen here,
this is just a big macro-level
of a vulnerability management program,
and looking at it over time.
Notice those spikes, right?
That happens about every Tuesday.
Why?
Because that's when Microsoft releases their patches,
and known vulnerabilities that add into the database.
So we see a higher detection level on Tuesday,
and then we fix things,
and next Tuesday we get more, and we fix things.
Is that okay?
Well, yeah, if you understand the trend.
Otherwise, your manager might look at that
and go oh, how come every Tuesday
we're getting more vulnerabilities, that's bad.
Well, not really, it's that our scanners
are getting better, right?
Now if we look at the bottom one,
you can see over time we have more and more
vulnerabilities coming out.
And we have those criticals, those mediums,
those highs, those informational.
Now, over time, we'd really like to get that down
to zero vulnerabilities, but guess what?
Every week, more vulnerabilities come out.
And every week, we're gonna find more.
So if you don't fix things, you're gonna see a trend
that looks like a big mountain.
That's a bad thing for your
vulnerability management program.
If you're staying pretty stable, the way that this trend is,
that's actually pretty good,
even though there's hundreds of vulnerabilities
on that particular network.
You're never gonna get down to zero, but you try your best,
and you just keep working at it.
And trend analysis will help you to show
that you are working at it,
keeping those vulnerabilities at a steady state,
or getting them to a lower level,
which is ideally what you want to do.
(light techno music).