The Good, The Bad, The Vendor
- 16 November, 2005 09:46
Patch management is tough business. First, somebody - a good guy, the vendor, or a bad guy - discovers a vulnerability. The vendor replicates the vulnerability, confirms the problem, and sets about making a software patch. The vendor's programmers and tech people find the root of the problem and come up with a solution. The solution is coded, and the patch is regression tested. After thorough testing, the patch is released to users. Administrators get the patch, determine criticality in their environments, install the patch in a test environment, and then deploy to their production environment. At least, this is the way it's supposed to be.
There is always that critical time between when the vulnerability is discovered and when the patch is applied. Often, the vulnerability becomes well-known because of the vendor's patch release; vulnerability testers and malicious hackers frequently reverse engineer the patch and create exploits that are then released into the wild or placed into some form of automated malware.
In the case of Microsoft's most recent patches, the time between two of the patches being released and exploit code being released was just one to two days.
I heard a rumour, which I haven't been able to confirm, that Microsoft was developing a new IPS-like product that would allow users to block exploits before they get a chance to execute against a particular system.
Actually, Snort inline already allows you do something like this. If placed on the appropriate ingress choke point, Snort can inspect every network packet coming across the wire. If it recognises a threat, it drops the packet or uses its replace feature to emasculate the malicious coding.
This is essentially what any IPS does. The trick is how to deploy the correct signature so that it catches the exploit; but where do you deploy the IPS to make sure it catches all the possible entry points? And is the best defence a firewall rule, a quarantined network segment or just simply packet dropping?
Internet Security Systems (ISS) has an interesting solution in its managed security service, Vulnerability Management Service (VMS). Using the ISS Web portal, administrators can learn about the latest vulnerabilities, run internal and external vulnerability scans, print reports and open vulnerability resolution tickets with ISS.
The feature I like best is the ability for approved administrators to click on a single button called 'Apply Virtual Patch' to deal with any new vulnerability. Clicking on this button results in the patch request being sent immediately to ISS support teams.
There are a lot of IPS alternatives that can do the same thing, but how many can do it with a click of the button, and within two hours of the original request?
True IPS solutions are supposed to do this sort of thing automatically in the first place, without any human intervention. The IPS should recognise the vulnerability, know that the client has vulnerable systems and then apply an appropriate action.
What I like about the ISS VMS, and any other vendor with a similar solution, is that experienced analysts are involved with the analysis and solution. Because an IPS is rarely 100 per cent accurate on its own, having knowledgeable humans on hand should theoretically make problem resolution more appropriate and better tested.
In either case, whether they're automatic or require human involvement, solutions that apply alternative defences in between critical patching are a welcome tool in any defence-in-depth strategy. As the time between vulnerability release and applied patching decreases, you should be looking at solutions beyond the traditional firewall and patch management answers.