Mark BurgessData security consistently remains one of the top priorities for CIO’s. Increasing threats combined with increasing regulatory and compliance requirements means this is unlikely to change in the foreseeable future.
Enhancing your data security using database hardening provides a robust way to ensure the policies designed to protect the organisation’s data are implemented directly on the database itself.
Why is it then that database hardening remains an uncommon practice across organisations?
4 Reasons Database Hardening Isn’t Common Practice
I believe there are several historical reasons for this:
- Data security policies have historically been implemented outside the database itself. Security policy implementation is traditionally defined as a network access policy.
- Application security is usually implemented as an account/role/privilege model. Database agnostic application development encourages the use of application code based security and not using database platform specific security features.
- Historically, regulatory and compliance requirements for data breach incidents were lower or non-existent.
- Databases were hosted in closed-off networks and supported siloed applications. This is increasingly not the case. Modern systems and applications are required to be accessed and available to global users and trading partners over the internet through a variety of devices.
Ultimately these reasons lead to a gap between data security policy and implementation. Furthermore, data security policies that have evolved in a network access context do not necessarily translate easily into a database context.
Database Platform Barriers To Success
To compound the problem there are a number of technical and operational barriers that can block or hinder efforts to harden the security on a database platform.
Software Upgrades
Database specific security features are constantly evolving and typically require database platform upgrades to adopt the latest features. However, software maintenance and application lifecycle schedules can limit the ability to easily upgrade to more current database releases. Whilst maintaining database software currency is desirable in many organisations it may not be achievable. This can be due to technical and business dependencies outside of the database platform.
Complexity
Hardening a database platform can be complex activity and require considerable application testing. Database hardening can require database security features to be implemented that have a wide range of options. When not implemented correctly there can be significant performance, security and maintenance costs incurred.
Functional and Operational Implications
Some database security features may introduce significant operational and functional change that requires ongoing testing and validation.
For example when implementing virtual private database (VPD) security, appropriate testing will need to ensure applications continue to function as expected with the VPD in place. Testing will need to ensure that the VPD configuration prevents any unauthorised access from viewing sensitive data as well.
It is possible to end up with tests that have to cover not only that the application works as expected but also any malicious activities are prevented as well. The ongoing cost to validate these types of security measures can add up over time.
Potential for Downtime
Implementing database encryption can require significant downtime in large mission critical systems. While there are enhancements being made to reduce the impact of encrypting a database, it still remains a significant change to implement.
Reduction in Application Portability
Application certification requirements can limit what database security features can be used. Database security features by nature are going to be database vendor specific. Oracle will implement security features which will be completely different to how things are done in PostgreSQL or SQL Server.
Certification and support for database specific security features may be unfeasible for many application vendors.
So Where Does This Leave Us?
There is an increased risk that the data security controls in place may not align to data security policy. Particularly when data security is “outsourced” from the database and implemented through application code or network and firewall policies.
Data security policies are defined to protect the organisations data assets. In reality what we end up with are controls being put in place “around” the data assets, not within the assets themselves.
It is uncommon to see security controls being placed “on” the data by using additional database features to ensure that data is protected, regardless of who is accessing the data or where they are accessing it from.
Why does it matter?
A combination of several factors have altered the security profile of mission critical database systems:
- Compliance requirements and data breach penalties are only going to increase as we move more towards a data driven society.
- Reputation and financial costs are real consequence of a data breach. Significant data breach events are now headline news and in many cases there is a corresponding market reaction to share prices.
- There are now severe criminal and financial penalties apply for negligent data breach events.
- An organisation’s databases are an asset that no longer just support business operations. Information on customer behaviour, purchasing preferences, internal business operations, employee patterns and behaviours all provide exponential value well beyond the basic transactional use of the data.
- Security threats are not reducing. Conventional methods of data protection are becoming obsolete as the sophistication of attacks increases.
- Systems are becoming more complex with the opportunity to “leak” data increasing as more systems are connected to external cloud services.
Where to Start Addressing Data Security Issues
If you don’t already, start defining a data security policy based on data access. In many cases this will mean a security policy driven by database access and not network resource access.
Defining a data security policy for a database requires specific data classes, attributes and protection requirements to be identified and documented. This could mean that particular data classes need to be:
- encrypted at rest in the database.
- encrypted at rest in the file system.
- fine grain audited for all access into the data.
- obfuscated to the application for specific attributes.
The most important aspect of this is that the policy is defined in database terms – not application or network terms. This enables the policy to be understood by the teams responsible for implementing the database security frameworks required.
For each data attribute that requires protection, identify available solutions for each data class based on the deployed database platform.
For Oracle Database this could mean consideration of options such as Transparent Data Encryption(TDE), Virtual Private Database(VPD), Oracle Row Level Security (RLS) and Oracle Database Vault. For Microsoft SQL Server Transparent Data Encryption (TDE), Cell Level Encryption (CLE) and Always Encrypted are options to consider.
Once the database requirements are defined you need to consider deployment options within the existing database platform architecture. Taking a database centric view of data security can mean the existing database platform requires re-engineering to meet requirements. Not taking this into consideration can result in significant software licensing or infrastructure changes required to the database platform in order to fit the security policy.
Implementation Considerations
Defining a comprehensive database centric security policy is the first step to database hardening.
Implementing the security policy needs to take into account the following:
- Technical implementation of the security controls in the database.
- Methods to monitor and report on exception events.
- Methods to benchmark database security controls against data security policies and industry standards.
What Role Does Database Audit Play?
Hardening databases is one part of a strategy to protect sensitive data. Auditing provides the means to validate the database security configuration implemented.
Auditing database activity has long been associated with poor performance and management of audit data can prove to be challenging. While this may have been acceptable in the past, a more efficient auditing framework for database activity is a core requirement in today’s landscape.
Historically, auditing review was a reactive activity performed against specific functional areas. While audit information could be captured in the system – typically through application auditing – it was difficult to act upon the audit data to help protect the system. The value of auditing detailed system access becomes somewhat limited if it can not help detect and prevent malicious activity as it occurs.
Translating data audit requirements into a database auditing implementation is another challenge that organisations deal with. Effectively defining audit requirements in business terms for implementation in technical terms requires effective communication between teams. This can be difficult when teams are distributed around the globe.
The above challenges often leads to a situation where audit information around the most valuable and secured data is either not captured fully, or is not easily available to be acted upon.
Next Steps
There are several practical steps that can be taken to start hardening the security around your database platform. It is time to revisit many of the myths around database audit and security hardening and start down the path of adding additional security to your most valuable IT assets.
