Patch Management Audit Checklist by GFI Software
Perform regular and systematic patch management audits to evaluate the success of an organization’s patch management program
Perform regular and systematic patch management audits to evaluate the success of an organization’s patch management program
Patch management consists of scanning computers, mobile devices or other machines on a network for missing software updates, known as “patches” and fixing the problem by deploying those patches at a determined time. Patches are necessary to ensure that the systems are fixed, up to date and protected against security vulnerabilities and bugs that were present in the software.
Because of the importance of patch management, an organization will find it beneficial to perform regular internal patch management audits to evaluate the success of their patch management program. These audits are best done systematically, following a number of steps on a checklist to ensure a thorough and complete audit.
The checklist of a patch management audit may vary, depending on an organization’s size and assets, but the larger point is that updates should not be installed as they become available. Instead, they should go through a process laid down by the organization. This process-oriented approach will make it easier to follow some of the best practices of patch management.
Inventory all network assets
A large enterprise can have hundreds of assets including servers, workstation, PCs, OS versions, third party applications and devices for remote access. The first step is to inventory all assets, so you know the scope of the patching operation. A complete inventory of assets establishes what you have, so you know what needs to be patched.
Have on file the inventory data on every system – including information such as hostname, location, IP address, MAC address, operating system and current revision level. While the information can be gathered manually, there are patch management tools for scanning a network that can provide a thorough inventory of all network assets – providing updates as needed. The inventory should be updated regularly as part of the patch management process.
Establish patching priorities
Assets should be prioritized based on exposure and risk vulnerability. What is the impact to the organization if a particular device is out of commission? Does this device need immediate patch deployment or a standard deployment (that could take weeks)? What is the sensitivity of information on a given device (like Social Security numbers or private patient data)? Is the device used for critical business operations, such as payment processing? Does it support the critical “public face” of a business, such as a main website?
Establish personnel that have authority to decide the urgency of patching activities – along with conducting vulnerability and exposure reviews of systems. Urgency reviews should decide whether there should be immediate action taken to patch or implement a workaround.
Establish a patch management policy
Having an established and documented patch management policy will help an organization protect itself from viruses and security vulnerabilities. The policy should document who is responsible for the patch management process, what should be patched, when they should be patched and how they should be patched. The policy should include a formal process for the deployment of patches but be adaptable enough to accommodate ad-hoc patching needs. It creates a consistent template that IT staff can follow but provides flexibility if something goes wrong during the patch deployment process.
Apart from deploying patches, a patch management policy should cover topics such as:
Monitor the patch status of all your applications
Always be aware when new patches are needed. The easiest way to accomplish this is by employing a solution that monitors your network patch status and notifies you automatically when patches are available. If budget is an issue, another possibility is to keep track of what applications you use and periodically check the respective websites for new issued updates.
The policy should include monitoring of current events. It is not always the case that a patch is released before a vulnerability is made widely known. It should also include a procedure for assessing emergency patches.
Always test patches
The patches are designed to work well in isolation, but in the real world, any computer will have more than one type of software. This means there is always a possibility for incompatibilities between a patch and other software. When deploying patches without properly testing them out, you risk that one of the patches might conflict and cause issues on the organization’s infrastructure.
Test the patches in an environment that mirrors your production environment. Review patch descriptions so the testing environment can include any known issues. It’s a good idea to test the patch on a handful of computers before applying it to the entire network. Include system reboots when testing so unanticipated reboots after patch deployment don’t affect regular business operations.
Document all patching efforts
Documentation is essential in case patch deployment issues arise beyond initial testing. Restrict access to configuration documentation including schematics and inventory lists. Limit access – including update capabilities – to authorized staff.
Deploy patches
As previously mentioned, the policy needs to include a notification to users when they can expect reboots or when they are required to have their machines available for a patch deployment. Apply the patch across the entire organization, if no issues were uncovered during the testing phase.
The biggest deployment challenge is to not disrupt production. If budget allows, evaluate automated patch management tools for patch deployment and maintenance. Find and use a tool that is the best fit for the size and complexity of your patch management operation.
Audit the patch deployment
Instigate a patch management audit to assess patch deployment and identify issues that require remediation. Analyze deployment logs and exceptions and formally validate that all deployments happened accurately. Monitor for any compatibility or performance concerns.
Be prepared for disasters
Establish a disaster recovery procedure, including details on how to revert bad patches or what the team should do if reverting to a previous version is not possible. Create a rollback plan that allows you to immediately reverse patches and go back to the pre-patched state. Again, review patch management tools to assist with these potential patch rollbacks.
Generate patch reports Document patching efforts to demonstrate compliance with regulations and to provide transparency of your efforts. Effective reporting can also help pinpoint potential issues that will help the team avoid pitfalls in future. Create detailed documentation and reports about patch download, testing and installation for auditing and compliance.
Once your organization has completed these steps, it should become easier to follow the audit checklist repeatedly. Each audit iteration should include evaluating possibly outdated machines, a policy review and deciding whether certain policy exceptions are still needed.
Downtime can be costly, so it’s important to follow preventative procedures before upgrading a server. While the following list is not exhaustive, it provides many tips on how to minimize the consequences of downtime and ensure business continuity.
It’s best not to perform network upgrades until you know a verified backup exists. Inspect backups for physical and virtual machines on a regular basis to check whether they can do a restore. Upgrades can fail, so use disk cloning technologies or disk images to recover data as well as a server’s configuration.
Monitor servers for problems before they fail. It’s useful to have a network monitoring solution that provides alerts on out the ordinary events such as high CPU or memory usage or a sudden server self-reboot. After upgrading, monitor critical events such as log files, error reports and backup operations. Periodically check other devices like switches, workstations and firewalls to make sure settings are all correct. These tasks can also be automated with network inventory and network configuration management software.
Be sure to confirm the operating system by performing a quick audit of the system you’re upgrading to confirm OS compatibility. Also, confirm that the chassis supports the upgrade. It’s best to actually open the case to find out whether the deployed server will work with the upgrade. Finally, don’t make assumptions about a device’s plug-and-play capabilities with the server’s OS. Verify that the device component is listed on the operating system vendor’s hardware compatibility list.
While on the surface, minimizing server restarts sounds like a good idea, it’s best not to perform multiple simultaneous upgrades with a single shutdown. Whether you’re adding disks, replacing memory or installing additional cards, the safer route is to perform these tasks separately. If there’s a problem, it can be hard to isolate what change was responsible for the error if there were multiple concurrent changes.
Once you’ve upgraded a server, update the documentation with information such as the component that was upgraded, the manufacturer, the vendor, order numbers, serial numbers – as well as warranty and support information. Also, document your operating procedures and make them easily accessible to employees to avoid downtime from human error.
A well-rehearsed recovery plan – where staff knows exactly what to do in an emergency – is key to minimizing downtime. Some organizations have a secondary data center site so if the primary site goes down, the secondary site keeps the organization up and running. Others use data backup and cloud services to avoid permanent data loss and to help the organization quickly recover from a disaster.
Over the last few years, automated patch management tools have emerged to take this pressure off administrators and to improve the overall efficiency of downloading and installing patches across different devices. As a result, every organization can update all its endpoints with the latest patches and with little human interference, regardless of its hardware specifications and geographical locations.
But how do you choose the right patch management software, given the large number of patch management tools available today? Here are some capabilities that should be present in any good automated patch management software:
The best patch management strategy for 2019
Learn six steps that can help you deploy an effective patch management strategy.
Exploring automated patch management solutions
Find out how automated patch management solutions go hand in hand with your vulnerability management program.
Download a 30-day trial of GFI LanGuard that includes Patch Management for Windows®, Mac OS® and Linux®
GFI LanGuard for patch management
Discover why thousands of IT admins worldwide use GFI LanGuard to scan networks for vulnerabilities, automate patching and achieve compliance.
GFI LanGuard Step by Step Guide
This step by step guide helps you understand how you can maintain a secure and compliant network with minimal IT effort.
GFI LanGuard free trial
Download a 30-day trial of GFI LanGuard that includes Patch Management for Windows®, Mac OS® and Linux®.
GFI LanGuard product features
Get an in-depth product understanding from this extensive library of videos and information.
How to deploy missing patches with GFI LanGuard
Watch this video and see how to quickly and easily deploy missing patches using GFI LanGuard.
