WAF vs. Secure Code vs. Dead Fish
I’ve been slowly catching up on my reading after months of near-nonstop travel, and this post over at Imperviews caught my eye. Ignoring the product promotion angle, it raises one of my major pet peeves these days. I’m really tired of the Web Application Firewall vs. secure coding debate, never mind using PCI 6.6 to justify one over the other for security effectiveness. It’s like two drunk cajuns arguing over the relative value of shrimp or pork in gumbo- you need both, and if either is spoiled the entire thing tastes like sh&t. You also can’t dress up the family dog and fish in a pinch, use them as substitutes, and expect your kids to appreciate either the results or use of resources (resulting gumbo or the loss of Rover). Here’s the real deal- Secure coding is awesome and you need to adopt a formal process if you produce any meaningful volume of code. But it takes a ton of resources to get to the old code (which you should still try to do), and can’t account for new vulnerability classes. Also, people screw up… even when there are multiple layers to detect or prevent them from screwing up. On the other hand, WAFs need to get a hell of a lot better. We’re seeing some positive advancements, as I’ve written about before, but they still can’t stop all vulnerabilities, can’t stop logic flaws and certain other categories of attack, can’t deal with the browser end, and I hear a lot of complaints about tuning (while I think liking WAFs with Vulnerability Assessment is a great start on this problem, we’re just at the start of that race). I absolutely hate to tell you to buy more than you need, but if you have a major web presence you likely need both these days, in the right combination (plus a few other things). If you don’t have the resources for both, I suggest two options. First, if you are really on the low end of resources, use hosted applications and standard platforms as much as possible to limit your custom coding. Then, make sure you have kick ass backups. Finally, absolutely minimize the kinds of information and transaction you expose to the risk of web attacks- drop those ad banners, minimize collecting private information, and validate transactions on the back end as much as possible. If you do have some more resources available, I suggest starting with a vulnerability assessment (not a cheap ass bare-bones PCI scan, but something deeper), and using that to figure out where to go next. Yes- we are eating our own dog food on this one. The blog is hosted using a standard platform. We know it’s vulnerable, so we’ve minimized the attack surface as best we can and make sure we have backups of all the content. I’ve been pleasantly surprised we haven’t been nailed yet, but I expect it to happen eventually. None of our sensitive operations are on that server, and we’ve pulled email and our other important stuff in house. Early next year we’re going to be launching some new things, and we will again go with remote hosting (on a more powerful platform). This time, we are switching to a more secure platform than WordPress (Expression Engine) and will pay for a full vulnerability assessment and penetration test (at least annually, or when any major new components come online). We may perform some financial transactions, and we’ll use an external provider for that. A WAF is out of budget for us, so we’ll focus on minimizing our exposure and manually fixing problems discovered by ongoing assessments. We also plan on using as little custom code as possible. But seriously- I’m tired of this debate. Both options have value, they aren’t exclusionary, and which you need depends on what you are doing and how many resources you have. Eventually we’ll get a better lock on this problem, but that’s a few years out. Share:
