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.