Stripping

The basic idea behind current IPS involve two parts, detection and prevention. The first is the hard part, actually detecting the attack, sometimes developing a signature is easy and sometimes not. Take the recent WMF exploit as an example, it requires reading a significant amount of data before a proper match can be made (in the worst case the IDS will have to buffer the whole image). In addition, the many variations on the WMF that can be made (for example HD Moore's gzip encoding tricks and header padding) mean multiple signatures need to be developed. Virtual Patching seems to ignore this, it focuses on a white list approach, which is usually much better.

What a virtual patch would do in this case is strip out the SetAbortProc() code of the WMF. But then the same problem occurs and all benefits of whitelisting are lost. Now you have the same problem of detecting a malicious WMF, with the addition of trying to salvage some useful WMF from it, which has a mess of problems with it. It is interesting to not that this isn't 'virtual patching' as the markeing team would have you believe, there is no way a network device can actually modify the GDI+ code without an actual patch, this is stripping the malicious request.

Then, given the other DoS conditions found in the GDI library for WMF, an IPS that just blocked the traffic would have kept you safe from that, whereas the 'virtual patch' wouldn't. This isn't some magic trick, it is just that the idea of blocking malicious traffic works on the assumption that malicious traffic is evil and none of it can be trusted. The, example used in the rational security post is that of a $50 million wire-transfer. When the hell would a legitimate $50 million wire-transfer contain a malicious request? Even assuming it does, once you know the transfer has been compromised, you don't try and fix it and continue, especially in this kind of high risk situation. You have some kind of intelligent failover which hopefully involves telling the user they have been compromised and to try again from a secure terminal.

The other example given by rational security is an active FTP session, where a legitimate user then goes crazy and tries to delete everything. An awkward example, but let's run with it. An IPS can already handle this, it can deny the delete request and let the rest of the session run amok. You will have to jump through some TCP hoops if you want this behaviour, but it can be done. This is a DUMB way of doing things however. If you want to deny all users from using the delete request then disable it in your FTP server, don't try and filter it out of the network traffic, this needs to be conducted in the application layer.

In summary, stripping a known malicious request of it's know bad parts is a bit like letting known criminals into your bank vault after taking their gun. It has the same complexity and problems in detection, but has a silly solution once detected.

Is this an IPS wearing a marketing frock?

It depends on your taste in frocks, but from where I am standing it seems this is an IPS with a slight difference. It suffers from all the same difficulties an IPS suffers in detecting attacks and the difference will more likely expose you to more risks rather than less.

Q: But, what about defense in depth? Why not use Patchpoint AND an IPS?

A: Because it would be redundant. If the IPS blocks the request before Patchpoint, then Patchpoint doesn't do any work, it is dumps it afterwards then Patchpoint wasted its time, if Patchpoint strips the malicious part and then the IPS lets it through, then you are exposing yourself to potentially malicious traffic for which a signature hasn't been developed yet.

Oh wait, there is one potential benefit of Patchpoint: the employees could produce high quality detection signatures. In this case, it should be compared to something like snort to see if their few employees do a better job than the snort community, I mean you could always turn off the inline patching and have it block malicious traffic. Given the price of the thing (starting at $30 500) it better be MUCH better than (the free) snort. If you are going to pay money, pay it to Tenable.

To quote Thomas Ptacek's Second Rule Of Security Marketing

If your inline network security device claims to provide "virtual patching", the box must use the actual binary patch from [the vendor] to do it.

UPDATE: Chris of RationalSecurity has responded, I don't think he adequately dealt with my points. Although he is being a good sport about it.