Patch Management

00:00

Hi. Welcome to module to lessen four dot to

00:03

and this lesson. We're gonna talk about patch management now, if you remember back in module one, we talked about vulnerabilities and, specifically, software vulnerabilities. Software vulnerabilities have patches that come out all the time, these patches or what you can apply to your systems to remediate vulnerabilities in the environment.

00:20

Now, if you remember those vulnerabilities they have, they have scores. They have identification. The C V E identification was a way that you can see what a what a vulnerability is and all of the different mitigations that you can take to remediate that vulnerability. And that's great for those of us who are protecting environments.

00:38

But it's also it could be used as a tool for those who are attacking an environment.

00:42

So one of the very popular ways that Attackers used to get into an environment is they'll go and look at one of the si ves. They'll see what a vulnerability is that See ve has all of the technical details about that vulnerability. It goes into detail about exactly what that vulnerability exactly what that vulnerability is,

00:59

and then they just write malicious code to exploit that vulnerability and voila!

01:03

A new piece of malware is born. Now it's just a matter of sending that to you in a phishing email, getting you to click it. And now you've got this Mauer in your environment that exploited a vulnerability. So it's very important to have a good, robust patch management program in place.

01:18

Now, in this lesson, we're really just going to talk about We're not gonna get into the weeds about the technical details of patching, because at the end of the day, patching is just installing a new version of a piece of software. If we've got Microsoft operating system and a patch comes out, we just run the installer and it updates the software. So it's

01:38

it's really not rocket science on how to install patches.

01:41

But what's very difficult is to maintain a patch management program that's effective. Going forward to reduce those vulnerabilities in the environment,

01:49

and the reason it's so difficult to do is because it seems like every 10 minutes some new vulnerabilities coming out. There's some new headline about a new critical vulnerability, so it's important to establish good processes

02:02

that help you identify which of these is really critical. And how am I going to get these in my environment in a timely fashion before the bad guys start

02:10

taking advantage of the vulnerabilities?

02:15

Here's just a few tips on your patch management program. The 1st 1 I'm going to say is Any time you can, you should use automatic updates. You know almost every application, not almost every. All the major applications have the ability to turn on automatic updates, and it's a very good thing anywhere you can do it.

02:31

Maybe in user workstations, you wanna automatically update anywhere you can do it, and you can take the burden off of you as an administrator

02:38

from having to install this software on 3000 systems anywhere you can turn on automatic updates. Turn it on now There's a lot of places you can't use. Automatic updates. A good example would be, let's, say, a production server in your environment. Maybe there's a production server. It's running Ah, business application.

02:57

You can't just have automatic updates turned on because

03:00

sometimes those updates need a reboot. You don't want your system rebooting in the middle of the day and kicking customers off so you can't have it turned on in those environments. But as a rule anywhere where you can turn on automatic updates, you should.

03:15

This next tip is prioritize your assets

03:17

when you're looking at all the vulnerabilities in your environment. As we said Module one. If you're using a vulnerability scanner to identify all of the assets in your environment, it becomes very overwhelming very quickly. All of the different vulnerabilities. How do you prioritize that you're only one person or one small team of people? How do you prioritize it? Cause there's no way you can do it all at once,

03:38

And a good way to do that is prioritizing your assets, understanding what devices in your environment are more critical than others

03:45

and in applying those patches to those critical devices, first is something that goes a long ways towards reducing the overall risk in the environment.

03:55

When you install patches on a system, don't just assume that it was that everything went smoothly. Sometimes you install a patch and it looks like it installed properly. But there was some error code in the background that happened, and it didn't actually fix the vulnerability

04:11

by re scanning. If you're using a vulnerability scanning to detect the vulnerabilities to begin with, re scanning that system after you patch It is a good way to validate that that vulnerability actually is gone, and that patch was effective.

04:25

This is another good one. Exceptions should have a remediation plan in an owner.

04:29

There are always going to be exceptions. There's going to be systems that that people say you cannot patch. You can't patch this system Ah, very common one is old systems in the environment. Let's say there's an end of life piece of software and the vendor doesn't even produce patches anymore because its end of life.

04:46

But you're still using the software in your environment for some

04:49

business reason.

04:51

It's important in these cases there's always gonna be these cases. But it's important in these cases to say, OK, let's given exception. It's gonna be a formal exception. We're going to document it. We're gonna have to have a remediation plan in place and an owner.

05:04

So by not just saying, yeah, we can't patch that system and moving on. We're saying Okay, we can't patch that system, but what is our plan? Because we can't just leave it sitting there forever into the end of time. We have to have some plan to eventually get to a place where we can have a system that's Patch Hable

05:20

so we can maintain it So we don't have vulnerabilities in it all the time, especially if it's critical.

05:26

So what is the plan? And by the way, who owns that plan? Because if we're going to be realistic about this thing actually getting updated, we need to assign an owner. Someone needs to be liable. For once the liability is a sign, it's more likely that that system is going to get sunset it eventually and replaced with something else.

05:46

Create a schedule for your patches. Don't just rely on vendor release states. You know, Microsoft every month has patched Tuesday where they release all of their patches. But don't don't just rely on individual vendors. If you you know Microsoft has one schedule and you know Adobe has another schedule in the Southern organization has another schedule.

06:05

You don't just randomly

06:08

put patches in whenever the vendors released them. Have a set schedule where you're gonna load all of the critical patches in your environment. All the most critical patches are the ones that you deem to be priorities in your environment. I would say that Scheduled needs to be at least monthly at a minimum.

06:23

But create that process where once a month you're gonna go in. During the month, you're gonna be collecting data about all the different patches that are out there and available for all of the different software that runs in your environment,

06:32

prioritizing it and then once a month or, you know, a smudge as often as possible, the more often the better. But I'm saying at least once a month, go in and install those patches and then run your validation scans. But you should also have a process for those out of bounds out of band patches.

06:47

If you Let's say you do it once a month, you patch your systems that on the first Tuesday of every month

06:54

well, on that Tuesday, you run your patch, and then Wednesday, a critical patch comes out from Microsoft. You don't want to wait 30 days to install that critical patch, so always have some process through your change management process or something like that that allows you to install critical patches if they come in,

07:12

um, in between your scheduling for your normal patches