Necessity of Securing Database Config

There are many problems with securing enterprise databases, far more than the IT industry would care to acknowledge. Research and discuss one particular database security issue. How can this problem be addressed?

One significant database security issue, according to McGowan, Bardin, and McDonald, is that “With any complex software system, poor configuration practices cause vulnerability.” (2009, p171) They, correctly, assert that this is the case with database systems. Oracle databases are a good example of the complexity and how poor configuration can occur. Configurable options include accounts, authentication modes, options and products, schemas, and passwords. (Oracle, 2012)

For instance, features of user accounts which are configurable include limits on failed login attempts, password lifetime, password reuse restrictions, number of concurrent sessions, and idle timeout. (Baccam, 2010) Preventing remote password brute force attempts, making sure to expire passwords, and making sure an idle session isn’t left available for hijacking all can be implemented through this type of options.

Another important configuration to be aware of it being sure to maintain audit trails and transaction records. Baccam’s paper details exact configuration options that should be enabled for security: settings like “AUDIT_SYS_OPERATIONS (Should be set to TRUE.)” and “AUDIT_TRAIL (Avoid FALSE or NONE settings.)” (2010, p5)

Default accounts, especially ones with static or predictable passwords, need to be addressed. It is the fourth item on Oracles Guidelines for Securing a Database Installation and Configuration.

1. Before you begin an Oracle Database installation on UNIX systems, ensure that the umask value is 022 for the Oracle owner account.
2. Install only what is required.
3. During installation, when you are prompted for a password, create a secure password.
4. Immediately after installation, lock and expire default user accounts.

(Oracle, 2012)

Limiting the install will be familiar to anyone who has tried to harden a server, where all unnecessary services running present additional potential attack vectors. Oracle mentions that the installation media defaults to installing multiple products and ones not required should be uninstalled or not installed by way of the custom choice. Similarly sample schemas are included for helping set up test databases. These should not be used for production machines. (Oracle, 2012)

---

Baccam, T. (2010). Oracle Database Security: What to Look for and Where to Secure. SANS Analyst Program. Retrieved from https://www.sans.org/reading-room/analysts-program/oraclewhitepaper-201004

McGowan, J., Bardin, J., & McDonald, J. (2009). Storage security. In Vacca, J. R. (Ed.), Computer and information security handbook. Boston, MA: Morgan Kaufmann Publishers.

Oracle. (2012). Keeping Your Oracle Database Secure. Oracle® Database Security Guide. Retrieved from http://docs.oracle.com/cd/B28359_01/network.111/b28531/guidelines.htm#i1007892