How hackers made minced meat of Department of Energy networks

Did the fake bomb scenario actually happen? I'd be interested in reading about that.

One significant reason I don't want the government collecting all of my data is because they seem totally incapable of creating a secure system or even a system that operates properly.

The problem has actually gotten worse -- by acting like asshats and spying on US citizens (as well as a whole litany of other stupidity, like racist drug laws, ...), it's presumably a lot harder to recruit and retain great people for the less-sexy roles like IT/IA.

In the payment industry there is the concept of PCI-DSS. It is basically a set of requirements regarding the handling of sensitive data. While a lot of it is just common sense some of it should be applied to any sensitive data that you are working with.

Encrypted database tables are not that common. More common is encryption of the whole disk or database using Oracle or some other software/hardware.

If you are storing full credit card #s it better be encrypted while the data is at rest.

Don't work in that area but

- http://en.wikipedia.org/wiki/Transparent_Data_Encryption

Apparently widely used enough to have support existing for it.

It's possible to end up with access to a database via some mechanism without having access to the code that can decrypt the values. Perhaps you've stolen a backup, or exploited an SQL injection to get access to one of these tables, but without the decryption code it's useless (if the encryption itself is done correctly).

It's weak protection, because obtaining the database and obtaining the code are pretty highly correlated, but it can make sense in some situations. Obviously, the easier it is to obtain the unencrypted values, the less likely an attacker is to get stranded between the encrypted values and the decryption code. (i.e., an "encrypted partition" doesn't do much to defend against any remote attack because they'll all be using the readable mounted partition, a pervasive API layer that automatically decrypts things for user code is that much easier to accidentally use by the attacker as well, etc. In a weird way you want these fields to be as hard to use as possible, violating normal software engineering rules; every normal ease-of-use consideration is a hole.)

Encrypting database tables is easy.

Key management so that you can do anything with the data is significantly harder, depending on your threat model.

I thought encryption of SSN was a well know basic practice, but other responses here have me wondering. Besides whole tables columns or individual elements (for non-normalized data) can also be encrypted. Some PII like name and address are rarely encrypted in my experience because it's low value, but I've worked on an anonymization project where all PII is stripped out after it's of no value to the organization.

Truly best practice: don't collect SSN unless you truly must have it, and never use it as a foreign key. The government is probably worst offender here, because there are really no consequences to individuals or organizations and tons of legacy systems.