There is no spoon.

I just read this article from TechTarget, quoting Gartner research vice president Ramon Krikken as saying:

[...] it may be time to ask whether it’s faster, cheaper and ultimately just as effective to use a device like a WAF to shield an application from a security flaw than face the unending cycle of developing, testing and implementing software patches. [...] I have an increasing number of customers starting to question whether putting a Web application firewall in front of an application to fix something is all that much worse than fixing the code.

And I agree that some apps can't be remediated in a short enough time span, others can't ever be fixed, and so on -- for those exigiencies where there's no other choice, a WAF is better than nothing (assuming it's actually in blocking mode and properly configured).

However, I would strongly caution anyone against deciding that the wave of the future is simply to rely on the WAF or any other network-based security device for application security, because THERE IS NO FRONT.

You can't put a WAF in your production DMZ and declare it done.  An attacker who bypasses that DMZ and gets into your internal network will have a field day inside the soft and chewy interior.  Dev and test applications, often with production data in them, will be vulnerable.  They may also have back doors -- excuse me, I mean "test harnesses" -- that don't get stripped out until the production build. 

So maybe you'll put a WAF on board every web application server on your network.  Are you ready to manage all those rules, as new security vulnerabilities are found?  (You may well have different versions of the same application throughout your enterprise.) And wouldn't it be tempting just to start loading any other functional fixes that you can onto the WAF instead of having to fix, test and release the code?

There's another problem, though:  portability of code.  You may not ever plan to make it available outside of your organization, but can you imagine giving it to a business partner, or selling it, and saying, "Oh yeah, you'll need to get a WAF and about 80 rules because we never fixed the code"?  That's just not an option for anyone who is shipping, releasing or sharing their apps.

And finally, don't forget that pesky cloud.  As applications become distributed among different sites and providers (not to mention mobile devices), there isn't going to be a choke point for all application traffic to go through in order to enforce policies and detect attacks.  As hard as it sounds, trust boundaries need to be built into the applications themselves so that they correctly handle and protect their own architecture components and processes.  Otherwise your app is going to be wandering around the Internet with its hair creepily following two steps behind.

A WAF is a Band-aid, not a cure.  And even though it can be very useful for defense, additional validation or data transformation, it still doesn't provide 360-degree protection for an app; only the app can do that.  Don't slip into becoming part of a popular blog.

Slide rules.

In my time as a CISO, and now as an analyst, I've seen more vendor presentations than I can possibly count.  Over time, I evolved a set of rules that you may want to know about if you're going to share a slide deck with me.

Here are the required elements:

1. First off, there must be a slide talking about The Problem We All Face, and indicate that it’s a scary, scary world out there.  Otherwise I would forget why we’re all here. 
2. Next, there must be a conceptual  slide that includes icons of people, the cloudernet, and either monitors or CPUs.  Extra points for locks, or creatively drawn bad guys.
3. Add a chart of your company’s growth with the arrow pointing skywards on the right-hand side.  Don't include any numbers or units on the axes; those details are irrelevant.
4. There must be at least one circle-shaped process flow, indicating that the customer will never be finished using your product.
5. Don't forget the obligatory page full of customer logos (whether they approved the use or not).
6. And tiny screenshots of your product, which I cannot possibly read.
7. Compliance.  The word compliance has to be on there; otherwise I’m not reading it.  APT is not a one-for-one substitute, although it’s close.
8. You must show your boxes replacing your competitor’s boxes in an abstracted network diagram.  If your product is only software, you should still use boxes.  Virtualized appliances should be depicted by cloudy boxes.
9. Please include some fancy transitions or build sequences so that I can watch them break, or miss them altogether, during an online presentation.
10. And finally:  I cannot take your presentation seriously without military references, a fortress metaphor, or an onion metaphor (depicting defense in depth).

Now, if you're feeling especially ambitious and would like bonus points, I would love to see:

1. The classic "risk = vulnerability x impact" equation.  I just can't get enough of that one.
2. Carefully chosen quotes from a couple of bank customers saying how wonderful your product is.  Because I hadn't been planning to buy until I saw those. Banks always know what they're doing.
3. A description of your bad-ass threat researchers, whose continuous stream of published vulnerabilities and exploits makes my job as CISO so much easier.
4. Add a percentage figure to your "low false positive" rate.  Better yet, make it zero; that saves us all time.
5. A reference to Kevin Mitnick is just the cherry on top.

Thanks for tuning in, and I look forward to the next 24-megabyte PowerPoint file in my inbox.