Practical Steps to Hardened Database Security

MarkBurgessMark Burgess  |  

Database security is crucial to protecting an organisations data assets. We cover some practical approaches to increasing your data security by hardening your database management systems.

Establish your database security baseline.

Before making any changes it is useful to establish the baseline of your database security. For Oracle this will mean running the DBSAT tool which provides a comprehensive review of the database security related configuration. For Microsoft SQL Server this will require running SQL Vulnerability Assessment. Both tools provide a wealth of information on the security related settings on your databases.

Enable auditing of sensitive tables, columns.

Robust database security frameworks have audit enabled on sensitive data. Sensitive data is typically limited to certain tables and columns in the database. Enabling audit on only these specific database objects provides an effective way to monitor access to sensitive data without incurring the overhead of full database auditing.

Blanket database audit implementations are an easy way to generate too much audit information. This causes the following problems:

  • Important audit events are masked due to the volume of audit data.
  • Application performance degradation.
  • Additional maintenance overhead to manage purge and archive policies around the audit data.

Selective, specific auditing of sensitive data objects makes it far easier for audit information to be collected and acted upon.

There are database features available that allow for the selective auditing of sensitive data. It is no longer acceptable to not audit sensitive data based on historical myths and perceptions around auditing.

Provide means to easily report and act on audit data.

Generating and collecting representative audit data is only one part of the solution. Correct audit data input is the critical precursor to an effective overall process to monitor access to sensitive data and the effectiveness of your database security configuration.

Data breach notification periods no longer allow for lengthy post-mortem analysis of the data breach. Data breach events must be detected, stopped and prevented in an instant to be useful.

Obtaining value from the audit data requires the ability to monitor and create timely alerts on suspicious audit events. There are a number of security tools available that allow for near real-time log collection and actioning. Implementing meaningful audit policies along with supporting management tools is essential.

Evaluate options to encrypt highly sensitive data at rest.

Data encryption at rest is not database encryption at rest. The two are distinctly different implementations and provide different protection against unauthorised access. Typically there are two options for encrypting data at rest: file system encryption or database encryption.

File System Encryption

The storage location that the database is located on is encrypted – provides no protection to unauthorised access to the running database. If an intruder gains access to a database server privileged account they will be able  to access data as if there was no encryption in place at all.

File system encryption protects against servers being “hijacked”. The storage containing the database can not be mounted on reboot preventing the database from being opened.

Database Encryption

Encrypting the data inside the database. An intruder has to be able to access the running database to be able to view the unencrypted data. Data encrypted inside the database is ineligible when attempting to view from an external operating system.

Database encryption at rest does not protect against unauthorised access to a running system. While there is some level of protection from certain threats, sophisticated intruders tend to go after the low hanging fruit – the open and running database itself.

Effective database security requires the correct types of encryption to be used.

Restrict Who Can Connect to the Database

Effective database security limits who can connect to the database and from where the connections can be made from. All database environments should have the following connection restrictions in place:

  • Limit connections to a known set of trusted network hosts.
  • A network or host firewall restricting connections to the database server ports and protocols.

The immediate benefit of the above approaches is to limit what clients can connect to the database. A secondary, and very important benefit, is the ability to monitor and report on connection exceptions is greatly simplified.

Implementing database level connection restrictions places control over connectivity directly on to the database server. The risk of misconfigured or missing network firewall policies or security restrictions is greatly reduced by having this additional layer of security on the database server.

Automate and Streamline Security Reporting

Regular database security auditing and reporting can be quickly and easily performed using a range of tools – most of them available for free. For the commercial database platforms Oracle provides the Database Security Assessment Tool (DBSAT). Microsoft provides the SQL Vulnerability Assessment for use on SQL Server. Both tools comprehensively analyse and report on database platform vulnerabilities and remediation actions required.

Periodic Security Reviews

Database hardening and security reviews need to be incorporated into regular operational procedures. Implementing appropriate database auditing, hardening and monitoring greatly simplifies the ease of database security reviews as part of normal systems operations.

Operational security reviews can effectively cover off who is accessing the database platform and what activities there are on sensitive data. Incorporating this level of analysis into operational procedures can go a long way to helping reduce the risk around data breaches from unauthorised access.

Where to from here?

The historical myths associated with database security and audit need to be dispelled. Two things are a given in the current IT landscape. The value of data is only going to increase and the sophistication of attacks is only going to increase. Delegating control over data access and security away from the database is no longer acceptable. IT organisations must embrace new technologies and methods to add additional security within their database platforms.

Starting with the practical steps listed in this article can get you on the path to greater security and visibility over your database platform.

We cover off the detailed implementation requirements for Oracle Fine Grained Auditing in this article.

About the Author

Leave a comment

Send this to a friend