IT Is Power. Try Living Without A Single Breadboard For A Day.

Don MacVittie

Subscribe to Don MacVittie: eMailAlertsEmail Alerts
Get Don MacVittie via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: PC Security Journal, Security Journal, Telecom Innovation, F5 Networks

Blog Feed Post

Predicting the Future, or Counting on Code-based Security

As long as we have applications being developed and deployed, it seems we will have bad guys looking to exploit them

There are some topics that warrant the occasional revisit as time goes on, and application security is certainly one of those. As long as we have applications being developed and deployed, it seems we will have bad guys looking to exploit them. While I do believe that the Internet, like the Old West, will eventually need to be cleaned up and a set of common rules enforced, still there will be bad-guys, some people never learn that you can’t just do whatever you want and expect to get away with it.

So we need application security. At this point, I cannot imagine a web app being deployed without it in one form or twenty. Developers have gotten more astute (in general) about securing their code over the years, and the tools they have available to discover vulnerabilities have gone way up in quality since the 90s. And yet, our systems are still being compromised. There are a lot of reasons for this situation, and others have covered it much better than I have.


What seems to keep cropping up is the expression that somehow, even though our systems are being compromised, useful tools like Web Application Firewalls are not wanted or needed in the enterprise. This line of  dubious logic seems to run along the lines of “if your developers are doing their job, you don’t need such a thing”.

Wouldn’t it be nice if that were true? How about “if the people built your car right, it should never break down”. Does that sound reasonable? No? Well, it’s essentially the same situation. The external environment – attack vectors, tools hackers use, your partner’s security, etc. are constantly changing. The developers are writing security for the now – when the application is developed – and might (or might not, depending upon how much time you give them) update it when next they touch the code. And that’s reality. The bad guys are constantly improving, your code is static, no matter how well crafted.

But a Web Application Firewall is a specialty product whose purpose is to help stop the bad guys. It does not relieve your developers from the need to lock down their code, it should be written as bullet-proof as possible, because defense-in-depth is a real boon to information security. A Web Application Firewall does add defense in depth, and the security it adds is more than just “another layer of the same”, because it can be updated independent of your developers’ time. Save as many of your developer hours as you can for developing the applications that make the business money, let the Web Application Firewall vendor worry about updating the security bit to stop the attack of the week. Seriously. It’s a lot quicker to update a Web Application Firewall on a regular basis than it is to develop specialty code for each and every attack vector. And many times because of its location a Web Application Firewall can stop attacks that it doesn’t actually know about because they have suspicious behavior.

Image from reenactor.net


By filtering out a ton of attacks before they ever make it to your application, a Web Application Firewall is effectively reducing the exposure of your application. And that means less worry for everyone – you, customers, developers, senior management.

Like everything, it’s not a panacea, and the vendor you choose will have an impact on how well your applications are protected (fair disclosure, F5 sells a Web Application Firewall named Application Security Manager – ASM), but choosing carefully can give you easy and seamless protection against an array of attack vectors. The array pun was intended, for if your WAF protects against N vulnerabilities, it does not protect against number N+1. Sorry, geek humor.

The one gotcha is that you have to make sure of your vendor and your configuration. If your Web Application Firewall interrupts your applications, then it’s as much problem as solution. There are stories about how bad this and configuration can be. Lots of stories. Remember that the industry is well over a decade old, and those stories are from the bad old early days. Do some current research, don’t get sucked under with the tide.

There are a variety of other reasons why Web Application Firewalls are useful – like the fact that they have a different view of attackers (across the network) than your application developer who cannot do too much in terms of proactive defense, since his code is static – but the big one to me is reducing your exposure without increasing the manhours required to develop each and every application. And frankly, Web Application Firewalls also protect those applications developed by a third party that you may or may not have source code for, may or may not have a developer familiar with. That’s a big hit in and of itself.

Image (indirectly) from AutoDataSolutions.com

So if you’ve heard a talking head discussing how Web Application Firewalls are not of any use, or aren’t strictly needed (technically they’re not, but neither is a car, technically, you could walk everywhere), consider if  they’ve ever done web development, infosec, or read PCI DSS. Chances are anyone making such a claim has not done any of the three – or not done them well.

Read the original blog entry...

More Stories By Don MacVittie

Don MacVittie is founder of Ingrained Technology, A technical advocacy and software development consultancy. He has experience in application development, architecture, infrastructure, technical writing,DevOps, and IT management. MacVittie holds a B.S. in Computer Science from Northern Michigan University, and an M.S. in Computer Science from Nova Southeastern University.