The Web Application Firewall debate has been raging for a very long time, and we keep hearing the same comments going back and forth. Many organizations have implemented them as a fast-track to compliance, primarily compliance with PCI-DSS, but the developer community is still hesitant to embrace them as a solution to their problems.
And that’s because like so many things out there, they are seen as an “either-or” proposition. Either they can relieve a developer of the need to write security code, or they can’t. If they can’t, then why have them? I’m a developer by trade, and I get the sentiment. It’s tough to say “spend all this money, and I’ll keep spending my time”, could almost seem to make no sense.
But very little out there is really an either/or proposition. Many of the things that a Web Application Firewall can do for you – like DOS/DDOS attack resistance – are outside the realm of the developer. If you’ve taken the time to write DDOS protection code into your web applications, you might just be in the wrong job. Many other things that Web Application Firewalls (WAF) can do are well within the bounds of the developer domain, but could save time if they were implemented in the centralized location of the WAF instead of over and over in each app. Not relieve you of the burden of writing secure code, but save you time by eliminating bits to focus on and reducing redundant development, freeing up CPU cycles in the process.
My Friendly Local Game Store (FLGS) – with doors.
And that’s the key. Web App Firewalls don’t have to do everything, they have to do something that makes them worth the time to install and utilize. While many orgs have installed them, I would argue they’re not utilizing them effectively because the installation was a check-box on a compliance report, not something the organization wanted to make adequate use of. Other organizations don’t have them. But there IS one driving reason to install a web app firewall.
A significant number of attacks are stopped before they get to your machine.
Let me say that again… Risk of a ne’er-do-well getting root and messing up your application and your server by taking advantage of some flaw in the OS or a library is zero for every attack that is stopped before the packets reach your server. And that’s important. Because no matter how secure your code, or the code of your purchased package, or whatever, the overall system is only as strong as the weakest point the attackers can reach. Just like a soldier hiding behind a window is harder to shoot because most of his body is protected, an application resting behind a web application firewall is mostly protected, and thus, harder for attackers to take control of. Yes, services and apps have to be open to the world in order for them to present value to your customer, but the fact that a business needs a front door to let customers in does not mean that all businesses should dispense with the front wall of their shop.
Another Branch of the FLGS – Without Doors!
So get the protection a Web Application Firewall offers, put it to its maximum uses that you trust (did I mention I was a coder? They can do more than I’d hand off to them ;-)), and spend the time you save on security development doing coding/projects that add business value, because security is only important when it’s breached, the next rev of an important customer portal will be talked about all the time. Hopefully with praise, but talked about, either way.
Or you could take the extra time and come to Green Bay to visit those FLGS’. They do rock, whether you’re into Monopoly, RPGs, CCGs, CMGs, Minis, or any of the other XXGs. And no, I don’t have any financial interest in them, and no, they don’t have a web presence, so you’ll have to visit Green Bay to see ‘em – but the top store is right by Packer Stadium, so you can get a double benefit for the trip.
I will point out that the store with no front door? Yeah, it’s counting on the protection of the mall’s doors, you know, kind of like an application and a Web App Firewall. Still has a drop down chain door though – because layered security is good.