# One Over X

One Over X

Security has few absolutes, we made our peace with  that some years ago.

Security Professionals know that we're never going to get to a state where risk is verifiably zero, or that the number of in the wild security defects is nil.  What I can tell you is the risk curve should look like a 1/x graph.The 1/x graph, if you've worked much with mathematics, drops sharply initially, then flattens out over time as it aproaches zero, never actually reaching it.  This is like risk, dealing with web applications, and security... follow?

Infinity

Initially, the risk associated with web applications, in my assertion, is infinity.  Since we don't know what it is, it can only be assumed to be infinitely high.  This is a good starting point for the risk conversation.  Odds are that after doing some sort of baseline or initial test you'll realize that your real risk really isn't ininify, and that's some quantifiable number ...but before you take your first run at it, the answer is always going to be inifinity.

I think that infinity is a good starting point simply because risk is an unknown, and any negatively impacting unknown must be weighted at it's highest potential.  On a mathematical scale, the highest potential is infinity, and this works well with the 1/x graph.  A mark of "infinite risk" serves the purpose for a few reasons though.

First it invites someone to think twice and ask a question - "Why is this infinity?"  More importantly perhaps, the follow-up is "How do we reduce it to something more meaningful, and less ridiculous?"  This brings the value of the security assessment, or at least a baseline assessment, into clear focus.

It might sound silly, but infinity as an initial risk rating is a completely defensible position!

Drastic Slope

The drastic slope that the 1/x curve produces makes a lot of sense when you look at quantifying risk.  Usually, when risk is very high, the initial changes are the ones that make a massive impact.  When Cross-Site Scripting (XSS) is running rampant in your web applications, often a simple implementation of some feature like HTML-encoding output immediately resolves a huge chunk of the security issues ...dropping risk significantly.  While less security defects (vulnerabilities) does not equal less risk - the correlation exists.  As Marisa F. (@dewzi) mentioned in her SecTor 2010 talk today, "Often the simple things make the biggest initial impact" (paraphrasing).  This is very true in web applications.

I have example after example of organizations where the risks were through the roof, and an initial effort made such an impact on the company's risk posture that the analysts themselves couldn't believe it.  It's always nice to have evidence like this to share in conversation, but I can virtually promise you when you're off on your web app security program you will end up with a very similar curve.

Infinitely Approaching Zero

What we know for a fact is that there will always be risks.  Moreso, web applications will always have security defects that don't get "resolved" but rather accepted as part of long-term business risk.  This is OK.  Even if you embark on a crusade to remove all IT risks from your business ...you'll still never reach zero.  If you haven't made your peace with this, now is a good time to do so.

As the 1/x line slowly approaches zero, forever, we realize that we start seeing an ever-increasing rate of diminishing returns on our effort.  Whereas a small effort had a major return in risk reduction early-on, late in the program stages high levels of effort yield only small levels of risk reduction.  What does this mean?  Ultimately, this becomes a business decision on how far "down the rabbithole" to chase this errand.  Some copanies will continue to spend money pushing ever-close to the zero line, while others (most) will choose to draw a line in the sand at some level their CIOs are comfortable with and move on to bigger issues.

In the end, you'll never really reach zero.  Chasing that forever is a fools' errand... but you need to know where to start, how much to spend, how deep to go, and when to stop - those are all very big challenges you'll need expert assistance with.

In the End...

What's right for your company, can only be determined by your company.  Every enterprise, every vertical, every website, every developer is different - but I can tell you for certain, the 1/x curve holds.  Try it... let me know what you think.

| ‎10-28-2010 08:29 AM

Cool way of thinking about Risk Management in Apps Sec. Couldn't this same formulae and arguement be used for all Risk Management regardless of the area?

(anon) | ‎10-28-2010 01:06 PM

@Allen  It's been used that way for ages.

There's that old InfoSec graph that juxtaposes a cost curve as almost "X/1"  and suggests that where the two intersect is "optimal security spend".  Not sure I've ever bought into that one, but it's been around for a while.

| ‎10-28-2010 01:31 PM

@Allen, I'm 100% in agreement with Alex, this should be something well-known in the information security and risk management circle.  Unfortunately, it's just not the case.

@Alex: I can buy into the x/1 curve for spend, but where the "optimal" point is, is different for each and every single enterprise.  That's why you may not buy into it 100%... but it's still valid.  If you don't spend enough, you're not getting enough value, but spend more than a "tipping point" and you're just throwing money away while only minimally improving security.  It's a very tight rope we walk, honestly.  Too little or too much - where's the line and how can you tell?  I shudder to think at some of the folks in big business making those decisions, especially when some of the feedback I get on posts like this is "really?" ...

Thanks for reading & taking the time to discuss guys.

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search