Recommendation: Start with prioritization of assets and the applicable patches. Consult developers, testers and other system administrators for their opinions. You will be amazed how their input can cut down test cycles because incompatibilities are caught early on.

5. Too much virtual patching or workarounds

Virtual patching is a concept where instead of installing the actual patch organizations deploy a firewall rule, an IDS signature or an antivirus update that prevent attacks exploiting the vulnerability that is fixed in the patch. This technique has its merits and can be very useful to buy valuable time, but relying on it for too long can land you into trouble, because you have to track which assets have what virtual patches.

Recommendation: Whenever possible apply the real patch from the vendor. Use virtual patching only as a temporary arrangement while the patch is being tested or software is being modified to work with the newly released patch. Also do your homework — make sure you benefit from virtual patching where you get the best returns (for example in web applications), which is a bit of a different area than traditional virtual patches.

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.