A Guide to Database Security

SQL injection attacks allow attackers to spoof identity, tamper with data, void transactions or change balances, disclose or destroy all data on the system, and become administrators of the database server (if you want to know how SQL injection attacks are carried out, there’s a good wiki page that explains the technical implementation).

A 2012 study found that the average web application received four attacks per month, and retailers received twice as many attacks as other industries.

To mitigate such attacks, security testing early in the development life cycle is critical to finding vulnerabilities or coding errors. In addition to SQL injection attacks, such code reviews check for Cross-Site Scripting and Permission Elevation attacks.

Here is our checklist of security measures that will protect your database from common threats:

Poor password selection for services like email, website and cloud services logins make them attractive to brute-force attacks to gain entry to a system. For example, an average person’s mailbox over time accumulates enough data for a fully-fledged identity theft.

But even if your password protocols are good, remember that the longer a database has been in operation, the more access rights drift away from a secure baseline. For this reason:

• Change user passwords when you install a database. If you reinstall, or reset the account in the future, always check that passwords haven’t reverted to the previous version.
• Delete user accounts that are no longer in use, especially any temporary ones set up during database testing, tutorials or for demonstration users.
• Enforce the use of strong passwords. The standard technique for securing passwords is by ‘hashing and salting’. Hashing uses algorithms to convert a password into a long series of jumbled numbers and letters which cannot be reversed. This allows the hashed password to be used to check a future login, but the password itself is never stored.
• There will never be a reason to let the general public have access to your database – so ensure there are no public accounts.
• Avoid the potential of security gaps by choosing either domain authentication or database authentication, not a combination of both, as this can lead to confusion of responsibility.
• Review user permissions to give only enough authorisation to do the job. Even if you use an automation tool to collect permissions, it’s a good idea to review the list manually to detect any unnecessary privileges.
• Don’t allow users to have access to administrative functions that they don’t need. Utility functions should be under access control and limited to the admin team.
• Make sure administrators have a clear understanding of their duties. This is particularly important if there are several administrators with different admin accounts set at different levels of access, as separation of duties reduces the risk of mistakes. Separating admin duties also allows the master DBA account to be locked down.

To keep your database secure requires more than just good access control. How it’s configured will also have a bearing on security, which is why adhering to standards, agreed procedures and good practice is important. If you’re not sure how your database is configured, there are freely available assessment tools you can use to find out, as well as by running database queries or analysing configuration files. Your security checklist should include:

• Remove any services you don’t need. This will remove the possibility of hackers using unneeded services to gain entry.
• Be consistent when applying configuration settings to all your databases.
• Create an approved baseline configuration document for reference by administrators. The document will also serve as a guide to future system misconfiguration.

Because all databases talk to the operating system to perform administrative tasks, it’s possible for database security to be compromised via the OS. To prevent this from happening:

• Ensure the platform on which the database is installed hasn’t got the same administrator privileges as the database itself. In other words, the database owner account shouldn’t be assigned domain administrator functions too.
• Domain administrators should not be database administrators too.
• Assign import/export utilities, start-up scripts, registry entries or properties files to the local database owner credentials.

Data is vulnerable to theft and modification while it is at rest, in a cache or session store, and while it is in transit. A key to protecting this data is to be conscientious of security risks while data is being accessed and make sure that communications are kept as private as possible. To do this:

• Encrypt sessions between applications and the database (especially web applications) by using a secure, encrypted connection.
• Change database port numbers to non-default values to make it harder for an attacker to get information, especially automated attacks.
• Block ad-hoc connections using access control. If you have personnel working outside the office, access can be restricted for any undesired locations, the time of day, or attempts to use unapproved applications.

If you’re applying a patch or updating the database on some way, make sure you certify the change before deploying it to production.

• Perform a sanity functions check (a very brief run-through of functionality) to make sure the system still works as expected.
• Use approved and verified copies of patches; don’t allow patch downloads by individual DBAs.
• Install patches as soon as they are released by the vendor. If possible, synch update cycles to coincide with patch releases.
• If a patch to a new threat is unsuitable for any reason (e.g. alteration of functions), work around it by reconfiguring the portion that is unacceptable. Use database and web application firewalls to block the threat until the right patch becomes available.

Service accounts, used by Enterprise and web applications, normally have a broad range of capabilities that go beyond basic data storage. Where a single database account is used by many database users:

• Minimise access permissions in accordance with the role of the user.
• Use different authorisation between common users and application administration accounts.
• Restrict connection pooling and divide the application processing into different groupings.
• Allow for database queries to be associated with an end-user for better audit and policy enforcement.

• Retain important logs and review them periodically, focusing on system failures and suspicious logins.
• Review log settings periodically.

After all is said and done, plan for what to do if your database security is breached:

• Know your team and instil a cooperative culture of advice and opinions.
• Catalogue all your sensitive data.
• Have an agreed plan if data is lost or stolen.
• Make sure you have a disaster recovery plan.