By Lisa Vaas  |  Posted 2007-03-30 Print this article 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 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 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 TJX—or both—there'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.

Protecting data requires constant vigilance, writes Eric Lundquist. Click here to read his column.

The assessment would include looking for default IDs and passwords that might still be present, for example, Julian said—a 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 steps—database assessing and monitoring—could "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."

Check out eWEEK.com's Security Center for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK's Security Watch blog.

Lisa Vaas is News Editor/Operations for eWEEK.com and also serves as editor of the Database topic center. Since 1995, she has also been a Webcast news show anchorperson and a reporter covering the IT industry. She has focused on customer relationship management technology, IT salaries and careers, effects of the H1-B visa on the technology workforce, wireless technology, security, and, most recently, databases and the technologies that touch upon them. Her articles have appeared in eWEEK's print edition, on eWEEK.com, and in the startup IT magazine PC Connection. Prior to becoming a journalist, Vaas experienced an array of eye-opening careers, including driving a cab in Boston, photographing cranky babies in shopping malls, selling cameras, typography and computer training. She stopped a hair short of finishing an M.A. in English at the University of Massachusetts in Boston. She earned a B.S. in Communications from Emerson College. She runs two open-mic reading series in Boston and currently keeps bees in her home in Mashpee, Mass.

Submit a Comment

Loading Comments...
eWeek eWeek

Have the latest technology news and resources emailed to you everyday.