Database: 9 Database Security Resolutions for 2011

 
 
By Brian Prince  |  Posted 2010-12-27
 
 
 

9 Database Security Resolutions for 2011

by Brian Prince

9 Database Security Resolutions for 2011

Database Security Is More than the Database

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.

Database Security Is More than the Database

Secure Practices for Developers

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.

Secure Practices for Developers

Reduce the Attack Surface

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.

Reduce the Attack Surface

Share Accounts, Shared Vulnerability

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

Share Accounts, Shared Vulnerability

9 Database Security Resolutions for 2011 - Page 6

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.

9 Database Security Resolutions for 2011 - Page 6

Patching Vulnerabilities

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.

Patching Vulnerabilities

Password Security

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

Password Security

Database Encryption

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.

Database Encryption

Designing the Database Security Policy

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.

Designing the Database Security Policy

Rocket Fuel