Dont Let These Security Gotchas Get Your Database

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

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.
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


 
 
 
 
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