Many common mistakes are easily avoided when securing the enterprise database
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.
Butand pardon me for stating the obviousplenty 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