Before we get into my list of patch management tools, we all have used WSUS and some of us have become proficient at SCCM, these tools aren't in my top 3 list... they don't even crack my top 10! However, from an enterprise point of view, an enterprise that is primarily Windows, those tools are great and they get the job done. I want to talk about 3 tools that are easy to set up, easy to use and provide a good value to the admin team when it comes to managing updates and patches. Administrators that have to manage patches (which is just about all of us) want an easy solution that's not going to require a ton of overhead. I feel like SCCM is a monster when it comes to management and overhead, maybe that's not your experience. The end result we all desire, is to move away from manually patching and find a solution that will do that work for us. My list is not be any means definitive, these are tools that I've actually had interaction with in the past and that I've found to be helpful and easy to use. Without further ado, here's my top 3 list of patch management tools (in no particular order) with an accompanying video:
SolarWinds Patch Manager
What do you think? Am I way off? Did I leave off any good tools that some of you are using out there? I'd love to hear from you.
It goes without saying that patching and updating your systems is a necessity. No one wants to deal with the aftermath of a security breach because you forgot to manually patch your servers over the weekend, or your SCCM/WSUS/YUM solution wasn't configured correctly. So how do you craft a solid plan of attack for patching? There are many different ways you can approach patching, in previous posts I talked about what you are patching, and how to patch Linux systems, but we need to discuss creating a strategic plan for ensuring patch and update management don't let you down. What I've done is laid out a step by step process in which you will learn how to create a Patching Plan of Attack or PPoA (not really an acronym but looks like a real one).
Step 1: Do you even know what needs to be patched?
The first step in our PPoA would be to do an assessment or inventory to see what is out there in your environment that needs to be patched. Servers, networking gear, firewalls, desktop systems, etc. If you don't know what's out there in your environment then how can you be confident in creating a PPoA?? You can't! For some this might be easy due to the smaller size of their environment, but for others who work in a large enterprise with 100s of devices it can get tricky. Thankfully tools like SolarWinds LAN Surveyor and and SNMP v3 can help you map out your network and see what's out there. Hopefully you are already doing regular datacenter health checks where you actually set your Cheetos and Mt. Dew aside, get our of your chair and walk to the actual datacenter (please clean the orange dust off your fingers first!).
Step 2: Being like everyone else is sometimes easier!
How many flavors of Linux are in your environment? How many different versions are you supporting? Do you have Win7, XP and Win8 all in your environment? It can get tricky if you have a bunch of different operating systems out there and even trickier if they are all at different service pack levels. Keep everything the same, if everything is the same, then you'll have an easier time putting together your PPoA and streamlining the process of patching. Patching is mind numbing and painful, you don't want to add complexity to patching if you can avoid it.
Step 3: Beep, beep, beep.... Back it up! Please!
Before you even think about applying any patches, your PPoA must include a process for backing up all of your systems prior to and after patching. The last thing anyone wants to do is have a RGE on their hands! We shouldn't even be talking about this, if you aren't backing up your systems, run and hide and don't tell anyone else (I'll keep your secret). If you don't have the storage space to back up your systems, find it. If you are already backing up your systems, good for you, here's a virtual pat on the back!
Step 4: Assess, Mitigate, Allow
I'm sure I've got you all out there reading this super excited and jonesing to go out and patch away, calm down, I know it's exciting, but let me ask you a question first. Do you need to apply every patch that comes out? Are all of your systems "mission critical"? Before applying patches and creating an elaborate PPoA, do a risk assessment to see if you really need to patch everything that you have. The overhead that comes with patching can sometimes get out of hand if you apply every patch available to every systems you have. For some, i.e. federal, you have to apply them all, but for others it might not be so necessary. Can you mitigate the risk before patching it? Are there things you can do ahead of time to reduce the risk or exposure of a certain system or group of systems? Finally what kind of risks are you going to allow in your environment? These are all aspects of good risk management that you can apply to your planning.
Step 5: Patch away!
Now you have your PPoA and you are ready to get patching, go for it. If you have a good plan of attack and you feel confident that everything has been backed up and all risks have be assessed and mitigated, then have at it. Occasionally you are going to run into a patch that your systems aren't going to like, and they will stop working. Hopefully you've backed up your systems or better yet, you are working with VMs and you can revert back to an earlier snapshot. Keep these 5 steps in mind when building out your PPoA so you can feel confident tackling probably the most annoying task in all of IT.
Let's talk about patching for our good friend Tux the Linux Penguin (if you don't know about Tux, click here.). How many of us out there work in a Linux heavy environment? In the past it might have been a much smaller number, however with the emergence of virtualization and the ability to run Linux and Windows VMs on the same hardware, it's become a common occurrence to support both OS platforms. Today I thought we'd talk about patching techniques and methods specifically related to Linux systems. Below I've compiled a list of the 3 most common methods I've used for patching for Linux systems. After reading the list you may have a dozen more way successful and easy to use methods that the ones that I've listed here, I encourage you to share your list with the forum in order to gain the best coverage of methods to use for patching Linux systems.
Open Source Patching Tools
There are a few good open source tools out there for use in patching your Linux systems. One tool that I've tested with in the past is called Spacewalk. Spacewalk is used to patch systems that are derivatives of RedHat such as Fedora and CentOS. Most federal government Linux systems are running Red Hat Enterprise Linux, in this case you would be better off utilizing the Red Hat Satellite suite of tools to manage patches and updates for your Red Hat system. In the case, your government client or commercial client allows Fedora/CenOS as well as open source tools for managing updates, then Spacewalk is a viable option. For a decent tutorial and article on Spacewalk and it's capabilities, click here.
YUMmy for my tummy!
No, this has nothing to do with Cheetos, everybody calm down. Configuring a YUM repository is another good method for managing patches in a Linux environment. If you have the space, or even if you don't you should make the space to configure a YUM repository. Once you have this repository created you can then build some of your own scripts in order to pull down and apply them on demand or with a configured schedule. It's easy to set up a YUM repository, especially when utilizing the createpro tool. For a great tutorial on setting up a YUM repository, check out this video.
Manual Patching from Vendor Sites
Obviously the last method I'm going to talk about is manual patching. For the record, I abhor manual patching, it's a long process and it can become quite tedious if you have a large environment. I will preface this section by stating that if you can test a scripted/automated process for patching and it's successful enough that you can deploy it, the please by all means, go that route. If you simply don't have the time or aptitude for scripting, then manual patching it is. The most important thing to remember when you are downloading patches via FTP site, you must ensure that it's a trustworthy site. With RedHat and SUSE, you're going to get their trusted and secured FTP site to download your patches, however with other distros of Linux such as Ubuntu (Debian based) or CentOS, you're going to have to find a trustworthy mirror site that won't introduce a Trojan to your network. The major drawback with manual patching is security, unfortunately there are a ton of bad sites out there that will help you introduce malware into your systems and corrupt your network. Be careful!
That's all folks! Does any of thing seem familiar to you? What do you use to patch your Linux systems? If you've set up an elaborate YUM repository or apt/get repository, please share the love!
All of us that have had any experience in the IT field have had to deal with patching at some point in time. It's a necessary evil, why an evil? Well if you've had to deal with patches then you know it can be a major pain. When I hear words like SCCM or Patch Tuesday, I cringe, especially if I'm in charge of path management. We all love Microsoft (ahem), but let's be honest, they have more patches than any other software vendor in this galaxy! VMware has their patching, Linux machines are patched, but Windows Servers, there is some heavy lifting when it comes to patching. Most of my memories or experiences of staying up past 12 am to do IT work has revolved around patching, and again, it's not something that everybody jumps to volunteer for. While it's definitely not riveting work, it is crucial to the security of your server, network device, desktops, <plug in system here>. Most software vendors are good about pushing out up to date patches to their systems such as Microsoft, however there are some other types of systems that we as IT staff have to go out and pull down from the vendor's site, this adds more complexity to the patching.
My question is, what are you doing to manage your organization's patching? Are you using SCCM, WSUS or some other type of patch management? Or are you out there still banging away at manually patching your systems, hopefully not, but maybe you aren't a full blown enterprise. I'm curious, because to me patching is the most mundane and painful process out there, especially if you are doing it manually.