Auditing access to your sensitive data is now simpler and more precise

June 25, 2024 | 4 minute read
Angeline Dhanarani
Senior Principal Product Manager, Oracle Database Security
Text Size 100%:

Sensitive data are your crown jewels and hackers’ favorite target. Verizon’s 2023 Data Breach Investigations Report shows that personal data (PII) is the topmost target for attackers.

Sensitive data access auditing is a powerful monitoring mechanism providing visibility into access and changes to sensitive data. In addition to helping demonstrate regulatory compliance, auditing may serve as a primary deterrence to those who do not have a business reason to access or modify data. Historically, auditing sensitive data access has been complex and challenging; with the cost of collecting and storing the resulting audit volume often outweighing the benefits.

Oracle Database 23ai introduces a new column-level audit capability that makes auditing access to sensitive simpler, more precise, and more effective. This blog will help you get started on monitoring access to sensitive data using the new column-level audit capability to build more efficient audit policies.

A key strategy for monitoring access to sensitive data includes:

  • Knowing your sensitive data
  • Auditing access to your sensitive data
  • Monitoring the audit trail

Knowing your sensitive data

Before configuring audit policies for sensitive data access, you need to know what sensitive information is contained within the database, which database tables contain the sensitive data, and who can access the data. The first step is to identify and understand your sensitive data landscape.

Several sensitive data discovery tools are available to identify and categorise sensitive data, including Oracle Data Safe, Oracle Audit Vault and Database Firewall (AVDF), Oracle Database Security Assessment Tool (DBSAT), and Oracle Enterprise Manager. In the example below, sensitive data discovery in Data Safe has identified the following sensitive data landscape in the HCM1 schema within an HCM application database.

 

Sensitive data discovery in Data Safe

Figure 1: Sensitive data discovery in Data Safe

Sensitive data, including its location (schema, tables, and columns), along with the sensitive data type, is discovered in Data Safe and visually presented, as shown here.

Sensitive data landscape in Data Safe

Figure 2: Sensitive data landscape in Data Safe

Auditing access to your sensitive data

Armed with the knowledge of the location of sensitive data, you can now construct audit policies to monitor access and updates to sensitive data. Oracle Database 23ai introduces the capability to create unified audit policies to audit actions on individual columns in tables and views. The feature enables you to configure more precise and focused audit policies and ensures that auditing is selective enough to monitor access to sensitive data in specific columns.

For instance, here is an audit policy that audits UPDATE statements to the SALARY column of the HCM1.EMPLOYEES table (discovered as sensitive in Figure 2):

Copied to Clipboard
Error: Could not Copy
Copied to Clipboard
Error: Could not Copy
CREATE AUDIT POLICY update_sal_employees

ACTIONS UPDATE(SALARY) ON HCM1.EMPLOYEES;

Subsequently, any updates to the SALARY column of the HCM1.EMPLOYEES table will be captured as an audit record in the unified audit trail.

Monitoring the audit trail

Many data protection regulations recommend incorporating continuous monitoring for sensitive data access to spot abnormal or unusual activity. On commencing audit collection in Data Safe, reports like the one shown below provide near-real-time visibility into sensitive data access across your fleet of Oracle Databases.

 

Sensitive data activity report

Figure 3:  Sensitive data activity report in Data Safe

Historically, Fine-Grained Auditing (FGA) was used to track access to sensitive data in specific columns of tables or views in the Oracle Database. Starting with Oracle Database 23ai, you should use unified auditing with column-level auditing instead of FGA unless your audit requirement is one of the following use cases where FGA is still required:

  • Monitor the sensitive data access based on row values. For instance, you have a requirement to audit UPDATE statements to the SALARY column of the HCM1.EMPLOYEES table if and only if the SALARY > 5000.
  • You need to integrate with event handler functions within the Oracle Database to notify administrators or other users of specific events proactively. For instance, alert the security administrator when an audited column that should not be changed at midnight is updated.

Refer to the graphic below for a demo of configuring audit policies to monitor access to specific columns in Oracle Database 23ai and review the audited entries:

Animiated graphic showing creation of a column-specific unified audit policy

To learn more, see the following resources:

 

Angeline Dhanarani

Senior Principal Product Manager, Oracle Database Security

Angeline Dhanarani is the Senior Principal Product Manager in the Oracle Database Security team, responsible for core database audit and activity monitoring capabilities in Oracle Data Safe. With 20+ years of experience, Angeline is involved in many customer engagement activities for over a decade at Oracle, and is responsible for all Database Security features and products for regions -APAC and Japan. Angeline helps Oracle customers adopt comprehensive database security strategies and closely works with the engineering team to define the product roadmap for audit and activity monitoring.

Show more

Previous Post

Microsoft Power BI can now connect with the Oracle Database using Microsoft Entra ID SSO tokens

Alex Keh | 7 min read

Next Post


Discover unmonitored databases with Oracle Audit Vault and Database Firewall (AVDF) 20.12

Nazia Zaidi | 3 min read
Oracle Chatbot
Disconnected