Security: Failing Gracefully, or Just Failing?

Wednesday, February 01, 2012

Dave Shackleford

1b061b1cec6b5898e5326992d9461610

Writing a book has put a serious crimp in my time for many other things, blogging included. I was warned, I know. I’ll quit complaining now.

I did a presentation with Alex Hutton and Rich Mogull recently to kick off 2012 at IANS, and we talked about a lot of major trends and themes in our space today.

These ranged from mobile security and “consumer-ization” of mobile devices to cloud security, advanced threats, blah blah blah. We made no predictions, since all the same stuff from last year is still on the plate. Well, I guess we could have predicted that.

During one of our discussions, focusing on advanced threats and incident response, Rich made a really good point (he does that). We were discussing the slowly dawning realization that we WILL be breached, and need to focus on detection and reaction more than anything at this point.

At some point in the conversation, Rich said our prevention tools and processes just need to “fail gracefully” and lead us into detection and response mode. I started thinking about this, and I think the concept holds for a lot of things we do.

First, and probably most obviously, there’s code. Whether it’s the Rugged Manifesto started by Josh Corman and Dave Rice, or just general coding best practices, it stands to reason that sometimes people will do things with your function calls, input vectors, and the like that you did not plan for or intend to happen. Invariably, this will lead to some unintended consequence.

Now, to be clear, sometimes that consequence is really nothing. Nada. It just pretends nothing happened and moves on. But more often than not, something doesn’t work. And the question, of course, is what happens then?

Do you post a happy little message to someone’s browser announcing that Microsoft SQL Server 2005 could NOT execute SQL query X? Hopefully not. Worse yet, you just cough up *really* sensitive data.

Another classic preventive control is antivirus. It fails. A lot. And then what? What other controls do you have to allow A/V to fail gracefully? Behavior-based detection at the host or network? Protocol-aware firewalls that can spot HTTP/HTTPS C&C traffic? What about your security awareness program and email spam/malware controls?

When they fail, people click on links. And then bad things happen. What controls can catch that (aside from A/V)? Do you have more innovative controls for your browsers, etc. like Invincea’s browser protection?

The list could go on and on, but I think a shift we need in security overall is to start thinking in terms of failure scenarios. Every single solution/control/process should be viewed in context of the others, really more like a “controls ecosystem” than any one specific point control.

This is somewhat related to the age old “Defense in Depth” concept we’ve touted for years, but it goes beyond that, I think. We’re pretty good at “if-then” analysis for controls in security, it’s the kind of analytical process many of us enjoy. Let’s turn it around though, and start thinking “if-then” in the negative sense.

Fail gracefully, my friends.

Cross-posted from ShackF00

Possibly Related Articles:
15983
Network->General
Information Security
Antivirus Cloud Security Best Practices Incident Response Advanced Persistent Threats Network Security Defense in Depth Mitigation Security Solution Mobile Security Dave Shackleford Consumerization Fail Josh Corman Dave Rice Rich Mogull Alex Hutton
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.