-: Corporate policy requirements.
So in the last lesson we talked about
legal requirements and legislative requirements.
In this one we're going to talk about
corporate policy requirements.
So when we talk about corporate policy requirements,
we have to think about things that don't
necessarily apply to the laws and regulations.
So PCI DSS and FISMA and FERPA and GLBA,
those apply some companies but not to all companies.
But you're corporate policy is gonna be something
that you guys are going to decide
inside your own organization because
vulnerability management is still an
important key concept to security of your systems.
And so therefore, organizations can
and do require scanning under their own corporate policies.
Now if you happen to be the chief security officer,
you might be the one dictating those policies.
First point you're going to think about is scanning targets.
What are you gonna scan and why?
What systems do you want to be covered by your scans?
You want your servers, your clients, your mobile devices,
your routers and switches, or everything?
Well it's easy to say everything
but if you do everything then you're going to take
a lot of time, effort and resources
and that may not be the right answer for your organization.
Do you scan all your systems
or just what is deemed a critical asset?
Again there is no right answer to this.
It's gonna be up to your organization
and the impact that those systems have.
And so you're gonna have to think about that.
Scanning tools like QualysGuard or Nessus
can be used to build an asset inventory
automatically by scanning your entire IP range
and reporting back that, "Hey you've got these
"systems and they are this type."
For instance you scan the network
and find out that you have 53 Windows 10 systems
and 10 Windows 2008 systems, right,
and these are the IP addresses and where they are located.
That can help you build an asset inventory
and then you can give that asset inventory
to your system administrators and you other key stakeholders
and they can start dictating, this is
critical or this is non-critical.
And then we can determine where we're going to spend
our resources and time fixing these
vulnerabilities and scanning in the future.
When you look at QualysGuard, this is an example
of that inventory that I was mentioning.
You can run a scan, and as you can see here
it's going to tell you a lot information.
It can tell you what vulnerabilities are out there
by severity, which ones are open, which ones are closed.
You can see what tickets are done,
if they've actually tied this to you ticking system,
and you can also do it from an asset group.
As you can see on the left bar there,
there is a tab for asset groups.
And you can actually build an asset base there.
So you can see what is your network
and what machines make up your network.
The next thing you have to decide in your
corporate policy is your scan frequency.
How often do you want to scan your systems.
Are we going to scan them continuously?
Are we going to do it everyday,
every week, every month, every year?
Well again this is going to be determined by your
organizational goals, your security state, your compliance,
and other business requirements.
You can actually generate automated email reports
and run these scans automatically.
For instance with Nessus you can setup daily,
weekly, monthly or other scheduled scans by date and time.
At the completion of the scan it can send that as an
email report in HTML format to your system administrators.
They can go, "Oh there's my problems,
"let me start fixing them."
Now that's a very simple way to do a
vulnerability management program
but it's not necessarily the best.
But again you have to answer that question,
scan frequency, how often do you want to scan the network?
Here's an example of what Nessus looks like.
This is the Nessus Vulnerability Scanner by Tenable.
You can see here as it runs a scan.
This happens to be a scan of one host,
and it shows up what plugins, which is
the vulnerability identified and how many count there was.
You'll see the one host, the 10.3.1.6,
it has one vulnerability we're looking at
specifically right now, which is plugin 34477.
This one has to do with a error in the old
Microsoft Windows code for XP and 2003 Servers.
This happens to be a 2003 server I scanned,
and you can see this a critical vulnerability.
I'm gonna show you how to use Nessus
in a future lesson, we'll do a video walkthrough
so you can see this tool in action
and how you can read some of these reports.
This should just give you an idea
of what this looks like versus
what I showed you with QualysGuard a little bit earlier.
Now when you look at your scan frequency
you have a lot of considerations.
The first and probably most important one is,
is your organization risk appetite high or low?
How quickly do they want to be able to
identify when there is a vulnerability
and when there is a threat.
If it's really low risk appetite,
they aren't willing to accept a lot of risk,
you have to do more frequent scans.
If they have a high risk appetite,
you can do less frequent scans.
You have regulatory requirements, again if your organization
works with FISMA, under FISMA rules
or PCI DSS you've got minimum requirements
of quarterly, semiannually or annually.
If you don't, then you can decide
your scan frequency on your own.
Technical constraints.
Your network may not support scanning everything.
For instance, I've worked on some really large networks
and if I only have one scanning engine,
it might take me a week and a half
to do a full scan of the network.
So if you told me to do weekly scans,
I physically don't have the technical capacity to do that
and so that's a technical constraint.
So that does go into your calculus
when figuring out how often do you want to scan.
Business constraints.
You have to avoid high periods of business activity.
For instance, I've been in organizations
that say you cannot scan between
eight in the morning and five in the afternoon
because that's when all of our employers are there,
we don't want you slowing down the network.
So instead we would run the scans starting at
five at night, pause them at eight in the morning
and then start the scan again
until we got the whole network done.
And the way we overcome that is by scoping it.
We'll talk about that in a little bit.
Licensing limitations.
Your engines as I said, are going to be based on licensing.
Some of them are going to determine
how many concurrent scans you can do at the same time.
For instance, if I have one Nessus scanner
that's one license but maybe I have five Nessus scanners
and I want them all to be running at the same time.
That means I need five licenses.
So then depending on what resources you've been given
and how many licenses you have
that may be a limitation for you
as you're determining your scan frequency.
So if you're creating a new program
what are some best practices you should look at?
Well the first I would tell you is, "Start small."
Let's identify the most critical assets
or a small section of the network and scan those first.
And then once we get comfortable doing that
we can start expanding out slowly.
And we'll start saying, okay now
we're going to do all the servers.
And then once we got all the servers done
then maybe we'll say, okay we're going to do all that
and the human resource clients.
And then we'll do, okay we'll do
human resources and accounting.
And then we'll do human resources, accounting and sales.
We'll just keep expanding and gradually adding
more scope until we find that sweet spot in our network .
You want to prevent overwhelming your
the enterprise systems and your system administration team.
Because I've seen some places, they try to go from
zero to 100 miles an hour on the first day.
They go, "We didn't have any scanning program
"and now we're gonna scan everything."
And the amount of data that comes
back just overloads everybody.
So, it's good to start small
and then gradually work your way out.
That is probably one of the best,
best practices that I can tell you
if you're starting a new vulnerability management program.