1. Unknown assets
Before patching, one needs to find what assets are affected and therefore eligible for a patch. Larger corporations spread across countries or continents have a hard time getting an accurate handle on the presence of their assets. And if an asset is not known, it cannot be patched.
Recommendation: Use an asset management tool, inventory control system or a similar process to monitor assets. No tool is perfect, so try out different ones and select what suits your needs. Usually a combination of multiple approaches gives the best results.
2. Many patches require assets to betaken offline
Mission critical systems cannot be taken offline, but many patches require a reboot, which would result in a downtime.
Recommendation: There are some highly available products as well as many operational tricks that can be experimented with to avoid downtime. The solutions are different depending on the software in question ó a chat with your operation folks or system administrators can give you some ideas to begin. Use your solution in a test environment first before deployment, and if possible group down times together.
3. Scarce IT resources
It is safe to say that most organizations lack sufficient IT staff to cover all needs. IT is always stretched thin and many times resources are not available for quick deployment of all patches on the world wide assets.
Recommendation: While most IT departments use some sort of a patch management system, many of these systems are excellent in one area (like Windows patches) but weak in others (like database patches). Use a combination of manual and automated approaches to cover your entire asset base. Properly managed networks and assets go a longway when it comes to patching.
4. Unreasonably long patch test cycle
Before patching, itís logical to test if the patch will not break anything. For example it make ssense to test if a critical home grown custom application works correctly after the patch is installed. While a good practice, it can sometimes can buried in bureaucracy and then takes too long, giving attackers valuable time to create worms that target the unpatched machines.
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.