Patch Management: Prioritise before you mend

The clock counts down to Patch Tuesday and IT departments across the land go through the usual process of balancing the risk of compromise versus that of the patch killing the box. Do you leave the server vulnerable to a known exploit or do you risk the "blue screen of death" on a business critical service?

Some organisations have staging and test environments where they can try a patch, although this is time-consuming and can be costly. Others just apply the patch and pray, while some leave the box unpatched, often due to having suffered a bad experience in the past. None of these approaches are perfect, particularly in light of some hacker activity that's been going on.

"Zero day" is a widely used term, but true zero-day attacks are rare. They tend to be part of a focused attack against an organisation, often emanating from the Far East or the former Soviet bloc.

If we're lucky, then the organisation targeted in the attack has diligent IT security administrators who notice that something unusual is going on and flag the traffic to the vendor. This is often the start of the process towards the vendor releasing a particular patch.

However, there's a catch here: before the vendor publishes the patch and acknowledges the vulnerability, there will be a period of time where only a small number of hackers are aware of the issue and related exploit code.

Those on the "dark side" capable of finding new vulnerabilities and writing exploit code tend to keep their code to themselves and close associates, certainly in the short term.

As soon as the patch is released, the trouble starts for real. The patch will be reverse-engineered by anyone capable of doing so. They will work out what the patch fixed, find the vulnerability and write the required exploit.

Then, on the day after Patch Tuesday, exploit code is posted on sites such as milw0rm.com and metasploit.com. Now every script kiddie in the world has access to these "point and click" exploits.

The vulnerability isn't zero day any more, but who has actually patched by Patch Wednesday? Those who carefully test patches for system stability probably won't have done. So should you just deploy untested and take a risk, in the hope of mitigating the more serious risk of compromise?

A very real window of exploitation is present just after vendors release patches, so you HAVE to be on the ball at this point.

Vendors occasionally release out-of-cycle patches, usually for highly critical vulnerabilities. These require particular attention by the end user as you can be certain that script kiddies and worm authors will exploit these.

It's also possible to buy exploits on the public internet; for example, take a look at wslabi.com. Unbelievably, it's an online auction site for new exploit code. It appears to operate as a resource for the security community and has the best intentions (we hope) - aiming to alert users to new threats - but there doesn't seem to be much to stop the hacker from snapping up a handy zero-day exploit.

Take a look at milw0rm.com and metasploit.com to familiarise yourself with the arsenal of exploits available, but use caution - these are hacker sites, so you might not want to browse them with Internet Explorer.

It seems rather ironic that patches, which are after all issued to prevent security issues, could actually be causing them. Unless you can react quickly enough to apply the patch, you become a sitting duck.

A more pragmatic approach to patching would be to first ensure that you have a process in place to make you aware of critical patches. Assess these first, then test and deploy these crucial patches only, before you start dealing with less critical issues down the line. Prioritisation is the key.

- Ken Munro is managing director of SecureTest. He can be contacted at ken.munro@securetest.com.

beforesecurityyou