posted on Tuesday, August 26, 2008 5:01 AM
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.
