Post reply

Not having TDE in all editions is stupid

  • December 7, 2011 at 2:43 pm

    #1418384

    Elliott Whitlow (12/7/2011)

    TravisDBA (12/7/2011)

    Not exactly accurate. With the advent of people's medical/psychological historical data becoming more and more sensitive every day, I can think of virtually thousands of databases across the country, not to mention the world, where the organizations themselves don't want just anyone looking at ANY of the data in those databases, period. Also, with HIPPA and PCI compliance becoming real issues now in the workplace, it is fast becoimg a requirement as well.

    So because they don't secure their databases this is a valid reason to use TDE, unfortunately TDE won't help in the cases you reference.. Also HIPAA and PCI hardly require full encryption. In the case of PCI you can store CC data but to be PCI compliant the keys can't be in the same database. Again TDE won't help if you can actively query the data. As for HIPAA things like notes and identify information are required to be protected. Some companies chose to go further. Again TDE won't protect this information if ti can be queried.. TDE ONLY protects data-at-rest when that database engine is NOT running or the database is backed up or disconnected. Don't get me wrong those are things that need to be mitigated but I wouldn't consider the data HIPAA compliant if I can do a seach of the Patients table by name directly such as:

    SELECT * FROM dbo.Patients WHERE LastName = 'Jones'

    Or

    SELECT NameOnCC, CCNumber, CCExpiration, CCCode FROM dbo.PaymentTypes

    TDE is not a solution for these cases..

    Also, look at the huge liability perspective a company or provider would possibly have if someone got hold of the thousands of Addiction, Substance Abuse, and Recovery databases that housed not only peoples names but other sensitive data/conditions about them (HIV positive, Hep C, etc..). Can you imagine the hundreds, if not thousands of lawsuits spawned out of a mass disclosure like that?

    TDE != HIPAA Compliance.. All the data you are referencing has one thing in common, a patient, that patient's name and other identifying information needs to be independently encrypted regardless of what you do to the database as a whole. See my points above..

    We are not just talking about an occasional bank account or credit card column anymore in one or two tables in a database.

    See my points above.

    Many databases today, and a lot more than .001% I might add, the ENTIRE database is sensitive, not just one or two columns.

    I challenge this assumption. Don't get me wrong your sales data is important but sensitive enough to encrpyt, not usually.. I have been in a single environment where the data was important enough to be considered sensitive accross the board.. The URLs for their websites all end in .MIL, and even in those cases not everything was sensitive.. I'm going to keep hammering on this point, TDE ONLY protects data-at-rest..

    As far as securing machines go, firewalls/security access measures stop outside penetration,

    No, they help, but they are a line of defense not a brick wall uterly preventing access. Defense in Depth is the key.. Every heard the phrase, "hard outer shell, soft chewy middle"? This is a good description of many companies who put up external firewalls/access security but utterly fail at internal security. Once you get in you are free to do as you wish..

    but they don't stop someone stealing a database from the inside and taking it down the street and attaching that database somewhere else and then releasing those peoples names to the public. Sure, ultimately they can go to jail for that if caught, but apparently that is not stopping alot of people from doing it anyway. 😀

    Good point, who has access to your backups? The keys to do the restores externally are available to your DBA so you aren't going to prevent him from doing it. So you are talking about someone else.. TDE WILL help in this case, but from my previous posts I argue that backup encryption should be available without having to do TDE. However without additional third-party tools this is not possible at present. Even with all that said if you encrypt the sensitive data in your databases you make it even more difficult to make use of, because then the perpetrator not only has to get access to the database backups and keys for the backups he has to get the keys/passwords for the independently encrypted data as well as the methodologies. And if he already has query access to the data TDE does nothing to stop him where independent encryption, even with keys stored in the database make it that much harder.

    CEWII

    I think we are talking about two different things here. I am referring to the ability for someone to take sensitive databases offsite either in pieces or as a whole, or transferring pieces of it to a smaller machine like a laptop or even a flash drive. I am not debating whether TDE is a solution against the direct querying of data. Of course not, I never said that. TDE is a solution for the possibility that anyone (with clearance) could steal a database or a backup from an organization, and take that database offsite, no matter what security measures are in place to prevent OUTSIDE penetration. We have huge amounts of security where I am at, and it is so simple for me to transfer a an unencrypted sensitive database to a large capacity flash drive, it is not even funny. Other standard security measures does not address this. It is not the first time a trusted person with high clearance has done this, and TDE is another protective layer in that defense. And as far as this goes, TDE should be available in other editions IMHO.:-D

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • December 7, 2011 at 3:03 pm

    #1418392

    TravisDBA (12/7/2011)

    I think we are talking about two different things here. I am referring to the ability for someone to take sensitive databases offsite either in pieces or as a whole, or transferring pieces of it to a smaller machine like a laptop or even a flash drive. I am not debating whether TDE is a solution against the direct querying of data. Of course not, I never said that. TDE is a solution for the possibility that anyone (with clearance) could steal a database or a backup from an organization, and take that database offsite, no matter what security measures are in place. We have huge amounts of security where I am at, and it is so simple for me to transfer a an unencrypted sensitive database to a large capacity flash drive, it is not even funny. Other standard security measures does not address this. It is not the first time a trusted person with high clearance has done this, and TDE is another protective layer in that defense. And as far as this goes, TDE should be available in other editions IMHO.:-D

    I'm just trying to make sure that the limits of TDE are understood. What cases it protects against and what limitations those protections encompass. I am a strong believer in defense-in-depth abd agree that TDE should likely be available at least in Standard Edition, I also think that SQL Agent should be included with Express, see how well that has worked out.. As far as laptops go, if you have ANY sensitive information on it then whole disk encryption should be employed because it is just too easy to miss that spreadheet you stored in some out of the way place.. I worked for a large company that ALL, I mean ALL computers even desktops had whole disk encryption. I also wanted to point out that TDE will not protect you from a trusted insider like a DBA who can get access to the keys and copies of the database if they really wanted to. And if you use other encryption you can also make sure that for the most protected data to be compromised it requires additional steps and likely collusion between 2 or more people. Again, defense-in-depth..

    In the end I just want to make sure that someone looking at TDE doesn't implement it and think "I'm safe now". As opposed to I have mitigated these cases(that may or may not exist in your environment), now what am I going to do about X?

    CEWII

  • December 7, 2011 at 3:32 pm

    #1418402

    Elliott Whitlow (12/7/2011)

    TravisDBA (12/7/2011)

    I think we are talking about two different things here. I am referring to the ability for someone to take sensitive databases offsite either in pieces or as a whole, or transferring pieces of it to a smaller machine like a laptop or even a flash drive. I am not debating whether TDE is a solution against the direct querying of data. Of course not, I never said that. TDE is a solution for the possibility that anyone (with clearance) could steal a database or a backup from an organization, and take that database offsite, no matter what security measures are in place. We have huge amounts of security where I am at, and it is so simple for me to transfer a an unencrypted sensitive database to a large capacity flash drive, it is not even funny. Other standard security measures does not address this. It is not the first time a trusted person with high clearance has done this, and TDE is another protective layer in that defense. And as far as this goes, TDE should be available in other editions IMHO.:-D

    I'm just trying to make sure that the limits of TDE are understood. What cases it protects against and what limitations those protections encompass. I am a strong believer in defense-in-depth abd agree that TDE should likely be available at least in Standard Edition, I also think that SQL Agent should be included with Express, see how well that has worked out.. As far as laptops go, if you have ANY sensitive information on it then whole disk encryption should be employed because it is just too easy to miss that spreadheet you stored in some out of the way place.. I worked for a large company that ALL, I mean ALL computers even desktops had whole disk encryption. I also wanted to point out that TDE will not protect you from a trusted insider like a DBA who can get access to the keys and copies of the database if they really wanted to. And if you use other encryption you can also make sure that for the most protected data to be compromised it requires additional steps and likely collusion between 2 or more people. Again, defense-in-depth..

    In the end I just want to make sure that someone looking at TDE doesn't implement it and think "I'm safe now". As opposed to I have mitigated these cases(that may or may not exist in your environment), now what am I going to do about X?

    CEWII

    Understood, but I think most people already realize that TDE is "transparent" and it is "at rest" encryption, so it does not cover all of the INSIDE possibilities, breaches, and compromises which you so aptly addressed. Totally agreed. 😀

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • December 7, 2011 at 3:53 pm

    #1418408

    TravisDBA (12/7/2011)

    Understood, but I think most people already realize that TDE is "transparent" and it is "at rest" encryption, so it does not cover all of the INSIDE possibilities, breaches, and compromises which you so aptly addressed. Totally agreed. 😀

    We have a lot of noobs reading these posts and I worry about them getting the wrong ideas.. So good deal, all clear now..

    CEWII

Viewing 4 posts - 31 through 33 (of 33 total)

You must be logged in to reply to this topic. Login to reply