Auditing is the main tool in the "trust but verify" approach to security, as well as a tool for forensic analysis, that is, finding who performed certain actions and when they performed these actions.
Maintaining an audit trail of activity is an essential component of any defense-in-depth strategy for securing a system. Even when access controls are properly configured and privilege grants are minimized, two important risks still remain. The first is that users who need significant privileges to perform their jobs may misuse those privileges. The second is that a user may gain unexpected access through access controls or privilege grants that are unintentionally configured to be more generous than necessary. Auditing is the primary tool for detecting the actions that these users perform so that they can be corrected.
Effective auditing requires audit policies that are selective in capturing the important details about significant events while minimizing the noise from routine activity. Some of the most important events to audit in databases are failed logins, events requiring access by privileged users, and data definition (DDL) types of activities such as
TRUNCATE. Besides databases, other systems such as operating systems, file systems, and directory services, also have audit data that can be collected. Auditing provides a history of who did what and when, and enables organizations to meet stringent controls and reporting requirements.
In addition, many customers must audit systems to comply with SOX, HIPAA, PCI DSS, GLB, FISMA, and other international standards. Internal governance, local security policies, and forensic reporting also drive the need to audit.
Auditing requires secure storage and controlled access for the audit data so that it cannot be manipulated to hide suspicious activities. Auditing also requires convenient ways to search through the collected audit data to find specific information or detect unusual activity.
You may be using Oracle Database's robust auditing features as well as auditing features of other database products. Regardless of whether you are using Oracle Database, auditing and auditing features of other database products are important to make sure that your systems are provisioned with sufficient storage capacity to sustain the amount of audit data collected. Oracle Database's native auditing has low overhead and does not degrade performance when done correctly. When using other database products, refer to their documentation libraries as necessary.
With effective monitoring of SQL input to the database, you can block or raise alerts for attempted policy violations and provide comprehensive reports about database activity for compliance purposes.
Most applications today operate using a single user account for communicating with the database, and many do not validate their input sufficiently. This application architecture, combined with the increasing number of attacks on databases via SQL injection or insiders with access to privileged accounts, has made database activity monitoring an important component of the overall security architecture.
SQL injection is perhaps the most common attack approach to databases. 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.
Whereas auditing captures events that already happened at the database, the Database Firewall monitors, and optionally blocks, malicious SQL before it reaches the database. Database Firewall not only monitors the connection to the database, but it monitors any connection to the database whether coming from an application server or a user connecting to the database directly. This monitoring reduces both insider threats, as well as the ability of an outsider to launch a successful SQL injection attack.
Database Firewall policies can be used to monitor, alert, block, and/or substitute SQL based on user session information, such as IP address or user name, or based on the SQL grammar itself. In this way, you can use a firewall to both allow approved SQL and disallow specific SQL statements.
Auditing and monitoring provides security against data breaches.
In today's global enterprise environments, security must be considered as important as high availability and scalability. Studies indicate that the most prevalent data breaches involve access by privileged users and SQL injection attacks. A DBA, or someone using a DBA user account privileged access rights, can walk out of the office with enormous amounts of sensitive data. Similarly, a remote intruder can gain access to sensitive data, and exploit a SQL injection vulnerability.
The recommended approach to securing data against breaches due to access rights is to "trust but verify." You can trust your privileged users, but you need tools to verify that neither they, nor others who have gained access to their privileges, have accessed data, or violated your security policies. Similarly, applications that access your databases are often vulnerable to SQL injection attacks if they are not programmed with the correct security considerations.
The Oracle solution to these problems is Oracle Audit Vault and Database Firewall. Oracle Audit Vault and Database Firewall can collect audit data from many different types of systems that produce audit trails. It also can monitor network activity to databases, analyze all SQL statements, and take appropriate action before this SQL reaches your database. This capability is called monitoring and blocking mode.
Oracle Audit Vault and Database Firewall provides support for Oracle Database, third-party databases, and operating systems. It provides the ability to capture and analyze audit data from Oracle Database, other databases, and operating system logs.
Oracle Audit Vault and Database Firewall provides a comprehensive way to deal with a large amount of audit data, the risk from SQL injection, application bypass attacks over the network, and problems of unauthorized access.
Deploying Oracle Database or third-party databases can produce a large amount of audit data to consolidate. In addition to audit data from databases, operating systems, file systems and other such systems produce audit trails that can be used to analyze events relevant to security.
Standard security practices require that you transmit and manage audit data on a remote centralized location, where it is secure from tampering by the individuals whose activities you want to audit.
With large amount of audit data, it is important to have a mechanism to efficiently monitor the ongoing stream of data, to find the specific events with security implications, and to identify problems that need immediate attention.
In addition to managing a stream of audit data from heterogeneous systems, it is important to protect against SQL injection attacks, and to monitor traffic going into the database.
A Comprehensive Solution
Oracle Audit Vault and Database Firewall:
Oracle Audit Vault and Database Firewall solves these problems by collecting and consolidating audit data, monitoring network traffic, blocking and substituting of SQL, logging, policy management, raising alerts, and providing comprehensive reports for forensic and compliance purposes.
Oracle Audit Vault and Database Firewall has three components:
Figure 1-1 Audit Vault and Database Firewall Architecture
You can choose to deploy Audit Vault Server with either the Audit Vault Agent component, or with the database firewall component, or with both components. You can use Oracle Audit Vault and Database Firewall to protect both Oracle Database, and third-party databases, and to protect both databases and non-databases such as operating systems, file systems, and directory services.
Using Oracle Audit Vault Server and Audit Vault Agents, you can consolidate audit data from multiple sources, manage Oracle Database audit policies, and monitor user entitlements.
Consolidate audit data from multiple sources:
Database audit trails including Oracle Database, Microsoft SQL Server, SAP Sybase, IBM DB2 for LUW, and MySQL. These audit trails can be audit tables, audit files, or Oracle Database REDO records.
Stored procedure auditing (SPA), which enables you to audit changes to stored procedures on monitored databases
User role auditing (URA), which enables you to audit and approve changes to user roles in the databases on a specified database server
Operating system audit trails (Linux, IBM AIX, Oracle Solaris, Microsoft Windows)
Directory services, such as Microsoft Active Directory
File systems such as Oracle ACFS
Custom audit data in either database tables or XML files
Manage Oracle Database audit policies
Monitor Oracle Database user entitlements or activities
Oracle Database Firewall specifically protects databases from SQL attacks over the network, and monitors database activity on the network with alerts and warnings.
Using the combination of Oracle Audit Vault Server and Oracle Database Firewall, you can monitor SQL transactions to your databases. You can then decide whether a SQL statement should be permitted, blocked, or substituted before it reaches the database server.
Oracle Database Firewall sends database activity events to Oracle Audit Vault Server, which then provides specialized database firewall reports. Oracle Audit Vault Server consolidates both database firewall event logs, as well as audit events from other sources where you may have also deployed Audit Vault Agents to collect audit data.
Oracle Audit Vault and Database Firewall is the key component of the Oracle security architecture.
Oracle's security architecture provides both preventative and detective pillars of protection against threats. Oracle Audit Vault and Database Firewall is the key component of the detection pillar.
The following products form the prevention pillar:
Oracle Advanced Security - This feature includes:
Transparent Data Encryption (TDE) - Automatically encrypts data before it is written on disk, and decrypts it when reading from the disk.
Oracle Data Redaction - Controls the display of sensitive data within applications.
Oracle Key Vault - Securely manages database encryption keys.
Oracle Database Vault - Controls access by privileged users.
Oracle Data Masking and Subsetting - Masks sensitive data before exporting it from the database.
Oracle Label Security - Simplifies the process of assigning labels to data and users and enforcing access control based on those labels
Use this Oracle Audit Vault and Database Firewall terminology when describing the system and its functions.
The following terms describe the Oracle Audit Vault and Database Firewall system and its functions:
Secured Targets: the systems that you want to monitor and protect
A secured target is any supported database or non-database system that you monitor with Oracle Audit Vault and Database Firewall. A secured target can be an Oracle Database, or a third party product. Secured targets can be monitored by the Oracle Audit Vault and Database Firewall Audit Vault Agent component, the database Firewall component (if the secured target is a database), or both components. All secured targets are registered in Audit Vault Server.
Oracle Audit Vault and Database Firewall supports various secured target types out-of-the-box. These include various databases, operating systems, file systems, and directory services. To capture audit trails from more secured target types, you can also create custom collection plug-ins for Oracle Audit Vault and Database Firewall by using the Oracle Audit Vault and Database Firewall software development kit (SDK).
Audit Trails: how you specify the location of the audit data to collect.
An audit trail specifies the location and type of repository where the audit data is collected. To collect audit data from a secured target, you add one or more audit trails in Oracle Audit Vault and Database Firewall for each secured target from which you want to collect the data. Defining the audit trail in Oracle Audit Vault and Database Firewall specifies the type of audit trail you are collecting, and the location of the audit data on the secured target. For example, a database can have multiple audit trails, with a different audit trail for each location where audit data is written. You can specify audit trails for a table or a transaction log. Other systems have specific locations where audit data is written. For example, in a Linux operating system, the audit trail is located in the
Collection Plug-ins: Agent components that collect audit data from specific secured target types.
The Audit Vault Agent component contains a set of collection plug-ins. There is one collection plug-in for each type of secured target that is supported out of the box. For example, there is a plug-in for Oracle Database, another plug-in for the Linux operating system, and so on. Each plug-in collects data from a specific type of audit trail, and maps the specific events from that audit trail to the audit record format in Oracle Audit Vault and Database Firewall.
You can also develop custom collection plug-ins to collect audit data from other audit trails that are not supported out of the box.
Hosts: the systems where you install the Audit Vault Agent component to collect audit data
If you want to collect audit data from a secured target, then you deploy Audit Vault Agent on a host computer (usually the same computer where the secured target is located). Before you deploy the agent on this host, you specify how to connect to it by registering the host in Audit Vault Server.
Enforcement Points: How you set up a Database Firewall to protect a database
If you are deploying one or more instances of the database firewall component to protect databases, then you configure one database firewall monitoring point (or enforcement point) for each database. Configuring an enforcement point in Oracle Audit Vault and Database Firewall lets you select the specific instance of a database firewall used for monitoring, identify the database being monitored, and identify the network traffic sources to that database. In the enforcement point configuration, you also specify whether you want the database firewall only to monitor and raise alerts on the SQL traffic to the database, or also to block SQL traffic that is out of policy.
This section contains:
The components of Oracle Audit Vault and Database Firewall are Oracle Audit Vault Server, Audit Vault Agent, and Database Firewall.
Oracle Audit Vault Server is required and at least one of the other two components. You have the flexibility to deploy Oracle Audit Vault Server with either the Audit Vault Agent component, with the database firewall component, or with both. The Audit Vault Agent component enables you to consolidate and manage audit data from heterogeneous sources. The database firewall component secures your databases from SQL attacks over the network. Depending on your needs, you can decide which of the components to deploy.
Oracle Audit Vault Server stores audit data from various types of sources (secured targets), and the event data from the firewall of Oracle Audit Vault and Database Firewall.
Event data refers to the data gathered when an Oracle Audit Vault and Database Firewall policy is applied on an incoming SQL statement. Specifically, an incoming SQL statement and session data are compared to those defined in the policy. An action is then performed, such as logging, blocking, or substituting data. Oracle Audit Vault Server enables you to manage Oracle Database audit policies, and manages firewall policies of Oracle Audit Vault and Database Firewall to protect databases. Oracle Audit Vault Server is a dedicated server that also contains the tools necessary to configure Audit Vault Agent and the firewall of Oracle Audit Vault and Database Firewall.
Oracle Audit Vault Server has a central repository of audit and event data (from both Audit Vault Agents and firewalls). This repository is contained in an embedded Oracle Database, which includes features such as compression, partitioning, encryption, and privileged user controls.
The Oracle Audit Vault Server Web interface provides administrators with the tools to perform the following tasks:
Some highlights of the Oracle Audit Vault Server Web console are illustrated in the following figures.
Figure 1-2 Audit Vault Server Dashboard
Figure 1-3 Audit Vault Server - Secured Targets
Figure 1-4 Audit Vault Server - Database Firewalls
The Information Lifecycle Management (ILM) component of the Oracle Audit Vault and Database Firewall handles audit data retention management.
The discovery task involves identifying hosts, deploying, and adding them as secured targets. Discovery manages audit data collected from all the secured targets.
Compliance Management involves evaluating compliance of targets and systems for security and storage. It performs many other tasks that maintain stability of the system.
Compliance Management enforces retention policy and expired event data. Retention policy management involves all of the tablespaces that are managed by the appliance. A new tablespace is created when a record from a target with the policy arrives into Oracle Audit Vault Server.
The audit data collected from secured targets is moved into new tablespaces based on the retention policy defined for a specific secured target. The new tablespace name is based on the retention policy. After the online retention period expires, the data is offline. The data remains in the system, and you can archive it. The data is offline, and kept local in the system until you manually archive it, either to a network file storage (NFS) or to NFS or a secure copy (SCP) location. Before triggering an archive job, you must define one or more archive locations.
You can schedule an archive job, and view the status. The tablespaces that contain audit data are automatically deleted after their retention period expires. The retention period is determined from the retention policy for a specific secured target. There is no manual intervention required.
After the tablespaces are moved to an archived location, you must not move them, or delete them manually. Any manual intervention hampers the back-end metadata, and leaves it in an inconsistent state. An inconsistent state can result in an unstable Oracle Audit Vault Server. If you want to run reports, or use tables for any other activity in the database, you can restore the tablespaces.
The appliance (Oracle Audit Vault and Database Firewall) manages expired event data. management involves all the tasks from creating, archiving, and deleting the tablespaces, based on the retention policy defined. However, you must manually archive the data.
The ILM component has a built in health check package. To check the current status of the component, execute the following command:
SQL> exec avsys.ilmcheck.run('check_all')
A log file with a name
ilmcheck.log is generated under the file path
To check more options with this health check component, run the following command:
SQL> set serveroutput on; exec avsys.ilmcheck.run('help');
Audit Vault Agent retrieves audit trails from various types of secured targets and sends the audit data to Oracle Audit Vault Server.
Secured targets can be either an Oracle Database, or other databases, operating systems, file systems, directory services, or custom audit data in either database tables or XML files.
Audit Vault Agent is deployed on a host. Usually the host is the same host running the audit data source (secured target), such as a database, or an operating system. However, you can also deploy the agent on a remote host. Hosts are registered in the Oracle Audit Vault Server. Each audit data source has an associated secured target, and one or more audit trails defined in Oracle Audit Vault Server for the secured target.
The Oracle Database Firewall component of Oracle Audit Vault and Database Firewall monitors databases, access activity events, and acts as a first line of defense on the network.
You can deploy Oracle Database Firewall using two different methods:
Oracle Database Firewall monitors databases, and provides a complete event repository of significant database access activity events, as defined by an Oracle Audit Vault and Database Firewall policy. Oracle Database Firewall also acts as a first line of defense on the network by enforcing expected database access behavior, thereby helping to prevent SQL injection, application bypass, and other malicious activity from reaching the database.
Oracle Database Firewall uses a highly accurate SQL grammar-based engine to monitor all SQL traffic, and to block unauthorized SQL traffic. By parsing the SQL, Oracle Audit Vault and Database Firewall can recognize the multiple number of ways to express the different equivalent SQL statements, so that you can properly decide whether to allow these statements. In contrast, naive filtering that is based on regular expressions usually recognizes only a subset of equivalent statements.
Unlike solutions that leverage regular expressions, Oracle Database Firewall parses the SQL itself to achieve the level of accuracy required for enterprise database monitoring. Oracle Database Firewall collects SQL requests from the network. SQL statements are then associated with as much session information as possible (for example, database user name, client program name, or client IP address). This information is then combined with further analysis of SQL statements, including SQL category, such as
SELECT statements, Oracle Definition Language (DDL) and Data Manipulation Language (DML) writes, Tool Command Language (TCL), and so on.
Oracle Database Firewall analyzes the SQL statements in accordance with the firewall policy. Oracle Database Firewall groups SQL statements into clusters, which are SQL statements with the same grammatical structure. This enables the distillation of hundreds of millions of SQL statements down to just a few hundred. Oracle Audit Vault and Database Firewall lets you define firewall policies that include both allowed SQL (a white list), and disallowed SQL (a black list). In this way, Oracle Database Firewall distinguishes normal transactions from abnormal transactions.
To ensure flexibility in the choice of the network point at which the traffic is monitored, Oracle Database Firewall also supports a monitor-only agent that is local to the database server. Host Monitor, which is part of the Audit Vault Agent, captures SQL traffic reaching the database server, and securely forwards it to Oracle Database Firewall. You can use Host Monitor to remotely monitor database servers running on Linux, Oracle Solaris, and Microsoft Windows platforms. To use Oracle Database Firewall Host Monitor, deploy the Audit Vault Agent. Note that Host Monitor does not perform the blocking.
Oracle Audit Vault and Database Firewall components work together to protect a secured target, and collect the appropriate audit trail from that secured target.
The Oracle Audit Vault and Database Firewall architecture provides a high-level overview of how the Oracle Audit Vault and Database Firewall components work together. Though this diagram shows both a database firewall and Audit Vault Agents, you can deploy Oracle Audit Vault Server with both components, or only the Audit Vault Agent component, or only the database firewall component.
Oracle Audit Vault and Database Firewall components work together in this way:
The Oracle Audit Vault and Database Firewall network topology differs depending on the size of your deployment, your high availability configuration, and optional integration with other systems.
The following illustration is a simplified illustration of Audit Vault Server with both database firewall and Audit Vault Agent components deployed. There are several ways to deploy the database firewall component on the network.
Figure 1-5 Illustration of Oracle Audit Vault and Database Firewall on the Network (Simplified)
In this illustration, to obtain high availability, two Audit Vault Servers and two database firewalls are deployed. You can pair database firewalls, pair Audit Vault Servers, or pair both database firewalls and Audit Vault Servers.
Oracle Audit Vault and Database Firewall offers multiple roles as part of the separation of duties.
The following table shows the user accounts in Oracle Audit Vault and Database Firewall.
Table 1-1 Oracle Audit Vault and Database Firewall User Accounts
Super administrators configure and maintain the Oracle Audit Vault and Database Firewall system, including Audit Vault Server settings such as network settings, high availability, data retention policies, etc. The super administrator can create other administrators or super administrators, and has access to all secured targets. The super administrator can also grant access to specific secured targets to other administrators.
The administrator can perform a subset of the system configuration tasks that a super administrator can, such as registering hosts and secured targets, running archive jobs, etc. Administrators can also manage secured targets for which they have been granted access by a super administrator.
An administrator cannot create another administrator. This can be performed by a super administrator only.
Database Firewall Administrator
The Database Firewall Administrator user can access the administrative interface on the Database Firewall Appliance. This user can configure the Database Firewall component's system and network settings, traffic sources, and view diagnostics information.
The Super Auditor user can create firewall policies, provision audit policies for Oracle Database secured targets, and specify settings for secured targets. For example, the Super Auditor user can create a policy that determines whether to enable stored procedure auditing. Super Auditor users also generate reports, and create alerts and notifications. Super Auditor users can access all secured targets, create auditor or super auditor users, and grant access to specific secured targets to those users.
Auditor users can perform all the functions of Super Auditor users, but only for the secured targets to which they have access.
Operating system Super User (root) account. Only use this account as instructed in the documentation, or under the guidance of Oracle Support. This account is typically used for upgrades and patching.
The Support user account should only be used under the guidance of Oracle Support. This account is typically used to log in, using SSH.
Oracle Audit Vault and Database Firewall (Oracle AVDF) supports integrating BIG-IP Application Security Manager (ASM).
This functionality is only supported on F5 BIG-IP ASM version
F5 BIG-IP ASM integration is deprecated in release
126.96.36.199.0, and can be desupported in a future release.
BIG-IP Application Security Manager (ASM), from F5 Networks, Inc., is a web application firewall (WAF) that provides protection against web-based attacks. BIG-IP ASM is deployed between web clients and the web application server. It analyzes each HTTP and HTTPS request, and blocks potential attacks before they reach the Web application server. Refer to the following figure for details:
Figure 1-6 Oracle AVDF with F5 BIG-IP ASM Data Flow Unit
Oracle Database Firewall is deployed between the web application server and the database. It provides protection against attacks originating from inside or outside the network. It works by analyzing the intent of the SQL statements sent to the database.
A deployment that includes both BIG-IP ASM and Oracle Database Firewall provides the functionality of both products, and enables the two systems to work in partnership.
A key benefit of the integration is that it allows BIG-IP ASM to pass to Oracle Database Firewall additional information about the SQL statements sent to the database, including the web user name, and the IP address of the web user who originated them. This information is not usually available from the SQL statements generated by the web application server.
Learn how to integrate Oracle Audit Vault and Database Firewall System Logging Protocol logs (
syslog) with a Security Information and Event Management (SIEM) system.
You can configure
syslog message destinations in Oracle Audit Vault Server. If you use a SIEM system, then you can configure it to receive the required information from
syslog messages that you can integrate with a SEIM system are:
Alert - alert messages raised by Oracle Database Firewall policies, and user-configured alerts
syslog messages from subcomponents of the Oracle Audit Vault Server and Oracle Database Firewall
Info - specific change logging from Oracle Database Firewall
Debug - a category that should only be used under the direction of Oracle Support
Oracle Audit Vault and Database Firewall has an integration with HP ArcSight SIEM. You can configure this integration in Oracle Audit Vault Server to send these types of
syslog messages for Oracle Database Firewall events directly to HP ArcSight.
Micro Focus ArcSight SIEM (previously known as HP ArcSight SIEM) is deprecated in
188.8.131.52.0, and is desupported in
184.108.40.206.0. Use the
syslog integration feature instead.
With the software appliance model, your hardware is dedicated to Oracle Audit Vault Server or to the Oracle Audit Vault and Database Firewall software firewall (the Database Firewall).
Both Oracle Audit Vault Server and the Database Firewall are software appliances. Unlike a hardware appliance, a software appliance uses your own industry-standard hardware. The software appliance includes the operating system, repository, and application. This system is preconfigured for you, and hardened to meet the requirements of Oracle Audit Vault and Database Firewall. Therefore, you do not need to change these settings, because the entire appliance is highly tuned. With this software appliance model, your hardware is dedicated to Oracle Audit Vault Server or to the Database Firewall software, both of which include an Oracle Linux operating system, Oracle Database, and the Oracle Audit Vault and Database Firewall software.
In addition to the benefits that Oracle Audit Vault and Database Firewall software provides, the appliance model provides these additional benefits:
In contrast to a hardware appliance model, the software appliance model provides the flexibility to choose hardware sizing to accommodate your needs.
This software model also provides easy patching and upgrading, which includes all components. Therefore, you do not need to install or patch components such as the operating system or repository separately.
You must not make any changes to the Linux operating system, or Oracle Audit Vault Server repository through the command line on these servers, unless you are following official Oracle documentation, or are under guidance from Oracle Support.
Oracle Audit Vault and Database Firewall Installation Guide for information on specific hardware required.
You can monitor the components of Oracle Audit Vault and Database Firewall using a plug-in to Enterprise Manager.
If you have Oracle Enterprise Manager Cloud Control 12c Release 2 (220.127.116.11.0) or higher, you can install the Oracle Audit Vault and Database Firewall plug-in to the Enterprise Manager (EM) to monitor Oracle Audit Vault and Database Firewall through the EM. This plug-in provides an interface within Enterprise Manager Cloud Control for administrators to manage and monitor Oracle Audit Vault and Database Firewall components.
Figure 1-7 Oracle Audit Vault and Database Firewall Plug-in for Oracle Enterprise Manager Cloud Control
The Oracle Audit Vault and Database Firewall plug-in gives you a summary view, and lets you monitor:
Audit Vault Agents
High availability information
Auditor activity notifications
Incidents and problems
To deploy Oracle Audit Vault and Database Firewall, you must prepare the server, plan the Oracle Audit Vault Server deployment, and plan the Oracle Database Firewall deployment.
Planning your Oracle Audit Vault and Database Firewall deployment includes planning Oracle Audit Vault Server deployment and deciding whether you will deploy the Audit Vault Agent, Oracle Database Firewall, or both. In addition, depending on which components you are deploying, you must gather some key information.