First, some justification. Patch management is still a poorly practised discipline. I can't think of a single audit report either written or reviewed by me that didn't mention missing patches as a finding. This is also a non-trivial issue. Patches drives attacks (you can read my vulnerability life-cycle for more justification), missing security patches really do put your organisation at risk, no matter how jaded we are about them.

Arguably, Microsoft has done the most work in making their patches reliable and easy to install. However, it's still possible for a highly experienced patch management expert to get things wrong in understanding the impact (and hence appropriate prioritisation) of a patch.

However, the people within your organisation responsible for 'patch management' are usually fairly low level techies. It is often seen as a plumbing and maintenance issue. You certainly don't have your top sysadmins jumping to it every Tuesday to put together a regression testing schedule and work out which machines to prioritise the deployment to. In South Africa, things are a little worse, where there appears to be an increasing dearth of top sysadmins, as many of them move up into less technical managerial positions away from the care of the metal, thankful to leave plumbing issues like patching behind them.

This is where the disconnect comes in. Even with a comprehensive toolset to easily deploy patches. The technical and security experience required to properly understand the affects of a patch, coupled with the operational and organisational experience required to understand those applied to a specific organisation are quite large however this maintenance issue is usually given to a junior technician. Additionally, even though Microsoft's patches have improved their stability dramatically, people still err on the side of caution and tend towards non-deployment. This disconnect can be resolved via an organisation patch management policy that codifies much of that experience, but in the words of haroon "Management don't buy into who cleans the fridge or when the light bulbs are replaced." For the same reason low-level techies are sent to do the patching, management are unlikely to spend money and time getting patch management right. The right way to cut through that is with a risk-based argument, although not every organisation has a risk-management function motivated to do much about patching. Why? Because it's boring. Not only is it boring, it's repetitive; every month there's more. I personally find it very hard to care about patches these days.

However, these are the problem in the case of some of the best patches out there. But the software stack deployed on your average desktop, let alone across the organisation is far more complex, and most third-party vendors haven't gotten their patch process up to the same level as Microsoft. Even if they have, they often come with their own seperate infrastructure that many organisations are disincentivised to duplicate, and this isn't likely to get better any time soon. There are great tools out there to help with this, Lumension and Shavlik for example, however as per the previous paragraph this isn't the sexy sort of problem people want to spend lots of money on, and getting everyone to run Debian, while ideal, is impractical :)

So that's my litany of problems around patching. While quite different from several years ago, much of it remains the same or is just a subtle reformulation. I don't see patching getting better, and I don't see people willing to spend much time (outside of select vendors) to make it better. But the risk remains (and your IPS which you never check anyway won't save you).