I’m sure everyone has heard about TJX’s recent data security “problems”, if that’s what you can call “the largest known customer record theft of all time”. The Chicago Tribune article linked above is well worth a read.
This eWeek article adds valuable details and analysis on how TJX had a data encryption
They quote TJX’s 10K filing:
“Despite our masking and encryption practices on our Framingham system in 2006, the technology utilized in the Computer Intrusion during 2006 could have enabled the Intruder to steal payment card data from our Framingham system during the payment card issuer’s approval process, in which data (including the track 2 data) is transmitted to payment card issuer’s without encryption. Further, we believe that the Intruder had access to the decryption tool for the encryption software utilized by TJX.”
And they interview Ted Julian, Application Security’s VP Strategy, where he says:
“I don’t care if it’s native encryption in an Oracle 10gR2 database or not,” he said. “It will be untenable.”
Obviously if the encrypted data is ever to be used again in the original form (as opposed to as a checksum), there will be vulnerabilities. Is Julian repeating that platitude or is there something to this event I have missed, I wonder.
1 Comment. Leave new
As we had a discussion about it with Paul, I recalled that we’ve been involved in couple projects encrypting sensitive data in Oracle database.
In one project, there was so called secure key server that was responsible for providing client a key used to encrypt and decrypt the data. Another project is based on decryption/encryption server where server itself does encryption/decryption with data sent over SSL encoded connection.
Interesting that in both cases, vulnerable information is used over and over again in its non-encrypted original form leaving an intruder a chance to capture that sensitive data. Both products/vendors are “certified” with well known these days security standards.