Rational Survivability

Complexity: The Enemy of Security? Or, If It Ain't Fixed, Don't Break It...

When all you have is a hammer, everything looks like a nail...

A couple of days ago, I was concerned (here) that I had missed Don Weber's point (here) regarding how he thinks solutions like UTM that consolidate multiple security functions into a single solution increased complexity and increased risk.

I was interested in more detail regarding Don's premise for his argument, so I asked him for some substantiating background information before I responded:

The question I have for Don is simple: how is it that you've arrived at the conclusion that the consolidation and convergence of security functionality from multiple discrete products into a single-sourced solution adds "complexity" and leads to "increased risk?"

Can you empirically demonstrate this by giving us an example of where a single function security device that became a multiple function security product caused this complete set combination of events to occur:

1. Product complexity increased
2. Lead to a vulnerability that was exploitable and
3. Increased "risk" based upon business impact and exposure

Don was kind enough to respond to my request with a rather lengthy post titled "The Perimeter Is Dead --  Let's Make It More Complex."  I knew that I wouldn't get the example I wanted, but I did get what I expected.  I started to write a very detailed response but stopped when I realized a couple of important things in reading his post as well as many of the comments:

• It's clear that many folks simply don't understand the underlying internal operating principles and architectures of security products on the market, and frankly for the most part they really shouldn't have to.  However, if you're going to start debating security architecture and engineering implementation of security software and hardware, it's somewhat unreasonable to start generalizing and creating bad analogs about things you clearly don't have experience with. 
   
• Believe it or not, most security companies that create bespoke security solutions do actually hire competent product management and engineering staff with the discipline, processes and practices that result in just a *little* bit more than copy/paste integration of software.  There are always exceptions, but if this were SOP, how many of them would still be in business?
   
• The FUD that vendors are accused of spreading to supposedly motivate consumers to purchase their products is sometimes outdone by the sheer lack of knowledge illustrated by the regurgitated drivel that is offered by people suggesting why these same products are not worthy of purchase. 
  
  In markets that have TAMs of $4+ Billion, either we're all incompetent lemmings (to be argued elsewhere) or there are some compelling reasons for these products.  Sometimes it's not solely security, for sure, but people don't purchase security products with the expectations of being less secure with products that are more complex and put them more at risk.  Silliness.
   
• I find it odd that the people who maintain that they must have diversity in their security solution providers gag when I ask them for proof that they have invested in multiple switch and router vendors across their entire enterprise, that they deliberately deploy critical computing assets on disparate operating systems and that they have redundancy for all critical assets in their enterprise...including themselves. 
   
• It doesn't make a lot of sense arguing about the utility, efficacy, usability and viability of a product with someone who has never actually implemented the solution they are arguing about and instead compares proprietary security products with a breadboard approach to creating a FrankenWall of non-integrated open source software on a common un-hardened Linux distro.
   
• Using words like complexity and risk within a theoretical context that has no empirical data offered to back it up short of a "gut reaction" and some vulnerability advisories in generally-available open source software lacks relevancy and is a waste of electrons.

I have proof points, ROI studies, security assessment results to the code level, and former customer case studies that demonstrate that some of the most paranoid companies on the planet see fit to purchase millions of dollars worth of supposedly "complex risk-increasing" solutions like these...I can tell you that they're not all lemmings.

Again, not all of those bullets are directed at Don specifically, but I sense we're really just going to talk past one another on this point and the emails I'm getting trying to privately debate this point are agitating to say the least.

Your beer's waiting, but expect an arm wrestle before you get to take the first sip.

/Hoff

Security RROI (Reduction of Risk on Investment)

The security blogosphere sure is exciting these days.  I can't decide whether to tune into the iPhone junkie wars, the InfoSec Sellout soap opera or the Security ROI cage match!

I'm going to pick the latter because quite honestly, the other two are about as inflated as Bea Arthur's girdle...

(edit: link added for Cutaway whose predilection towards Bea Arthur and her undergarments are disturbing at best...) Warning...May Cause Chaffing...)

Unless you've been under a rock (or actually, gasp!, working) you've no doubt seen Rich Bejtlich's little gem titled "No ROI?  No Problem" that re-kindled all sorts of emotive back and forth debating the existence of Security ROI.

It was revisited by Rich here and then here...and then picked up by Lindstrom, Hutton, Cutaway and the rest of the risk management cognoscenti.  All good stuff.

It seems that the unofficial scoring has the majority of contributors to the debate suggesting that Security ROI does not exist...sort of.  The qualification of the word "return" really seems to be the important lynchpin here as contribution (margin, profit, etc.) versus cost avoidance really is what sends people off the deep end.

It appears that if we define 'return' to suggest that what you get back is a way of avoiding shelling out money, then indeed, one may quantify a return on the investment made.

Fine.  I'm good with that.  To a point.

However, I've never used ROI in any metric I've produced.  NPV?  Nope.  ROSI?  Nuh-uh.

What I have chosen to use is RROI -- the reduction of risk on investment.  HA!  Another term.

Basically, I've used various combinations of metrics and measurements to quantify data points and answer the question:

"If I invest in some element of my security program (people, process, technology) -- or after I have invested in it -- am I more secure than I was before and how much more?  Furthermore, how should I manage my investment portfolio to give me the best reduction of risk?"

One doesn't hire security guards because of an expectation that this action will cause one to be more profitable; it's a cost of doing business that allows one to asses the risk based on impact and decide how, if at all, one could or should invest in security to defray the impact and cost associated with the event(s) one is trying to mitigate.

Ah yes, the old "why would you spend $1000 to protect a $10 asset?" question.  Can you answer this question for every security investment you make?

I'd say that I've always been able to communicate what the "return" (see above) would be on investments made and done so in a manner that has always seen my security budgets grow when necessary and trim when warranted.  The transparency I strive to produce is communicated in business terms that anyone who can understand basic math and business logic can process.  Maybe I'm just lucky. 

I'm not saying I have the problem licked or that I found the holy grail, but the problem just doesn't seem to be as daunting as some would have you believe.  Start small, be rational and build and manage your portfolio accordingly.

So, how many of you have risk dashboards that can, in near-time, communicate where you invest, why and how this maps to the business and helps you most effectively manage risk per dollar spent?  This is what's really important.

I'm just wondering that instead of trying to globally force-feed a definition across a contentious landscape of religion and philosophy, perhaps we could spend the time arguing less about terms and more about solving problems.  Ask the business how they want to see your security value communicated and go from there.  If they want ROI, then fine...define the "R" appropriately and move on.

I'm going to "return" to work now... ;)

/Hoff