Database Hardening Checklist
Introduction: This checklist contains generic hardening procedures for database servers that balance industry best practices with the unique requirements of UCD’s environment. Since no database product comes configured securely out of the box it is necessary to follow these steps to prevent attacks from exploiting known vulnerabilities. While this checklist is relatively short, the actual steps for hardening a specific database platform may be more in-depth. The DBA associated with each platform should ensure they understand the detailed tasks that make up each bullet here. These steps should be followed to secure a typical UCD database server, but may not be appropriate in all cases. In cases where an exception must be made, documentation should be retained on this worksheet describing the reason for the exception and any mitigating actions. In all cases, this worksheet should be retained for future reference. Procedure: Complete server hardening checklist. Ideally, run on latest supported version (or at least a supported version) of the Operating System. If at all possible, use the latest generation of database server. MSSQL 2003 is much more secure than 2000, MySQL 4 is much more secure than 3, and Oracle 9 and 10 are much more secure than 7 or 8. Install the latest vendor-provided patches for the database. Be sure to include patches for database support software that isn’t directly bundled with the database. Remove sample databases and database users. Manually review installed stored procedures and delete those that aren’t going to be used. In many cases, most or all stored procedures can be deleted. Where possible, isolate sensitive databases to their own servers. Databases containing Personally Identifyable Information, or otherwise sensitive data should be protected from the Internet by a network firewall, and administrative/DBA access should be limited to as few individuals as possible. Ensure that application access to the database is limited to the minimal access necessary. For example, reporting applications that just require read-only access should be appropriately limited. Manually validate that logging of successful and failed authentication attempts is working. Use complex names for database users. Use especially complex passwords for these users. Use IPsec or SSL to protect access to databases from other network servers. IPSec is particularly easy to setup on Windows hosts using MSSQL, and both Oracle and MySQL provide SSL-based access methods. Create alternative administrative users for each DBA, rather than allowing multiple individual users to regularly use the default administrative account.
1
Applied Trust Engineering, Inc. 8/29/2005 Page 1 of 1