Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

It's Time for Encryption Expand / Collapse
Author
Message
Posted Monday, November 2, 2009 8:13 PM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: Moderators
Last Login: Monday, September 15, 2014 9:16 AM
Points: 6,784, Visits: 1,895
Comments posted to this topic are about the item It's Time for Encryption

Andy
SQLAndy - My Blog!
Connect with me on LinkedIn
Follow me on Twitter
Post #812697
Posted Tuesday, November 3, 2009 6:03 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, September 12, 2014 5:40 AM
Points: 31, Visits: 563
I agree , these days with the rise in white collar crime all data should be treated as sensitive.
Post #812875
Posted Tuesday, November 3, 2009 6:07 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Monday, May 7, 2012 9:23 AM
Points: 304, Visits: 716
Imagine a database of valued recipes. The company that keeps this database does not want you to know what ingredients go into their product. They also do not want you to know the cooking steps to make the given recipes. I can understand that in a case such as this hypothetical, those columns must be encrypted.

Now imagine a customer calling up and asking if the company makes a certain product, but some knucklehead encrypted the product column and the customer service person has to respond that they need 15 minutes to locate the DBA, decrypt that column, and then lookup whether or not they make the product.

On the one hand, you have an intelligent use of encryption of sensitive database columns. On the other hand, you have a DBA who has made a simple customer request a major project, cost the company time, money, and likely the customer is not going to hang around waiting.

This is the scenario I have faced many times in my career - DBAs who think everything under the Sun should be encrypted without thinking about the consequences and costs in time and effort to the company.

The answer? I would not agree that everything should be encrypted. I think the use of encryption, like many database features, has to be thought out beyond the mind of just the DBA. Indeed, the DBA is the last person to make this decision because usually, they are the people who do the least consuming of the database information. Leave this matter to Customer Service, Management, and the Customers - serve them!!! Not the DBAs often myopic idea of what amounts to sensitive data.


There's no such thing as dumb questions, only poorly thought-out answers...
Post #812876
Posted Tuesday, November 3, 2009 6:35 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, July 17, 2013 12:22 PM
Points: 107, Visits: 290
Everything definitely should NOT be encrypted. The US military learned long ago that "overprotecting" classified material was as bad as no protection.

The reason? Human nature.

When all material had to be handled as "Top Secret", including information that is unimportant or irrelevant, people tend to assume that none of the material is really that important.

Encrypt everything and you will begin to see encryption keys written down on post-it notes hanging off monitors.

Also, there is the issue of cost in both time and money.

It may be easiest for a DBA if everything is encrypted, but that doesn't mean it is best for the organization.
Post #812892
Posted Tuesday, November 3, 2009 7:16 AM


SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Monday, September 8, 2014 11:08 AM
Points: 644, Visits: 2,134
For those worried about the loss of keys, do what we do in our company.

Any new or changed encryption key is always in two parts. The security team typically enters one half and the DBA's enter the second half. Neither of us know the other's password. Plus, we have our half of the key written down and locked in the CIO's safe and so do the security folks.

Back up your keys and you should be good to go.


Gaby
________________________________________________________________
"In theory, theory and practice are the same. In practice, they are not."
- Albert Einstein
Post #812909
Posted Tuesday, November 3, 2009 7:23 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, September 12, 2014 5:40 AM
Points: 31, Visits: 563
It depends on how incryption is setup and managed
Post #812912
Posted Tuesday, November 3, 2009 9:04 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, February 2, 2011 11:51 PM
Points: 1, Visits: 7
I would certainly try TDE -- if only it were available on SQL 2008 Standard. Any experts with recommendations on alterntives to TDE for the rest of us who don't have SQL 2008 Enterprise?
Post #813001
Posted Tuesday, November 3, 2009 11:21 AM
Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Friday, August 29, 2014 11:17 AM
Points: 707, Visits: 396
While reaing this article I was reminded of an old episode of 60 Minutes on CBS where they were interviewing a professional car thief. When the thief was asked by the interviewer how he could avoid getting his fancy car stolen, he replied "don't buy it" and further stated that all he had to do to steal the vehicle was use a fork lift to set it on the back of a flatbed truck and drive off.

Even with all of the data protection tools available in today's world, if someone wants the data bad enough and they are persistent, in many cases they will find a creative way to obtain it.



Post #813113
Posted Tuesday, November 3, 2009 11:24 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, September 12, 2014 5:40 AM
Points: 31, Visits: 563
Agreed but as DBA's we also have to think like them (thieves) and make do with the tools we have
Post #813117
Posted Tuesday, November 3, 2009 12:46 PM


SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Monday, September 8, 2014 11:08 AM
Points: 644, Visits: 2,134
Mad Hacker (11/3/2009)
While reaing this article I was reminded of an old episode of 60 Minutes on CBS where they were interviewing a professional car thief. When the thief was asked by the interviewer how he could avoid getting his fancy car stolen, he replied "don't buy it" and further stated that all he had to do to steal the vehicle was use a fork lift to set it on the back of a flatbed truck and drive off.

Even with all of the data protection tools available in today's world, if someone wants the data bad enough and they are persistent, in many cases they will find a creative way to obtain it.

But to carry the analogy further, imagine an encrypted database is a car where the doors, hood, and trunk are all welded shut and the undercarriage is covered by a large metal plate also welded on. Decryption is the "magic" that can cleanly remove the weld, but it makes the luxury car pretty useless for the thief if he has to destroy it to open it.


Gaby
________________________________________________________________
"In theory, theory and practice are the same. In practice, they are not."
- Albert Einstein
Post #813161
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse