TJX: Its the target of the largest known customer record theft of all time, and its a case in point that encryption is not a silver bullet.
This is the heart of the encryption problem, quoted from the 10-K filing The TJX Companies made to the Securities and Exchange Commission:
“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 issuers approval process, in which data (including the track 2 data) is transmitted to payment card issuers without encryption. Further, we believe that the Intruder had access to the decryption tool for the encryption software utilized by TJX.”
Encryption has no value when data isnt encrypted, obviously, but credit cards cant be processed when their numbers are encrypted. Hence, a smart crook will seek a way to get the data during that window of time when its in that state of being “in the clear”—that is, unencrypted.
TJXs intruder also had a backup plan if data in the clear wasnt attainable: namely, the decryption key.
There are several reasons why encryption didnt save TJX and wont save many companies, regardless of how much legislators have mandated or want to mandate its use. (One example of which is the June 2006 White House mandate requiring federal agencies to encrypt the hard drives of all their laptops and mobile devices.)
In an interview with eWEEK, McAfee Chief Security Officer Dr. Martin Carmichael said that after he had read TJXs take on the intrusion, he was curious if TJX was using data masking as articles indicated, or some sort of data encryption. Dr. Carmichael indicated there were different methods of encryption key methods: shared key, in which the sender and receiver of encrypted data both have the same key, or asymmetric, which uses a public/private key pair.
Shared-key encryption is inherently risky, since humans think up convenient but absurdly insecure places to store their keys. “We have seen … some companies that chose to use shared-key [encryption] that stores the key with the data,” Carmichael said. “Which is outside of most policy. Sometimes ease of development can be [counter to] good security process.” In fact, Carmichael has seen keys in data files that are named “key to data.”
Another encryption trap is the use of weak encryption. Original DES (Data Encryption Standard) encryption is now considered to be insecure for many applications, chiefly due to its 56-bit key size being too small. DES keys have been broken in less than 24 hours. Some analytical results point to theoretical weaknesses in the cipher, as well, although those have not been proven in practice. In May 2002, DES was superseded by AES (Advanced Encryption Standard) following a public competition, but DES remained in widespread use as late as 2004; Carmichael said it was “very common in a lot of applications.”
Did TJX use DES? TJX has determined that its data was first accessed by an unauthorized intruder in July 2005, and DES was widely used in 2004, so its imaginable that the company did.
Asymmetric cryptography gives part of a key to the data sender and part of the key to the data receiver. The receiver of data—for example, a bank thats receiving your bank account number or user name and PIN—can publish whats called the public part of the key to the whole world. The only thing that encrypts data, however, is the private part of the key. You as a bank customer can contact your bank using one part of the key, and the bank can match that up with its part of the key, thus having an encrypted session with two different keys.
This type of public/private key cryptography is used because key distribution is a major problem, Carmichael said. Shared keys have to be stored somewhere. They can be unsecure, no matter where theyre kept.
Those who use public/private key cryptography have the private key have more options with asymmetric cryptography and a certificate server thats hard-ened and secured, Carmichael said. The certificate server offers options for key escrow and certificate revocation list offering greater control over keys and their use.
Did the TJX intruder stumble on a key stored with the encrypted data, a la shared-key cryptography, or did the intruder have access to a certificate server? The question is moot, given that the intruder figured out a way to take the data before it was encrypted, but the details of nabbing an encryption key will be instructive if we discover them as TJXs investigation continues.
And so that leaves us with asymmetric, aka public/private, key cryptogra-phy. Is it safe to consider that form of encryption a silver bullet? Encryption is not a silver bullet and weaknesses in key management represent a bullet that can backfire.
Next Page: The downside of encryption.
2
Ted Julian, vice president of strategy for Application Security, said in an interview with eWEEK that the practical issue for customers contemplating encryption is that the technology always has performance overhead. This, in fact, is a common deal breaker, he said.
The reason for the performance hit is that so many applications use sensitive data as an index field. One example Julian offered was the formerly common practice of using a college students Social Security number as a college ID number. To look up any information about a given student meant queries had to be run against that one index field, whether it was looking up grades or tuition payment records.
But given that that field contains a sensitive piece of data—a Social Security number—that index field is also the field an organization will eventually want to encrypt. Once that happens, Julian said, the system will be brought to its knees.
“I dont care if its native encryption in an Oracle 10gR2 database or not,” he said. “It will be untenable.”
To change that scenario, youd have to change all the applications so that they use a different index field. Thats a lot of work. And theres no guarantee that that work wont break applications.
Another equally important issue with public/private key encryption has to do with architecture. The considerations range from how strong the keys are, to where theyre stored, to who gets access. “Not that any of those require a roomful of rocket scientists to figure out, but it takes expertise, and you have to make sure you get it right,” Julian said. “You have to test it in the lab, have to make sure its working effectively, have to get involvement from multiple parts of the organization to make sure its in line with security policy, [and so on].”
Then again, theres the question of application impact. Applications that once handled data that only ran in the clear now have to handle ciphered data. That kind of load change can “quite possibly” break applications, Julian said. An application that wasnt expecting to get a large quantity of data back could easily suffer a buffer overflow.
“Theyll slow down, but you dont know until you build a trial version and do tests in the lab,” he said. “You use a simulated production environment, see how its working and slowly roll out an application. Its a six- to 12-month process for sure.”
And that time, Julian said, is only for one application. One that might break under the strain, to boot.
For those organizations trying to figure out whether to use encryption or how to avoid becoming another TJX—or both—theres hope. For a fraction of the time it would take to set up encryption, an organization could do far more for its security by doing a database vulnerability assessment and setting up active database monitoring, Julian said.
The assessment would include looking for default IDs and passwords that might still be present, for example, Julian said—a situation thats far from rare. It would also include looking for known vulnerabilities, patching them and hardening the databases against attack. Just there, Julian said, an organization can “make material improvements in a single day.”
Monitoring database activity will alert an organization not only to people who are trying to attack a database but also to trusted individuals performing unwarranted actions. Even a DBA, for example, should never do a select-* on a credit card number column.
Those two steps—database assessing and monitoring—could “enormously improve the security posture of a database,” Julian said, “and you havent even started with crypto. Youre still talking about it.”
None of that apparently helped TJX. “Nothings foolproof, to be clear, but in this case it sure appears that monitoring would work,” Julian said. “Youd think 47.5 million credit cards would show up on your screen. If you were watching.”
Editors Note: This story was updated to clarify statements made by Dr. Carmichael.
Check out eWEEK.coms Security Center for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEKs Security Watch blog.
