Server patching principles. The nirvana process

In the imperfect world we live in, patching stuff, be it desktops, software or servers is a fact of life. We do it or we risk being exposed to the latest security threat, missing out on new functionality or suffering performance degradation.

We discussed desktop client patching over in the desktop management workshop. In this leg of the workshop we’re all about servers, but in practice, is patching just patching? Beyond the obvious – a server running a critical application is more important to the business than a single desktop – is what you patch the real issue or is it more important to have the right tools and processes in place?

I’m going with process. Anyway, nobody in their right mind spends money on tools without first working out to at least some degree where and how they will be used. Erm, right? So what does a patch management process look like?

In practice, a series of stages need to be worked though to create and operate a process for patch management. Like most processes, those for patch management span more than one domain. The development, operations and security groups are all involved. There’s a list of things you need a handle on: hardware and network inventory, asset management, change and configuration management, not to mention a degree of formalized planning for areas such as costs, maintenance and communications plans.

Needless to say, you can’t set up a ‘proper’ process without an audit somewhere: creating an inventory of what software runs on what machines and linking this in with asset, change and configuration management, will do nicely. Then you get everyone to agree on monitoring for new vulnerabilities and available patches, and that representatives from the three groups will work together to ensure patches can be rolled out to a timetable which includes testing, distribution, exception handling, tracking and reporting.

When you look at all the pieces, the effort required to get a ‘proper’ process in place might look a bit daunting. However, not having such a process in place is almost guaranteed to be even more problematic, with service interruptions and security breaches more likely to occur and then requiring considerable fire-fighting effort to put things right.

But where do you start if you do want to make improvements? For many IT shops, the area of asset and configuration management may be the biggest challenge, especially if things have been allowed, for whatever reason – resourcing usually – to drift out of date. However, if you don’t know what you have in your environment, don’t know what version of x is running or don’t know what the last change made to a specific item was, you can’t do proper patching.

It’s not going to get any easier either. The spread of virtualisation technology poses some interesting difficulties. For example, how do you ensure dormant machines are patched? It may be worth getting some plain and simple measures in place right now to govern the virtual stuff. A starter for ten might be: ‘If your VM isn’t worth patching, we’re not keeping it.’

With all this in mind, if your IT shop has moved from a chaotic or simply labour intensive patching regime to an altogether happier place, you’ve discovered the ‘best tool ever’ or virtualisation is playing havoc with your regime, we’d love to hear all about it.

Content Contributors: Martin Atherton