2By Lisa Vaas | Posted 2007-03-30 Email Print
News Analysis: The largest data theft ever is a case in point that encryption is not a security cure-all.
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 student's 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 dataa Social Security numberthat 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 don't care if it's native encryption in an Oracle 10gR2 database or not," he said. "It will be untenable."
To change that scenario, you'd have to change all the applications so that they use a different index field. That's a lot of work. And there's no guarantee that that work won't 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 they're 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 it's working effectively, have to get involvement from multiple parts of the organization to make sure it's in line with security policy, [and so on]."
Then again, there's 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 wasn't expecting to get a large quantity of data back could easily suffer a buffer overflow.
"They'll slow down, but you don't know until you build a trial version and do tests in the lab," he said. "You use a simulated production environment, see how it's working and slowly roll out an application. It's 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 TJXor boththere's 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 saida situation that's 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 stepsdatabase assessing and monitoringcould "enormously improve the security posture of a database," Julian said, "and you haven't even started with crypto. You're still talking about it."
None of that apparently helped TJX. "Nothing's foolproof, to be clear, but in this case it sure appears that monitoring would work," Julian said. "You'd think 47.5 million credit cards would show up on your screen. If you were watching."