1. What is a patch management audit checklist?

2. Patch management audit checklist – ten important steps

3. How to prevent downtime while updating your company systems

4. Deciding on patch management audit checklist software tools

5. Blogs

6. Additional resources

What is a patch management audit checklist?

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.

Patch management audit checklist – ten important steps

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.

1. 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.

2. 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.

3. 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:

   • Handling cases where a patch isn’t available. Include details of what the security team should do when an application or operating system component requires patching, but that patch is not yet available.
   • Cover all patching requirements. Applications that are not connected with the operating system also require patching because they can be a security risk. It is important to ensure no application is overlooked during the patch management process.
   • Patch deployment timing. The patch management policy must list the times and limit of operations for the patch management team. The policy needs to include a notification to users when they can expect reboots or when they are required to have their machines available to deploy patches.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

9. 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.

10. 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.

How to prevent downtime while updating your company systems

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.

• Be sure to have backups
  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.

• Closely monitor before and after upgrading
  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.

• Don’t trust … verify
  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.

• Upgrade step by step and not all at once
  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.

• Document what you do
  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.

• Create a detailed disaster recovery plan
  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.

Deciding on patch management audit checklist software tools

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:

• Works across different platforms and operating systems – including Microsoft®, MAC OS X® and Linux® operating systems, Amazon Web Services (AWS), other cloud platforms, as well as third-party applications

• Scans the entire network to identify missing patches across different software

• Downloads patches directly from vendors’ sites

• Includes efficient patch testing and deployment

• Provides detailed reporting to give administrators a complete idea of missing, downloaded, tested and installed patches

• Installs easily across all devices such as desktops, laptops and servers

• Integrated with automated patch management to help you save time

• Generates reports on the status of each update and relevant statistics about patch installs and updates for auditing purposes

Blogs

Additional resources