Patching is the most effective, efficient and simple method to mitigate malware, worms and viruses. It may not protect against advance attacks that make use of 0-day vulnerabilities, but for the most part it is an excellent cost effective and reliable solution. But many organizations have a hard time patching. This made me want to examine: what challenges exist and how can we address them? Here are some common hurdles for patching and tips that organizations can use to move toward a better patching posture.

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.