9 Database Security Resolutions for 2011
by Brian Prince
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.
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.
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.
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.
No Title
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.
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.
Password Security
Organizations should ditch default or weak passwords. This password policy should be enforced throughout the entire organization.
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.
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.