Patching Best Practices for Virtual Machines and Servers

Patching is necessary to keep servers secure from attackers and viruses as well as free from bugs, which can sap productivity. Designing your server and virtual machine infrastructure to suit service levels and future change management will save you time and potential outages when the time comes to patch—and when it does, these simple best practices will help smooth the process.

General Patching Best Practices

Inventory documentation

You’ll need to know the status of your infrastructure in order to find patches and track what needs protection. Include physical servers, hypervisors, virtual machines, and software on each machine. When performing inventory, the opportunity is ripe to update software that is no longer supported, like old versions Internet Explorer.

Keep an eye on common targets

Microsoft seems like an obvious choice here, but the most commonly exploited software is Java from Oracle and Acrobat, Flash, and Reader from Adobe. Be sure to keep all of these up to date.

Schedule regular patching

Check for patches and updates at least once per month if not more frequently. If your company can’t handle the additional workload, consider working with a partner for managed services, vulnerability management, or security services.

Automate patches if feasible

This saves time for IT and also eliminates some level of human error. It is also required for some compliance and regulatory standards. Automation can lead to problems when it comes to proper testing for compatibility errors, but many auto patching tools offer some level of control over deployment.

The Patching Process

The first step in patching is simply finding necessary patches. Most software includes update tools to check for the latest patches, or you can hit vendor websites. Microsoft groups patches in ratings from Critical to Low:

Critical: Vulnerability could allow the propagation of an Internet worm without user action.

Important: Vulnerability could result in compromise of the confidentiality, integrity, or availability of user data or processing resources.

Moderate: Exploitability is mitigated to a significant degree by factors such as default configuration, auditing, or difficulty of exploitation.

Low: A vulnerability whose exploitation is extremely difficult, or whose impact is minimal.

Obviously critical and important patches should be installed first. Most organizations perform critical updates in 48 hours, including testing, to limit vulnerability. Lower priority patches can be tested for longer to eliminate compatibility problems, or even ignored all together. Treatment of low priority patches all depends on the risk level acceptable to your organization.

Preparing to Patch

When preparing to patch you should try to figure out what effect the patch will have on the server or virtual machine, from file version conflicts with existing software to system-level dependence.

Testing should be performed on isolated virtual machines and included installation tests, verification tests, execution tests, and rollback tests. This checks each stage of the patch install, to make sure that it will install without errors, that all files, registry keys, and shortcuts created by the patch are functional, that all existing applications and networking still work, and that if necessary the patch can be uninstalled or the server/VM rolled back to a previous version.

Luckily virtual machines are easy to clone, test, and roll back to older versions. Make sure to check all configurations in your environment, including different operating system versions, core productivity applications like Office, security tools like antiviruses, mail servers, databases, etc.

Rolling Out

After initial testing, prepare a plan to roll out patches to larger environments. Note that if you are updating the hypervisor itself, the virtual machines may need to be paused or shut down in order to install updates.

Depending on your organizational policies, you may have various service levels. If patching a server and not a virtual machine, VMs can be migrated to other host servers in order to avoid downtime. Be sure to schedule any patching that will impact critical systems outside of regular business hours.

Virtual machines should be backed up, of course, via snapshot or third party software. Notify users of any potential access issues due to the patching process, then go ahead and let that patch rip. Test systems again after patching to make sure everything operates as expected, and roll back if necessary.

With a little planning ahead, patching can be a pain-free process that doesn’t take too much time from your IT team. Plus, the planning process helps identify additional problems like outdated software, misallocated resources, or even old VMs and storage that is no longer needed.