SQL injection and buffer overflows are database vulnerabilities that have been exploited for more than a decade, yet they remain common attack vectors in compromising database systems, even when patches and workarounds exist. Attackers also burrow their way in using default user account names and passwords; all the while, database administrators and IT professionals complain about the costs of provisioning user accounts. And finally, through public breach disclosures we learn that unencrypted tapes are lost or sensitive data is regularly moved to unsecured systems.
Clearly we're still missing the basic steps for securing database systems.
So forget fancy encryption techniques, event correlation or forensic analysis. Instead, organizations, especially in this troubled economy, need a clear, actionable and pragmatic approach to database security. Unfortunately the essentials are often overlooked in large organizations and appear overwhelming to database professionals who don't know quite where to start.
We want to make it simple. Here we'll offer a quick checklist to cover database configuration, data safeguards, account provisioning, OS/database interaction and considerations for front-end applications that use the database. Without these foundational sanity checks in place, many elaborate database security measures are a waste of time.
Here are the rudimentary security measures that you must take to protect the database from common threats. While they may take time to investigate and effort to perform, they are easy and effective:
ACCESS CONTROLS AND AUTHORIZATION STEPS
You may be tempted to skip ahead because you think you already have access controls in place, and then promptly fail a security review. Just because you have an access control system does not mean your system is secure. Database authentication and domain authentication are different, and great care must be taken so these two systems coordinate access and don't allow users to bypass database authorization entirely.
This is your first line of defense for database and data security, and it warrants close inspection to ensure proper configuration of accounts, as well as proper deployment of the two systems. Keep in mind that the longer a database has been in operation, the more access rights drifts away from a secure baseline.
- Change default user passwords immediately upon installing the database. Periodically verify they have not reverted because of a reinstall or account reset.
- Lock user accounts not in use. If you are certain they will never be used, remove them. This is especially important with canned database testing, tutorials or demonstration users. These known accounts are packaged with the database, and are exploitable to gain access to data and database functions.
- Enforce stronger passwords. If you are using domain-level access to control database authorization, then you can set policies for stronger passwords. Our recommendation is you rotate passwords, and move away from static passwords.
- Remove public accounts, as well as public access from all accounts. There is no use case where you want the general public to have access to your database.
- Choose domain authentication or database authentication for your database users, and stick with it. Do not mingle the two. Confusion of responsibility will create security gaps.
- Examine roles and groups closely. List out user permissions, roles and group participation, and review it to make sure users have just enough authorization to do their job. Unfortunately, depending upon the number of users in your database, this can be time consuming. Even when automation tools collect permissions assigned to each user account, manual review of settings is still required to detect problems. The bad news is this is not fun, and for large databases, you should plan on spending a day to get the permissions mapping right. The good news is once it is set, it is much easier to detect unwanted changes and stop escalated privileges.
- Protect administrative functions from users. Database vendors list functions, roles, stored procedures and utilities dedicated for administration. Do not delegate these functions to users.
- Divide database admin duties. For companies with more than one database administrator, divide administrative tasks between different admins, operating under different administrator accounts. The relational database platforms provide advanced access control provisions to accomplish this, allowing both for separation of duties, as well as locking down the master DBA account.
ASSESS DATABASE CONFIGURATION
This is very important for determining security and operational integrity.
- Find out how your databases are configured, either through database queries and analysis of configuration files, or via a freely available assessment tools. All database vendors recommend configuration and security settings, and it does not take very long to compare your configuration to the standard.
- Remove modules and services you don't need. Not using replication, for example? Then remove those packages. These services may or may not be secure, but their absence assures you are not leaving an open door for hackers.
- Document approved configuration baseline for databases. This should be used for reference by all administrators, as well as a guideline to detect misconfigured systems.
- Use scanning tools to discover the databases you have, and be consistent when applying configuration settings.
ASSESS DATABASE/PLATFORM INTERACTION
All databases provide means to directly call operating system commands for administrative tasks. These functions are comprised of OS and database code, running under administrative permissions, and offering a bidirectional portal to the database. These recommendations are meant to close security holes along this boundary.
- Disable extended or external stored procedures.
- Ensure the database owner account on local platform, under which the database is installed, is not assigned domain administrator functions.
- Make sure domain administrators are not database administrators.
- Tie import/export utilities, startup scripts, registry entries or properties files to the local database owner credentials.
SECURE COMMUNICATIONS
You want to make sure that communications to the database are kept private.
- Encrypt sessions between applications and the database, especially Web application connections.
- Reset database port numbers to non-default value. For example, moving Oracle's default port of 1521 to a random value defeats automated attacks, and makes it harder for an attacker to probe for information.
- Block ad-hoc connections. Ad-hoc connections from undesired locations, time of day or through unapproved applications can be detected and rejected by simple login triggers, database firewalls and some access control systems.
PATCH THE DATABASE
Your goal is to leverage the security knowledge and expertise of the database vendor, allowing them to find and address security issues. This requires certifying and installing patches on a regular basis.
- Create an environment and process to perform a sanity functions check on database patches prior to production deployment.
- Don't allow patch downloads by individual DBAs; Rather have centralized, approved and verified copies available.
- Synch internal patch cycles with vendor patch releases.
- Reconfigure in the cases where patch or alteration of functions is unacceptable. If you employ database/Web application firewalls, determine if you can block the threat until a suitable patch is available.
APPLICATION USAGE OF THE DATABASE
Enterprise and Web applications leverage more than basic data storage, using service accounts that are provisioned with a broad range of capabilities.
- Segment the authorization between common users and application administration accounts.
- Restrict connection pooling where a single database account is leveraged by all database users. If possible, divide the application processing into different groupings, and perform these operations under different database user accounts. In addition, access permissions can be minimized in accordance with the role as it provides segregation of duties and makes log file analysis easier.
- Modify the application-to-database connection to allow for database queries to be associated with an end user. This makes audit analysis and policy enforcement easier.
MEDIA PROTECTION
Protecting backup media is not optional because lost media is the leading cause of data breaches. There are several methods available that do not require alteration of processes or applications, including database transparent encryption, which requires no changes to application code and is often available free from the database vendor.
LOG AND EVENT REVIEW
- Use logging if you can.
- Create a log retention policy, determine what events you don't need and filter them out.
- Review logs periodically, focusing on failures of system functions and logins that indicate system probing.
- Review log settings periodically.
EMBRACE INSECURITY
No matter what you do, you will never be 100 percent secure. Take this into account, and plan your response to security events.
- Inventory your databases.
- Discover and catalog your sensitive data.
- Have a plan on what to do if data is lost or stolen.
- Have a disaster recovery plan.
- Create a cooperative culture, get to know the applications developers and administrators, and make sure they understand that everyone needs to work together. If you have a compliance group, get to know them, and ask for their advice and opinions.
COMPLIANCE FORCES ENCRYPTION, AUDITING
If you have valuable data, odds are you have an industry or governmental obligation to perform the following recommendations. They are good security practices for everyone, but as it costs additional time and money to implement, they were largely ignored prior to regulatory pressure. The two most commonly prescribed regulatory requirements are auditing and encryption. These functions can be accomplished with the tools provided by the database vendor, but given the difficulty of implementation, deployment and management of these systems, you will be purchasing additional tools and platforms to alleviate day-to-day management and performance issues.
Auditing. Database auditing is used to capture a record of database transactions, which is then used to detect suspect activity and perform forensic audits. All of the relational database platforms have auditing features that capture transactions on the data and administrative operations against the database system. Depending upon the vendor and how the feature is deployed, you can gather detailed transactional information, filter unwanted transactions to capture a succinct view of database activity, and do so with only modest performance impact.
Using the standard software provided by database vendors will be ample to collect needed data, but you will need to develop a review process and reports to demonstrate compliance. Database auditing monitoring and log management tools are also available to automate these efforts. While the latter requires additional investment, these tools provide better performance, are easier to use, and have prebuilt policies and reports specifically designed for regulations.
Encryption. There are many forms of database encryption available, but they typically break into two families: transparent encryption that covers the entire database and requires no modifications to business processes, and user encryption applied only to select objects within the database that requires alteration of the application code. Transparent encryption is really designed to protect data on media, such as disk drives and backup tapes, from being accessed outside of the database. User encryption can be used for both media protection and protecting data from misuse.
When we discuss encryption to meet regulatory mandates, transparent encryption options are not suitable measures to meet requirements such as the Payment Card Industry Data Security Standard (PCI DSS), but they do satisfy most state data breach notification law requirements. As the cost and complexity is radically different between these two options, you will need to discuss which is appropriate to satisfy your auditors before deciding upon a course of action. Make sure you are addressing the right threat before deciding how you are going to implement database encryption.
You can begin any of these actions today, and they are proven effective at preventing the most common database attacks. Better still, the basic steps are free, and with a little of your time and energy, they can be completed without having to purchase specialized products or services. You can buy aftermarket products to perform these tasks, and they will do the job better, faster and with less effort on your part.
You need not let cost stop you from performing these security steps, and in this economic climate where we are all expected to do more with less, that is a good thing.
Adrian Lane is a senior security strategist with Securosis LLC, an independent security consulting practice. Send comments on this article to feedback@infosecuritymag.com.
