I hope it goes without saying it is incredibly important to keep our systems patched and up to date from both the performance perspective and a security perspective.
A lot of these attacks we hear about often there have been patches to shore up. The vulnerabilities those attacks exploit for weeks and sometimes even months
is 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 you need to document patch management and the life cycle 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 that 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. So maybe on a virtual system or in our lab, because we want to make sure that we understand any change to a baseline configuration of the systems might 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. So we're going to document the changes that have to be made.
We roll out the pouches. 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 optimize, repeat. So look 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 roll out, 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 restore point,
but we have to be able to determine between that patch, roll out in the recording capabilities to determine if there's an issue that the patches caused.
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 sort of 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 sort of 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
pocket and Traffic analysis
Sniffer performed the service for us,
we capture packets on the networks. That way we can analyze them.
We might be interested in determining what type of traffic is on the network. What sort of protocols that are in use. One information is going across the network in plain text,
just like an attacker uses a sniffer. So can an administrator to learn more about the network.
Whether we're looking at passive or active passive, it's 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.
if I know and I see a ton of traffic is going to a particular server at eight o'clock 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 sensitive.
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 life cycle 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 sort of 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. That way we can detail any sort of 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