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. If all goes well, 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 consumers. 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 one to two days. Not much time for an administrator to test the patches and deploy without rushing.
I heard a rumor, 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. The idea is that by deploying alternative defenses, the threat is successfully mitigated and administrators have enough time to thoroughly test patches before deploying them.
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 Snort -- using its signatures and preprocessors -- recognizes 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 defense a firewall rule, a quarantined network segment, or just simply packet dropping?
Internet Security Systems (ISS) has an interesting solution in their 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. They review the request, the vulnerability, the client’s defenses that are managed by ISS, and then deploy an appropriate alternative defense.
For example, during the last Snort exploit (such as the Snort Back Orifice preprocessor overflow), an ISS client knowing that their environment contained vulnerable Snort versions could click on the Apply Virtual Patch button. ISS would then develop a remediation plan: The solution could install a new signature in one of the client’s IPS systems to detect and drop exploit packets, develop new firewall rules that deny access to the ports the Snort preprocessor is listening on, quarantine the Snort sensor machines, or implement another remediation effort as deemed necessary. Best of all, according to ISS’s service level agreement, all of this must happen within two hours of the single button click.
Of course, the VMS solution leverages clients with ISS-managed services and devices. There are a lot of IPSes 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 recognize the vulnerability, know that the client has vulnerable systems, and then apply an appropriate action, such as dropping malicious packets. 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 IPSes are rarely 100 percent accurate on their 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 defenses in between critical patching are a welcome tool in any defense-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.