November 2, 2009 at 8:13 pm
Comments posted to this topic are about the item It's Time for Encryption
November 3, 2009 at 6:03 am
I agree , these days with the rise in white collar crime all data should be treated as sensitive.
November 3, 2009 at 6:07 am
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.
November 3, 2009 at 6:35 am
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.
November 3, 2009 at 7:16 am
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
November 3, 2009 at 7:23 am
It depends on how incryption is setup and managed
November 3, 2009 at 9:04 am
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?
November 3, 2009 at 11:21 am
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.
November 3, 2009 at 11:24 am
Agreed but as DBA's we also have to think like them (thieves) and make do with the tools we have
November 3, 2009 at 12:46 pm
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
November 3, 2009 at 3:06 pm
Jody Roberts (11/3/2009)
I agree , these days with the rise in white collar crime all data should be treated as sensitive.
I have to take exception to that. You should definitely review your data for things that need to be protected, but encryption has a cost in more than money, processing and loss of functionality are all costs. So encryption is not free, even if it doesn't cost $. There are very few cases where everything in your database should be protected at this level. I would venture to say that in 99.9% of ALL databases there are probably not more than 10 columns that contain truly restricted/protected data, and those columns SHOULD be protected.
I just think whole db encryption "just to be safe" is overkill, and from my perspective lazy.
Things like you backups should probably be encrypted as well as your user's laptop hard drives, you are much more likely to lose or misplace them. But data in a live system is much more easily monitored and controlled. And most of the breaches that have made the news have come from mistakes that internally I can't believe no one said was a bad idea.. Unencrypted wifi, storing an entire years worth of CC data on a store machine, let alone it not being encrypted, poor access monitoring, poor system change control, etc..
All this adds up to a tried and true defense technique, defense in depth:
http://en.wikipedia.org/wiki/Defence_in_depth
Mideaval castle were an example of this..
I was reading a book recently by Kevin Mitnick, you know the worlds most dangerous hacker..
He made a reference to most organizations defense, a crunchy outside with a nice chewy inside. Meaning that once you breach the outer wall you have little between you and the prize.
CEWII
November 3, 2009 at 3:27 pm
I think TDE is of limited use in reality. It protects backups on tape but no need to encrypt an entire production database on an enterprise web application to achieve that. Non-encrypted backups can be restored onto a second server, encrypted, new encrypted backup made and copied to tape. OK, more hassle but if it's that important an little bit of time will create an automated process to do it for you.
If your server is a small box with local disk in a relatively insecure room then certainly TDE helps you if someone broke in and stole the server. All our data is on a big san in a relatively secure data centre. Even if someone were to get into the data centre will they make it out the door with the san; I doubt it. These things are pretty large. You won't get one in a back pack :-D. If they do get away with the san, will they know how to work out how to access the correct partitions on it to be able to attach the database to a copy of SQLServer; I doubt it. Most people wouldn't even know how to plug it in and access it. I can't say it will never happen, but the odds are so low they don't justify the use TDE. After all, once we use TDE there is the old cherry of how to protect the key and the risk if it is lost and should it in fact be encrypted as well, not to mention the loss of being able to use compression in backups and on the database in SQL 2008 (a key feature nowadays with databases being many hundreds of GB).
Are you really protecting the database if you use tde; I don't think so. Bear in mind the data is only encrypted on the disk. Once it is in cache it's not encrypted any more. There is a far greater risk of someone hacking into the server because of poor passwords and lack of proper database security, or using sql injection to corrupt your database, than someone managing to steal your san and knowing how to access the data on it.
Your time is better spent actually making your server more secure than encrypting the data with tde. TDE does not protect you if someone gets access to the sqlserver.
We considered tde but came to the conclusion it offered us very, very little extra protection over what we already had with our san, but came at a very high cost in terms of additional risk of losing keys and managing and using keys during out of hours support in the middle of the night and loss of compression.
Better to focus on how secure your server and databases actually are in my opinion.
Cheers
Roddy
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply