IPS or WAF Dilemma

As they endeavor to secure their systems from malicious intrusion attempts, many companies face the same decision: whether to use a web application firewall (WAF) or an intrusion detection or prevention system (IDS/IPS).  But this notion that only one or the other is the solution is faulty.  Attacks occur at different layers of the OSI model and they often penetrate multiple layers of either the stack or the actual system infrastructure.  Attacks are also evolving—what once was only a network layer attack has shifted into a multi-layer network and application attack.  For example, malicious intruders may start with a network-based attack, like denial of service (DoS), and once that takes hold, quickly launch another wave of attacks targeted at layer 7 (the application).

Ultimately, this should not be an either/or discussion.  Sound security means not only providing the best security at one layer, but at all layers.  Otherwise organizations have a closed gate with no fence around it.

Often, IDS and IPS devices are deployed as perimeter defense mechanisms, with an IPS placed in line to monitor network traffic as packets pass through.  The IPS tries to match data in the packets to data in a signature database, and it may look for anomalies in the traffic. IPSs can also take action based on what it has detected, for instance by blocking or stopping the traffic. IPSs are designed to block the types of traffic that they identify as threatening, but they do not understand web application protocol logic and cannot decipher if a web application request is normal or malicious.  So if the IPS does not have a signature for a new attack type, it could let that attack through without detection or prevention.  With millions of websites and innumerable exploitable vulnerabilities available to attackers, IPSs fail when web application protection is required.  They may identify false positives, which can delay response to actual attacks. And actual attacks might also be accepted as normal traffic if they happen frequently enough since an analyst may not be able to review every anomaly.

WAFs have greatly matured since the early days.  They can create a highly customized security policy for a specific web application. WAFs can not only reference signature databases, but use rules that describe what good traffic should look like with generic attack signatures to give web application firewalls the strongest mitigation possible.  WAFs are designed to protect web applications and block the majority of the most common and dangerous web application attacks.  They are deployed inline as a proxy, bridge, or a mirror port out of band and can even be deployed on the web server itself, where they can audit traffic to and from the web servers and applications, and analyze web application logic.  They can also manipulate responses and requests and hide the TCP stack of the web server. Instead of matching traffic against a signature or anomaly file, they watch the behavior of the web requests and responses.  IPSs and WAFs are similar in that they analyze traffic; but WAFs can protect against web-based threats like SQL injections, session hijacking, XSS, parameter tampering, and other threats identified in the OWASP Top 10.  Some WAFs may contain signatures to block well-known attacks, but they also understand the web application logic.  In addition to protecting the web application from known attacks, WAFs can also detect and potentially prevent unknown attacks.  For instance, a WAF may observe an unusually large amount of traffic coming from the web application. The WAF can flag it as unusual or unexpected traffic, and can block that data.

A signature-based IPS has very little understanding of the underlying application.  It cannot protect URLs or parameters. It does not know if an attacker is web-scraping, and it cannot mask sensitive information like credit cards and Social Security numbers.  It could protect against specific SQL injections, but it would have to match the signatures perfectly to trigger a response, and it does not normalize or decode obfuscated traffic.  One advantage of IPSs is that they can protect the most commonly used Internet protocols, such as DNS, SMTP, SSH, Telnet, and FTP.  The best security implementation will likely involve both an IPS and a WAF, but organizations should also consider which attack vectors are getting traction in the malicious hacking community.  An IDS or IPS has only one solution to those problems: signatures. Signatures alone can’t protect against zero-day attacks for example; proactive URLs, parameters, allowed methods, and deep application knowledge are essential to this task. And if a zero-day attack does occur, an IPS’s signatures can’t offer any protection.  However if a zero-day attack occurs that a WAF doesn’t detect, it can still be virtually patched using F5’s iRules until a there’s a permanent fix.

A security conversation should be about how to provide the best layered defense.  Web application firewalls like BIG-IP ASM protects traffic at multiple levels, using several techniques and mechanisms.  IPS just reads the stream of data, hoping that traffic matches its one technique: signatures. 

Web application firewalls are unique in that they can detect and prevent attacks against a web application.  They provide an in-depth inspection of web traffic and can protect against many of the same vulnerabilities that IPSs look for.  They are not designed, however, to purely inspect network traffic like an IPS.  If an organization already has an IPS as part of the infrastructure, the ideal secure infrastructure would include a WAF to enhance the capabilities offered with an IPS.  This is a best practice of layered defenses. The WAF provides yet another layer of protection within an organization’s infrastructure and can protect against many attacks that would sail through an IPS.  If an organization has neither, the WAF would provide the best application protection overall.



Technorati Tags: F5, PCI DSS, waf, owasp, Pete Silva, security, ips, vulnerabilities, compliance, web, internet, cybercrime, web application, identity theft

Published Sep 28, 2011
Version 1.0

Was this article helpful?