The Unpossible Task of Eliminating Risk

An ant named Archimedes is in a hole 6' deep. He climbs half the distance to the top every hour. How long does it take for him to escape the hole?

Trick question. He can never, mathematically, escape. Realistically, we know that when Archimedes gets close to the top he will escape because he is actually longer than the amount of hole he has left to go. But what if every hour that Archimedes climbed the hole expanded 6" and thus changed the equation?

He'd be one frustrated ant, that's what he'd be. That's how IT security professionals must certainly feel when trying to climb out of the hole that is web application security they're tossed into every day and then told "hurry up, get us out of here!" 

Elimination of risk is an impossibility. If elimination were a possibility, then network errors would never occur. At the very core of computing and networking lies this basic fact: bits are either on or off. But are they? By using light and electrical signals to transmit bits we have introduced the risk that a bit with be maybe on or maybe off. Both types of signals can weaken due to distance or fluctuations in power strength, thus degrading the options to black, white and some shade of gray. This makes interpretation more fuzzy: it's on, off, or somewhere in between.

This is why we always talk in terms of mitigating risk, not eliminating it. Elimination of risk is pretty much a mathematical limit and the equation changes every day with the introduction of new technology, newly discovered exploits and vulnerabilities, and an increase in the number of "bad guys" out there attempting to slither through your security measures. The ratio of them to you is pretty frightening, and even though you've likely employed a vast array of security technology measures to stop them, you can't eliminate the possibility entirely. You can only mitigate it, and get it as close to zero as possible.

If Archimedes (who was really one of the greatest mathematicians in history and came up with the idea of limits and not an ant) were an IT security professional today he'd probably say that you can get close enough that you might as well have eliminated all the risk. But there's a big difference between a polygon being close enough to be a circle and mitigating risk being close enough to eliminating it. For one, Archimedes' job wasn't on the line if a polygon wasn't really a circle, and he wasn't trying to protect personal, private data of thousands of people. 

That's why it's amusing to me when folks rail against web application firewalls. A WAF is another weapon in your arsenal with which you can reduce the risk of a security breach. It's another layer of security that can help prevent a wide variety of attacks and has the added benefit of reducing the burden of scanning and inspecting requests on servers so they can perform better and work more efficiently.

When you're faced with an impossible task like eliminating risk, why eschew any help you can get? While no technology can get you to zero risk, a WAF can get you closer much faster.

Side note: the etymology of impossible includes "unpossible", most commonly used in the middle ages. While now obsolete, sometimes it just sounds cooler than "impossible". But it is really a word.

AddThis Feed Button Bookmark and Share

Published Aug 11, 2008
Version 1.0

Was this article helpful?

1 Comment

  • Hey Mike, can't resist back! :-)

     

     

    I'm not convinced that all these tasks should be done one place or another. Should is a moral imperative, after all, and there's no law that says all these things must be done in the application or in the network.

     

     

    From reading the web app sec list most applications can easily be bypassed. ;-) Neither is a panacea. Even if developers were addressing these vulnerabilities there'd still be compelling arguments for deploying a WAF. A WAF offloads the task of data scrubbing, input validation, anti-XSS, etc... from the application. We offload a lot of security functions - like SSL - and no one cries "that should be done on the web server". Why is that? Because over time we've come to accept that in many ways centralizing SSL and offloading it from the server provide additional benefits that are realized such as improved performance, easier management, reduced costs, and a simpler architecture.

     

     

    Offloading some security tasks in terms of web application security to a WAF is not putting a band-aid on poison ivy, it's simply getting a shot of instead of a pill to solve the problem.

     

     

    Contextual-based security (i.e. vulnerabilities in logic) are currently only addressed well by the application, true, but data-based security can easily be addressed by either the app, a WAF, or both.

     

     

    Lori