Timely patching of information technology systems is critical to maintaining the operational availability, confidentiality and integrity of information assets. Our hosting partners provide patch management at the network, hardware and operating system level. We are responsible for patch management of our software (OrgChart Now) and any associated software components.

Audience

All developers and data center ops staffs.

Purpose

This article describes a best practices approach to managing how patches are evaluated and applied to various software components without our solution.

Patch Management Procedure

The following procedure is repeated on an ongoing basis. Phases may be revisited as new issues arise.

  1. Identification Phase – The identification phase is used to access software updates and whether they are relevant to the our environment.
  2. Evaluation Phase – Patches are evaluated by the appropriate personnel (developers or data centers ops) to ensure they work as expected
  3. Planning Phase – Determination is made if and when identified patch need to be deployed (e.g. on an emergency or standard patch timeline). Potential risks are also identified.
  4. Deployment Phase – Actual deployment of patches per the schedule defined in the Planning Phase
  5. Post-Implementation Review – Any open issues or potential improvements should be recorded

Identification Phase

Patches are identified on an ongoing basis as part of the standard development cycle.

Patches are identified through various channels that include:

  1. Security testing – Vulnerability Scans and analysis of CERT Advisories
  2. Vendor repository scanning – Analysis of software updates that may be beneficial to our systems
  3. Developer initiated – Fixes and enhancements generated by our developers

Patches provided by external vendors must be verified through one of the following processes:

  1. Are the patches from a trusted source?
  2. Has the patch been vetted through a third party advisory group

Evaluation Phase

Patches are evaluated by the appropriate personnel (developers and/or data centers ops staff) to ensure they work as expected.

Criteria for evaluation include:

  1. Threat Mitigation – an action with the potential to cause damage.
  2. Vulnerability Mitigation – flaw, improper configuration or weakness that allows security of a host to be compromised.
  3. Value to End User – benefit to the end user.

A patch request may be denied or deferred based on the review during the evaluation phase.

Testing is a key component of the evaluation phase. The following guidelines should be followed with respect to testing patches:

  • Where applicable clone the configuration of the production environment in a staging environment that is as close to production as feasible.
  • After applying the patch to the staging environment, assess whether or not the patch resolves the intended vulnerability and does not cause failure of other functionality.
  • Re-run the vulnerability scan if applicable.

Planning Phase

Patches are deployed based on criticality:

  • Crtitical – Within 12HRS
  • High – Within 1 week
  • Medium – Depending on availability, deploy a new service pack or update roll-up that includes a fix for this vulnerability within 2-4 weeks.
  • Low – Depending on availability, deploy a new service pack or update roll-up that includes a fix for this vulnerability within 3-6 months.

Patches, when possible, are included as part of a product release cycle. This ensures that testing prior to release will include any functionality impacted by a patch.

Deployment Phase

The following guidelines should be followed with respect to deployment:

  1. Back up the production system prior to applying the patch.
  2. After applying the patch to the production environment, assess whether or not the patch resolves the intended vulnerability and does not cause failure of other functionality.
  3. Re-run the vulnerability scan if applicable.

Post-Implementation Review

After implementation is complete:

  1. Log any installation issues so they can be addressed by developers or data center staff
  2. Log any omissions, improvements or lessons learned.