Manage Learn to apply best practices and optimize your operations.

Should management processes change based on a patch release schedule?

Expert Michael Cobb explains why planned patch release schedules, though helpful, may alter they way you handle the deployment of your own updates.

Now that more software vendors like Adobe are transitioning to a regularly scheduled monthly or quarterly patch release schedule, should enterprises adjust their patch management processes as a result? For instance, if we only push Adobe updates twice a year, should we change our process so that it is aligned with the vendor?
Earlier this year, Adobe was caught off-guard by a zero-day vulnerability in Acrobat Reader being actively exploited by attackers. The JBIG2 stream-array indexing flaw results in a buffer overflow, potentially allowing an attacker to take control of the affected system. Security experts and customers alike criticized the company's slow response, which has led Adobe to change its approach to software security. Adobe is modeling its Secure Product Lifecycle on Microsoft's Secure Development Lifecycle, created as part of Microsoft's Trustworthy Computing Initiative. As part of the drive to improve its patch testing and deployment, Adobe has committed to a quarterly patch schedule, releasing its patches on the same days as Microsoft. Adobe's first quarterly patch release took place in June, with the next released scheduled for September.

Because one of the most effective ways of protecting systems and networks is the timely application of security updates, I'm very much in favor of a planned patch release schedule. Most large software vendors have introduced scheduled patch releases to help improve the manageability and predictability of the patch-management process for their products. There is evidence that scheduled patches are of a better quality with more detailed advisories, and that more users deploy them. Other benefits of regular and scheduled patch releases include:

  • Predictability allowing for advanced planning, with increased time to evaluate and test.
  • Multiple fixes consolidated into one patch, reducing downtime and repeat testing.
  • Reduced implementation risks and impact on business processes and users.

Adobe's decision to align its patch releases with Microsoft's will make your job easier in many ways as you won't be faced with a constant stream of patches to test and apply. However, having to install several patches from different vendors at the same time requires careful testing to ensure compatibility. You have to ensure one patch doesn't break another. Personally, I think it may have been better to opt for a release date one or two days after Microsoft's. Nevertheless, being able to timetable known patch release dates makes the job more efficient and that much easier to plan. I would certainly recommend that you align your patch processes to those of your key vendors.

Obviously there are exceptions to any planned patch release schedule if customers are at immediate risk. Most vendors allow for "out-of-band" patches to be released as dictated by the urgency of the issue, and you should have a policy and process for dealing with situations that need remedying as soon as possible. Unfortunately, there's no standardized industry classification or patch-naming conventions, so it's important that administrators responsible for patch management fully understand the patch process operated by their vendors. This will help ensure they understand the relevance of the patch, pack or update and afford it the appropriate urgency.

This was last published in August 2009

Dig Deeper on Microsoft Patch Tuesday and patch management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.