Technical Article

You're Doing It Wrong

Don and I were discussing security as a service and, as usual, he spouted off some wisdom in the form of an analogy that was too good to not to share.

When you're walking down the street with your entourage and an angry, I mean really angry, man steps out in front of you with a lead pipe where should your bodyguard be?

Yeah, that was my thought, too. He should be in front of me to stop the threat before I have to react. Even though the threat may not hit me if the bodyguard is beside me because he manages to reach out and grab the lead pipe before it lands a blow, I've probably expended unnecessary resources avoiding or flinching or cringing or screaming like a school girl at the action. Resources I didn't need to waste. I might even be (gasp) sweating from the exertion. And what a terrible faux pas for someone who can afford an entourage and a bodyguard to sweat in public.

Basically, if I get hit by that lead pipe or I expend effort avoiding being hit or even momentarily look like something out of an Edvard Munch painting, my bodyguard is fired because he wasn't doing his job. He's doing it wrong.

That's the difference between security as a service when provided by a web application firewall and security as a service when implemented as an internal, software service solution. The WAF is inline, in front of the application, preventing that lead pipe from damaging the application. The application never has to expend unnecessary resources or sweat in public (wasted CPU/memory utilization/connections) when the security is deployed in front of the application.

If you're thinking, "Hey, what's that really gonna do? Waste a couple milliseconds? Pshaw! No one will notice!" then you need to go now and read this post on latency. Really - go now. I'll wait.

Threat defense is necessarily defensive. And the best defense is a good offense; one that is proactive rather than purely reactive. That means acting before the threat truly becomes a threat. Allowing a threat to reach the application before it's been identified and filtered out is certainly better than doing nothing, but stopping it before it gets near the application is even better.

"A more effective strategy is to learn self-defense so that you don't need a body guard except in special situations."

Self-defense against which attack? Yesterday's? Today's? Tomorrow's? The analogy isn't perfect, mind you, as application threats require specific countering moves whereas general self-defense can work against many types of attacks. Even so, when you're taught self-defense they specifically teach you "This move works against this type of attack." So you have to not only know the defense, but how to recognize the attack.

"The web app firewall has to be told what to do with each new app and each change to existing apps."

And the application has to change to defend against every new threat. Unlike a WAF, this requires new code, testing, and redeployment. That's a brittle system that incurs additional costs and, unfortunately, the potential for introducing more errors due to changes in code.

And yeah, for us a bodyguard is pretty useless. But for people who might be targets is it? How many threats are stopped simply because those bodyguards exist? And how many would succeed if there was no bodyguard...

Application logic security, yes. General data scrubbing/input validation/etc...? That's not logic, that's essentially schema. Easy for a WAF to handle and leaves the application developer without the burden of needing to learn every attack there is and how to counter it.

There's room for both strategies, and they can complement and augment each other.