2

 
 
By Lisa Vaas  |  Posted 2007-05-08 Email Print this article Print
 
 
 
 
 
 
 


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. 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 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.


 
 
 
 
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...

 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel