Core Security
info@coresecurity.com  | +1.617.399.6980 | Contact Us   Core Blog Core Blog Twitter LinkedIn youtube
News
SHARE
Don't Let These Security Gotcha's Get Your Database

(...)

Other common gotcha's 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, somebody's 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. "We've 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 doesn't want its cashiers to make withdrawals of more than $10,000. On the client software that runs on cashiers' workstations, the bank's 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 don't 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 don't allow overflows into the database itself: a best practice that Cupps employs.

Those are the common gotchas, and I'm sure I missed others. Write to me at lisa_vaas@comcast.net to let me know about other scenarios you see pop up frequently. Also, stay tuned for future database security columns, where I'll be taking a look at issues around regulations such as Sarbannes-Oxley.

Database Center Editor Lisa Vaas has written about enterprise applications since 1997.


Source: eWeek
http://www.eweek.com/article2/0,4149,1409103,00.asp

Related Content