Which security strategy takes more time: configuration or coding?

One of the arguments against the deployment of web application firewalls (WAF) is that it takes time to configure these devices to fit each individual environment. This is allegedly one of the reasons that secure coding is preferred over security devices. But it takes time to code solutions and deploy them, too.

In fact, depending on the lifecycle management at any given organization, it can take more time to code a solution and get it moved through a phased environment into production. One of the benefits of an application delivery platform and web application security deployed at the perimeter of the network is that solutions are often deployed in days rather than weeks. Consider the case of BusinessWeek's infected site; a week after discovering the infection and vulnerability, the site was still not protected. Perhaps because the solution was still being put together and coded. A WAF could have protected that site within hours - if not sooner - of the vulnerability being discovered.

In some cases that time isn't all that important - perhaps the vulnerability being addressed is obscure, or highly peculiar to a custom application - and is highly unlikely to be exploited between the time it's discovered and the time a fix is put into production. But with language and platform specific vulnerabilities, the likelihood of that hole being discovered and exploited is much higher simply because attacks bots are often automated and sent to sniff out such holes like bloodhounds on an English fox hunt.

The configuration of an intelligent WAF in these situations is relatively quick compared to a code-based solution, and rarely must that configuration go through the same process, which results in reducing the likelihood your application will fall victim to the latest exploit.

But what about the normal configuration process, you say. That's where the time investment really adds up.

True. You can't simply deploy a WAF and click a button and say "start protecting my apps". Just as it takes time to code a solution so, too, it takes time to configure a web application firewall to secure your environment and applications, because they're all different. But it doesn't take nearly as much time as identifying where in the code to put a solution and what that solution should be, let alone doing the research to find the multitude of attacks you'll need to prevent.

The configuration of a WAF is partially automated; it can learn the hierarchy and architecture of your application and then begin applying security policies for them. The configuration really comes in with handling exceptions, and clicking some check-box options to determine how much security you want to apply. Yes, it takes some time, but not nearly as much time as asking developers to (1) learn every attack against which they'll have to code a solution, (2) code the solutions, (3) test the solution, and (4) deploy the solution.

A good WAF solution will also provide basic defenses against layer 2-7 attacks that are nearly impossible for a developer to code into their solution. An application does not generally keep tabs on each of the processes spawned to deal with a connection. A layer 7 DoS (Denial of Service) attack, for example, is unlikely to ever be recognized by an application because it requires a view of all requests across all connections, something an application is never coded to examine. Many of these protections require little to no specific configuration other than a check-box in a GUI.

There may be valid arguments out there against deploying a WAF, but the time it takes to configure them is not one of them.