Automatic security response: What will it take for you to trust it?

Tuesday, November 13, 2012

Tripwire Inc


Article by Dwayne Melancon

I was at a Cyber Security Summit recently in Minneapolis. (Small bit of trivia – did you know that the “twin cities” of Minneapolis / St. Paul have more Fortune 500 companies than any other city in the US? Me neither).

I was at a reception where Howard Schmidt, former Special Assistant to the President and Cybersecurity Coordinator, spoke with us on various topics.  One of the topics we discussed was the pace of cyber attacks and the fact that, increasingly, there is no advance warning when an attack is about to begin.  That means we need to be very quick at recognizing we’re being attacked, and also very quick at initiating a response and appropriate countermeasures.

The need for speed

Ultimately, we need to evolve our security capabilities to a point where both the detection and the countermeasures can be automated and, ultimately, automatic.  That is the only way we’ll get fast enough to prevent (or at least significantly limit) the damage from these unexpected attacks.  The problem?  We don’t tend to trust automation.

That got me thinking:  What will it take for us to trust security automation enough to “turn it loose” and let it guard our infrastructure in a fully automatic mode?  It’s not as though we don’t rely on automation every day — for example:

  • Many (if not most) of the airline flights we take are landed and piloted using automation;
  • Automated cruise control is becoming commonplace on new cars;
  • Our airbags deploy automatically in the event of a crash.

Even further along the spectrum, we’ve seen recent news coverage that Google’s self-driving car is now legal in California.  How’s that for trusting automation?

And yet, we aren’t there with full-scale security response automation (and I don’t think we will get there very soon…).

Fragmentation and automation

There are a bunch of challenges that make it harder to rely on automatic security response.  Some of the ones that come to mind for me include:

  • Fragmented technology environments.  When you look at successful automation projects, they tend to work due to tightly controlled technical environments – specific hardware, specific OS’s, specific assemblies, etc.  and they tend to be deployed and operated as a known unit of technology.  In our “real world” IT environments that isn’t the case, and we’re lucky if we can  maintain consistency over a long period of time within a single, controlled data center.  If you suddenly try to expand an approach to another data center or (heaven help us) to another company’s data center, you’re likely to have a miserable time making it all work.  In short, our environments’ diversities make them bad candidates for broad-scale automation.
  • Lack of standards.  Going back to Google’s self-driving car, one of the benefits of working on it within a specific state is that there is a fair amount of consistency in how the roads are constructed, how they are marked, how the traffic signs and patterns work, etc.  That standardization makes it easier to create algorithmic responses and functions.  In the world of cyber security, there aren’t a lot of standards to help enable consistency.  And, even when you find common elements, there is no universal expectations about how certain OS’s, hardware, logical controls, etc. will be implemented.  That increases the amount of logic that must be developed — and which must work flawlessly — for us to be able to rely on automatic security response.
  • Lack of testing and structured R&D.  I think one of the biggest issues, though, is that very few companies have the same level of rigor in their testing, as compared to industrial automation companies and others who have been successful with long-term use of automation.  While you may find specific vendors who do a lot of testing within the bounds of their own products, they aren’t doing the kind of integrated, system-level testing that we’d need to be able to trust automatic security response on mission-critical systems.  How many of us test our automation in production, or with minimal pre-production testing?

I know there are more – these are just three that came to mind for me after last night’s chat. Automation can act fast – and screw up fast, too

Sure, we do use automation for IT but it is most often used for operations & deployment, as you can see by the success of Puppet Labs, HP Opsware, BMC RealOps, and others like them.   But their product are mostly used to push things into the environment (and usually to a known set of targets) – not to analyze and respond dynamically and automatically.

And we all know that automation doesn’t always play well with the other children.  For example, we heard about problems with automated financial trading that caused real economic damage when the algorithms collided and began to put trading in a tailspin.  The big east coast power outage in the US in 2003 was due, in part, to software and other systems problems that led to a “cascade failure” of the power grid.

Obviously, we don’t like it when things like these happen, so I think it’ll be a while before we rely on fully automatic security response.  After all, nobody wants a Robocop moment when it comes to our security.

What do you think?  What would it take for you to trust automatic security response?  And I mean really trust it.  I’d love to hear your opinion.

Cross-posted from Tripwire's State of Security

Possibly Related Articles:
Enterprise Security
Information Security
Incident Response Intrusion Detection Network Security Monitoring Automation
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.