Why You Need a Database Audit Trail

Your ability to answer very detailed questions about what’s going on in your organization’s databases can make or break a compliance audit or security investigation. Aside from the obvious need for this information in the event of a breach, it’s also important because government, financial, and health regulations and fines related to data scrutiny have intensified.
You need to be able to answer a variety of questions such as:
“Who exactly accessed or changed data within our systems?”
“When was that data access or when was it changed?”
“How did a specific user gain access to the data?”
“Was the change to the database table approved before the change was made?”
“Are the privileged users abusing their unlimited access?”
Answers to these kinds of questions are central to issues at hand during a typical compliance audit. You need to have systems that monitor and ensure that sufficient data logging and protection is in place. Database auditing gives you that capability.

(Also, check out our Gartner report, “How to Use the Data Security Governance Framework,” where you’ll learn how to use database auditing and other strategies to mitigate the risks caused by security threats, data residency and privacy issues.)

Database Auditing Defined

The general database auditing concept is about tracking the use of database records and authority. When you audit a database, each operation on the data can be monitored and logged to an audit trail, including information about which database object or data record was touched, what account performed the action and when the activity occurred.
However, not all audit logs have the same value to the auditors. Auditors need logs that present the information in a meaningful and contextual manner – from their perspective.  This type of log is only generated by stand-alone database monitoring solutions. The “native audit” logs that can be enabled within the database produce a very different type of audit log. The native audit logs are designed for database administrators who are looking for the information they need for debugging applications and tuning database performance.
Attempting to use native audit logs for compliance and security purposes poses a number of critical issues including:

• 10-20% overhead on the database server,
• Large audit archives that consume critical database storage, and
• Perhaps most important, necessary information not captured in a format that the auditors and security teams can use.

There are also differences between auditing only for compliance and auditing for both compliance and security. In a typical compliance scenario, a company would monitor a select set of data – for example access of national ID numbers and credit card information. They would also monitor “privileged users” who, because of their job requirements, have access to large amounts of sensitive data. The audit log for these data and users is stored, with a monthly or quarterly report generated. Monitoring systems with alerting capabilities can be configured with policies to detect and send out alerts when unauthorized behavior occurs, for example a request to retrieve more than 10 social security numbers. In this scenario, the scale of operations is limited and reporting typically happens long after the activity is completed.
Security auditing must inspect virtually all database activity for all users and the service accounts. The ability to capture critical details, generate real-time alerts and selectively block transactions are all basic requirements. The Security Ops team will need immediate access to activity logs with drill-down capabilities that maintain the contextual information necessary to trace the event to an entry point and individual account and IP address. In this scenario, the scale of operations is significantly larger, requiring automation of tasks and integration with other security systems. Database monitoring solutions built for compliance alone will be difficult to deploy and maintain at this scale and native audit is simply not a viable option (see Figure 1).

Figure 1: Performance overhead comparison on an Oracle database server between no auditing solution, native audit, and the Imperva database auditing and monitoring solution (DAM agent).

Why Obsess About It?

Consider Health Insurance Portability and Accountability Act (HIPAA) regulations. HIPAA requires that healthcare providers deliver audit trails about anyone and everyone who touches any data in their records. This is down to the row and record. The new European Union General Data Protection Regulation (GDPR) has similar requirements.
All kinds of industries – from finance and energy to food service and public works – have similar regulations. The Sarbanes-Oxley Act (SOX), for example, places a wide range of accounting regulations on public corporations. These organizations need to analyze data access and produce detailed reports on a regular basis.
It’s important to note that since audit trails help identify infiltrators, they promote deterrence among “insiders”. People who know their actions are scrutinized are less likely to access unauthorized databases or tamper with specific data. A comprehensive audit trail analysis can track activity to specific users (see Figure 2).

Figure 2: Examples of policy results in Imperva SecureSphere. Context on the user and action detail helps evaluate risk.
Audit trails also help with root cause analysis, intrusion detection and data integrity issues. An audit solution allows you to examine these on a case-by-case basis.
The new financial services industry regulation proposed to go into effect March 1, 2017 recognizes the importance of audit trails as one of the key requirements – even in small organizations.

Security Issues and the Insider Threat

A lot of this is about security threats. Every day, every year, every month, internal and external forces are actively compromising company data (accidentally and deliberately). Some of the most serious threats come from current employees with authorized access. Some want to settle a score while others are opportunistically looking to make extra money selling private information. An audit trail helps uncover this activity, when coupled with the new machine learning capabilities of Imperva CounterBreach even sophisticated data abuse can be detected, documented, and blocked (see Figure 3 and Figure 4).

Figure 3: Security teams can efficiently investigate the riskiest data access events by filtering open incidents by severity as well as by a specific user, server or client host.

Figure 4: Security teams can investigate incidents specific to the individual, then drill down to a behavior profile to view a baseline of typical user activity, comparing a given user with that user’s peer group.

Comprehensive Protection

Your first line of defense is to limit data access to only those individuals whose job function requires it. It’s no longer acceptable to allow unfettered data access to the vast majority of your employees, and you must monitor those with access for proper data access behavior.
The right data audit and protection solution needs to:

• Protect the entirety of an organization’s database and Big Data environment
• Automate security and compliance tasks to ensure uniform coverage, enforcement and reporting
• Analyze all database activity in real-time, which allows for a proactive security enforcement layer, as well as the crucial “who, what, when, where, and how” audit trail for every database transaction
• Be easy for auditors and Security Ops teams to use and for IT to deploy and maintain at scale

Learn more about Imperva data and audit protection strategies.