Approval paths can be time drains down which patch promptness can all too easily drown. Because even the most efficient patch deployments can cause downtime, it's important both to make technical issues clear to nontechnical staff who must sign off on the patch, and to ensure IT understands the business implications of the patch. Communicating clearly in advance that you need to add extra time to the email server's scheduled maintenance, for instance, takes less time than explaining during the downtime why it's taking so long.
"Preapproval of patch deployment authorities is not only an important aspect of an organization's emergency plan," says Andrew Bosch, product manager at Symantec, "[but] it can save vital time and anxiety in critical situations."
With the right people identified in advance, especially in relation to critical systems, "You're not going to be chasing people in the middle of the night to find out when you can patch a critical server," Bosch says.
This one should be among the simplest and most straightforward steps, but bear in mind it involves people, authority, and almost undoubtedly politics, each of which could add to the time required to get sign-off on the sign-off list.
Time-saver: Create and maintain a comprehensive patch deployment approval and sign-off path along with your systems inventory, including emergency and off-hour contact information for all personnel on the list.
4. Take time to test patches before going operational.
Even the most critical and time-sensitive patches, such as those that seal holes that are being actively and aggressively exploited in the wild, must be thoroughly tested before deployment. In fact, those critical and often rushed-to-distribution patches could require more testing before you unleash them on your systems.
So it's crucial that your test platforms and procedures related to them be established and in place constantly, not just assembled on an ad-hoc basis the day of a patch release.
Symantec's Bosch recommends building one day of test time into your planned deployment schedules.
Pay attention as well to patch-testing with new and emergent technologies your organization is using, and with an eye toward easily overlooked things. Don't forget virtualization software and virtual machines, for example.
The initial time investment required to include and establish all systems in your ongoing test platform, and especially the time required to add new systems and applications as soon as they are introduced, will be offset by the time savings achieved by your familiarity with those systems when patches for them are released.
"Patch testing shouldn't be an adventure every time," Bosch says.
Time-saver: Establish comprehensive patch test platforms, including platforms for new technologies and configurations ahead of time, and make their maintenance, readiness, and upgrades an ongoing part of your operations overhead and budget. Build a day of patch-test time into your patch deployment schedule.
Meanwhile, patches, both scheduled and emergency, require planning and time allocation.
You must address in advance the time required to prioritize, schedule, authorize, and test both the patches themselves and your organization's ability to manage patch deployment -- in both technical and business operations contexts. That's the only way to ensure a relatively painless patch process.
Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.