Patching. Every pen-tester and auditor will point it out and every security geek pretty much *facepalms* when you admit you haven’t patched since last week. But patching is half art and half time commitment. The reality of patching is that it is not quite as easy as we always make it sound, but that doesn’t make it any less necessary as a cornerstone to digital security.
You have a Windows environment with more than 100 systems. In other words, sneakernet just doesn’t work anymore, and a good portion of these systems are servers that you need to stagger reboot/install times during a maintenance window. Basically, you qualify for WSUS!
The easy part of patching with WSUS is getting a spare server with enough storage set up, WSUS installed, and all the patches downloaded that you want to manage (start small because the storage needed adds up quick!).
The next part is figuring out your WSUS groupings and your Group Policy Objects. If you don’t do much to manage the structure of your Machines OU, you might want to start here. Time spent on planning here will save time later on in reworking things you didn’t anticipate. Using Group Policy will help ensure that you don’t have to chase every new system and herd them into WSUS. Joining the domain should take care of it!
If you’re trying to massage a new WSUS implementation in an already-built Group Policy arrangement, you’ll probably have a lot of hair-pulling or catastrophic mistakes as you try to move inheritance around, policies around, and break things out properly. It’s really not all that fun early on.
Once you start getting systems populated, you then can start looking at your deficiencies in WSUS. More than likely you will end up approving everything, but that is still a boring time sink. This might also expose a few issues. First, all the systems you’ve neglected for months or years. Second, whether you want to approve patches for every system. I’d suggest approving for every system. That way if you create a new WSUS group later on, inheritance will still apply everything you’ve done previously. If you want to split, say, servers and workstations, I’d suggest getting a separate WSUS instance/box rather than compromise the inheritance stance. It really will pay off someday when you find surprise machines in your environment, but thankfully have been patched because you approve everything for everything.
In the process, you’ll learn how to view the reports in the WSUS management console. This is tricky, so play with the filters extensively. It sucks to get a nice warm fuzzy feeling as you get caught up only to realize you hadn’t even begun to look at what systems had errors or have a backlog of updates from years ago. Don’t just look at new patches!
Eventually, you’ll get caught up!
Then on patch day you have to figure out what systems you want to approve patches for as a test before you slam them out to all the other systems. And you need some method to validate the testing. This is harder than it sounds because you need systems that get used, but are not so important that you’ll jeopardize the business if they screw up. You also need to then manage their WSUS membership (and thus their GP objects and OU assigments) to accomodate their status as test boxes. Basically, good luck with that!
Then after some testing time, you can roll out the patches everywhere. Of course, this probably gets preceded by a wide announcement of patching, rebooting, and possible downtime in your maintenance window or overnight, and all the dumb questions that come back from it.
After all of that is done, you get the fun task of going back into WSUS to see which systems failed to do their installs. Then troubleshoot those installs, announce a second round of downtime, and get things up to speed.
In addition, you’ll probably have systems that no one likes to reboot, so they just accumulate months of patches, such as twitchy domain controllers, old systems that are more brittle than leaves in autumn, and database servers. Everyone loves a sudden database server reboot!
Whew, done, right? Nope! Now you have to have a process to validate that patches are installed on all systems that you manage. While WSUS does include reporting, it might be necessary to get some checking done out-of-band from your patching. Enter: vulnerability scanners!
This is a beast in itself as you need to be careful initially with how much you let the scanner beat on your systems. You might just end up doing Windows patch scans, which is an ok baseline if that’s all you can do. Of course, you get the pain of:
– getting systems into the scanner target list (too often this is manual!)
– getting dead systems out of the scanner target list
– parsing through the reports for both of the above
– parsing through the reports for the missing patches or alerts
– reconciling all the issues
The bottom line is patching is a necessary foundation to security. If you don’t have a patch management process for your OS of choice, you can’t have a good security stance. And too often the people who flippantly say patching is easy, don’t know anything about enterprise patching and think it’s just all about Automatic Updates and clicking the yellow icon every month before they go to bed. Proper patching is a time commitment that needs to be made by your IT or security staff, and it takes longer than you probably expect. Oh, and we’ve not even touched on non-Windows patching!