>> I hope it goes without saying
it is incredibly important to keep
our systems patched and up-to-date from
both a performance perspective
and a security perspective.
A lot of these attacks we hear
about often there have been patches to show up
the vulnerabilities those attacks
exploit for weeks and sometimes even months.
It's a difficult process to keep systems
patched because vendors push out a lot of patches.
If you're not familiar with Microsoft Patch Tuesday,
where they roll out their patches
and all their software products,
you will become familiar with Patch Tuesday.
It's important, just like everything else,
that we have a documented process.
With patches, we need to document
patch management and lifecycle of patches.
At first we go through discovery phase.
There's a new patch that's been released,
or more likely lots of
new patches that have been released.
We have to categorize and prioritize.
We certainly want to be able to give priority to
security patches and those patches that are urgent,
and we need to develop a policy
that talks about how we're going to do it.
We continue to monitor for
new patches as they're released.
We may have a centralized
patch server that keeps the track
or gets alerts based on these new patches.
When patches are available we
generally bring them down and test them.
We test those patches,
of course, in non-production environments.
Maybe on a virtual system or in a lab,
because we want to make sure that we
understand any change to
a baseline configuration of
the systems may cause the environment to become unstable.
We want to test those patches.
Not everything that's released out there
is going to have a beneficial impact.
Configuration management.
We're going to document the changes that have to be made.
We've rolled out the patches.
It's best if we can automate that,
which is exactly what a central patch server will do.
Windows has a product called
Windows Software Update Services,
and that's a central patch server.
There are lots of other third-party tools
that will help you manage your patches.
We want to be able to provide
reporting so that way we can
go back and can know that we're
keeping our systems up to date.
Then review, optimized, repeat,
so looks at our reports,
figure out where we can strengthen
our processes and start all back over.
Some of the patches may need to be
rolled back at any point in time.
Usually vendors provide the information
on how to roll back those patches.
If at any point in time we're coming into
difficulty during the testing period or after rollout,
we should be able to go back
a step before the patches were installed.
At the very least, we can go back to
an earlier snapshot or a resort point.
But we have to be able to determine
between that patch rollout and
the recording capabilities to determine
if there's an issue that the patch has caused.
Baseline configuration. Like I said,
baseline configuration is essential
because how am I going to
know when things are out of
the norm if I don't know what the norm is?
When we're talking about baseline performance we're
talking about compliance with
security goals and policies.
Whatever we're talking about,
baseline is the standard that we want to adhere to.
We'll have a baseline security configuration,
and we want to adhere to that baseline.
It's the point that's fixed in
time that's tied to what our goals are.
We document baseline performance
and then we monitor when we
see that in order to detect
things outside of the baseline.
Packet and traffic analysis.
Sniffer perform the service for us.
We capture packets on
the network so that way we can analyze them.
We might be interested in
determining what type of traffic is on the network,
what protocols that are in use,
when information is going
across the network in plain text.
Just like an attacker uses a sniffer,
so can administrator to learn more about the network.
Whether we're looking at passive or active,
passive is just monitoring.
Active would mean we're injecting data into
the data stream just to determine results.
Also, I'll mention that sometimes you don't even
have to capture the data to get what you need.
Sometimes you can simply analyze the flow of traffic.
For instance, if I know and I see a ton of
traffic is going to a particular server at 8:00 AM,
that may tell me that's a domain controller.
Sometimes just watching where traffic is going,
is going to give me some information.
Also, the fact that traffic is
encrypted tells me that something is insensitive.
That sometimes is referred to as a side channel attack,
where you're learning about the network without
really capturing the actual information.
But you're looking through other pathways.
To wrap up this last section,
we talked about the patching
lifecycle and how we go through
a process where we have to have
our policies and procedures in place.
We have to discover that patches have been released.
We have to have some means of prioritizing them,
testing them, and then
rolling them out in an orderly fashion.
We continue to monitor those patches
and we're looking for any evidence that we
might need to roll patches back in order
to maintain smooth operations.
We also talked about the importance
of baseline configuration,
and we talked about how our baselines must be set and
documented so that way we can detail any changes.
Really, this whole section focus on
the importance of knowing
your network and monitoring your network,
looking for vulnerabilities, reviewing log files,
but staying on top of things because
things can change very quickly in the network.
I want to make sure that I have
the tools at my disposal and
the knowledge of how to use
those tools and interpret the results.