Poisoning The Data Well

This week Forrester Research released a new report written by analyst John Kindervag called "Killing Data," which claims that security professionals don't do enough to make data stores undesirable to thieves looking to fence that information on the black market.

"Control placement is often flawed and security pros frequently leave toxic data, data associated with legal or compliance mandates, and certain types of intellectual property unprotected and vulnerable. Traditionally, security pros have not stored email addresses in an encrypted format — because they don’t view them as toxic or sensitive data," the report read. "In order to properly protect data, security professionals must put a value on it based on how much the data is worth on the open market."

Dark Reading spoke to Kindervag to expand on the ideas that drove him to write the report and to discuss the importance of encryption in today's threat environment.

DR: I like your idea of poisoning the well for criminals by making it harder to peddle stolen data. Can you talk a little more in depth about what it means to kill data for the bad guys?

Kindervag: It became clear to us that we could keep layering controls on it, or we could try to solve this problem in a more fundamental level. And the fundamental levels seem to be, let’s try to take the value out of data because if no one can sell the data, then no one will want to steal it.

It's our view that the future of the default data state will be encrypted. That will go a long way to solving a lot of these problems because it will take us out of having to deal with breach notification; even if somebody steals our data, it's gobbledygook as long as the key management is done correctly. It will deincentivize attackers to try to steal that data. I like to say that encryption covers a multitude of sins. You can screw up security in a whole bunch of places, but if you do encryption right, you reduce your liability significantly.

DR: It sounds like there are a couple of challenges at hand to reach that default encrypted data state. Obviously, key management is a big one, and one that a lot of organizations don't do well. Why is key management so important in this effort?

Kindervag: A lot of people just focus on the technology behind the encryption itself -- the algorithms, all that kind of stuff, because it sounds sexy. It sounds like a spy novel or some crime TV show where they always break encryption in two seconds. The reality is, all of that stuff is the easy stuff. It's all standardized.

The place where you can screw up is key management.,nd people don't think about that. I talk to customers all the time who say, "Well, we didn't want our keys to get lost, so we emailed them to three or four different people."

That's not enterprise key management. Key management is about how you deal with key escrow, key revocation -- all those big issues. And we're starting to address them as a profession around things like key management interoperability protocol. So we're starting to address them as an industry.

If you do good, robust key management, you can have lots of cryptographic subsystems you deploy that have a different solution for mobile devices versus laptops verses databases versus email encryption, but you want to have that key management as centralized as possible. And you want it as automated as possible because the process is what's important here, and you don't want to rely on just Active Directory or something like that to do key management. You don't want to do ad-hoc key management.

DR: In your report you broke down the typical encryption strategy into three main components: endpoint, email and database, and network storage encryption. Can you talk about how all of these puzzle pieces work together?

Kindervag: Really, what we're looking at is transitions in data states. So at different times I have to transition data from one person to another or one state to another. That's where those products come into play.

I need to email this particular record to somebody else. I want it encrypted before it goes out. We don't have to worry too much about the whole PKI thing. That confuses a lot of people, and quite frankly, a lot of people have a bad taste in their mouths from the old days of PKI. We're evolving PKI to the point where we're doing inverted PKI now. Instead of a single cryptographic system that seeds everything else, we can now deploy individual cryptographic systems like an email encryption gateway.

And that doesn't have to be by the same vendor as our database encryption product or our laptop encryption product. We can chose three different vendors, but for the most part, the key concepts are exactly the same or very, very similar. There might be some differences in how one vendor implements versus another, but over time we'll start to standardize that. So really, what you'll be looking at is the dashboard or management console for your key management program and all of the actual encryption will be abstracted from you. It will be transparent and you won't have to worry about it. It'll just be the same way as saving stuff to your hard drive now. In the future, we think that all of that will be happening in the background, and we'll have a level of abstraction that gives us easy manageability of it.

And so we'll be able to encrypt and decrypt on the fly based on our identity and whether or not we need to have access to a particular piece of data in order to do our job. So it ties into the whole zero-trust concept that we're developing.

Next Page: The evolution of database encryption. DR: So that's why key management is so important -- because you see it as the glue that allows you to take each component of the encryption spectrum and glue them together?

Kindervag: Absolutely

DR: Database encryption is particularly interesting because it seems to have come a long way in recent years. For a long time, DBAs in particular hated the idea of it because they're performance junkies. But now with newer encryption technology, that's not necessarily the case. Can you talk about the evolution there?

Kindervag: Database encryption has matured a lot, I think, primarily pushed by PCI, which required those databases to have encryption of cardholder data. We see a lot more columnar kind of encryption where we don't have to encrypt the whole thing. We see offloading of that encryption too, onto some sort of appliance or hardware security module, so we don't have to use up the CPU and its transparent to our DBA.

The DBAs don't need to know if the data is encrypted or not. They just need it stored securely and then they need to make sure it can be queried properly. But it shouldn't be their business whether it's encrypted or not. That should be a policy decision from the business side. And we can't do things just to make their lives easier. But the maturity of database encryption has allowed us to meet the business needs related to encryption without making the job of the people maintaining the databases significantly harder.

DR: Where are we with database encryption deployments within the enterprise?

Kindervag: It's huge in areas where you have custodial data that's regulated somewhere. It's what we talk about as toxic data: personally identifiable information, personal health information, and PCI -- the three Ps.

So we have a lot of database encryption in that world. And we're just now starting to see it go into the world of intellectual property, which is the next place is should go. You want your intellectual property to be encrypted -- say, your AutoCAD files for your new fighter plane. You've got to make sure those can't be stolen because that's what APT is all about. State-sponsored attacks steal intellectual property because it’s a whole lot easier to steal a defense contractor's plans for a next-generation strike fighter than it is to come up with your own idea and your own plans. That's why you see that happening in my opinion.

DR: If you say we want to move toward a place where the data is encrypted by default, what about when we start dealing with big data?

Kindervag: It doesn't necessarily throw complication in there if we've done it right and it's properly abstracted. We wrote a report called "The Future of Data Security and Privacy: Controlling Big Data," [which drove] the idea that now that we've got all of this data that we're aggregating in terms of big data, wow, there's going to be a whole bunch of problems that people aren't thinking about. We've got this thing called the big data security and control framework. We break it up into three big sections: define, dissect, and defend.

In "define" we have data discovery and data classification -- where's my data located and how toxic is it? Then in the "dissect" part of it, we have data intelligence and data analytics -- how can we get value from the data? In the "defend," we have assess, inspect, dispose, and kill. The idea is that we need to assess our data properly, we need to inspect who's getting control over it, we need to get rid of it when we no longer need it, or we need to kill it, which is killing data technology [such as] tokenization and encryption.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.