Who's watching the watchers?

It has always seemed to me that most security incidents are not the work of heavily-financed super attackers but are due to something more pedestrian – human error. And no, I’m not going to go on one of those “humans are the weakest link” diatribes. That would be unfair. Systems are complicated with many inter-dependencies which are often outside the control of the people responsible for securing them. When a vendor updates software, only so many scenarios can be tested, and the more complicated the system, the more likely something is to break.

So, when there was widespread concern last week that Amazon Web Services (AWS) may have accidentally allowed support administrators access to every AWS S3 bucket for about ten hours, I wasn’t particularly surprised. (Read the AWS security bulletin here.) My feeling didn’t come from a lack of confidence in AWS. It’s that I believe everyone makes mistakes, and with systems this complicated, it’s bound to happen. It can happen to anyone. I certainly have a long enough playlist of my own gaffs that I’m not about to throw any stones.

The real question here is, how can you protect your data when a super admin has full access?

This was one of the questions our co-founder and Chairman Lou Steinberg was asking himself when he was the CTO of a Fortune 500 financial services company. He’d just been handed a mandate to move the company’s data to the cloud and one of the scenarios he was concerned with was the one that happened last week. He wondered, what if I could make my sensitive data un-sensitive to unauthorized users – like a cloud provider’s admins? The answer was what is now our Microshard™ technology. (Lou’s name is on the patent, by the way.)

Before I explain how we help with incidents like last week’s, I’ll give a quick overview of the microsharding process:

1. A file is shredded into four-byte microshards, making each microshard too small to hold any identifiable information. (You can configure the size of the microshards.)
2. The microshards are mixed into multiple Microshard containers with some poison data thrown in to make reassembly that much more difficult. (You can also configure the amount of poison data used.)
3. Lastly, we distribute those containers to multiple storage locations. These may be with multiple cloud providers, multiple regions, multiple data centers, or a hybrid mix of these.

The net is that if an unauthorized user gains access to one of your storage locations holding your Microshard data, that user only gets one jumbled up piece of the puzzle. The data they see is unintelligible and of no value to them – even if they’re a support admin. Also, Microshard data contains no file names, no file extensions, no metadata, nothing to show relationships among the microshards, how many storage locations there are, or where they’re stored. In short, they get bupkis. (That’s a technical term.)

We’d love to tell you more, so click the button at the top of the page to schedule a demo with us and be sure to check our home page for upcoming webinars and events.