TL;DR version - if you don't apply security patches, or take basic precautions, you will get compromised.
It is sad that our government IT organizations are so poor, I would consider that a National Security threat much more than having the FBI help some whack job build a fake bomb so they can publicly "break up" a terror plot.
I've seen various stories about it. In a couple cases, evidence suggested that the FBI sought out unstable individuals and convinced them to engage in terror plots (instead of working their way into existing terror groups).
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 NSA seems technically capable, though. (They seem to get the best of the best software engineers / IT people.) Not that it's good they have it, but at least they can keep it safe from outside attackers.
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.
> Chief among them is the fact that none of the 354 database tables containing social security numbers were encrypted. Using strong cryptography to protect such "at rest" PII has long been considered a best practice in government and corporate data security.
Really? Although I don't work in that field ('government and corporate data security', or generally anything where we have to deal with SSN's and such) -- that doesn't make a lot of sense to me. Encrypted database tables? I've never even heard of that. Can someone who does work in this domain tell us if this makes any sense at all, or translate this into what it actually means technically?
(On the other hand, the fact that 354 database tables existed with SSN's is a red flag in the first place, clearly. There's plenty of clear problems with what was described, I'm just curious about this alleged 'encrypted database table best practice')
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.
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.)
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.
20 comments
[ 2.7 ms ] story [ 57.3 ms ] threadIt is sad that our government IT organizations are so poor, I would consider that a National Security threat much more than having the FBI help some whack job build a fake bomb so they can publicly "break up" a terror plot.
I've seen various stories about it. In a couple cases, evidence suggested that the FBI sought out unstable individuals and convinced them to engage in terror plots (instead of working their way into existing terror groups).
> so they can publicly "break up" a terror plot
I thought it was purely to get publicity or instill fear in people while getting good press for the FBI, rather than for a sting operation.
Really? Although I don't work in that field ('government and corporate data security', or generally anything where we have to deal with SSN's and such) -- that doesn't make a lot of sense to me. Encrypted database tables? I've never even heard of that. Can someone who does work in this domain tell us if this makes any sense at all, or translate this into what it actually means technically?
(On the other hand, the fact that 354 database tables existed with SSN's is a red flag in the first place, clearly. There's plenty of clear problems with what was described, I'm just curious about this alleged 'encrypted database table best practice')
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.
- http://en.wikipedia.org/wiki/Transparent_Data_Encryption
Apparently widely used enough to have support existing for it.
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.)
Key management so that you can do anything with the data is significantly harder, depending on your threat model.
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.
So I'm not really going to look down on the govt IT workers (or contractors).