Web Application Security: We Need Web Application Firewalls To Work. Better.
Jeremiah Grossman is just finishing up his keynote at the SANS conference on web application security. Jeremiah and I have talked a few times about the future of web application security, and we both agree that many current approaches just can’t solve the problem. It’s increasingly clear that no matter how good we are at secure programming (SDLC) , and no matter how effective our code scanning and vulnerability analysis tools are, neither approach can “solve” our web application security problem.
We not only develop code at a staggering pace, we have a massive legacy code base. While many leading organizations follow secure software development lifecycles, and many more will be adopting at least some level of code scanning over the next few years thanks to PCI 6.6, it’s naive to think that even the majority of software will go through secure development any time soon. On top of that, we are constantly discovering new vulnerability classes that affect every bit of code written in the past. And, truth be told, no tool will ever catch everything, and even well-educated people still make mistakes.
Since these same issues affect non-web software, we’ve developed some reasonably effective ways to protect ourselves on that side. The key mantra is shield and patch. When we discover a new vulnerability, we (if possible) shield ourselves through firewalls and other perimeter techniques to buy us time to fix (patch) the underlying problem. No, it doesn’t always work and we still have a heck of a lot of progress to make, but it is a fundamentally sound approach.
We’re not really doing this much in the web application world. The web application firewall (WAF) market is growing, but has struggled for years. Even when WAFs are deployed, they still struggle to provide effective security. If you think about it, this is one big difference between a WAF and a traditional firewall or IPS. With old school vulnerabilities we know the details of the specific vulnerability and (usually) exploit mechanism. With WAFs, we are trying to block vulnerability classes instead of specific vulnerabilities. This is a HUGE difference. The WAF doesn’t know the details of the application or any application-specific vulnerabilities, and thus is much more limited in what it can block.
I don’t think stand-alone external WAFs will ever be effective enough to provide us the security we need for web applications. Rather, we need to change how we view WAFs. They can no longer be merely external boxes protecting against generic vulnerabilities; they need tighter integration into our applications. In the long term, I’ve branded this Application and Database Monitoring and Protection (ADMP) as we create a dedicated application and database security stack that links from the browser on the front end, to the DB server on the back.
There are a few companies exploring these new approaches today. Jeremiah’s company, WhiteHat Security, has teamed up with F5 to provide specific vulnerability data from a web application to the F5 WAF. Fortify is moving down the anti-exploitation path with real-time blocking (and other actions) directly on the web application server. Imperva is tying together their WAF and database activity monitoring. (I’m sure there are more, but these are the web-application specific companies taking this path I can remember offhand). They are all taking different approaches, but all recognize that “static” WAFs or code scanning alone are pretty limited.
Andre Gironda Jun 3
WAF’s will not work BECAUSE of the work that Jeremiah Grossman did. That he does not realize this is pure irony.
Take, for example, the Mass SQLi worm running around the web. Put a WAF pair at your Internet data center. When the Mass SQLi worm infects a user of your organization, typically the worm is going to take the VPN or private connection to that data center, circumventing the WAF. Sure, you can do threat-modeling on the network to prevent this problem, but people won’t (1).
Yes, ADMP solutions such as Fortify Software Defender and Imperva SecureSphere will protect the application in the above example (and many other examples). It’s just F5 and “appliance-based” WAF’s (I’m sorry, but to most of the world — WAF means security appliance) that do not typically work.
There are other solutions such as AOP point-cuts that can also be used (2). Let’s just stop using the word “WAF” so that we can differentiate the good solutions from the bad ones. I’m all for using ADMP and I’m hoping that it will catch on.
Mike Andrews recently blogged about “How to Improve the Web” (3). In his last section, `Monitoring’, Mike speaks to `behavioral monitoring [with an] undo capability’. This is similar in technology to RBIPS (4). I have seen RBIPS work, but again, it can have the same threat-modeling problems as WAF.
However, RBIPS does not have most of the operational problems that WAF’s have. If we need WAF’s/ADMP to work “better”, then what we need is not a technology solution. We need people/process solutions. Have you or Jeremiah Grossman ever implemented a WAF or RBIPS? I have been working on protecting applications at the operations-level for over 10 years. Together with groups of several people, I all but invented/designed (but not developed) WAF, RBIPS, and ADMP technologies. While they are all difficult to implement properly, the reason that RBIPS works so well for this problem is that it turns itself off in the default state, preventing large classes of false positives and other operational nightmares. I think this is what Mike Andrews was getting to above.
Since we have identified people/process as the missing link for any technology solution, let’s speak to it. People support Process supports Technology. You can’t have good Process without good People; you can’t have a working Technology solution without good Process. Why should any given organization spend all of their time working towards an operations-based plan for web application security people/process improvements (e.g. to get to “ADMP”) when they could instead spend a similar amount of time and effort improving the people/process side of their SDLC?
Andre Gironda Jun 3
Links:
(1) hxxp://labs.neohapsis.com/2008/05/22/easiest-way-into-a-company/
(2) hxxp://shmoocon.org/2008/presentations/AOP%20Talk.pdf
hxxp://shmoocon.org/2008/videos/Using%20Aspect%20Oriented%20Programming%20to%20Prevent%20Application%20Attacks%20-%20Rohit%20Sethi%20and%20Nish%20Bhalla.mp4
(3) hxxp://www.mikeandrews.com/2008/05/20/how-to-improve-the-web/
(4) hxxp://en.wikipedia.org/wiki/Intrusion-prevention_system#Rate_based
Ted J Jun 5
WAFs, DB sec, and packaged app sec are different customers, processes, infrastructure components, etc. The functions will indeed collapse, but are far more likely to do so into classes that share a common buyer, have technical synergy, are deployed in a similar location / technical function, etc. WAFs into a next-gen firewall? Sure. They’re both gateway / perimeter-oriented enforcement points, decide what gets in, are bought by the same buyer to support a common process. WAFs into Db sec? Different part of the infrastructure, different buyer, related but substantially different process (ex. audit). Crossing these boundaries is possible only by the very large (ex. IBM) or industry standards.