Wednesday 4 January 2012

Three reasons why IPS and WAF won’t converge anytime soon

Continuing on the IPS vs WAF theme, one might consider the notion that WAF will just converge with IPS. I wanted to point out three reasons why I think this will NOT happen anytime soon. The reasons center around demand, performance, and implications, and feed into each other.

It’s akin to Chris Rock’s joke about driving a car with your feet: You can drive your car with your feet if you want to, that don’t make it a good __ idea!

1) The key reason why we won’t see IPS and WAF converge anytime soon is the associated performance implications and potential to decrease IPS security protection.

Typical IPS deployments are inline, which makes the IPS’ performance critical in order to avoid network delays. Take for instance an IPS that is ASIC-based with Deep Packet Inspection, performing inspection at wire-speed across multiple interfaces.

For an IPS, the filtering and packet inspection happens in memory through packet disassembly and analysis as the packets come through. Each packet related to a stream is tagged and the IPS compares the stream to its signatures, using the usual statistical mojo employed on these devices. The IPS is doing this for all TCP and UDP packets. Once the stream is analyzed it is discarded, most IPS perform this assembly & inspection task in parallel with multiple packets and streams.

For the IPS to work as a WAF, it now has to do extra work for the web-based streams. The IPS will now have to parse the stream, decrypt the SSL (which is another conversation entirely), normalize the HTTP portion, and process the elements inside looking for the usual battery of web threats. This also has to be done for the corresponding web server HTTP response data coming back. The IPS would then need to apply some method of learning to this traffic and reference it for future use. This entire sequence has to happen for ALL the web application traffic in parallel, without impacting all the OTHER protection the IPS is providing.

2) No market drivers: customers aren’t asking for it and no product evaluation is scoring for it!

Independent lab testing criteria is a good metric of (a) what customers are looking for in a technology, (b) broad index of what to look for during product selection, and (c) how products in a technology segment perform. I found it interesting and relevant to note that the NSS Labs criteria, and this is true of ICSA Labs as well, does not include SSL decryption as a requirement or even optional evaluation criteria. Gartner isn’t looking for it in their IPS Magic Quadrant. No SSL decryption would limit a WAF. In addition, the criteria isn’t geared toward application footprinting or analysis.

If product evaluation criteria and market forces aren’t calling for or driving toward integration, no vendor is going to develop a product that combines the two. No vendor wants their IPS product to score a 17% effectiveness in lab testing. If you applied the ICSA Lab’s WAF criteria to any IPS on the market, I dare say none would pass.

3) Typical WAF configuration lends itself to producing a much higher volume of events/detects than an IPS!

An IPS performing WAF duties would likely not provide identical coverage of a dedicated WAF, so there would be even more events / detects generated with the IPS because the vendor is going to ensure their solution identifies as many threats as possible. Each event has to be stored and likely alerted to another system. Alerting is not a trivial task on any platform and web session event data is more resource intensive to store and forward than a typical IPS network event.

For anyone who hasn’t managed or monitored a WAF deployed in a high traffic environment or even a custom web application environment, let’s just say that the Positive Security model of a WAF is very chatty. The log and alert data contain the HTTP elements relevant to the event/detect, like HTML form elements, HTTP method, URL, Response Code, etc. After all, just like an IPS, on a WAF we typically block what we know is bad and alert on anything we aren’t 100% sure about for further analysis by a human.

Wrap-upThe overhead associated with the inspecting web sessions and processing the resulting event volume is enough to tax most dedicated WAF hardware, but to implement this same amount of workload on an IPS that is having to work at wire-speed, protecting ALL network traffic, is likely to degrade the IPS performance and jeopardize security protection.

No comments:

Post a Comment