Patch Management: Should it even exist?

From the outside in, it’s easy to question the need for software patching. “Surely,” some might ask, “If software was written properly we wouldn’t need the IT department to spend time patching it?”

The even more cynical might suggest that the whole thing is a money-making ruse – without the need for patching, we wouldn’t have an army of other software firms writing patch management software, and before you could say HFNetChkLT the world would be a poorer place.

By and large, though, most software is written properly. The market has come to accept that software vendors ship code with vulnerabilities and that part of the joy of ownership/use involves a semi-continuous programme of updates and improvements, whether they involve fixing bugs, adding new functionality or addressing security flaws as they are discovered.

The only way to reverse this state of affairs would be to hold off on all new releases for a few years while development teams perfected their existing product sets and worked out how to create ‘perfect’ software going forwards. Although most IT professionals would welcome the breathing space, it’s not going to happen.

So how does it all pan out for the IT department running countless different software applications? Microsoft’s ‘Patch Tuesday’ has become a fixture on many an IT professional’s diary. It’s probably not their favourite calendar date but at least they know it’s coming.

If every vendor has its monthly patch day we can easily appreciate why certain quarters of the IT industry talk about why we must reduce the ratio of effort between keeping the lights on and adding value, and are keen to offer tools designed to help IT departments do just that.

There is no shortage of tools in the market to help address patching activities and this may even play a part in making, or keeping, life complicated for the IT department. A tool which automates the patching process may sound like a great idea; but if your environment is currently patched on an ad-hoc basis (ie, with little or no formal processes in place to plan, test, track and report on progress) then implementing an automated system might not be the best thing to do immediately.

Then there is the question of which product or type of product to use. Vendors such as Shavlik, PatchLink and others offer ‘pure-play’ patching tools. But there are also tools which fall into this realm from related disciplines: change management, security management configuration management and life-cycle management to name but four. Then there are vendor specific tools, such as Windows-only tools from Microsoft.

Let’s be clear though. Patching is by no means a Windows only issue, but its ubiquity and programmatic bulk means that it will be forever both a target for nay-sayers/doers and an ongoing source of opportunity for Microsoft development teams and lots of others to boot.

Maybe the open source community has this area nailed. Continual, community driven change and development might just be a big cover-up for what the rest of the IT community using proprietary software sees as a pain, but at least it’s what they signed up for. And they get to say funny things like “Linux – it’s a patch for Windows isn’t it?”.
<br
But then, maybe it doesn’t. In reality, open source has its own challenges on the patching/testing side. For example, it puts even more onus on the IT team to work out what each patch provides, what it doesn’t address and how to test it.

Proprietary or not, until the day comes that every piece of software in use from a third party lives ‘in the cloud’, the need for patching will continue. And then it will still continue, but you won’t care. While we wait for that special day, who’s got it right/wrong/easy/hard in your world when it comes to software patching?

Content Contributors: Martin Atherton