10 Integration with Third Party SIEM and Log-data Analysis Tools

Oracle Audit Vault and Database Firewall supports integration with third-party SIEM (Security Information and Event Management) and log-data analysis tools.

Oracle Audit Vault and Database Firewall can push alerts to an external system using SYSLOG. It also allows third party tools to connect directly to the database and extract (pull) data from the event log table using a collector provided by the SIEM.

Integration with any SIEM tool is achieved through one of two methods:

  1. Oracle AVDF pushes alerts into the SIEM using SYSLOG. For the push method where Oracle Audit Vault and Database Firewall sends alerts to the SIEM using SYSLOG, see Configuring Audit Vault Server Syslog Destinations for information.

  2. Configure SIEM to pull events from the AVSYS.EVENT_LOG table in Oracle AVDF. Use the SIEM's database table connector to configure this functionality. For the pull method, configure SIEM to view and extract all of the data from the AVSYS.EVENT_LOG table using the collector provided by the SIEM. This requires creating a user in Oracle Audit Vault and Database Firewall with the auditor role. Ensure that this user has access to the targets whose data has to be sent to SIEM. This is the database user the SIEM will use to connect to the database. The remaining configuration needs to completed in the SIEM. The Oracle Audit Vault and Database Firewall schema and the specific mapping in the AVSYS.EVENT_LOG table to the SIEM depends on the SIEM. A description of the EVENT_LOG table is available in Appendix Oracle Audit Vault and Database Firewall Database Schemas.

Note:

In case of Database Firewall configured for high availability, the settings must be the same for all the Database Firewall instances. In the event of a failover, the standby Database Firewall instance becomes the primary. The SYSLOG settings on the standby Database Firewall instance is in effect. In this due course, some SYSLOG settings and logging is turned off. This is done to avoid duplicate logs sent by both the instances.

When the previous primary becomes active again, there is no transfer or sharing of settings between the Database Firewall instances. Manual modification of the rsyslog.conf must be avoided as any changes result in erasing the settings during the following failover. The actual saved values in the SYSLOG settings should not be changed on failover.