News Database Security
Poisoning The Data Well
A Q&A with Forrester's John Kindervag about how encryption makes data worthless to the criminals
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."
More Security Insights
- Information Protection: The Impact Of Big Data
- Cloud-based data backup: A buyer's guide - How to choose a third-party provider for development, management of your data backup solution
- Informed CIO: SDN and Server Virtualization on a Collision Course
- InformationWeek 2013 IT Spending Priorities Survey
- The Untapped Potential of Mobile Apps for Commercial Customers
- Using InfoSphere Information Server to Integrate and Manage Big Data
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.