eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Securing the database is top of mind at most organizations now more than ever. How not? As it is, Slammer slapped us last winter, Microsoft had yet another SQL Server Hotfix patch out as of Friday, and Oracle on Friday put out a high-severity security alert warning of Secure Sockets Layer (SSL) vulnerabilities that require immediate attention.
Some good comes out of even these miseries. Case in point: Following the SoBig and Blaster devastation wrought over the summer, Microsoft in August finally declared that it had committed to automatic security patch updates for its SQL Server database.
But—and pardon me for stating the obvious—plenty of bad is still coming out of these worms and viruses. More stating of the obvious: We cant rely on vendors to secure the database. No matter how locked-down-by-default Oracle 10g gets (click here to read about Oracle security guru Mary Ann Davidsons plans for making 10g secure by default), no matter how automated SQL Server security patches get, database administrators and security officers are still making mistakes that can easily be avoided.
For example, many database security problems arise from a lack of tweaking. Users install a database straight out of the box, leaving it the way it is without turning off all the default features, passwords and accounts that ship wide open with the product. While these features make it easier for DBAs and developers to work with a product, they were never designed to be left on in a live database, lest an enterpise be left vulnerable to internal and/or external attack.
So lets say you do lock down a database. Does that mean you can walk away and forget about it? Nope. You need to revisit it on a recurring basis to see if things have changed. Are there new vulnerabilities? Has somebody unlocked something that was previously locked? Does a user mysteriously have privileges nobody ever gave him or her?
Its impossible to say how often you need to check up on your database. It all depends on how active, how large and how important it is, points out Aaron Newman, database security guru, CTO and co-founder of Application Security Inc. Other factors that play into the formula include how many resources a firm has to throw at database security, including DBAs or, in the best-case scenario, independent parties to review security.
Next page: More easy-to-avoid database security gotchas
Easy
-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.