At this point, I'll assume you've figured the details of your patch process and you're about to look into tools that can help you do the job.
There are lots of patch management systems on the market. I've worked with two of them professionally, evaluated a third, and heard stories about others. All have their good and bad points.
Most patch management systems work something like this:
- An agent is installed on the PC. This agent scans all the OS, applications, and registry to determine what the machine's current patch state is.
- The agent transmits this information to a central server, where it's available to administrators for reporting and monitoring purposes.
- The agent receives periodic updates from the central server, telling it what vulnerabilities or patches it should look for when it scans the PC. When those vulnerabilities are found on a PC, the agent notifies the server.
- The agent downloads the patch installers from the central server, and installs them on the PC.
- At an appropriate time, the agent reboots the PC to complete the patch application.
- The agent re-scans the PC and reports that the patches are no longer missing (if they applied correctly) or that they are still needed (if the installation failed).
- Administrators decide how often machines are scanned, when they are patched, which patches are to be applied (and which are not), etc. The agents take their cues from this.
- Administrators use the data on the central server to create reports showing current patch status, vulnerable machines, etc., and may "push" patches out to specific desktops to get them current.
Not every patch management tool works this way, but it's usually a variation on this basic process.
Based on my experience using a couple of different patch management tools, here are some of the things I would look for (or think about) when choosing one:
- Does it have a central repository that I can use to report on patch status, patch availability, vulnerable machines, etc.? Management and security personnel like it when you can produce reports on-demand showing current patch status.
- Can you identify whether a specific PC has received a specific patch? There are times when you will discover incompatibilities after deploying a patch. Users may report a problem similar to the one caused by the patch, but if the patch isn't installed on that PC, the symptoms have another root cause.
- Can you group machines into different categories and apply patches differently to each? For example, maybe you have a sensitive line of business application that can't accept updates to the Microsoft .NET Framework. If so, you may want to create a group of machines that never receive .NET updates, but receive all other update.
- Can you separate the reboot process from the patch process? You may want to patch laptops during the business day while they're likely to be powered on and connected to your LAN. You probably do not want to reboot those machines during the business day, however. You may not even want to reboot them at all. Make sure your patch tool supports that.
- Can your patch tool wake up machines that have been powered down (Wake on LAN)? Many companies and employees try to be environmentally responsible, powering off systems at the end of the work day. If you need to patch them, you'll want to be able to power them on without having to run all over the building to do it.
- Can you define your own custom patches to the system? None of the patch tools I've worked with provide patches for every application in use in the organization. It's good to be able to incorporate patches for other software right into the same system you're using for all other patches. Similarly, the custom patch mechanism might allow you to run scripts or tools that perform non-patch functions (like checking that system settings are correct, running disk defragmentation tools, backups, or other activities). This can be very handy for general administration work with the PCs.
- Can you provide the reports and statistics you need to show your management team that a particular patch is fully applied, partially applied, etc.? Can you show all machines that have, or don't have, a particular patch?
- Can you run vulnerability scans on-demand to ensure that one or more machines is patched to current levels?
- Can you place certain patches in an "auto fix" mode so that any machine that checks into the server will receive the patch immediately? (This can help in situations where machines sit in a closet for weeks or months before being suddenly powered on.)
- How easy is it to get details (from within the patching tool) about the individual patches, what issues they're intended to fix, etc.? Links back to vendor knowledge base articles or release notes can be helpful.
- Are there gateway options that allow you to patch corporate PCs that may be on the Internet but not directly connected to your LAN/WAN at the time?
- How often does the vendor update, upgrade, and patch the patch management tool itself? If updates are frequent, will this add to patch workload?
In an ideal world, your patch management tool will also integrate with your hardware asset inventory, software asset inventory, software distribution, and other client management functions. This will allow you to answer ad hoc questions that will come up like "How many machines have Adobe Acrobat XI installed and received patch MS15-052?"
When you first deploy a patch management tool, you'll probably be overwhelmed by the number of missing patches it finds in your environment. Don't be. Realize that these patches have been missing for a while and you had no idea. Now that you have a clue, start prioritizing the patches and pushing them out. Before long, you'll be looking at a bunch of well-patched desktops.