<a href="http://g.adspeed.net/ad.php?do=clk&zid=15220&wd=468&ht=60&pair=as" target="_blank"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15220&wd=468&ht=60&pair=as" alt="i" width="468" height="60"/></a>
Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
<a href="http://g.adspeed.net/ad.php?do=clk&zid=15491&wd=120&ht=300&pair=as" target="_top"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15491&wd=120&ht=300&pair=as" alt="i" width="120" height="300"/></a>
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
SQLServerCentral.com
»
Editorials
»
It's Time for Encryption
12 posts, Page 1 of 2
1
2
»»
It's Time for Encryption
Rate Topic
Display Mode
Topic Options
Author
Message
Andy Warren
Andy Warren
Posted Monday, November 02, 2009 8:13 PM
SSCertifiable
Group: Moderators
Last Login: Thursday, May 09, 2013 12:38 PM
Points: 6,462,
Visits: 1,384
Comments posted to this topic are about the item
It's Time for Encryption
Andy
SQLShare - Learn One New Thing Each Day
SQLAndy - My Professional Blog
Connect with me on LinkedIn
Follow me on Twitter
Post #812697
Jody.WP
Jody.WP
Posted Tuesday, November 03, 2009 6:03 AM
SSC Rookie
Group: General Forum Members
Last Login: 2 days ago @ 7:19 AM
Points: 31,
Visits: 513
I agree , these days with the rise in white collar crime all data should be treated as sensitive.
Post #812875
blandry
blandry
Posted Tuesday, November 03, 2009 6:07 AM
Old Hand
Group: General Forum Members
Last Login: Monday, May 07, 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
bwillsie-842793
bwillsie-842793
Posted Tuesday, November 03, 2009 6:35 AM
SSC-Enthusiastic
Group: General Forum Members
Last Login: Friday, April 12, 2013 7:43 AM
Points: 107,
Visits: 287
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
GabyYYZ
GabyYYZ
Posted Tuesday, November 03, 2009 7:16 AM
Right there with Babe
Group: General Forum Members
Last Login: 2 days ago @ 12:30 PM
Points: 795,
Visits: 1,985
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
Jody.WP
Jody.WP
Posted Tuesday, November 03, 2009 7:23 AM
SSC Rookie
Group: General Forum Members
Last Login: 2 days ago @ 7:19 AM
Points: 31,
Visits: 513
It depends on how incryption is setup and managed
Post #812912
randy.c
randy.c
Posted Tuesday, November 03, 2009 9:04 AM
Forum Newbie
Group: General Forum Members
Last Login: Wednesday, February 02, 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
Mad Hacker
Mad Hacker
Posted Tuesday, November 03, 2009 11:21 AM
Say Hey Kid
Group: General Forum Members
Last Login: 2 days ago @ 9:26 AM
Points: 700,
Visits: 374
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
Jody.WP
Jody.WP
Posted Tuesday, November 03, 2009 11:24 AM
SSC Rookie
Group: General Forum Members
Last Login: 2 days ago @ 7:19 AM
Points: 31,
Visits: 513
Agreed but as DBA's we also have to think like them (thieves) and make do with the tools we have
Post #813117
GabyYYZ
GabyYYZ
Posted Tuesday, November 03, 2009 12:46 PM
Right there with Babe
Group: General Forum Members
Last Login: 2 days ago @ 12:30 PM
Points: 795,
Visits: 1,985
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 »
12 posts, Page 1 of 2
1
2
»»
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.
