The Database Audit Conundrum

by Fernando Ohana DBA and Database Security Architect

Database solutions have become ubiquitous in today’s technological world. DataBase Management Systems (DBMS)  has evolved greatly since the 80’s making it easier to install and deploy database centric solutions. Now, it’s fair to say that the majority of companies, regardless of its size, have some sort of Database to facilitate business.

The number of database solutions not only increased in absolute numbers, but also the amount of information being stored skyrocketed. In other words, the size of databases is growing at a larger pace than ever, as well as the variety of information therein. And, in this scenario, companies are gathering and storing highly sensitive information:

• Inside information: companies are depending upon technology to improve its business by adopting systems to increase performance and handle internal information faster;
• From external parties: companies are now using information to have closer relations with clients, partners and suppliers. Therefore, a number of critical and external information is stored.

As a famous Uncle Ben once said: “With great power comes great responsibility”. Collecting, storing and processing sensitive and confidential information has become a major challenge in a highly connected world. Securing these data from threats is a highly demanding task, especially when these threats might come in all shapes and forms: Terrorism; Vandalism; Theft; Hackitivism…

With a growing amount of sensitive and confidential information, spanning from personal data to financial data, company daily memos to sensitive trade secrets – protecting these assets has become paramount. It is imperative to understand how each and every business object translates to database objects. Keeping track of sensitive and confidential information within the database is crucial to the development of secure solutions. This means that one has to know their data design in order to guarantee its protection – know your business.

Recognizing the need for a stronger approach in security, a number of laws have been passed to ensure companies would do their due diligence to safeguard these data. Not only that, certain industries also require high-level security to manipulate critical information. 

The most famous security requirements come from the following:

• SOX – Sarbanes-Oxley Act – compliance is mandatory to each and every company listed in the United States NY Stock Exchange. Its goal is to safeguard companies’ financial information to prevent tampering and manipulation;
• GDPR – General Data Protection Rule – Is the recent law passed within the EU to ensure that personal data goes through a process that mitigates or minimizes the risk exposure;
• PCI DSS – Payment Card Industry Data Security Standard – is not a law per se, but is demanded by the Payment Card industry for each and every company to manipulate credit card data.

God-like Creatures – DBA controls Database Management Systems

In response to these laws and standards, one of the most difficult tasks is to secure and protect Database from internal access, usually regarded as safe. The Database Administrator (DBA) is responsible for maintaining databases and its’ servers, for that they require high privileges and direct access to these servers. Ultimately they are supposed to be the most privileged users in these “realms”, controlling every major aspect of database systems’ behavior. 

DBA is a role that requires a lot of trust and confidence in the professional’s technical skills, as well as their character and ethics. Companies, however, should not operate solely on the basis of trust. They have to implement ways to mitigate these risks and put some control over the activities a DBA executes.

There are, basically, two ways to tackle this issue:

• • Use DBMS’ native auditing;
  • Use 3rd-party tools.

DBMS Native Auditing

As implied, this auditing functionality comes embedded with the DBMS and can be activated/deactivated from within the database server/instance. Furthermore, it is usually easier to implement and operate.

3 Elephants in a China Store

Looking at a practical standpoint, the use of native auditing poses three major problems:

1. High impact on performance: estimates suggest that turning auditing might cause up to 20% degradation;
2. Lack of Control of Auditing activities: auditing administration still resides within the database realm, where DBAs have full control and can manipulate and tamper with the generated audit data;
3. Integrating Different Data: Audit Data is generated in proprietary format, thus centralizing and consolidating data from different technologies might be cumbersome.

In short, the use of native auditing technology can be seen as a sort of inexpensive solution, since it does not require additional licensing. However, the hidden costs can be quite daunting, especially when they come as a surprise.

To put it simply, going with native auditing “costs” up to 20% of server performance, plus the amount of time needed to parse, consolidate and report upon all audit data gathered. Moreover, the “cherry on top” is the fact that DBAs, one of the main subjects of database auditing, can turn it on/off at their discretion.

3rd-Party Tools

Referred to as Database Firewalls or Database Activity Monitoring, these tools are vendor neutral and work well with all the major brands of commercial database engines. Understanding these solutions’ architecture it is easy to see how each of the previous 3 “elephants” can be tackled:

To each its own
These solutions are usually implemented as Appliances. This means that most of the auditing capabilities are executed outside the Database Server, thus preserving the server’s processing time to do what it’s supposed to.

Appliance-based solutions limit the performance degradation to around 5%.

Hands off my process

Best practices’ in implementing Database Security state one should not audit him/herself. Therefore, DBAs should have no control whatsoever over the auditing processes. The use of external tools allow Security and Audit personnel to ensure that data has not been manipulated or tampered with.

Eureka Moment

These solutions that are vendor neutral will work with the major commercial database engines. Centralizing audited data in the same repository allows the generation of integrated and consolidated reports, providing a full view of audit trails for the database entire environment.

The ability to report and gather information from consolidated data allows for better tracking of DBA’s, and other privileged users, activities. Furthermore, with the ability to generate alerts and full reporting capabilities make identifying deviations a bit simpler.

Also, it is worth mentioning that in a world of developing Security Environment, the adoption of the same tool for all the different brands of Database Software makes it easier to integrate with SIEMs and other Log Management solutions for broad spectrum analysis, correlating internal database events with external events elsewhere identifying overall trends and/or problems.

Cutting to the chase

When all is said and done, the design of security solutions might come in all shapes and forms. It can be cutting edge, expensive technology, but it can also be homegrown based on open-source technology. The architecture should be based on the security requirements, to implement the most adequate and efficient solution possible. Nevertheless, what matters is the possibility of answering Who did What, Where, When and How?

When designing the solution, one should consider, at least, a few variables:

• • Cost – the existing budget is one of the most important constraints;
  • Level of details – how much information should be collected?;
  • Duration – for how long should audit trails be kept?
  • Reasons to implement – why design and implement security? Is it mandatory due to legal obligation? Is it optional, as following standards and best practices?
  • Existing threats – what is the environment landscape? Is it a target for any reason? Do you process or store sensitive information? Remember: “It is not paranoia if you are really being chased!”;
  • Exposures – what kind of network connectivity exists? Are systems connected directly to the internet?
  • Impact on business – security and auditing measures creates sensible overhead to day-to-day activities, therefore it should be considered what is the “reasonable” degradation ratio resulting from these activities.

Looking at all these perspectives, when developing a solution for Database Security it is paramount to determine some of these answers before-hand. Security Solutions can pose quite a massive overhead if not set correctly, therefore understanding the needs and requirements is crucial to reduce possible problems.

Performance is key

Out of all the existing variables, one that is critical do Database Solutions is Performance. Databases are expected to respond accurately and in a timely manner, so any unnecessary processing can be quite burdensome. 

There are a few best-practices that can be followed to reduce the amount of overhead:

• Limit the amount of information monitored and audited to what is actually required;
• Maintain information so long as required to avoid hoarding of unnecessary data;
• Keep processing off of Database Servers:
  • Use external monitoring tools, if possible;
  • Use of native auditing tools, if required, DO NOT process data locally in the database server itself.

These are three rules that should be used as guidelines in the architecture and design phase. However, good judgement and understanding of the requirements is a must.

Keep it Safe and Fast.