By Lisa Vaas  |  Posted 2003-12-09 Email Print this article Print

-to-avoid database security gotchas"> Other common gotchas include physical and logical location of database servers within an organization. According to Mark Shaiman, an analyst with Meta Group, a good number of organizations with largely distributed database infrastructures locate the physical database on, say, somebodys desk on a small server. Meta advises instead physical consolidation in one location. Also, pay attention to logical location: Is the database behind the demilitarized zone? In most cases, it should be in the DMZ—i.e., between two firewalls. Other common areas of database security weakness include poor authentication. "The most common mistake we see is poor authentication," said Ivan Arce, CTO of Core Security Technologies Inc. "Weve seen [weak passwords] at every level: at the operating system and the database levels."
Another typical scenario is when organizations secure the client side and ignore the server side. For example, a bank doesnt want its cashiers to make withdrawals of more than $10,000. On the client software that runs on cashiers workstations, the banks security staff disallows transactions above that $10,000 limit. It seems like a good solution, Arce said, until you come across the technically savvy and ethically challenged cashier who can disable this check by using a generic SQL client and can then connect directly to the database, where there are no checks on what she can do.
Databases that ship with Web front-ends are creating another security problem that should be fairly easy to fix, according to James Cupps, security information officer for a multibillion-dollar company that he declined to name. "If you dont filter incoming information, you can wind up with some weaknesses," Cupps said. To avoid weakening the enterprise infrastructure, DBAs and developers have to check Web interfaces or SQL interfaces that issue direct SQL calls back to the database and standardize code in each field to make sure they dont allow overflows into the database itself: a best practice that Cupps employs. Write to me at lisa_vaas@comcast.net to let me know what other security issues are plaguing your database—and/or to nominate issues for my end-of-year database highlights list. Database Center Editor Lisa Vaas has written about enterprise applications since 1997.
What common, easily avoided security sins do you see perpetrated on the database? Share them and see more from other readers at this eWEEK forum.

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