Securing your Database: 101

Regardless of whether you are running your SQL database (Yes, I know... I should be calling them Relational Databases) on Windows, UNIX, or Linux, the threats and vulnerabilities are very similar.

There are many SQL database vendors on the market. The fact that they need to function in a similar manner based on the SQL standards, makes them vulnerable to similar types of attacks.  These attacks can be initiated locally on the SQL server, or as far away as a client's Web Browser.

Database Vendors: (Comparison of relational database management systems)

Microsoft MSSQL, Oracle, Sybase, IBM DB2, MySQL, PostGreSQL, Informix

Below, I will outline some of the typical threats and misconfigurations that could endanger your SQL database. After each threat/misconfiguration, you will find some of the remediation strategies that can be used to reduce each risk.


Typical Threats

• SQL injection - A SQL Injection is a hacking technique which attempts to pass unauthorized SQL commands through a web application with the intent of having them executed by the SQL server.
• require SQL be constructed using parameterized queries, preventing SQL injection attacks by differentiating code from data.
• require Web Inputs be sanitized and validated - cast type and length.
• install Intrusion Detection/Prevention software and configure it to log and alert!
• do not provide SQL error or warning messages to the public
• limit database privileges

• Network eavesdropping - Network Eavesdropping consists of capturing data packets on the network inline with the intenet of capturing passwords, session information, or confidential data.
• require all communications between Webserver and Database Server be SSL/TLS encrypted.
• also require all communications between developers/administrators workstations and database server be SSL/TLS encrypted 
• Unauthorized server access - Unauthorized server access can be related to poorly configured or patched systems, or improper management of account privileges.
• ensure that database server and all connecting web and app servers upstream are patched in a timely fashion.
• ensure that all unused accounts, services, and features are disabled
• employ "Least Privilege Principle"
• use local firewall to restrict source systems
• install and configure Intrusion Detection/Prevention on database/web/app servers.
• LOG!!!  Review and Alert!  (I can't tell you how important custom logging/alerting is!)
• Password cracking - Password Cracking is the exercise of attempting to recover passwords from a file or network stream using various methods such as a dictionary attack.
• use complex passwords
• install and configure Intrusion Detection/Prevention on database/web/app servers.
• LOG!!! Review and Alert! (Did I mention how important this is?)
•  
• Denial of Service attack - An extension of the SQL Injection, a SQL Denial of Service attack will use any search forms available on your website to get your SQL database to execute a number of long running and CPU intensive queries so that the site becomes unusable to other users.
• install and configure Intrusion Detection/Prevention on database/web/app servers.
• LOG!!! Review and Alert! (Ok... this is important! Really!)

Typical mis-configurations 

• Default, Blank & Weak Username/Password  - As in any computer system, Database password controls are critical in setting and maintaining security of the database.  Default passwords must be changed upon installation. Corporate Password Standards should be maintained for all accounts.
• Excessive User & Group Privilege - Employ both Principle of Least Privilege and Segregation of Duties between Administrative, Application, and User accounts.   
• Unpatched Databases/Operating Systems - Database software, like the Operating System, is an integral part of your overall system security. Failing to patch in a timely fashion based on the vendor's recommendations places you in a state of higher risk.
• Unnecessary Enabled Database/Operating System Features - Any user/service account, feature, or service, installed on a system, that is enabled but not used, is a potential vector for attack.  If you do not need an account,  feature, or service in your production database, turn it off or better yet, remove it.
• Unencrypted sensitive data – at rest and in motion Todays servers have aqequate resources to negate any arguement around encryption/decryption performance. Any sensitive data that resides within the database should be encrypted.  I'm not saying encrypt entire tables or databases, unless required by compliance, but sensitive fields (Social Insurance Numbers, financial information, etc..) should be encrypted. Many SQL Vendors now also provide Transparent Data Encryption for full tables or Databases. Also ensure that any communications to and from the SQL server uses SSL/TLS encryption to prevent eavesdropping.
• Failure to configure audit and transaction logging - Properly configured, audit and transaction logs will allow you to identify abnormal or malicious traffic to your server. If coupled with Intrusion Detection/Prevention software, will be able to alert and/or remediate the intrustion immediately.
• Location of SQL Database server/data - During installation, ensure that the DB software and Databases are on a separate drive/volume from the operationg system. This allows you to provide greater protection to the storage volume without adversely impacting the underlying OS. 

And finally:  On UNIX Systems..... USE A CHROOT JAIL!

A chroot provides a sandboxed environment to install a critical service that "looks like" the host operating system.  It has a file structure similar to the host, and has copies of all the files and libraries required to run the application, but is logically segregated from the operating system it is hosted on. 

A properly configured chroot environment will prevent privilege escalation from the hosted application to the hosting operating system. What happens in chroot, stays in chroot!




Reference Material:


Default  SA accounts: (these need to be disabled or renamed once installation is complete)

Database	Admin Account Name	Admin Database
MSSQL	sa	master
Oracle	sys, system	dba_users
DB2	dasusr1
MySQL	root	mysql
PostGreSQL	postgres	pg_shadow
Sybase	sa, sccadmin	master

Default TCP ports: (firewalls should restrict access on this port to only servers/workstations authorized to communicate with the DB server)

Database	Ports Used
MSSQL	TCP 1433
Oracle	TCP 1521
DB2	TCP 3700
MySQL	TCP 3306
PostGreSQL	TCP 1433
Sybase	TCP 4200

Vulnerapedia! - Extremely nice matrix tool for Vulnerability Attacks/Controls/Threat Agents

databasesecurity.com

How to Build a Chroot Environment in CentOS

Best Practices for UNIX chroot() Operations
Increasing Security With Chroot Jails

Microsoft MSDN: Improving Web Application Security: Threats and Countermeasures
Secure Your MSSQL Server Database
Tips For Securing Your Database Server: MSSQL 2008 Transparent Data Encryption
MySQL: Reference Manual - Security Guidelines
MySQL SQL Injection Cheat Sheet
Symantec: Securing MySQL: step-by-step
IBM Developerworks: Total security in a PostgreSQL database
Security-Enhanced PostgreSQL (SE-PostgreSQL)
Securing PostgreSQL From External Attack
Oracle® Database 2 day Security Guide
Oracle Security Checklist
Oracle 11g Security - Those Pesky Predefined Accounts
Application Security Inc. - Hack-proofing DB2
Securing Your Data Assets Using Sybase® IQ Advanced Security Option

Top Ten Database Security Threats
The 10 Most Common Database Vulnerabilities
Threat and Vulnerability Matrix (Database Engine)
Tackling the network eavesdropping risk
Dark Reading: Five Ways To Stop Mass SQL Injection Attacks
Default Credentials: Low-hanging Fruit in the Enterprise
The Simplest Security: A Guide To Better Password Practices
Database Risk in 2011