6. Conflicting binaries
Sometimes a patch from Vendor A may not install successfully due to binaries installed by a patch from Vendor B. Over the course of year I think this has improved but once in a while you will face this situation.
Recommendation: If possible, do not overload the same server with products from multiple vendors and use dedicated servers for discrete business function to reduce conflict between multiple software programs. A good infrastructure to test will go a long way in identifying these conflicts early.
7. Third party patches
While your vendor is working on developing a patch to fix a vulnerability, the security researcher (or his company) that identified the vulnerability released his or her private patch. Do you install this third party patch or wait for a patch from the vendor?
Recommendation: The urgency of the situation and credibility of the third party patch creator play a vital role here. For most situations I advise not installing such a third party patch as it may break something else, may not be correctly tested or in the worst case could come from an imposter with malware embedded inside the fake patch. Try to implement the workaround provided by the vendor first before exploring third party patches.
8. Expired Licenses
What do you do when a new patch will not download or refuses to install because the software license or support has expired? Mistakenly expired licenses or deliberately used pirated software will not install patches.
Recommendation: Mistakenly expired licenses mostly reflect lapse in the administration of the system. Try to find the root cause and make sure you have proper policies in place. In some countries pirated software is common, but creates a breeding heaven for viruses and worms. Make sure you tie up with respectable vendors. Use vulnerability scanners or asset managers to finding unauthorized installations of software in your organization.
9. Patching kiosks, industrial control systems or critical infrastructure
Kiosks, industrial control systems, critical infrastructure or SCADA systems are increasingly using standard operating systems like Windows or Linux. But their version of Windows may be a slightly modified version of the standard OS - which has been customized by the SCADA vendor, so when Microsoft releases a patch, it cannot be installed on these systems. These systems have to wait for the customized or recompiled patch from the SCADA vendor.
Recommendation: Demand from your vendor expedite re-release of such custom patches. If the standard patch can be installed; demand from your SCADA vendor some sort of guidance on the safety of installing the standard patch on your critical infrastructure or factory floors.
10. Large number of patches
In the last few years we have seen unusually high numbers of patches and patches which fix tons of vulnerabilities. Itís very difficult to cater to such a high number of patches.
Recommendation: We cannot control how many patches are released by vendors. But with proper asset management, patch management tools and correctly maintained infrastructure we can prepare ourselves better for the dreaded patch day.