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.

The 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.

What are your thoughts?


Posted on January 2, 2010, in Security / Risk, Security Management and tagged , , , , . Bookmark the permalink. 3 Comments.

  1. Although you may be right that IPS’ may not yet do a good job at being web application firewalls, the convergence as a regular traffic firewall is definitely coming, soon. As a matter of fact, its already here… but imo the IPS’s are yet full firewalls and the firewalls are full line-speed IPS’. There is definitely a market driver for it. its not all that rational to have multiple security devices inline… except that when trying to get the best performance and best security, we have no choice.

  2. Very informative information. Can you please respond to my below query?

    If I am decrypting SSL at WAF do i need to also enable SSL decryption at the IDS/IPS?

  3. Short Answer, yes, both WAF & IPS must decrypt traffic to be effective. Ideally, one box would be able to search for all signature-based attacks, and application-level attacks. Unfortunately, I don’t know of a WAF that addresses generalized OS, generalized web and web app attacks. Nor do I know of an IPS that cares enough about the application. Yet another reason for the convergence: The very resource intensive process of decryption would be done only one time if it was on one box.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: