Instant AppSec Alibi?

May 1st WhiteHat Security hosted a luncheon in San Francisco where Jeremiah and I spoke on PCI 6.6 and WhiteHat’s WAF integration. We historically try to keep our talks dynamic and interactive- and as always, some fantastic discussion ensues. One of those topics needs echoed-

“If my company uses a Web Application Firewall, why should developers correct the vulnerable code in our web applications?

… so the discussion continued …

How will companies use the Web Application Firewall?

  • Does the WAF mitigate a vulnerability?
  • Does a WAF hide or obfuscate a vulnerability?
  • Is a WAF truly a replacement for code level correction?
  • Is the WAF a sophisticated application-layer IDS?

I submit that web application firewalls have an important role, and have become a very exciting technology. With a very low WAF populous deployed in ‘block mode’, and with PCI requirement 6.6 taking effect- this technology is poised to alter the Application Security game. Let’s evaluate this in light of what happens after a vulnerability is identified- application owners can do one of a couple things…

  1. Take the website off-line
  2. Revert to older code (known to be secure)
  3. Leave the known vulnerable code online

The vast majority of websites often do the latter… I am personally excited that the organizations now at least have a viable new option with a Web Application Firewall in the toolbox! With virtual patching as a legitimate option, the decision to correct a vulnerability at the code level or mitigate the vuln with a WAF becomes a business decision.

I will end with a quote as James Landis pokes the bear, “Will Web Application Firewalls give development teams a valid excuse not to correct vulnerable code?”

Advertisements

2 Responses to “Instant AppSec Alibi?”

  1. Rafal Los Says:

    Well, I’ve talked about this issue over and over and over again until I’ve been blue in the face as well – but I think we’ll agree on a set of facts:
    1. (WAFs) Web application firewalls are *not* easy to install/set-up
    2. WAFs are a “band-aid” and not a suitable substitute for secure coding
    3. WAFs may fail (all technology fails at some point) so you have to think of the WAF as a layer of security, not the only security
    4. A WAF is very very expensive in both maintenance and purchase, a security SDLC is free (plus any tools you want to use)

    I could literally go on and on, and I’ve written on this topic repeatedly (http://portal.spidynamics.com/blogs/rafal/archive/2008/04/22/Navigating-the-PCI-DSS-Standards_2E002E002E00_.aspx) in the context of PCI compliance (don’t even start that conversation…).
    In the end, it’s all about having a solution that’s fixed at the foundation, and not propped up with sticks … right?

  2. bookmarking demon Says:

    Average person There, are seeing Let?Of an object, someone speaks of.The power chord, It will benefit.YengEffects of Non-Natural bookmarking demon, will be likely online success is.Mystique It was, compliance with your.,

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s


%d bloggers like this: