Recommended practices – Part-5: Software updates and patching

/in /by

This is a multi-part series on recommended IT practices for organizations and their end-users.  Additional parts will be included in upcoming newsletters.

In general, software manufacturers update their products for these reasons:

  • Resolve problems
  • Fix vulnerabilities
  • Make easier to use
  • Provide new features

The first two are of significant concern, particularly with operating systems (Microsoft Windows, Google DROID, Apple iOS, etc.) and with commonly used applications like Microsoft Office, Adobe Reader, etc.

Many operating-system manufacturers, especially those with large user populations (Microsoft, Google, Apple), release patches to address problems and security concerns.  These patches are typically small applications that either replace a portion of the operating system or update specific components (files) of the operating system.

Unfortunately, particularly with Microsoft Windows, patches that resolve an issue can often lead to unforeseen and unintended consequences; some patches actually designed to fix one area can break things in a different area.  Also, security updates are often time-sensitive; once released, it is important to apply them promptly.

Like operating systems, many popular applications require occasional updating.  Applications are typically not updated as often as operating systems, but their patching can critical to fix vulnerabilities.

The IT department or IT-outsourcing partner (i.e.:  Bryley Systems) of many organizations typically perform patch management with the objective “…to create a consistently configured environment that is secure against known vulnerabilities in operating system and application software.”2  These groups perform their patching in a cyclic fashion, often taking these steps:

  • Verify that the patch has a reasonable purpose in the environment,
  • Investigate its stability and usefulness by checking user forums,
  • Delay (if needed) deployment to ensure wide-spread acceptance,
  • Test it in the environment before deploying, and
  • Deploy and then validate this rollout.

If a rollout fails, procedures are in place to roll-back the operating system or application to its pre-patched state.  Periodic auditing and assessment is useful to ensure that the process is current and appropriate; audits should also identify systems that are not in compliance with the organizations patching standards.

Often, a Remote Monitoring and Management (RMM) tool – GFI, LabTech, Kaseya – or a patch-management tool – PatchLink, SolarWinds, Tivoli – is used to automate and centrally manage the process:  These tools permit the timely, managed deployment of patches and updates to groups of computers.

Notes:

2 Quote taken from the article by Jason Chan of PatchManagement.org “Essentials of Patch Management Policy and Practice”, but actual article is an excellent, in-depth treatise on this subject.

Other resources: