9 Database Security Resolutions for 2011

by Brian Prince

Defending the database extends beyond the database itself. All applications and reporting that are configured to interact with the database need to be part of the security audit to, for example, verify passwords are secure and not hard-coded anywhere.

Developers have a lot on their plates, but they need to make sure there is room for security on there, too. Some tips: use static SQL—most Web applications should never use dynamic statements, and if they do, all input should be validated. Also, consider using bind variables (parameterized queries) and ensure that database schema for your applications have minimal privileges.

Optional DBMS features can give database application developers more power, but there is a downside—the more features a software package has installed or enabled, the more likely it is that flaws can be introduced. Install only what you use, and remove everything else.

Group accounts can pose a challenge when it comes to locking data access and auditing activity, and should be used with caution.

Access ControlsDatabase access should be mapped to job requirements. In a May survey of 430 members, the Independent Oracle Users Group reported that less than one-third of respondents said they could prove their super-users were not abusing privileges. Care should also be taken when assigning any privileges to public or guest accounts.

Its easy to fall behind in the patching process when databases are in play. However, not keeping up with patching can leave security holes in your database infrastructure.

Organizations should ditch default or weak passwords. This password policy should be enforced throughout the entire organization.

Sensitive data should not be stored in clear text. In addition, consider data masking for test data. Part of this may involve data discovery, so you know where the confidential data is in your enterprise.

Keep any relevant industry compliance regulations in mind, and embrace the dark side—think like a hacker. Look for security issues in configurations and bugs. When you have a security policy set, roll it out gradually, focusing first on the issues you have identified as high risk.