On Data Breach Containment

Thursday, April 12, 2012

Rafal Los


I've had this post in the drafts for a while but today seems timely to post this given CNet's story about Global Payments and their statement that the data breach they've experienced is currently "contained to the best of our ability". 

That's an interesting thing to say... 'contained'.  I think it merits further discussion because I read people on Twitter dismissing this statement far too quickly.

You've heard others, including me, say for a while now that information security isn't about reaching some mythical state of 'secure' but rather a constant battle on the ever-changing front lines of your organization to minimize any damage that the evil hackers can do once they find an in. 

I recall other breaches where the key point wasn't whether the organization was secure or not, but how quickly they reacted and whether they were able to contain the breach or not.  I think this is valid today and will be even more valid into the future.  This doesn't give any organization a free pass to get breached, mind you, but it does provide some level of accountability for the now what post-breach response.

I think there are far too many organizations that believe they can do enough security to keep from getting breached... almost as many as think that they can do nothing and won't be a target.  The thing is, both of them are wrong. 

You'll never reach a state of 'secure' no matter how much you spend, or how much technology your implement. Even if you're sufficiently fortified on the technology front, odds are your human element is still exposed and likely will be the source of any breach.  It's just an arms race you can't possibly win against people who have more resources than you do.

If you look at the vast majority of the data breaches in the last year that have been successfully triaged and have kept the company from imploding you can gleam a common thread - response and containment.

Containment is a tricky subject though, because it relies solely on the ability to prove your organization's ability to contain an intrusion or breach.  Proof is a tough thing to get when you've just been breached. 

You have to get your consumers, your investors, and the media to trust that you've done your diligence and contained the intrusion as you say... and in the middle of a breach is not the best time to try and flex your public trust muscle - so you're back to strong proof.

How do you contain?  Compartmentalization is key.  Having systems that are segmented according to task, purpose, data criticality and even further with strong controls both technical and human between them is key. 

Having strong audit trails of movement of packets and processes between zones or containers (containment zones) is critical as well, even within something like a database.  This isn't trivial to set up, and clearly not infallible, but it's necessary.

As you can see, 2 key points here are compartmentalization and audit.  Nothing terribly new... but oddly something many organizations are just waking up to.  I don't think this bears mentioning but I'll say it anyway - cloud computing makes this even more important. 

In the cloud it's all about compartmentalization with multi-tenancy and even compartmentalization within a unique tenant environment between high security and low security zones, with a strong audit trail of packets and data between them sent off to a place that can't easily be attacked. 

Again, compartmentalization and audit isn't something you're going to be able to bolt on after you've been breached and realize that for next time you need to protect yourself and your consumers. 

Good security starts in the architecture of things... and isn't that what we've been saying since... forever?

Cross-posted from Following the White Rabbit

Possibly Related Articles:
Information Security
breaches Enterprise Security Databases Security Strategies Incident Response Data Loss Prevention Data Protection IT Security Network Segmentation
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.