Poisoning The Data Well

A Q&A with Forresters 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 dont 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 todays 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.
Its 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, its 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 dont 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. Its all standardized.
The place where you can screw up is key management.,nd people dont think about that. I talk to customers all the time who say, Well, we didnt want our keys to get lost, so we emailed them to three or four different people.
Thats not enterprise key management. Key management is about how you deal with key escrow, key revocation -- all those big issues. And were starting to address them as a profession around things like key management interoperability protocol. So were 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 whats important here, and you dont want to rely on just Active Directory or something like that to do key management. You dont 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 were 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. Thats 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 dont 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. Were evolving PKI to the point where were 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 doesnt 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 well start to standardize that. So really, what youll 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 wont have to worry about it. Itll 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 well have a level of abstraction that gives us easy manageability of it.
And so well 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 were developing.
Next Page: The evolution of database encryption.

DR
: So thats 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 theyre performance junkies. But now with newer encryption technology, thats 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 dont have to encrypt the whole thing. We see offloading of that encryption too, onto some sort of appliance or hardware security module, so we dont have to use up the CPU and its transparent to our DBA.
The DBAs dont 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 shouldnt be their business whether its encrypted or not. That should be a policy decision from the business side. And we cant 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
: Its huge in areas where you have custodial data thats regulated somewhere. Its 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 were 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. Youve got to make sure those cant be stolen because thats what APT is all about. State-sponsored attacks steal intellectual property because it’s a whole lot easier to steal a defense contractors plans for a next-generation strike fighter than it is to come up with your own idea and your own plans. Thats 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 doesnt necessarily throw complication in there if weve done it right and its properly abstracted. We wrote a report called The Future of Data Security and Privacy: Controlling Big Data, [which drove] the idea that now that weve got all of this data that were aggregating in terms of big data, wow, theres going to be a whole bunch of problems that people arent thinking about. Weve 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 -- wheres 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 whos 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 youd like to contact
Dark Readings
editors directly,
send us a message
.

Last News
▸ Scan suggests Heartbleed patches may not have been successful. ◂ Discovered: 23/12/2024 Category: security	▸ IoT Devices on Average Have 25 Vulnerabilities ◂ Discovered: 23/12/2024 Category: security	▸ DHS-funded SWAMP scans code for bugs. ◂ Discovered: 23/12/2024 Category: security

**Cyber Security Categories**
Google Dorks Database	Exploits Vulnerability	Exploit Shellcodes

CVE List

Tools/Apps

News/Aarticles

Phishing Database

Deepfake Detection

Trends/Statistics & Live Infos

Tags:
Poisoning The Data Well