Patch vs Vulnerability Management – Gitt’er Done

According to a survey of 276 IT decision makers, 20% of organizations have admitted to being hit by a security issue due to patches not being up to date.  Many organizations still do not have adequate Patch Management or Vulnerability Management processes in place.  Despite popular misconception, Patch Management (PM) is not the same thing as Vulnerability Management (VM).  Many organizations think that if they have a plan for assessing and deploying patches, they have their security issues covered.  Not so fast!

Patch Management is the first reaction typically exhibited when a company comes to the realization that their vendors are releasing a steady stream of updates and patches to the products that the company has come to rely upon.  The sheer volume of products in use within an organization and the number of patches and updates issued in a year can appear overwhelming.  PM examines this problem from a procurement and deployment mindset.  We have this many apps, expect this many patches, and have this amount of time to deploy them.  PM relies on the application vendors to announce patches, requires a means to gather patches together to reduce downtime, a method for deployment (preferably automated), an agreement around the timing and prioritization of patches based on their types (Service Packs, functionality/performance patches, security patches), resource management, and must be coupled with an asset inventory mechanism to be effective.

The president of Qualys has estimated that 53% of companies are affected by downtime when it comes to deploying patches.   Another 29% of companies had IT teams conduct patching after hours, leading to significant increase in costs and impact on overtime and work-life balance.  Only 17% of organizations carried out patching without impact on the business or its IT staff.  It is not clear how many of that 17% were effective in their patch deployment efforts.  44% said the biggest pain point around patching is the frequency of patch releases, and the time taken to deploy.

Vulnerability Management takes a more proactive view of managing this daunting task, and encompasses more than just patch management.  Vulnerability Management requires more up-front planning and its end result is automation of many of the tasks that generally are performed manually in Patch Management efforts.  VM will require a regularly updated hardware asset inventory, a regularly updated software asset inventory, a means to scan those assets for current patch levels, some method to report what it has found, a clear and effective vulnerability assessment scale, definition of asset ownership throughout the organization, a means to deploy patches, and a means to validate that the patches or other mitigation techniques have been effectively deployed.

Vulnerability Management typically allows for the inclusion of additional mitigating factors, as it doesn’t necessarily rely on the announcement of vendor released patches to get the assessment and planning phases rolling.  The discover and announcement of a vulnerability can start things along, even before the vendor has completed the patch development procedure.  Other mitigations could include blocking access to or from an application to the Internet, removing underlying protocols required for exploitation, firewalling, additional monitoring, signature development, or even replacing the vulnerable application or technology outright.

To be effective, VM should be linked to or include PM, and both must be linked to deployment processes.  Automation of deployment and remediation validation processes will move VM & PM up the maturity ladder quickly and effectively in short order.

An organization can start to address their security exposures through Patch Management, but should do so with the intention and a roadmap to move to Vulnerability Management at some point in time.  The earlier this transition is completed, the better for the organization.