Easy

 
 
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