Overview of Oracle Audit Vault and Database Firewall

1 Overview of Oracle Audit Vault and Database Firewall

Monitoring database activity to support incident investigation, detect potentially malicious behavior, and fulfill regulatory requirements is essential. Enabling either database auditing or monitoring network events can help you to get this visibility.

Database Activity Monitoring (DAM) is a security technology for monitoring and analyzing database activity. DAM solutions are used to identify and report on fraudulent, illegal, or other undesirable behavior and typically used to address security and compliance needs.

Oracle Audit Vault and Database Firewall (Oracle AVDF) supports native database audit data collection and network-based SQL monitoring to deliver a comprehensive Database Activity Monitoring solution.

Activity monitoring is essential, but organizations are also worried about the security posture of their databases. Were best practices followed when configuring the databases? Are databases in compliance with security standards? What else should be considered to strengthen the Oracle Database further? Database security posture management (DSPM) helps answer those questions, combining the ability to assess database configuration and security settings with sensitive data discovery to provide an integrated picture of a database’s risk and security posture.

Oracle AVDF 20.9 and later expands the product’s capabilities from database activity monitoring (DAM) to database security posture management (DSPM).

Oracle AVDF expands beyond database activity monitoring to manage your Oracle Database’s security posture. AVDF’s best-in-class activity monitoring capabilities are enhanced with visibility into security configuration, user entitlements, stored procedures, and how much and what types of data are in the database.

Use Cases

There are two key use cases for Database Activity Monitoring, namely, compliance and corporate security guidelines.

Corporate security guidelines: While corporate security guidelines vary, they often require setting baseline database security configuration and detecting deviation, discovering sensitive objects and privileged users, auditing privileged user activity, logon, and logoff events, sensitive data access, monitoring database traffic, preventing SQL injection attempts, and many other common security-relevant activities. These guidelines typically require both database auditing and network-based SQL traffic monitoring capabilities
Accelerate regulatory compliance: Organizations need to address the requirements of regulations such as GDPR, PCI, GLBA, HIPAA, IRS 1075, SOX, and UK DPA. These regulations require complete visibility of activities on sensitive objects, privileged users, value change auditing, data structure changes, etc. Database auditing and network-based SQL traffic must be monitored as part of the regulatory requirements to give this level of visibility for the forensic analysis of security events.

1.1 Database Auditing and Network Based SQL Traffic Monitoring: Why Both Are Needed

Database Auditing

Database auditing involves creating and enabling database policies to track the actions taken on database objects or users. When auditing is enabled, database activities on specified objects and users produce an audit trail of these operations. Each action generates an audit record that includes what database operation was performed, who performed the operation, the database objects involved, time of execution, and the SQL statement itself. Database auditing not only captures local activity but also any database activity that does not cross the network as SQL, such as logging local or remote console connection, to make database and user changes.

Network Based SQL Traffic Monitoring

SQL injection is perhaps the most common method used to attack databases by exploiting application vulnerabilities. SQL injection exploits flaws in application code—the application that sends SQL statements to a database. Given that much of that application code is written without analyzing possible SQL injection issues, many applications are exposed to vulnerabilities.

Database Firewall can be used to monitor and analyze the SQL traffic to the database, whether coming from an application server or a user connecting to the database directly. By monitoring and analyzing the SQL statements, the database firewall can intercept SQL statements generated as a result of a SQL injection attack, block or substitute them with other SQL statements, thereby thwarting SQL injection attack. As SQL statements are evaluated for policy compliance and the actions are taken over the network it does not consume resources on the database server.

In many instances, corporate or regulatory policies may require that trusted path access to corporate applications should be enforced. This could involve only allowing application access to the database from certain IP addresses or users. Database Firewall policies can be used to monitor, alert, block, and substitute SQL statements based on user session information, such as IP address or database user name. You can also use the Database Firewall to train it to understand normal or approved SQL, and block anything else that is different.

Why Both

Oracle recommends a holistic approach to Database Activity Monitoring, requiring both database auditing and SQL traffic monitoring. Auditing typically captures detailed information after a certain event has occurred, while monitoring SQL traffic helps you monitor the SQL statement before it reaches the database, making it possible to block suspicious statements. Both of them give different views into the same event, one after, and one before. You can start with either capability and expand their architecture to include both.

1.2 Oracle Audit Vault and Database Firewall Components

Oracle Audit Vault and Database Firewall (Oracle AVDF) has three main components: Audit Vault Server, Audit Vault Agents, and Database Firewall.

Audit Vault Server

The Audit Vault Server is a mandatory component of AVDF. Every AVDF installation has at least one Audit Vault Server. This server has the following components:

A hardened Oracle Linux operating system
An Oracle Database, which serves as the audit repository. The audit repository database is encrypted using Oracle Transparent Data Encryption and protected with Oracle DatabaseVault.
The AVDF application, which provides the interface for the AVDF console and the Audit Vault Command Line Interface (AVCLI).

The Audit Vault Server is the central repository of audit records and events captured by the Database Firewall. The Audit Vault Server performs four primary functions:

For Oracle databases, it captures both before and after values, as well as changes to user entitlements and stored procedures. Similarly, for Microsoft SQL Server (Oracle AVDF 20.9 and later) and MySQL (Oracle AVDF 20.11 and later), it captures before and after values, along with stored procedures. The support for pre-seeded audit policies further facilitates the implementation of auditing best practices.
Default predefined reports with customization capabilities: Audit Vault Server provides dozens of default reports including changes to database configuration, security, and user entitlements. It also provides reports on login and logout, sensitive data access and modification, stored procedure changes, and many more. Report data can be easily filtered and searched for investigations. Using predefined compliance reports for GDPR, PCI, GLBA, HIPAA, IRS 1075, SOX, and UK DPA, you can easily provide needed reports to auditors. Third-party reporting tools can connect to the Audit Vault Server schema for further analysis.
Configuring alerts and notifying when certain events occur: Audit Vault Server raises alerts on user-specified events such as multiple failed login attempts, sensitive table access by unauthorized users, and data export operations. Custom alerts can be configured in Oracle AVDF.
Oracle AVDF supports information life cycle management (ILM) policies to help organizations meet compliance requirements. Per target policies can be created specifying the online and offline retention periods, and based on that, activity data is automatically moved from the Audit Vault Server to the archive. If necessary, data in the archive location can be restored to the Audit Vault Server, and this data then becomes visible in the reports.

Audit Vault Server supports a high-availability architecture to ensure that audit record collection does not stop. A secondary audit vault server can be configured so that in the event of a failure of the primary, the secondary becomes the primary without any manual intervention.

Audit Vault Agent

Audit Vault Agent retrieves audit data from audit trails (sources of audit data) for various types of targets and sends the audit data to the Audit Vault Server. For directory-based trails, the Audit Vault Agent is deployed on the same machine as the trail, and for database table based trails it can be deployed on a remote machine. A single Audit Vault Agent can collect from multiple targets and trails.

Audit trails include database audit trails, OS trails, and directory trails. Database audit trails include Oracle Database, Oracle Autonomous Database, Microsoft SQL Server, SAP Sybase, IBM Db2 for LUW, MySQL, MongoDB and PostgreSQL. The audit data can come from audit tables or files. Oracle AVDF can also capture before and after values from REDO records of Oracle databases, Microsoft SQL Server (Oracle AVDF 20.9 and later), and MySQL (Oracle AVDF 20.11 and later). OS audit trails include Oracle Linux, Red Hat Linux, Oracle Solaris, Microsoft Windows, and IBM AIX. You may use the QuickCSV collector (AVDF 20.11 and later) to collect audit data from MariaDB, EnterpriseDB (Postgres), and other systems that create audit data in CSV.

Note:

Starting in Oracle AVDF 20.9, you can use agentless collection instead of the Audit Vault Agent for up to 20 Oracle Database table audit trails. Starting in Oracle AVDF 20.10, you can also use agentless collection for Microsoft SQL Server directory audit trails for .sqlaudit and .xel (extended events). The total number of audit trails for agentless collection should not exceed 20. See Adding Audit Trails with Agentless Collection.

Database Firewall

Database Firewall inspects SQL traffic going into the database and determines with high precision whether to allow, log, alert, substitute, or block the SQL. Database Firewall events are stored in the Audit Vault Server and consolidated with the audit data giving you a unified view into all activities. The Database Firewall is covered in detail in the next chapter.

Figure 1-1 Oracle AVDF Architecture

Description of "Figure 1-1 Oracle AVDF Architecture"

1.3 Database Security Posture Management

Database security assessments are essential because they help identify security risks that can compromise the confidentiality, integrity, and availability of data. However, conducting thorough and periodic evaluations is frequently challenging, especially when you’re not just managing 10–20 databases but are responsible for hundreds or thousands of them. Complex database systems can make it difficult to identify potential vulnerabilities and threats consistently. Another challenge is the availability of skilled personnel to perform and evaluate comprehensive security assessments.

AVDF - Database security posture management (DSPM) provides a fleet-wide simplified and centralized view of security configuration assessments for Oracle Database, along with security findings and associated risks. Summarized risk findings help prioritize and guide immediate action on potential risks associated with the Oracle Database fleet. AVDF also assists you in discovering sensitive data and privileged users in the Oracle Database.

1.4 Enterprise Deployment

Delivered as a pre-configured software appliance, Oracle AVDF can be installed on an x86 hardware of choice giving you the scale you need. Periodic release updates for Oracle AVDF include updates to the embedded operating system, Oracle database, and the Oracle AVDF application itself simplifying its maintenance. Further, Audit Vault Server automatically updates the agents used for collecting audit data and eliminates administrator involvement. You can use the rich command-line interface to automate administrative operations.

Audit Vault Server can consolidate audit data and firewall events from hundreds or thousands of databases and operating systems. It can be deployed in active-standby mode, ensuring availability. You can configure the data archival policies to automatically archive historic data to low-cost storage and retrieve it as needed.

Beyond hardened configuration, Oracle AVDF encrypts the collected data using Transparent Data Encryption, encrypts the network traffic, uses Database Vault to restrict access to data, and provides separation of duties between the administrator and the auditor.

1.5 Hybrid Cloud Support

Organizations increasingly face the situation where some of their databases are deployed on-premises while others are deployed in the cloud. The challenge is to audit and monitor them all, ideally with a single console. Utilizing a solution deployed on-premises for both on-premises and cloud database targets has many advantages including consistent policies, unified reporting, and common alert management. Existing alert configurations and data retention polices can be applied for cloud databases. For you the main benefit here is that the cloud vendor cannot modify the audit data, and thus you have an independent view of the events on your cloud databases. Thus, you get full control, and have complete view over your audit data using one single unified dashboard.

1.6 Provisioning Audit Policies for Oracle Databases

Databases contain sensitive data – data whose access should be controlled and monitored. Examples of sensitive data might include financial reports, credit card numbers, email addresses, and data that describes an employee or customer. Sensitive data access auditing presents a powerful monitoring mechanism providing visibility into access and changes of sensitive data within the organization, and serves as a primary deterrence to those who do not have a business reason to access or modify them.

Users, some of whom may be privileged, access databases – for example, database administrators (DBAs) are frequently considered privileged users because of their broad access within the database. Privileged user accounts are often a soft target for hackers attempting to gain access to critical systems and data. Continuous privileged user activity auditing allows security teams to easily identify any anomalous behavior and quickly detect leaks of sensitive data.

Databases users are granted privileges to perform operations within the database, and some of those privileges may be considered powerful like system privileges whose usage should be constantly monitored. Few other noteworthy actions in the database includes multiple failed login attempts, schema changes, and so on. Such actions within the database that warrant greater scrutiny and constant monitoring because it can potentially be abused are categorized into security-relevant events. A surveillance mechanism of such susceptible actions in the database constitutes security-relevant events auditing, and helps detect anomalous activities in the database very efficiently.

Focusing audit configuration on sensitive data access, privileged user activity and security-relevant events helps build better audit policies - polices that are focused on the activity that matters, selective enough to reduce the creation of unnecessary audit records, and effective enough to let you meet your audit goals.

While Oracle AVDF provides support for both unified audit and traditional, we will focus on unified auditing, as Oracle recommends that you use unified auditing going forward. For provisioning unified audit policies, Oracle AVDF provides the following three categories:

Core Audit policies: These are policies recommended by Oracle AVDF pertaining to capturing critical database activity such as creating users, creating roles, and altering profile, database schema changes, logon events for specified users, all admin activity, and user activity for a list of specified users. With a single click, you could enable auditing for privileged users from Oracle AVDF. Oracle AVDF creates the selected policy in the target and enables it.
Oracle predefined policies: Oracle Database provides several pre-created unified audit policies that cover common security relevant audit settings, such as logon failures, database parameter changes, modifications to user accounts and privileges, and other activities. These pre-created policies can be enabled from Oracle AVDF in addition to the core policies.
Custom Policies: You can also develop custom unified policies in the target database that are specific to your schema and auditing needs. For example, some users may create custom audit policies that monitor select activity on specific sensitive tables by privileged users. These custom developed policies can be enabled or disabled on target databases from Oracle AVDF.

1.7 Monitoring Oracle Database Entitlements

Tracking changes in entitlements is important for many reasons, such as identifying potentially malicious activities and taking corrective action before they occur, or mistakes made by the DBA in granting certain roles to users which should not have been done. In other cases, tracking entitlement changes is useful for forensics to understand why certain users got access to tables they should not have been given.

For Oracle Databases, Oracle AVDF provides the ability to retrieve entitlement settings on a scheduled basis and compare them to understand changes. The entitlement data contains information pertaining to the creation and changes to users, roles, privileges, profiles, and other objects. Using the entitlement report, you can look at all the entitlement changes of a user during a specific time period, for example to understand how they were able to view data they were not authorized to do so.

1.8 Monitoring Oracle Stored Procedures

Stored procedure contain some of the important business or data access and modification logic. It is therefore very important to understand if any of these procedures have been modified or deleted.

Using Oracle AVDF, you can periodically check the Target to understand stored procedure creation, deletion and modifications. Oracle AVDF provides the ability to track stored procedure changes and details pertaining to when it happened and by whom.

1.9 Summary

Oracle Audit Vault and Database Firewall helps organizations increase security by proactively assessing the security posture of databases, monitoring database activity on the network and inside the database, protecting against SQL injection threats, consolidating audit data into a secure and scalable repository, and automating reporting to support audit and compliance activities.

AVDF was already a best-in-class provider for database auditing and activity monitoring platform. Now with comprehensive security-posture management for your enterprise, the discovery of sensitive data, and privileged user capabilities, AVDF becomes a one-stop solution for assessing, discovering, monitoring, and protecting the most critical asset of an organization—its data. Oracle AVDF includes an enterprise quality audit data warehouse, host-based audit data collection agents, powerful reporting and analysis tools, alert framework, audit dashboard, and a multistage Database Firewall. Users can leverage the pre-seeded policies to quickly enable database auditing with a single click.

The next chapter will discuss the Database Firewall and how you can use it to monitor and block SQL traffic before it is executed in the database.

1.10 Support Policy When Additional or Third Party Software is Installed on Oracle AVDF

Oracle Audit Vault and Database Firewall (Oracle AVDF) is shipped as an appliance, and no third-party software should be installed on the Audit Vault Server. Oracle does not test or certify any additional or third party software on Oracle AVDF. If third party software is installed, and results in problems with the Audit Vault Server and/or Database Firewall, then Oracle may not be able to help you recover the system. In cases where we believe the third party software has contributed to an issue, we may ask you to reproduce the issue on an Oracle AVDF system that does not include the third-party software.

During patching or upgrade of Oracle AVDF, you may find that the presence of third party software contributes to difficulties in completing the operation. You may also find that the process of patching/upgrading Oracle AVDF causes third party software to malfunction or cease to work altogether. Oracle AVDF upgrades also update the underlying operating system and may remove any custom libraries added by third party software.

Audit data is particularly sensitive, and loss of an audit data may result in inability to support compliance reporting and forensic investigations. In the event that you choose to install third party software on Oracle AVDF, then Oracle recommends you take additional appropriate precautions such as more frequent backups that may reduce the damage in the event the third-party software causes system instability or corruption.