The Conficker saga highlighted this tardiness last year after a flood of computers were infected by the worm over several months, even after a patch was made available by Microsoft in October 2008. In April 2009, Sophos' senior technology consultant Graham Cluley blogged that 11 percent of users who had taken the company's endpoint assessment test online, had yet to patch their systems.
Patch management is not the only aspect of enterprise security, but security vendors point to it as an important piece of the corporate IT protection puzzle.
ZDNet Asia spoke with three industry experts to highlight some essential elements that a sensible patch management strategy should include:
1. Vulnerability assessment
Ronnie Ng, Symantec's senior manager of systems engineering for Singapore, said in an e-mail that organizations need to constantly identify vulnerabilities and assess risks, in obtain to obtain "an accurate snapshot of possible threats to their IT environment".
Policies for patch management and risk mitigation should also be habitually reviewed, Ng added.
2. Patch acquisition and testing
Enterprises, he said, ought to monitor closely the availability of patches or updates. "The available patch's relevance and criticality to the IT environment should then be determined, and its source and integrity verified."
IT security administrators must also ensure patches will not damage or come in conflict with existing configurations or applications, he added. This can be achieved by deploying patches in a test setup that closely mirrors the production environment.
On top of that, the network should also be validated to ensure it can sustain the updates, said Ng, adding that patches should be deployed in a controlled and predictable fashion.
3. Smart patch deployment
He noted that communication is an important aspect during the deployment phase. When implementing patches, businesses need to keep users informed of patch rollout schedules, he explained.
Mark Goudie, Asia-Pacific managing principal for investigative response at Verizon Business, pointed out that enterprises should minimize the patch packages, and keep things simple in their environment.
"Why use patch packages that you do not need? An attacker will happily use a package that you do not use but have installed on your system, to break into your enterprise," Goudie said in an e-mail. "The smaller the number of installed packages, the less moving parts in the system and therefore, [fewer] things can go wrong."
At the end of the day, organizations should not rush to patch as breaches resulting from of zero-day exploits are rare, he said. "The 2009 Data Breach Investigations Report showed only one vulnerability exploited that had a patch available for six months," he noted. "The other exploited vulnerabilities that led to a data breach had patches available for more than a year."
Patrick Chan, IDC's chief technology advisor for emerging technologies, said in an e-mail interview that enterprises need to have a contingency plan in place for "rollback", should a particular patch happen to "break" the system.
Forward-looking organizations, he observed, are taking proactive steps to refine their patch management practices, including centralizing patch management efforts and roles, testing patches within enclosed virtualized environments before implementation, and leveraging virtualization technologies to patch a single image and deploy to many instances.
Putting in place IT governance relating to the use of automation tools, Chan added, is "imperative" for organizations. This includes logging actions and changes made during the patching process.
"Some organizations are increasingly looking to shift some of these responsibilities to their outsourced vendors and cloud computing platform providers," he said. "However, for on-premise assets, organizations still need a stringent practice [such as] ITIL (IT Infrastructure Library) to introduce lifecycle approaches to patch management."
4. Patch consistency
After the deployment, organizations need to verify that patches have been properly and successfully applied to all systems that require the update.
"Patching must be done completely; companies can't afford to miss a few systems [because] they were hard to patch, or the patch did not apply and no one checked it," Goudie pointed out. "Hackers will check your patch management systems for you."
To that end, development and testing systems ought to be included, he said. "If the system has production data or access to production data, it must be properly patched and managed.
"Speed is not the key to being safe, consistency is," said Goudie.
Symantec's Ng added that enterprises should carry out regular inventory checks on both hardware and software so that they have an updated view and are kept up-to-date on the resources that need to be protected.
5. External validation
According to Goudie, enterprises should also seek a third-party view of their patch management environment. "We all tend to look at our own work and see what we think is there, rather than what is really there.
"Get someone from a different part of the company--an auditor [or] a consultant to review your patch management system and processes, and test what has been deployed," he said.
Should fixed schedules for patching be eliminated?
Symantec's Ng noted that the time difference between the announcement of a vulnerability and the release of an exploit code, has "shortened dramatically", where businesses now have less than a week to patch holes. In addition, attacks are also becoming more malicious and sophisticated.
In view of this, software vendors and developers should not just focus on a fixed patch schedule but instead employ a combination of a fixed cycle, and a "when necessary" routine for greater flexibility and ability, he pointed out.
"However, it is important to realize that patch management is a two-way street," Ng said. "Vendors may provide the relevant patches in a timely manner, but it rests with the organization to apply them as quickly as possible.
"The failure to deploy patches promptly or correctly can bring about significant impact to the organization such as mass outages, security breaches and loss of revenue."
Software players are typically hesitant to issue patches out of their regular schedules. Last month, Adobe Systems' Brad Arkin said in a blog post that the company decided not to produce an out-of-cycle fix for a vulnerability in its Acrobat and Reader, as it would take about two to three weeks to code and "negatively impact the timing of the next quarterly security update" scheduled for Jan. 12.
However, Microsoft last July deviated from its monthly Patch Tuesday to release an emergency patch for a critical vulnerability in Internet Explorer and a less severe one in Visual Studio.
Verizon's Goudie said the regular patching cycle has its merits to organizations--offering them "predictability" and ensuring there are available systems when needed.
"The current status quo of a fixed patch cycle is what all enterprises have based their patch management processes around, and a change to on-demand patching would require a major retooling for many enterprises," he pointed out.
IDC's Chan noted that patching schedules may not be an issue in future. "Software are surfacing with capabilities to self-repair, automatically patching errors in deployed software."
In the "near future", the research firm expects more patching systems and processes to become more intelligent and real-time in fixing software, he said.