-: Implementing and Testing,
so we've talked about the fact you have to
detect something, you need to remediate it,
based on the priority, and now you need to
implement that and test it.
So let's talk about what that involves.
Vulnerability analysts don't actually fix the issues.
We just point them out.
It's really the system administrators that
have to fix the issues.
So our role is to find the issues and pass
them to people who can fix them.
Somebody who can implement those patches.
The fixes may not be quick, and often they're
gonna require approval from a Change Control Board.
And if it's something that is critical,
we may have to do an out of cycle change control board
called the unemergency change control board.
Fixes should always best tested in a lab
environment first, before pushing it out
to all of your clients on the enterprise.
And the reason is you may break something with a fix,
there have been instances when Microsoft
or Linux or any of these other places out there
that push out a vulnerability patch have pushed
out something and then it broke your systems.
Right, so you gotta be careful and test them
in the lab environment first.
You need to coordinate your efforts.
You as a vulnerability analyst can view fixes
as the highest priority in life.
Because your report is showing all sorts of red
all over, and your manager is like we gotta fix
these vulnerabilities.
But when it comes down to it,
what is the purpose of the network?
If the purpose of the network is to provide
service to the customers,
then taking it offline to fix a vulnerability
may not be the highest priority.
Not everyone in your organization
is gonna view fixing your vulnerabilities
as their highest priority.
So you've gotta coordinate your efforts
and work with the system administrators
and the change control board
to get these things fixed.
This is when vulnerabilities get remediated,
is when you have proper coordination with other people.
When you do something, you need to make sure
you're not causing service degredation,
breaking promises to customers, or other IT governance
because all of those things can slow down
your vulnerability remediation efforts.
And we'll talk about each of those
a little bit more specifically in this lecture.
Service Degradation, vulnerability scanning
is gonna place a resource tax on your network.
If you're doing it from a centralized server,
that's bandwidth that's being consumed over
the network as you're running these scans.
And when you're scanning a particular machine
each of those machines is getting a processor load
and a memory load associated with that scan.
This can actually disrupt critical business functions.
So you have to be careful in scanning things
like production servers.
You need to overcome objections because people
are gonna be like, hey I don't have time
to do this right now, I'm too busy,
I can't afford the outage, right.
And so you've gotta coordinate that.
Often what that will mean is you're gonna be
running your scans overnight when it's non-peak hours.
You may be setting your scans to lower intensity modes
where instead of scanning everything once a second
it's gonna do it once a minute and space out those scans.
The problem is all of these things are gonna take more time
and reduce your ability to do your scans.
So it is a balancing act between the operations
and the security perspective here.
Now when we talk about promises to customers,
what are we talking about?
Well, we're talking about MOU's and SLA's.
This is your Memorandums of Understanding and
your Service Level Agreement.
These have specific requirements for uptime, performance,
and other requirements that your organization has
promised to it's customers it's going to meet.
So if you're gonna do scans that are gonna disrupt
the business functions and make them not meet
their MOU or SLA requirements, that can be an issue.
How do you overcome those objections?
Well, as a cyber security team, you want to make sure
that you're involved in drafting the MOU's and the SLA's.
And make sure that they're realistic.
If you have an SLA, that says you have to have a 100% uptime
that means you can never take it down
for scanning or patching, that's just unrealistic,
you can't do that, right.
So you have to make sure there's language in there
that allows for these type of things.
You need to discuss the appropriate times
and scopes for your scans as well.
To make sure there is time associated with it
that may be over the weekend, that may be over
the evening times and often you'll be running
at different times than the rest of the crew
because of that reason and to keep those
SLA metrics up and running.
And the third thing you'll run into that's gonna
cause you a problem is IT Governance.
Now what does that really mean?
Well IT Governance is the processes in place
that control changes to the network.
This can create hurdles in getting an approval
to implement your changes.
So you may go, oh my gosh, there's this huge
remote code vulnerability, we've gotta get
this patch out there right now,
take down the server and put the patch in place.
Well that can disrupt business functions, right?
Obviously.
So we have to overcome the objections
and some of the ways we do this is by
working within the organizational policies
to ensure we get the resources and support we need.
So if it's something that is a non-critical issue,
so it's a high medium or low, we can actually
work through the change control process and
we can get those things pushed in and maybe
once a week or once a month they'll implement those
changes for us.
Now if it's a critical thing we're gonna do what's
called an emergency change control board.
We'll convene the emergency change control board
through the IT Governance process and bring
up the reasons why this is so important that
we have to disrupt business.
And so you don't want to play this Trump card
all the time but it can be useful
and you may need to.
For instance I'll go back to the wanna cry example
because it's a fairly recent one.
Lots of organizations had to stop what
they were doing to implement those fixes.
Right now to prevent issues in the future
and that's part of the IT Governance that
they had to follow.
This is the idea, you need to make sure
that you're overcoming these objections
because people are gonna try to stop you
at every turn when it comes to vulnerability
management because it's just a hassle for them
they wanna get the business functions done
they wanna make the money they need to make
and taking things down to patch is not always
at the forefront of their mind.
(upbeat techno music)