Oracle Audit Vault and Database Firewall

Oracle® Audit Vault and DatabaseFirewallConcepts Guide

Release 12.2E49916-09February 2018

Oracle Audit Vault and Database Firewall Concepts Guide, Release 12.2

E49916-09

Copyright © 2012, 2018, Oracle and/or its affiliates. All rights reserved.

Primary Authors: Karthik Shetty, Gigi Hanna

Contributing Authors: Andrey Brozhko

Contributors: Sunil Channapatna Ravindrachar, Marek Dulko, Paul Hackett, Ravi Handyal, Anita Hegde,William Howard-Jones, Slawek Kilanowski, Shirley Kumamoto, Ravi Kumar, Paul Laws, Harm Joris Napel,Eric Paapanen, Sajid Rahi, Scott Rotondo, Vipin Samar, Sreekumar Seshadri

This software and related documentation are provided under a license agreement containing restrictions onuse and disclosure and are protected by intellectual property laws. Except as expressly permitted in yourlicense agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify,license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means.Reverse engineering, disassembly, or decompilation of this software, unless required by law forinteroperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. Ifyou find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it onbehalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software,any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are"commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of theprograms, including any operating system, integrated software, any programs installed on the hardware,and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications.It is not developed or intended for use in any inherently dangerous applications, including applications thatmay create a risk of personal injury. If you use this software or hardware in dangerous applications, then youshall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure itssafe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of thissoftware or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks oftheir respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks areused under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron,the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced MicroDevices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products,and services from third parties. Oracle Corporation and its affiliates are not responsible for and expresslydisclaim all warranties of any kind with respect to third-party content, products, and services unless otherwiseset forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not beresponsible for any loss, costs, or damages incurred due to your access to or use of third-party content,products, or services, except as set forth in an applicable agreement between you and Oracle.

Contents

Preface

Audience viii

Documentation Accessibility viii

Downloading the Latest Version of this Manual viii

Where to Find More Information ix

Related Documents ix

Conventions ix

Changes In This Document

Revision History xi

1 Overview of Oracle Audit Vault and Database Firewall

1.1 Introduction to Database Security 1-1

1.1.1 What Is Auditing? 1-1

1.1.2 What Is Database Activity Monitoring? 1-2

1.1.3 Why Auditing and Monitoring? 1-3

1.2 What Is Oracle Audit Vault and Database Firewall? 1-3

1.2.1 Introduction to Oracle Audit Vault and Database Firewall 1-4

1.2.2 Audit Data Consolidation Functions 1-5

1.2.3 Database Firewall Functions 1-5

1.2.4 How Oracle Audit Vault and Database Firewall Fits into the OracleSecurity Architecture 1-5

1.3 Oracle Audit Vault and Database Firewall Architecture, Components, andRoles 1-6

1.3.1 Oracle Audit Vault and Database Firewall Terminology 1-6

1.3.2 Oracle Audit Vault and Database Firewall Components 1-7

1.3.2.1 Introduction to Oracle Audit Vault and Database FirewallComponents 1-8

1.3.2.2 Audit Vault Server 1-8

1.3.2.3 Audit Vault Agent 1-10

1.3.2.4 Database Firewall 1-10

iii

1.3.2.5 Oracle Audit Vault and Database Firewall Components WorkingTogether 1-11

1.3.2.6 Oracle Audit Vault and Database Firewall Components on theNetwork 1-13

1.3.3 Roles and User Accounts in Oracle Audit Vault and Database Firewall 1-14

1.3.4 Integrating Other Systems With Oracle Audit Vault And DatabaseFirewall 1-15

1.3.4.1 Integrating Oracle AVDF with F5 BIG-IP ASM 1-15

1.3.4.2 Integrating Syslog with a SIEM System 1-16

1.4 Understanding the Software Appliance Model 1-17

1.5 Oracle Audit Vault and Database Firewall and Oracle Enterprise Manager 1-17

1.6 Planning an Oracle Audit Vault and Database Firewall Deployment 1-18

2 Planning the Audit Vault Server Deployment

2.1 Introduction to Audit Vault Server Deployment 2-1

2.2 Planning and Rolling Out the Audit Vault Server 2-1

2.3 High Availability in Oracle Audit Vault and Database Firewall 2-2

3 Planning the Audit Vault Agent Deployment

3.1 Introduction to Audit Vault Agent Deployment 3-1

3.2 Understanding Audit Data Collection and Audit Policies 3-3

3.2.1 Introduction to Audit Data Collection and Audit Policies 3-3

3.2.2 What to Audit 3-3

3.2.2.1 Auditing Relevant Activities 3-3

3.2.2.2 Guidance on Auditing for Database Activity 3-4

3.2.3 Predefined Unified Audit Policies in Oracle Database 12c 3-6

3.3 Managing Oracle Database Audit Policies Using Oracle Audit Vault andDatabase Firewall 3-6

3.4 Monitoring Oracle Database Entitlements 3-7

3.5 Planning and Rolling Out Audit Vault Agent 3-7

4 Database Firewall Deployment

4.1 Introduction to Database Firewall Deployment 4-1

4.2 Planning the Protection Level for Your Databases 4-3

4.3 Understanding Database Firewall Policies 4-4

4.3.1 Introduction to Database Firewall Policies 4-4

4.3.2 Components of a Database Firewall Policy 4-5

4.3.2.1 Exception Rules 4-5

4.3.2.2 Analyzed SQL 4-5

4.3.2.3 Session Profiles 4-6

iv

4.3.2.4 Novelty Policies 4-6

4.3.2.5 Default Rule 4-6

4.3.3 Flow of SQL Through a Database Firewall Policy 4-7

4.3.4 How Database Firewall Handles Unauthorized SQL 4-8

4.4 Planning and Rolling Out the Database Firewall 4-8

5 Oracle Audit Vault and Database Firewall Reports and Alerts

5.1 Introduction to Oracle Audit Vault and Database Firewall Reports 5-1

5.2 Built-in Reports 5-2

5.2.1 How to Use the Built-in Reports 5-2

5.2.2 Available Built-in Reports 5-3

5.2.3 Customizing Built-in Reports 5-4

5.2.4 Examples of Customizing Built-in Reports 5-5

5.2.4.1 Login Failures Report 5-5

5.2.4.2 Database Schema Changes 5-8

5.3 Custom Reports 5-10

5.3.1 Introduction to Custom Reports 5-10

5.3.2 Tools for Creating Your Own Custom Reports for Oracle AVDF 5-11

5.4 Alerts and Notifications 5-11

Index

v

List of Figures

1-1 Audit Vault Server Dashboard 1-9

1-2 Audit Vault Server - Secured Targets 1-9

1-3 Audit Vault Server - Database Firewalls 1-10

1-4 Audit Vault and Database Firewall Architecture 1-12

1-5 Illustration of Oracle Audit Vault and Database Firewall on the Network (Simplified) 1-13

1-6 Oracle AVDF with F5 BIG-IP ASM Data Flow Unit 1-16

1-7 AVDF Plug-in for Oracle Enterprise Manager Cloud Control 12c 1-18

2-1 Pairs of Audit Vault Servers and Database Firewalls in High Availability Mode 2-3

3-1 Audit Vault Server with Audit Vault Agents Deployed 3-2

4-1 Database Firewall Deployed Inline, Out-of-Band, or as a Proxy 4-2

4-2 Database Firewall Deployed with a Host Monitor (Audit Vault Agent Required) 4-3

4-3 Flow of SQL Through a Firewall Policy 4-7

5-1 Oracle AVDF Built-in Reports - Compliance Reports Section 5-2

5-2 Browsing, Scheduling, or Viewing Previously Generated Reports 5-3

5-3 Interactively Customizing a Built-In Report 5-5

5-4 Login Failures Report 5-6

5-5 Customizing the Failed Logins Report into a Chart Format by Client IP 5-6

5-6 Failed Logins Shown in a Bar Chart by Client IP Address 5-7

5-7 Filter the Failed Logins Report for a Specific User 5-7

5-8 Database Schema Changes Report 5-8

5-9 Filtering a Report by Event Name 5-9

5-10 Database Schema Changes Filtered for a Specific Event Name and User 5-9

5-11 Database Schema Changes Shown in a Bar Chart by User Name 5-10

5-12 Downloading Report Template and Definition Files 5-11

vi

List of Tables

1-1 Oracle Audit Vault and Database Firewall User Accounts 1-14

4-1 Database Secured Target Matrix 4-9

5-1 Available Types of Built-in Reports in Oracle Audit Vault and Database Firewall 5-3

vii

Preface

Oracle Audit Vault and Database Firewall Concepts Guide introduces the conceptsand terminology used in Oracle Audit Vault and Database Firewall (referred to asOracle AVDF). It also describes its main features.

This preface contains the following topics:

• Audience (page viii)

• Documentation Accessibility (page viii)

• Downloading the Latest Version of this Manual (page viii)

• Where to Find More Information (page ix)

• Related Documents (page ix)

• Conventions (page ix)

AudienceThis document is intended for security managers, audit managers, and databaseadministrators (DBAs) who are involved in the configuration of Oracle Audit Vault andDatabase Firewall.

Documentation AccessibilityFor information about Oracle's commitment to accessibility, visit the OracleAccessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic supportthrough My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsif you are hearing impaired.

Downloading the Latest Version of this ManualYou can download the latest version of this manual, as well as the entire Oracle AuditVault and Database Firewall online library, from the following website:

http://www.oracle.com/pls/topic/lookup?ctx=avdf122

You can find documentation for other Oracle products at the following website:

http://docs.oracle.com

Preface

viii

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs

http://www.oracle.com/pls/topic/lookup?ctx=avdf122

http://docs.oracle.com

Where to Find More InformationFor detailed instructions about configuring and using Oracle Audit Vault and DatabaseFirewall, refer to these documents:

• Oracle Audit Vault and Database Firewall Administrator's Guide: This guideprovides the following instructions:

– Configuring and administering Oracle Audit Vault and Database Firewall

– Deploying the Audit Vault server, Database Firewall, and Audit Vault Agent

– Backing up and restoring data

– Configuring high availability

– Archiving data

– Setting up external storage

• Oracle Audit Vault and Database Firewall Auditor's Guide: This guide provides thefollowing instructions:

– Creating audit policies and firewall policies

– Generating reports

– Creating alerts on audit and firewall data

– Creating alert notification templates

• Oracle Audit Vault and Database Firewall Developer's Guide: This guide providesinstructions for creating, packaging, and testing custom audit collection plug-ins.

Related DocumentsFor more information, see the following documents in the documentation set:

• Oracle Audit Vault and Database Firewall Release Notes

• Oracle Audit Vault and Database Firewall Installation Guide

• Oracle Audit Vault and Database Firewall Administrator's Guide

• Oracle Audit Vault and Database Firewall Auditor's Guide

• Oracle Audit Vault and Database Firewall Developer's Guide

• Oracle Audit Vault and Database Firewall Licensing Information

ConventionsThe following text conventions are used in this document:

Convention Meaning

boldface Boldface type indicates graphical user interface elements associatedwith an action, or terms defined in text or the glossary.

italic Italic type indicates book titles, emphasis, or placeholder variables forwhich you supply particular values.

Preface

ix

Convention Meaning

monospace Monospace type indicates commands within a paragraph, URLs, codein examples, text that appears on the screen, or text that you enter.

Preface

x

Changes In This Document

This section lists the updates and correction to the document in Oracle Audit Vault andDatabase Firewall (AVDF) release 12.2.

Revision HistoryThe following are the updates and correction in this document.

E49916-09 (February 2018)

Here is the deprecation notice for F5. Starting with Oracle Audit Vault And DatabaseFirewall release 12.2.0.7, support for F5 is deprecated. Kindly note and prepare to usealternatives after you upgrade.

E49916-08 (December 2017)

Minor cosmetic changes to the document.

E49916-07 (August 2017)

• Included important instruction in Introduction to Audit Vault Agent Deployment(page 3-1).

• The Data Modification Before-After Values Report displays both before andafter values in the master report. See Available Built-in Reports (page 5-3) forcomplete information.

– Filter on Column Name can be added in before and after values report.

– Information Lifecycle Management is extended for before and after valuesdata.

E49916-06 (June 2017)

Included important note. See How Oracle Audit Vault and Database Firewall Fits intothe Oracle Security Architecture (page 1-5) for more information.

E49916-05 (December 2016)

Introducing support for retrieval of data from multiple targets. Updated section Planning and Rolling Out the Audit Vault Server (page 2-1).

xi

1Overview of Oracle Audit Vault andDatabase Firewall

Topics

• Introduction to Database Security (page 1-1)

• What Is Oracle Audit Vault and Database Firewall? (page 1-3)

• Oracle Audit Vault and Database Firewall Architecture, Components, and Roles(page 1-6)

• Oracle Audit Vault and Database Firewall and Oracle Enterprise Manager(page 1-17)

• Understanding the Software Appliance Model (page 1-17)

• Planning an Oracle Audit Vault and Database Firewall Deployment (page 1-18)

1.1 Introduction to Database SecurityTopics:

• What Is Auditing? (page 1-1)

• What Is Database Activity Monitoring? (page 1-2)

• Why Auditing and Monitoring? (page 1-3)

1.1.1 What Is Auditing?Auditing is the main tool in the "trust but verify" approach to security, as well as a toolfor forensic analysis, that is, finding who performed certain actions and when theyperformed these actions. Maintaining an audit trail of activity is an essentialcomponent of any defense-in-depth strategy for securing a system. Even when accesscontrols are properly configured and privilege grants are minimized, two importantrisks still remain. The first is that users who need significant privileges to perform theirjobs may misuse those privileges. The second is that a user may gain unexpectedaccess via access controls or privilege grants that are unintentionally configured to bemore generous than necessary. Auditing is the primary tool for detecting theseincidents so that they can be corrected.

Effective auditing requires audit policies that are selective in capturing the importantdetails about significant events while minimizing the noise from routine activity. Someof the most important events to audit in databases are failed logins, events requiringaccess by privileged users, and data definition (DDL) types of activities such as CREATE,DROP, ALTER, RENAME, or TRUNCATE. Besides databases, other systems such as operatingsystems, file systems, and directory services, also have audit data that can becollected. Auditing provides a history of who did what and when, and enablesorganizations to meet stringent controls and reporting requirements.

1-1

In addition, many customers must audit systems to comply with SOX, HIPAA, PCIDSS, GLB, FISMA, and other international standards. Internal governance, localsecurity policies, and forensic reporting also drive the need to audit.

Auditing requires secure storage for the audit data so that it is a reliable record ofevents and especially so that it cannot be manipulated to hide suspicious activities.Auditing also requires convenient ways to search through the collected audit data tofind specific information or detect unusual activity.

You may be using Oracle Database's robust auditing features as well as auditingfeatures of other database products. Whether or not you are using Oracle Database, itis important to understand your database's auditing features and to make sure thatyour systems are provisioned with sufficient storage capacity to sustain the amount ofaudit data collected. Oracle Database's native auditing has low overhead and does notdegrade performance when done correctly. When using other database products, referto their documentation libraries as necessary.

See Also:

• Understanding Audit Data Collection and Audit Policies (page 3-3)

• What to Audit (page 3-3)

• Predefined Unified Audit Policies in Oracle Database 12c (page 3-6)

1.1.2 What Is Database Activity Monitoring?Most applications today operate using a single user account for communicating withthe database, and many do not validate their input sufficiently. This applicationarchitecture, combined with the increasing number of attacks on databases via SQLinjection or insiders with access to privileged accounts, has made database activitymonitoring an important component of the overall security architecture. With effectivemonitoring of SQL input to the database, you can accomplish the following:

• Block or raise alerts for attempted policy violations

• Provide comprehensive reports about database activity for compliance purposes

SQL injection is perhaps the most common attack approach to databases. SQLinjection exploits flaws in application code—the application that sends SQL statementsto a database. Given that much of that application code is written without analyzingpossible SQL injection issues, many applications are exposed to vulnerabilities.

Whereas auditing logs events that already happened at the database, the DatabaseFirewall monitors, and optionally blocks, malicious SQL before it reaches thedatabase. Database Firewall not only monitors the connection to the database, but itmonitors any connection to the database whether coming from an application server ora user connecting to the database directly. This monitoring reduces both insiderthreats, as well as the ability of an outsider to launch a successful SQL injectionattack.

Database Firewall policies can be used to monitor, alert, block, and/or substitute SQLbased on user session information, such as IP address or user name, or based on theSQL grammar itself. In this way, you can use a firewall to both allow approved SQLand disallow specific SQL statements.

Chapter 1Introduction to Database Security

1-2

See Also:

• Introduction to Database Firewall Deployment (page 4-1)

• Understanding Database Firewall Policies (page 4-4)

1.1.3 Why Auditing and Monitoring?In today's global enterprise environments, security must be considered as important ashigh availability and scalability. Studies indicate that the most prevalent data breachesinvolve access by privileged users and SQL injection attacks. A DBA or someone thatuses a DBA's privileged access rights can walk out of the office with enormousamounts of sensitive data. Similarly a remote intruder may gain access to sensitivedata exploiting a SQL injection vulnerability.

The recommended approach to securing data against breaches due to access rights isto "trust but verify." You can trust your privileged users, but you need tools to verifythat neither they, nor others who have gained access to their privileges, haveaccessed data or violated your security policies. Similarly, applications that accessyour databases are often vulnerable to SQL injection attacks if they are notprogrammed with the correct security considerations.

Oracle's solution to these problems is Oracle Audit Vault and Database Firewall, asystem with the capability to collect audit data from many different types of systemsthat produce audit trails, as well as the capability to monitor network activity todatabases, analyze all SQL, and take appropriate action before this SQL reaches yourdatabase.

Oracle provides security products that address security problems in a heterogeneousenterprise environment. These products make it easier to streamline securitymanagement where there are other database products besides Oracle Database. Inthis guide, we provide information on Oracle Audit Vault and Database Firewall(AVDF).

See Also:

How Oracle Audit Vault and Database Firewall Fits into the Oracle SecurityArchitecture (page 1-5) for more information on Oracle database securityproducts.

1.2 What Is Oracle Audit Vault and Database Firewall?Topics:

• Introduction to Oracle Audit Vault and Database Firewall (page 1-4)

• Audit Data Consolidation Functions (page 1-5)

• Database Firewall Functions (page 1-5)

Chapter 1What Is Oracle Audit Vault and Database Firewall?

1-3

• How Oracle Audit Vault and Database Firewall Fits into the Oracle SecurityArchitecture (page 1-5)

1.2.1 Introduction to Oracle Audit Vault and Database FirewallA large deployment of Oracle and non-Oracle databases can produce a great amountof audit data to consolidate. In addition to audit data from databases, other systemssuch operating systems and file systems produce audit trails that can be used toanalyze events relevant to security.

Good practice dictates that audit data should be transmitted to a remote centralizedlocation where it is secure from tampering by the individuals whose activities are beingaudited.

With large amounts of audit data, it is important to have a way to efficiently monitor theongoing stream of this data to find the particular events with security implications, andidentify problems that need immediate attention.

In addition to managing a stream of audit data from heterogeneous systems, it isimportant to protect against SQL injection attacks and to monitor traffic going into thedatabase with Database Firewall.

A Flexible Solution

Oracle Audit Vault and Database Firewall (Oracle AVDF) is a key tool in providing acomprehensive way to deal with large amounts of audit data, and the risk from SQLinjection or application bypass attacks over the network, and the problems ofunauthorized access.

Oracle Audit Vault and Database Firewall solves these problems by collecting andconsolidating audit data, monitoring network traffic, blocking and substituting of SQL,logging, policy management, raising alerts, and providing comprehensive reports forforensic and compliance purposes.

Oracle Audit Vault and Database Firewall has three components:

• Audit Vault Server, which stores audit data from various types of sources, enablesyou to manage Oracle Database audit policies, and manages Database Firewallpolicies to protect secured targets. A secured target refers to the audited orprotected systems with their databases, operating systems, and file systems.

• Audit Vault Agent, which retrieves audit trails from the secured targets and sendsaudit data to Audit Vault Server

• Database Firewall

You can choose to deploy Audit Vault Server with either Audit Vault Agent, or withDatabase Firewall, or both. You can use Oracle Audit Vault and Database Firewall toprotect both Oracle and non-Oracle databases, and to protect both databases andnon-databases such as operating systems, file systems, and directory services.

See Also:

Oracle Audit Vault and Database Firewall Components (page 1-7) for moreinformation on these components.


1-4

1.2.2 Audit Data Consolidation FunctionsUsing Audit Vault Server and Audit Vault Agents, you can:

• Consolidate audit data from multiple sources:

– Database audit trails including Oracle, Microsoft SQL Server, SAP Sybase,IBM DB2 for LUW, and MySQL. These can be audit tables, audit files, orOracle Database REDO records.

– Stored procedure auditing (SPA), which enables you to audit and approvechanges to stored procedures on monitored databases

– User role auditing (URA), which enables you to audit and approve changes touser roles in the databases on a specified database server

– Operating system audit trails (Linux, AIX, 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 (10g, 11g, and 12c) audit policies

• Monitor user entitlements for Oracle Databases

1.2.3 Database Firewall FunctionsThe Database Firewall specifically protects databases from SQL attacks over thenetwork, and monitors database activity on the network with alerts and warnings.Using the combination of Audit Vault Server and the Database Firewall you canmonitor SQL transactions to your databases and can decide whether a SQL statementshould be permitted, blocked, or substituted before it reaches the database server.

The Database Firewall sends database activity events to Audit Vault Server, whichthen provides specialized Database Firewall reports. Audit Vault Server consolidatesboth Database Firewall event logs as well as audit events from other sources whereyou may have also deployed Audit Vault Agents to collect audit data.

1.2.4 How Oracle Audit Vault and Database Firewall Fits into theOracle Security Architecture

Oracle's security architecture provides both preventative and detective pillars ofprotection against threats. Oracle Audit Vault and Database Firewall is the keycomponent of the detection pillar.

The following products form the prevention pillar:

• Oracle Advanced Security - this includes:

– Transparent Data Encryption (TDE) - Automatically encrypts data before it iswritten on disk and decrypts it when reading from the disk.

– Oracle Data Redaction - Controls the display of sensitive data withinapplications.

• Oracle Key Vault - Securely manages database encryption keys.


1-5

• Oracle Database Vault - Controls access by privileged users.

• Oracle Data Masking and Subsetting - Masks sensitive data before exporting itfrom the database.

• Oracle Label Security - Simplifies the process of assigning labels to data andusers and enforcing access control based on those labels

See Also:

Oracle Audit Vault and Database Firewall Administrator's Guide for moreinformation on network encryption.

1.3 Oracle Audit Vault and Database Firewall Architecture,Components, and Roles

This section contains:

• Oracle Audit Vault and Database Firewall Terminology (page 1-6)

• Oracle Audit Vault and Database Firewall Components (page 1-7)

• Roles and User Accounts in Oracle Audit Vault and Database Firewall(page 1-14)

• Integrating Other Systems With Oracle Audit Vault And Database Firewall(page 1-15)

1.3.1 Oracle Audit Vault and Database Firewall TerminologyWe will use these terms in describing the system and its functions in the rest of thisdocument:

• Secured Targets: the systems you want to monitor and protect

A secured target is any supported database or non-database product that youmonitor with Oracle Audit Vault and Database Firewall. A secured target can be anOracle or a non-Oracle product. Secured targets can be monitored by the AuditVault Agent, the Database Firewall (if the secured target is a database), or both.All secured targets are registered in Audit Vault Server.

Oracle Audit Vault and Database Firewall supports various secured target typesout-of-the-box. These include various databases, operating systems, file systems,and directory services. You can also create custom "collection plug-ins" for OracleAudit Vault and Database Firewall in order to capture audit trails from moresecured target types using the Oracle Audit Vault and Database Firewall SDK.

• Collection Plug-ins: Agent components that collect audit data from specificsecured target types

The Audit Vault Agent contains a set of collection plug-ins, one for each type ofsecured target that is supported out of the box. For example, there is a plug-in forOracle Database, another plug-in for the Linux operating system, and so on. Eachplug-in collects data from a specific type of audit trail, and maps the specific

Chapter 1Oracle Audit Vault and Database Firewall Architecture, Components, and Roles

1-6

events from that audit trail to the audit record format in Oracle Audit Vault andDatabase Firewall.

You can also develop custom collection plug-ins to collect audit data from otheraudit trails that are not supported out-of-the-box.

• Hosts: the systems where you install the Agent to collect audit data

If you want to collect audit data from a secured target, you deploy the Audit VaultAgent on a host computer (usually the same computer where the secured targetis). Before you deploy the agent on this host, you specify how to connect to it byregistering the host in Audit Vault Server.

• Audit Trails: how you specify the location of the audit data to collect

To collect audit data from a secured target, in addition to deploying the Audit VaultAgent, you add one or more audit trails in Oracle Audit Vault and DatabaseFirewall for each secured target from which you want to collect the data. The audittrail definition in Oracle Audit Vault and Database Firewall specifies the type ofaudit trail you are collecting and the location of the audit data on the securedtarget. For example, a database could have multiple audit trails, with a differentaudit trail for each location where audit data is written. Other systems havespecific locations where audit data is written, for example, in a Linux operatingsystem, the audit trail is located in the audit.log file.

• Enforcement Points: how you set up a Database Firewall to protect adatabase

If you are deploying one or more instances of Database Firewall to protectdatabases, you configure one enforcement point for each database. Configuringan enforcement point in Oracle Audit Vault and Database Firewall lets you selectthe specific Database Firewall used for monitoring, identify the database beingmonitored, and the network traffic sources to that database. In the enforcementpoint configuration, you also specify whether you want the Database Firewall toonly monitor and alert on the SQL traffic to the database, or to also block SQLtraffic that is out of policy.

See Also:

Oracle Audit Vault and Database Firewall Developer's Guide for information onhow to develop a custom plug-in.

1.3.2 Oracle Audit Vault and Database Firewall ComponentsThis section contains:

• Introduction to Oracle Audit Vault and Database Firewall Components(page 1-8)

• Audit Vault Server (page 1-8)

• Audit Vault Agent (page 1-10)

• Database Firewall (page 1-10)

• Oracle Audit Vault and Database Firewall Components Working Together(page 1-11)


1-7

• Oracle Audit Vault and Database Firewall Components on the Network(page 1-13)

1.3.2.1 Introduction to Oracle Audit Vault and Database Firewall ComponentsAs mentioned earlier, Oracle AVDF includes three components:

• Audit Vault Server

• Audit Vault Agent

• Database Firewall

Audit Vault Server is required and at least one of the other two components. You havethe flexibility to deploy Audit Vault Server with either Audit Vault Agent, with DatabaseFirewall, or with both. The Audit Vault Agent enables you to consolidate and manageaudit data from heterogeneous sources. The Database Firewall secures yourdatabases from SQL attacks over the network. Depending on your needs, you candecide which of the components to deploy.

1.3.2.2 Audit Vault ServerAudit Vault Server stores audit data from various types of sources (secured targets),and the event data from Database Firewalls. Event data refers to the data gatheredwhen an Oracle AVDF policy is applied on an incoming SQL statement; that is, anincoming SQL statement and session data are compared to those defined in the policywhich in turn results in an action such as logging, blocking, or substituting data. TheAudit Vault Server enables you manage Oracle Database (10g, 11g, or 12c) auditpolicies, and manages Database Firewall policies to protect databases. Audit VaultServer is a dedicated server that also contains the tools necessary to configure AuditVault Agent and Database Firewall.

Audit Vault Server has a central repository of audit and event data (from both AuditVault Agents and Database Firewalls). This repository is contained in an embeddedOracle Database, and includes Oracle technologies such as compression, partitioning,encryption, and privileged user controls.

Audit Vault Server Web interface provides administrators with the tools to perform thefollowing tasks:

• Create the essential definitions necessary to monitor secured targets andconfigure the system

• Managing system settings, services, and network connections

• Configuring Audit Vault Agent host connections

• Configuring (that is, adding, editing, and deleting) secured targets, audit trails, andenforcement points

• Setting up data retention (archive) policies and archive locations

• Configuring external storage

• Setting up connections to external systems, for example, for email notificationsand syslog destinations

• Configuring high availability

• Controlling access by administrators and auditors


1-8

Some highlights of Audit Vault Server Web console are illustrated in the followingfigures.

Figure 1-1 Audit Vault Server Dashboard

Figure 1-2 Audit Vault Server - Secured Targets


1-9

Figure 1-3 Audit Vault Server - Database Firewalls

1.3.2.3 Audit Vault AgentAudit Vault Agent retrieves audit trails from various types of secured targets and sendsthe audit data to Audit Vault Server. Secured targets can be Oracle or non-Oracledatabases, operating systems, file systems, directory services, or custom audit data ineither database tables or XML files.

Audit Vault Agent is deployed on a host, usually the same host running the audit datasource (secured target) such as a database or operating system. However, you canalso deploy the agent on a remote host. Hosts are registered in Audit Vault Server.Each audit data source has an associated secured target, and one or more audit trailsdefined in Audit Vault Server.

See Also:

Planning the Audit Vault Agent Deployment (page 3-1) for more informationon the Audit Vault Agent.

1.3.2.4 Database FirewallThe Database Firewall monitors databases and provides a complete event repositoryof significant database access activity events (as defined by an Oracle Audit Vault andDatabase Firewall policy). The Database Firewall also acts as a first line of defense onthe network by enforcing expected database access behavior, thereby helping toprevent SQL injection, application bypass, and other malicious activity from reachingthe database.

The Database Firewall uses a highly accurate SQL grammar-based engine to monitorall and block unauthorized SQL traffic. By parsing the SQL, Oracle Audit Vault andDatabase Firewall can recognize the infinite number of ways to express the same SQLstatement so that you can properly decide whether to allow it or not. In contrast, naivefiltering based on regular expressions usually recognizes only a subset of equivalentstatements.

Unlike solutions that leverage regular expressions, Database Firewall parses the SQLitself to achieve the level of accuracy required for enterprise database monitoring.Database Firewall collects the SQL request from the network. The SQL statement is


1-10

then associated with as much session information as possible (for example, databaseuser name, client program name, or client IP address). This information is thencombined with further analysis of the SQL statement, including SQL category (such asSELECT statements, DDL, DML-write, TCL, and so on).

The Database Firewall analyzes the SQL statement as per the firewall policy.Database Firewall groups SQL statements into clusters, which are SQL statementswith the same grammatical structure. This enables the distillation of hundreds ofmillions of SQL statements down to just a few hundred. In this way, Database Firewalldistinguishes the “normal" transaction from the “abnormal" transaction. Oracle AuditVault and Database Firewall lets you define firewall policies that include both allowedSQL (a white list) and disallowed SQL (a black list).

The Database Firewall also supports a monitor-only agent that is local to the databaseserver to ensure flexibility in the choice of the network point at which the traffic ismonitored. Host Monitor, part of the Audit Vault Agent, captures SQL traffic reachingthe database server and securely forwards it to Database Firewall. It can be used toremotely monitor database servers running on the Linux, Solaris, and Windowsplatforms. To use the Host Monitor capability of the Database Firewall, deploy theAudit Vault Agent. Note that the host monitor does not perform the blocking.

See Also:


• Database Firewall Deployment (page 4-1) for more details on theDatabase Firewall.

1.3.2.5 Oracle Audit Vault and Database Firewall Components WorkingTogether

Figure 1-4 (page 1-12) provides a high-level overview of how the Oracle Audit Vaultand Database Firewall components work together. Though this diagram shows both aDatabase Firewall and Audit Vault Agents, you can deploy Audit Vault Server with onlythe Audit Vault Agent, or only the Database Firewall, or with both.


1-11

Figure 1-4 Audit Vault and Database Firewall Architecture

Audit VaultServer

Databases· Oracle· MySQL· Sybase· IBM· Microsoft

DatabaseFirewall

Audit Vault Agent

Other Systems· OS· Directory Services· File System· Custom Audit Logs

Audit Vault Agent

Auditor

Policies

Reports

Alerts

Applications

Users

Audit Data,Event Logs

DatabaseFirewallEvents

AuditData

The Oracle Audit Vault and Database Firewall components work together in this way:

• An Audit Vault Server is deployed for every Oracle Audit Vault and DatabaseFirewall installation. You can configure multiple secured targets from differentdatabase product families, as well as nondatabase products, using the same AuditVault Server. For example, your secured targets could be a heterogeneous set ofdatabases, operating systems, file systems, or custom audit logs. For eachsecured target, the Audit Vault Agent may be deployed. If the secured target is adatabase, then the Database Firewall may also be placed in the network andconfigured to protect that secured target. If you want to collect audit data from thesecured target, then you must deploy the Audit Vault Agent on the host.

• If the Audit Vault Agent is deployed, Oracle Audit Vault and Database Firewall isconfigured to collect the appropriate audit trail from the secured target. If theDatabase Firewall is deployed to protect a database, a firewall policy is applied forthat database secured target by configuring an enforcement point.

• The Audit Vault Agent retrieves the audit data from secured targets and sends thisdata to Audit Vault Server.

• The Database Firewall monitors SQL traffic to database secured targets, createstraffic logs, and takes actions according to a firewall policy. The firewall policy canbe designed to monitor and raise warnings only, or to block SQL traffic andoptionally substitute harmless statements in place of the blocked ones. TheDatabase Firewall sends traffic logs to the Audit Vault Server.

• Audit Vault Server stores the Oracle Audit Vault and Database Firewallconfiguration data, the collected audit data, and Database Firewall event data in itsinternal repository. An auditor can then generate and customize reports, as well asconfigure email notifications and syslog messages on Audit Vault Server.


1-12

1.3.2.6 Oracle Audit Vault and Database Firewall Components on the NetworkThe network topology will differ depending on the size of your deployment, your highavailability configuration, and optional integrations with other systems.

Figure 1-5 (page 1-13) is a simplified illustration of Audit Vault Server with bothDatabase Firewall and Audit Vault Agent deployed. There are several ways to deploythe Database Firewall on the network.

Figure 1-5 Illustration of Oracle Audit Vault and Database Firewall on theNetwork (Simplified)

Secured Target

Host

Resilient Pair

Resilient Pair

Applications

Users

Audit Vault

Server

Database

Firewall

Audit Vault

Server

Database

Firewall

Network Switch

In this illustration, two Audit Vault Servers and two Database Firewalls are deployedfor high availability. You can pair Database Firewalls, Audit Vault Servers, or both.

See Also:

• Introduction to Database Firewall Deployment (page 4-1) for moreinformation on deployment with illustration Figure 4-1 (page 4-2).

• High Availability in Oracle Audit Vault and Database Firewall (page 2-2)for information on how high availability works in Oracle Audit Vault andDatabase Firewall.


1-13

1.3.3 Roles and User Accounts in Oracle Audit Vault and DatabaseFirewall

Table 1-1 (page 1-14) shows the user accounts in Oracle Audit Vault and DatabaseFirewall.

Table 1-1 Oracle Audit Vault and Database Firewall User Accounts

Account Description

Super Administrator Super administrators configure and maintain the Oracle AuditVault and Database Firewall system, including Audit VaultServer settings such as network settings, high availability, dataretention policies, etc. The super administrator can create otheradministrators or super administrators, and has access to allsecured targets. The super administrator can also grant accessto specific secured targets to other administrators.

Administrator The administrator can perform a subset of the systemconfiguration tasks that a super administrator can, such asregistering hosts and secured targets, running archive jobs, etc.Administrators can also manage secured targets for which theyhave been granted access by a super administrator.

Database FirewallAdministrator

The Database Firewall administrator user can access theadministrative interface on the Database Firewall appliance andconfigure the Database Firewall's system and network settings,traffic sources, and view diagnostics information.

Super Auditor The super auditor can create firewall policies, provision auditpolicies for Oracle Database secured targets, and specifysettings for secured target such as whether to enable storedprocedure auditing. Super auditors also generate reports, andcreate alerts and notifications. The super auditor can access allsecured targets, create auditor or super auditor users, and grantaccess to specific secured targets to those users.

Auditor Auditors can perform all the functions of super auditors but onlyfor the secured targets to which they have access.

root This account, which is the operating system super user account,should only be used as instructed in the documentation or underthe guidance of Oracle Support. This account is typically usedfor upgrades and patching.

support This account should only be used under the guidance of OracleSupport. This account is typically used to log in via SSH.


1-14

Note:

• To provide greater security, the Oracle Audit Vault and Database Firewalladministrator and auditor roles have different user interfaces anddifferent user accounts. This ensures that there is a separation of dutiesbetween these two roles.

• In addition to these Oracle Audit Vault and Database Firewall useraccounts, you will set up user accounts on your secured targets asnecessary in order for Oracle Audit Vault and Database Firewall to accessthese targets for collecting audit data. Oracle Audit Vault and DatabaseFirewall provides scripts to set up these user accounts on databasesecured targets, as well as guidance for other types of secured targets.

1.3.4 Integrating Other Systems With Oracle Audit Vault AndDatabase Firewall

Topics:

• Integrating Oracle AVDF with F5 BIG-IP ASM (page 1-15)

• Integrating Syslog with a SIEM System (page 1-16)

1.3.4.1 Integrating Oracle AVDF with F5 BIG-IP ASMBIG-IP Application Security Manager (ASM), from F5 Networks, Inc., is a WebApplication Firewall (WAF) that provides protection against Web-based attacks.

Note:

Starting with Oracle Audit Vault And Database Firewall release 12.2.0.7,support for F5 is deprecated.

BIG-IP ASM is deployed between the Web clients and the Web application server, asshown in Figure 1-6 (page 1-16). It analyzes each HTTP and HTTPS request, andblocks potential attacks before they reach the Web application server.


1-15

Figure 1-6 Oracle AVDF with F5 BIG-IP ASM Data Flow Unit

DatabaseServer

SyslogServer

WebClients

http/https

Syslog messages containing username,IP address, user cookies, and other data

F5 BIG-IP ASM WebApplication Firewall

Web ApplicatonServer

SQL

Oracle Database Firewall

The Database Firewall is deployed between the Web application server and thedatabase. It provides protection against attacks originating from inside or outside thenetwork and works by analyzing the intent of the SQL statements sent to thedatabase.

A deployment that includes both BIG-IP ASM and the Database Firewall provides thefunctionality 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 the DatabaseFirewall additional information about the SQL statements sent to the database,including the Web user name and IP address of the Web user who originated them.This information is not usually available from the SQL statements generated by theWeb application server.

1.3.4.2 Integrating Syslog with a SIEM SystemOracle AVDF sends these types of messages to syslog:

• Alert - alert messages raised by Database Firewall policies, and user-configuredalerts

• System - syslog messages from subcomponents of the Audit Vault Server and theDatabase Firewall

• Info - specific change logging from the Database Firewall

• Debug - a category that should only be used under the direction of Oracle Support

You can configure syslog message destinations in the Audit Vault Server.

If you use a SIEM system, you can configure it to receive the required information fromsyslog.


1-16

Oracle AVDF has an integration with HP Arcsight SIEM. You can configure thisintegration in the Audit Vault Server in order to send these types of syslog messagesfor Database Firewall events directly to Arcsight.

1.4 Understanding the Software Appliance ModelBoth Audit Vault Server and the Database Firewall are software appliances. Unlike ahardware 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 OracleAudit Vault and Database Firewall. Therefore, you do not need to change thesesettings, because the entire appliance is highly tuned. With this software appliancemodel, your hardware is dedicated to Audit Vault Server or to the Database Firewallsoftware, both of which include an Oracle Linux operating system, Oracle Database,and the Oracle Audit Vault and Database Firewall software.

Benefits of the appliance model in contrast to distribution of the Oracle Audit Vault andDatabase Firewall software only are as follows:

• Time (cost) saving on the configuration of components, the appliance comes withan operating system, database, and middleware pre-configured for optimaloperation of Oracle Audit Vault and Database Firewall application software

• Implicit upgrading and patching, there is no need for separate patching of theoperating system, database or application. All component updates are deliveredas bundle patches that are installed in a single, simple procedure.

• Improved reliability and support responsiveness due to restricting scenarios toparticular combination of the operating system, database, and application.

In contrast to a hardware appliance model, the appliance model provides the flexibilityto choose hardware sizing to accommodate your needs.

This model also provides easy patching and upgrading that includes all components.Therefore, you do not need to install or patch components such as the operatingsystem or repository separately.

You must not make any changes to the Linux operating system, or Audit Vault Serverrepository, through the command line on these servers unless you are following officialOracle documentation or under guidance from Oracle Support.

See Also:

Oracle Audit Vault and Database Firewall Installation Guide for information onspecific hardware required.

1.5 Oracle Audit Vault and Database Firewall and OracleEnterprise Manager

If you have Oracle Enterprise Manager Cloud Control 12c Release 2 (12.1.0.3.0) orhigher, you can install the Oracle AVDF plug-in to the Enterprise Manager (EM) tomonitor Oracle AVDF through the EM. This plug-in provides an interface within

Chapter 1Understanding the Software Appliance Model

1-17

Enterprise Manager Cloud Control for administrators to manage and monitor OracleAVDF components.

Figure 1-7 AVDF Plug-in for Oracle Enterprise Manager Cloud Control 12c

The Oracle Enterprise Manager AVDF plug-in gives you a summary view, and lets youmonitor:

• Audit Vault Agents

• Database Firewalls

• Secured targets

• Audit trails

• Enforcement points

• High availability information

• Auditor activity notifications

• Incidents and problems

1.6 Planning an Oracle Audit Vault and Database FirewallDeployment

Planning your Oracle Audit Vault and Database Firewall deployment includes planningAudit Vault Server deployment and deciding whether you will deploy the Audit VaultAgent, the Database Firewall, or both. In addition, you will need to gather some keyinformation depending on which components you are deploying. The followingchapters provide information and considerations you need to make to deploy thecomponents of Oracle Audit Vault and Database Firewall.

Chapter 1Planning an Oracle Audit Vault and Database Firewall Deployment

1-18

See Also:

• Planning the Audit Vault Server Deployment (page 2-1)

• Planning the Audit Vault Agent Deployment (page 3-1)

• Database Firewall Deployment (page 4-1)

Chapter 1Planning an Oracle Audit Vault and Database Firewall Deployment

1-19

2Planning the Audit Vault ServerDeployment

Topics

• Introduction to Audit Vault Server Deployment (page 2-1)

• Planning and Rolling Out the Audit Vault Server (page 2-1)

• High Availability in Oracle Audit Vault and Database Firewall (page 2-2)

2.1 Introduction to Audit Vault Server DeploymentYou must deploy Audit Vault Server before you can deploy the other components: theAudit Vault Agent to collect audit data and the Database Firewall to protect databases.

Audit Vault Server performs these primary functions:

• Consolidating the following data:

– Audit data from Oracle and non-Oracle databases, operating systems,directories, and other custom sources

– Event logs from Database Firewall

• Managing audit policies for Oracle Database 11g and earlier

• Managing Database Firewall policies for any supported database

• Alerting

• Reporting and distribution of ad-hoc or scheduled reports

• Managing the system configuration including settings for Audit Vault Server itself,networking, firewalls and enforcement points, agents and agent hosts, securedtargets, audit trails, high availability, SAN storage, archiving policies and locations

2.2 Planning and Rolling Out the Audit Vault ServerWhen planning the Audit Vault Server deployment, it is important to consider thequestions below. Several of these questions impact the sizing of Audit Vault Server.See the Oracle AVDF sizing guide for help in estimating the amount of storagerequired. Work with your Oracle account team to obtain the sizing guide.

• How many databases do I need to protect with Database Firewall?

• How many systems (for example, databases, operating systems, file systems) amI going to need to collect audit data from? How many audit events do I expect tocollect each day? Typically, if you mainly audit privileged user access or directconnections to a database, then the audit data is likely minimal up to a fewhundred records every day. If you want to perform a fine-grained audit, you mustfirst look at how much data is actually created.

2-1

The amount of data you will collect, and how long you retain it, will determinewhether you upgrade to a higher capacity disk, or possibly configure SAN storagefor Audit Vault Server data. Work with Oracle Support for help in estimating theamount of storage required.

• How long do I need to retain data in Audit Vault Server?

Audit Vault Server lets you set data retention policies, and configure archivelocations. You must determine how long you want data to be available online inAudit Vault Server before it is archived, and how long you want to retain the datain the archives before it is purged.

Retaining data online in Audit Vault Server lets you view reports based on thatdata. Once data is moved from Audit Vault Server into archive locations, the datais no longer visible in reports, but can be retrieved to Audit Vault Server ifnecessary. Once its specified archive period has ended, the archived data isdeleted so the data can no longer be retrieved to Audit Vault Sever.

Before you start collecting audit data, you should define your data retentionpolicies in Audit Vault Server, and select a retention policy for each secured targetas required. Once data is collected, the selected retention policy will be applied tothat data and cannot change. Changing the retention policy for a secured targetapplies that policy to new data from that point forward.

• Do I need to configure high availability, and if so, will I have paired Audit VaultServers, paired Database Firewalls, or both?

Remember that your network must also be resilient in order to achieve highavailability for the Oracle AVDF system.

• How often will I back up Audit Vault Server data and configuration?

• Does my hardware support hardware acceleration, such as encryption usinghardware security modules for Transparent Data Encryption (TDE)?

This is important for sizing Audit Vault Server. More CPUs are required if theCPUs do not support hardware acceleration.

2.3 High Availability in Oracle Audit Vault and DatabaseFirewall

Planning for high availability is an important part of deployment planning. Within theOracle Audit Vault and Database Firewall system, the term high availability is focusedon ensuring no audit data is missed or lost. This is accomplished by configuring pairsof either Audit Vault Servers, Database Firewalls, or both. It is important to note thatyou must also ensure that high availability is built into the network itself.

Figure 2-1 (page 2-3) has a simplified illustration of an Oracle Audit Vault andDatabase Firewall deployment where there are both Audit Vault Servers and DatabaseFirewalls configured for high availability.

Chapter 2High Availability in Oracle Audit Vault and Database Firewall

2-2

Figure 2-1 Pairs of Audit Vault Servers and Database Firewalls in HighAvailability Mode

Secured Target

Host

Resilient Pair

Resilient Pair

Applications

Users

Audit Vault

Server

Database

Firewall

Audit Vault

Server

Database

Firewall

Network Switch

With Audit Vault Server in high availability mode, during normal operation the systemperiodically checks the availability of the primary Audit Vault Server in the resilient pair.If the primary Audit Vault Server becomes unavailable, the system automatically failsover to the secondary Audit Vault Server. The secondary Audit Vault Server continuesto collect audit data, without loss, if the primary fails. Once the former primary AuditVault Server is repaired, it can then become the new secondary server.

With the Database Firewall in high availability mode, both primary and secondaryDatabase Firewalls:

• Have the same configuration (which Audit Vault Server synchronizes). This is theconfiguration of secured targets, enforcement points, policies, and othermonitoring settings.

• Monitor the same traffic.

• Create log files according to the policy applied.

• Send out alerts to Audit Vault Server. Audit Vault Server then sends only the alertsfrom the primary Database Firewall.

Audit Vault Server collects traffic logs from the primary Database Firewall. If there is atime gap in the traffic logs from the primary Database Firewall, possibly due to arestart of this Database Firewall, then Audit Vault Server collects traffic log files fromthe secondary Database Firewall. Audit Vault Server then deletes all the traffic log filesfrom both Database Firewalls.


2-3

Audit Vault Server controls the state of the resilient pair of Database Firewalls. Thereis no communication between Database Firewalls in a resilient pair. If Audit VaultServer is unable to contact the primary Database Firewall for an extended period oftime, Audit Vault Server collects the log files from the secondary Database Firewalland promotes the secondary Database Firewall to be the primary.

See Also:

Oracle Audit Vault and Database Firewall Administrator's Guide for detailedinstructions for configuring high availability.


2-4

3Planning the Audit Vault Agent Deployment

Topics

• Introduction to Audit Vault Agent Deployment (page 3-1)

• Understanding Audit Data Collection and Audit Policies (page 3-3)

• Managing Oracle Database Audit Policies Using Oracle Audit Vault and DatabaseFirewall (page 3-6)

• Monitoring Oracle Database Entitlements (page 3-7)

• Planning and Rolling Out Audit Vault Agent (page 3-7)

3.1 Introduction to Audit Vault Agent DeploymentIf you want to collect and consolidate audit data from various systems (securedtargets), then you must deploy one or more Audit Vault Agents. Typically, you deploythe Audit Vault Agent on the same host as a secured target, but you can deploy it on adifferent host as well, depending on the host location. Secured targets can bedatabases or other systems that Oracle Audit Vault and Database Firewall supports.

The Audit Vault Agent contains collection plug-ins that collect audit data from specificsecured targets. Each supported secured target has a corresponding collection plug-inin the Audit Vault Agent. You can also develop custom plug-ins that collect audit datafrom a source that is not already supported out-of-the-box using the Oracle Audit Vaultand Database Firewall SDK.

Figure 3-1 (page 3-2) shows Audit Vault Server with Audit Vault Agents deployed onboth database and non-database systems. The agents are collecting audit data fromthese systems and sending this data to Audit Vault Server.

Oracle Audit Vault and Database Firewall auditors can then generate numerous pre-configured, customizable reports that consolidate this data, and can also configurerule-based alerts and notifications that are triggered when certain conditions are met.

3-1

Figure 3-1 Audit Vault Server with Audit Vault Agents Deployed

Audit VaultServer

Databases· Oracle· MySQL· Sybase· IBM· Microsoft

Audit Vault Agent

Other Systems· OS· Directory Services· File System· Custom Audit Logs

Audit Vault Agent

Auditor

Policies

Reports

Alerts

Applications

Users

Audit Data,Event Logs

AuditData

Only one Audit Vault Agent can be installed on a host for a single Audit Vault Server.Multiple audit trail collections can be started using a single Audit Vault Agent.

One Audit Vault Agent can collect audit data from multiple secured targets, if the auditlogs are accessible from the agent. For example, the database can be accessed usinga database connection string and the files (file path) can be accessed from that host.So in some cases secured target may not be on the same host. Even if there aremultiple databases on the same host, the agent can collect from multiple securedtargets. For each secured target, you will configure one or more audit trails in OracleAudit Vault and Database Firewall. For example, an agent may be collecting audit datafrom a database and an operating system. This agent is deployed on a host, and theremay be three audit trails configured. For example, two audit trails can be configured tocollect data from two different audit data sources on the database (for instance, fromREDO logs and from the SYS.AUD$ dictionary table), and one audit trail can be configuredfor the operating system (for instance, from the audit.log file on a Linux system).

See Also:

• Oracle Audit Vault and Database Firewall Installation Guide for supportedsecured targets.

• Oracle Audit Vault and Database Firewall Developer's Guide for detailedinstructions on how to develop custom plug-ins.

• Oracle Audit Vault and Database Firewall Reports and Alerts (page 5-1)

Chapter 3Introduction to Audit Vault Agent Deployment

3-2

3.2 Understanding Audit Data Collection and Audit PoliciesTopics

• Introduction to Audit Data Collection and Audit Policies (page 3-3)

• What to Audit (page 3-3)


3.2.1 Introduction to Audit Data Collection and Audit PoliciesWhether you are auditing Oracle Database or another type of database, keep in mindthat privileged users are often targeted by infiltrators to infiltrate systems. You canapply the philosophy of "trust but verify" by understanding the specific auditingcapabilities of your system and setting its auditing features accordingly. With thisunderstanding, you can then deploy Oracle AVDF to collect and consolidate auditinformation from the various systems you are monitoring.

In addition to consolidating audit data from these heterogeneous systems, OracleAVDF supports retrieving Oracle Database (10g, 11g, or 12c) audit policies, modifyingthem directly from Audit Vault Server, and then provisioning the updated policies toOracle Database.

If you use Oracle Database 12c, you can take advantage of its predefined unified auditpolicies mentioned in this section.

3.2.2 What to AuditTopics

• Auditing Relevant Activities (page 3-3)

• Guidance on Auditing for Database Activity (page 3-4)


3.2.2.1 Auditing Relevant ActivitiesAlthough auditing is relatively inexpensive, you should limit the number of auditedevents to those required for your needs. This minimizes the performance impact onthe execution of audited statements and the size of the audit trail, making it easier toanalyze and understand. The big impact is on the storage requirements on the AuditVault Server, especially if the archival time is large.

Follow these guidelines when devising an auditing strategy:

1. Evaluate your reason for auditing and focus on specific activities.

After you have a clear understanding of the reasons for auditing, you can devisean appropriate auditing strategy and avoid unnecessary auditing.

For example, an important reason for auditing is to monitor the activity ofprivileged users. If you are auditing database activity, we recommend you auditthe activity of any user who has direct access to the database, especiallyadministrative users such as the DBA.

Chapter 3Understanding Audit Data Collection and Audit Policies

3-3

In the case of a DBA, audit all of their activities. For other users, you can narrowyour focus to specific types of suspicious activity. One auditing strategy might beto audit unauthorized deletions from arbitrary tables in the database. This narrowsthe type of action being audited and the type of object being affected by thesuspicious activity.

2. Audit efficiently.

Audit the minimum number of statements, users, or objects required to get thetargeted information. This prevents clutter from unnecessary audit informationfrom obscuring the meaningful information. Balance your need to gather sufficientsecurity information with your ability to store and process it.

See Also:

Guidance on Auditing for Database Activity (page 3-4)

3.2.2.2 Guidance on Auditing for Database ActivityWhen you first configure auditing for a database, we recommend starting with thedatabase's default audit settings. Beyond that, you can use these guidelines:

1. Audit common suspicious activities.

Auditing these common activities below can help you spot suspicious activity:

• Activity of privileged users such as SYS, users who have been granted theSYSOPER or SYSDBA administrative privileges, or users who have been grantedthe DBA role

For example, for an Oracle Database that has not yet migrated to unifiedauditing, set the AUDIT_SYS_OPERATIONS initialization parameter to TRUE.

• Users who access the database directly. This can reveal activity such as:

– Users who access the database during unusual hours

– Multiple failed login attempts

– Login attempts by non-existent users, which can happen if an intruder isattempting to gain access

• Attempts to access critical business information in tables or columns. Forexample, if you see the same username coming from different IP addresses, itcould be an hint that multiple people are sharing the same account.

In addition, monitor users who share accounts or multiple users who are logging infrom the same IP address. For example, if you are auditing to gather informationabout database activity, then determine exactly what types of activities you want totrack, audit only the activities of interest, and audit only for the amount of timenecessary to gather the information that you want. As another example, do notaudit objects (such as tables or views) if you are only interested in logical I/Oinformation for each session.

2. Audit only relevant actions.

At a minimum, audit user access and the use of system privileges. Also auditchanges to the database schema structure. These include DDL changes such asthe Oracle Database CREATE TABLE or DROP TABLE SQL statements. To avoid


3-4

cluttering meaningful information with irrelevant audit records and reduce theamount of audit trail administration, only audit the targeted database activities.

Remember also that auditing too much can affect database performance. Forexample, auditing DML changes to all tables in a database produces far too manyaudit trail records and can slow down database performance. However, auditing allDDL changes, or selected tables with sensitive columns, is highly recommended.

3. Be careful when auditing sensitive information.

Be aware that sensitive data, such as credit card numbers, can appear in the audittrail columns, such as SQL text when used in the SQL query. If you have sensitivedata that is being audited, do not enable the collection of SQL text in the audit trail.

4. Remember your organization's privacy considerations.

Privacy regulations often lead to additional business privacy policies. Most privacylaws require businesses to monitor access to personally identifiable information(PII), and monitoring is implemented by auditing. A business-level privacy policyshould address all relevant aspects of data access and user accountability,including technical, legal, and company policy concerns.

5. Check your database log files for additional information that can be usefulfor auditing purposes

The log files generated by a database may contain useful information that you canuse when auditing the database. For example, in Oracle Database, you can auditREDO logs to see before and after values for a particular database object. Byenabling the REDO logs in Oracle Database, then creating an audit trail in OracleAudit Vault and Database Firewall to collect events from redo logs, you will be ableto see this information in an Oracle Audit Vault and Database Firewall report (theData Modification Before-After Values report). After this audit trail data has beensent to Audit Vault Server, you should purge the audit trail data from the database.

6. Archive audit records and purge the audit trail.

After you collect the required information, archive the audit records of interest andthen purge the audit trail of this information. Consult the documentation for yourdatabase for specific instructions.

See Also:

• Oracle Database Security Guide http://docs.oracle.com/database/121/DBSEG/tsdp.htm#DBSEG855 to hide sensitive information for Oracle Database12c.

• Oracle Database Security Guide: http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006 to hide sensitive information forOracle Database 11g.

• Oracle Database Security Guide for information about purging audit trailrecords.

• Oracle Database Administrator's Guide for more information about redologs.


3-5

http://docs.oracle.com/database/121/DBSEG/tsdp.htm#DBSEG855

http://docs.oracle.com/database/121/DBSEG/tsdp.htm#DBSEG855

http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006

http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006

3.2.3 Predefined Unified Audit Policies in Oracle Database 12cIf you use Oracle Database 12c and have migrated to unified auditing, then you canenable six predefined audit policies. These policies apply to the Oracle Database 12cunified audit trail, which captures audit data from several audited components andplaces the data in a single location in a single format.

These predefined unified audit policies cover commonly used security-relevant auditsettings:

• Logon Failures - Tracks failed logons

• Secure Options - Provides all the secure configuration audit options, such asaudits to ANY privileges (for example, CREATE ANY JOB) and audits to actions that canhave a wide impact such as altering users, creating roles, or dropping profiles.

• Oracle Database Parameter Changes - Audits changes to the Oracle Databaseparameter settings: ALTER DATABASE, ALTER SYSTEM, and CREATE SPFILE.

• User Account and Privilege Management - Audits commonly used user accountand privilege settings, such as CREATE USER, ALTER ROLE, GRANT, REVOKE.

• Center for Internet Security Recommendations - Performs audits that arerecommended by the Center for Internet Security (CIS)

• Oracle Database Vault - Audits all actions that are performed on the OracleDatabase Vault DVSYS and DVF schema objects, and the Oracle Label SecurityLBACSYS schema objects

You can enable multiple policies in one database. If you do not have unified auditingenabled, or if your version of Oracle Database is earlier than Release 12c, then youmay want to create policies that model these policies. You can find the unified auditpolicy creation statements for these policies in Oracle Database Security Guide.

See Also:

Oracle Database Security Guide for more information about policies.

3.3 Managing Oracle Database Audit Policies Using OracleAudit Vault and Database Firewall

With the Audit Vault Agent deployed, if a secured target is an Oracle Database 11g,10g, or 12c, in addition to collecting audit data from it, you can also retrieve, modify,and provision audit policies for the database. You can modify audit settings, as well asadd new audit policies, for the following:

• SQL statements

• Database schema objects

• User management

• Fine-grained auditing

• Capture rules for redo log activity

Chapter 3Managing Oracle Database Audit Policies Using Oracle Audit Vault and Database Firewall

3-6

See Also:

Oracle Database Security Guide for information on Oracle Database 11gauditing.

3.4 Monitoring Oracle Database EntitlementsAn entitlement is a role, permission, or group membership that lets a user perform aspecific task in Oracle Database. The set of entitlements can change over time, so it isimportant for an auditor to be able to track these changes to make sure nounauthorized entitlements have been granted. For example, an auditor may want tocheck grants of the DBA role or new user accounts and privileges.

With the Audit Vault Agent deployed, Oracle Audit Vault and Database Firewall letsyou take snapshots in time of Oracle Database entitlements, and then comparesnapshots in a number of reports, as well as see overall Oracle Database entitlementinformation.

See Also:

Oracle Audit Vault and Database Firewall Auditor's Guide for detailedinformation.

3.5 Planning and Rolling Out Audit Vault AgentBefore deploying the Audit Vault Agent, you will need to think about the followingquestions:

• From which systems do I need to collect audit data?

For each of the systems from which you want to collect audit data, you must up asecured target in Audit Vault Server.

• How many Audit Vault Agents do I need, and where will they be deployed?

Identify the hosts on which you will deploy the Audit Vault Agents (usually thesecured target host), and get their host names and/or IP addresses, so that youcan register them in Audit Vault Server.

• What types of audit trails, audit logs, and redo logs do I need to collect, and whereare they located?

Different types of secured targets produce different types of audit data, and placethis data in various locations. For example, for a Microsoft SQL Server databaseyou may want to collect audit data from C2 audit logs, server-side trace logs, andsqlaudit log files. You may also want to collect Oracle Database audit recordsfrom syslog files on a Linux platform. Finally, you may also want to collect datafrom Windows event logs for these two databases, as well as from a Windows OSand a Microsoft Active Directory.

• What audit settings do I need on my secured target?

Chapter 3Monitoring Oracle Database Entitlements

3-7

It is important to know the auditing features for your types of secured targets andto have an auditing strategy for each of them. Consult the documentation for thespecific secured targets you have (for example Oracle Database, or Microsoft SQLServer).

• How many audit trails will be collected by one Agent?

Estimating the number of audit trails associated to a particular Agent will help youmake performance optimizations.

See Also:

Oracle Audit Vault and Database Firewall Administrator's Guide

Chapter 3Planning and Rolling Out Audit Vault Agent

3-8

4Database Firewall Deployment

Topics

• Introduction to Database Firewall Deployment (page 4-1)

• Planning the Protection Level for Your Databases (page 4-3)


• Planning and Rolling Out the Database Firewall (page 4-8)

4.1 Introduction to Database Firewall DeploymentThe Database Firewall monitors SQL traffic to databases, logs activity, and sends alerts to Audit Vault Server. The Database Firewall can also block specific types ofSQL statements and replace them with harmless statements that you specify. Basedon the policy, the Database Firewall can also terminate an application's connection tothe database.

The Database Firewall can connect to databases in one of four ways, illustrated in Figure 4-1 (page 4-2) and Figure 4-2 (page 4-3):

• Out-of-Band: Monitoring database activity in this mode, the Database Firewallreceives a copy of network traffic, including client requests to the database and thedatabase's response to those requests.

There are several technologies that can be used to copy database traffic to thefirewall. These include (but are not limited to) spanning ports or network taps, andpacket replicators.

In this mode, the Database Firewall can monitor and alert on SQL traffic, butcannot block or substitute SQL statements.

• In-line (bridge): In this mode, the Database Firewall is deployed as a transparentnetwork bridge, simply inserted into the network in a segment that lies betweendatabase client application servers and the databases being protected. This “in-line" bridge architecture requires no configuration changes to database clients,applications, or to the database itself.

In this mode, the Database Firewall can both monitor and block SQL, as well asoptionally substitute SQL statements.

• Proxy: In scenarios where it is difficult to add a network bridge, or if the databaseservers are in remote places, Database Firewall can also be configured as a proxysuch that all traffic to the database server is routed through the Database Firewall.To act as a traffic proxy, the Database Firewall is explicitly configured to listen fortraffic on a specified network interface and port, and forward what it receives onthat interface/port to the designated database.

This requires the Database Server IP address/port on the database client orapplication to be changed to the IP address/port of the Database Firewall proxy,along with changes to the database listener to reject direct connections.

4-1

Most enterprise network switches and traditional firewalls can also be used toredirect database traffic to a Database Firewall proxy port, allowing SQL traffic tobe protected without any changes to database clients or applications.

In this mode, the Database Firewall can both monitor and block SQL, as well asoptionally substitute SQL statements.

• Host Monitor: The Database Firewall supports a local server-side, monitor-onlyagent to provide more flexibility in the choice of the network point at which thetraffic is monitored. Host Monitor is helpful in situations where it is not easy to useany of the above Database Firewall networking options.

Host Monitor is part of the Audit Agent, so to use this mode with the DatabaseFirewall, an Audit Vault Agent is placed on the host server and configured tomonitor network traffic to and from the database (as this traffic comes across thenetwork interface card). Host Monitor then securely forwards the incoming (but notoutgoing) traffic to a Database Firewall. Host Monitor monitors only the networktraffic, but not traffic from local clients on the same host.

Host Monitor can be configured for database servers running on Linux andWindows platforms.

With Host Monitor, the Database Firewall can monitor and alert on SQL traffic, butcannot block or substitute SQL statements.

Note that the same Database Firewall can monitor traffic from multiple Host Monitors,and at the same time be a proxy for some databases, out-of-band (span) for somedatabases, and in-line for others.

Figure 4-1 Database Firewall Deployed Inline, Out-of-Band, or as a Proxy

Spanning Port

Audit Vault

Server

Database

Firewall

Auditor

Policies

Reports

Alerts

Applications

Users

DatabaseFirewallEvents

Inline blockingand monitoring

Proxy

Out of band

Chapter 4Introduction to Database Firewall Deployment

4-2

Figure 4-2 Database Firewall Deployed with a Host Monitor (Audit Vault AgentRequired)

Audit Vault

Server

Database

Firewall

Database

Firewall

Events

Host

Monitor

SQL

Traffic

4.2 Planning the Protection Level for Your DatabasesDepending on operational needs, the Database Firewall can operate in one of thefollowing modes:

• Database Activity Monitoring (DAM): In this mode, the Database Firewallmonitors SQL traffic to the database, and produces alerts based on a firewallpolicy.

• Database Policy Enforcement (DPE): In this mode, the Database Firewall bothmonitors and alerts, but can also enforce a firewall policy by blocking SQL andoptionally substituting a harmless SQL statement for one that is not allowed by thepolicy.

The mode you choose and the firewall policies you create depend on yourrequirements, as indicated here:

If you need to monitor SQL traffic and actively control access to databases

• Place the Database Firewall in-line with your database traffic on the network(between the database and its clients), or configure the Database Firewall as aproxy.

• Configure the Database Firewall to operate in DAM mode (specified inenforcement points in Audit Vault Server) first, and then switch to DPE mode whenyou are satisfied with the policy results.

• Create a policy that includes blocking, and optionally substituting, SQL statements.

If you only need to monitor, alert, and report on SQL traffic to databases

• You can choose from a number of networking options.

• Configure the Database Firewall to operate in DAM mode (specified inenforcement points in Audit Vault Server).

Chapter 4Planning the Protection Level for Your Databases

4-3

• Create a policy geared for monitoring and alerting only (without blocking SQL).

See Also:

Introduction to Database Firewall Deployment (page 4-1)

4.3 Understanding Database Firewall PoliciesTopics

• Introduction to Database Firewall Policies (page 4-4)

• Components of a Database Firewall Policy (page 4-5)

• Flow of SQL Through a Database Firewall Policy (page 4-7)

• How Database Firewall Handles Unauthorized SQL (page 4-8)

4.3.1 Introduction to Database Firewall PoliciesTo understand Database Firewall policies, it is helpful to understand the terms whitelistand blacklist. Though you will not see the terms whitelist or blacklist in the Oracle AuditVault and Database Firewall user interface when you are creating a firewall policy,these concepts will be useful as you define the parts of the firewall policy (described inthe next section).

A blacklist policy specifies a set of harmful statements that are disallowed. It alsoprovides information about the various parameters and properties attached to thestatements such as the incoming IP address, user name, and so on. Most monitoringsolutions on the market today rely on regular expressions within their policies todetermine which SQL statements should be blocked from reaching the database. Thechallenge with these first-generation solutions is that regular expressions do not matchthe expressive power of the SQL language. Because there are many different ways towrite a SQL statement that will have some harmful effect, it is nearly impossible towrite a regular expression rule that will detect all such statements. You can benefitfrom a blacklist by using it to define policies that disallow certain SQL statementsbased on the type of statement, the database object it acts upon, or sessioninformation such as IP addresses, user names, or client application names.

Since the set of harmful statements does not remain constant, instead of blocking afixed set of “bad" statements, it is much more effective to allow only “good" statementsbased on the normal activity of the applications and users that connect to thedatabase. This set of good statements is a whitelist. To set up a whitelist policy, createa policy that monitors “normal" user behavior.

Database Firewall policies focus on the positive enforcement model of whitelists.However, a firewall policy can also support blacklists in the sense that you can usevarious elements of a firewall policy to disallow specific SQL statements.

Chapter 4Understanding Database Firewall Policies

4-4

See Also:

Oracle Audit Vault and Database Firewall Auditor's Guide for detailedinformation on creating Database Firewall policies.

4.3.2 Components of a Database Firewall PolicyTopics

• Exception Rules (page 4-5)

• Analyzed SQL (page 4-5)

• Session Profiles (page 4-6)

• Novelty Policies (page 4-6)

• Default Rule (page 4-6)

4.3.2.1 Exception RulesException rules (also called preconditions) within a firewall policy evaluate variousfactors before analyzing SQL statements. Exceptions are similar to “allow" and “deny"settings in traditional firewalls, and evaluate these session factors:

• Database or OS users

• Application IP addresses

• Application program names

For example, you can use an exception to block a set of client applications fromaccessing the database, except if the request is from a specific set of users. Similarly,an exception could be used to enable a specific remote administrator, coming from apredetermined IP address, to diagnose a particular application performance issuewithout being bound by the rules for "normal" SQL set in the firewall policy.

As these examples show, exceptions can be seen either in terms of a whitelist or a blacklist depending on how you define them. For blacklists, you also can disallowclusters based on the user or the IP address.

4.3.2.2 Analyzed SQLDatabase Firewall automatically analyzes actual SQL traffic to a database, thengroups the SQL into groups of similar statements known as clusters. You can thenuse a simple policy manager UI to quickly set up whitelists of “normal" behavior for thesame type of SQL interaction. This is accomplished by setting an appropriate actionfor each cluster, for example Warn or Block, in the Analyzed SQL part of a firewallpolicy. In this way, you build a set of rules for different kinds of SQL statements in yourfirewall policy.

You can also approach analyzed SQL from a blacklist perspective in the sense thatyou can disallow specific clusters in your policy.


4-5

4.3.2.3 Session ProfilesAs with exceptions, session profiles in firewall policies evaluate session informationbefore analyzing SQL statements, including:

• Application IP addresses

• Application program names

• Database or OS users

However, session profiles are different from exceptions in that an exception lets youbypass all the rules for analyzed SQL in your normal policy, whereas a profile lets youdefine rules for any cluster in the analyzed SQL based on the session factors.

For example, you might have different rules for the same SQL cluster if it originatesfrom a specific set of users or IP addresses.

You can define several session profiles within a single firewall policy. By evaluatingsession information first, the policy lets you define different rules for the sameanalyzed SQL depending on the session information.

As with exceptions, session profiles can be seen either in terms of a whitelist or a blacklist depending on how you define them.

4.3.2.4 Novelty PoliciesNovelty policies within a firewall policy can be used to prevent or allow specific typesof SQL statements acting on specific database tables. Novelty rules are often used forcontrolling behavior of DBAs over the network where it might be necessary to stopthem from accessing specific application tables.

A novelty rule can be specified to act on the following categories of SQL:

• Data Manipulation: INSERT, UPDATE, DELETE, SELECT INTO, and so on

• Data Manipulation Read-Only: SELECT

• Procedural: stored procedures or RPC commands

• Data Definition: CREATE, DROP, ALTER, and so on

• Data Control Language: GRANT, REVOKE, and so on

• Composite: commands that are executed in a transaction

• Transaction Control Language (TCL): COMMIT, ROLLBACK, and so on

• Composite with Transaction: a DML statement with a TCL command, and so on

By combining rules for the above SQL categories with specific tables, novelty rulescan provide an easy way to disable logging for entire classes of tables, such as theunderlying database dictionary tables that are not related to the application itself.

As with other parts of a firewall policy, novelty policies can be seen either in terms of a whitelist or blacklist, depending on how you define the policies.

4.3.2.5 Default RuleThe default rule in a firewall policy covers any remaining SQL that does not match anyof the other policy rules, such as rules for analyzed SQL, novelty policies, etc. The


4-6

default rule specifies the action that the Database Firewall takes for all of thisremaining SQL.

4.3.3 Flow of SQL Through a Database Firewall PolicyWith the basic firewall policy concepts described in the previous sections, you can seethe order in which SQL statements are evaluated using the firewall policy in thefollowing illustration.

Figure 4-3 Flow of SQL Through a Firewall Policy

Analyzed SQLRules

SessionProfiles

Action

Exceptions

DefaultRule

NoveltyPolicies

SQL

All remaining SQL

Rule match

Rule match

Rule match

Pass Warn

Alert

Block

The Database Firewall monitors incoming SQL to the database, and applies thefirewall policy assigned to the database in the order below. Once the SQL matches arule in the firewall policy, the Database Firewall takes the action defined in the policy.

• Exceptions to the policy are evaluated first. For example, if an exception says"apply the rules for analyzed SQL, except if the request is from this administrator,"that rule is considered first.

• Session Profiles are considered next. Depending on the session information (forexample, the request is coming from a specific set of IP addresses), the policyapplies the set of rules for analyzed SQL for that session profile.

• Next, the Database Firewall looks at the SQL statements and matches the rulesdefined for Analyzed SQL clusters.

• Novelty Policies are considered next for a possible rule match. These policieslook at which database tables are accessed, and what type of SQL statement isused to access them.

• Finally, the Default Rule is applied to any remaining SQL that does not match anyof the above rules.


4-7

4.3.4 How Database Firewall Handles Unauthorized SQLWhen the Database Firewall finds an unauthorized statement, it can handle thestatement in one of the following ways (or a combination of them), based on thefirewall policy you define:

• Alert on all out-of-policy SQL statements.

• Block the SQL statement. This specific statement is stopped from reaching thedatabase server. When a statement is blocked, the following actions can be set inthe firewall policy:

– Do nothing after blocking the statement. When this happens the clientconnection appears to hang, and the client has to terminate the session andreconnect to the database to execute more SQL.

– (Preferred) Provide a substitute for the blocked SQL statement, that is,replace it with a new harmless statement that does not return any data. Thiswill give the best end user experience and ensure applications can keeprunning. The client session is maintained, and the client can execute moreSQL if needed without having to reconnect.

– Drop the connection to the client. This blocks all traffic from that specificconnection to the database. This is the most aggressive action, and if theapplication is using connection pooling, this will impact all the users using thepool. Since an attacker may reestablish the connection, we recommend thatthis action is always logged, and that appropriate users are alerted.

4.4 Planning and Rolling Out the Database FirewallWhen planning the Database Firewall deployment and configuration, you will need tothink about the following questions:

• Which databases do I need to protect? In which networks are they located?

Each of the databases you want to protect will be added as secured targets inAudit Vault Server. The database location on the network impacts how you canplace the Database Firewall in order to achieve the type of monitoring you need.

• Do I need to both monitor and block or substitute SQL traffic to my databases, oronly monitor and alert?

You may have a different answer depending on the database being protected.Remember that to block and substitute SQL statements, a Database Firewallneeds to be in-line between the database and its client applications, or configuredas a proxy.

• How many Database Firewalls do I need and where will they be on the network?Which ones will be in-line (bridge), out-of-band (for example, using a span port), orconfigured as proxies?

Based on your answer to this as well as the previous question, you can have amatrix showing the database secured targets, level of protection, and networkmode, for example:

Chapter 4Planning and Rolling Out the Database Firewall

4-8

Table 4-1 Database Secured Target Matrix

Secured Target Monitor Only orBlock?

Network Mode Audit VaultAgent Needed?

Database 1 Monitor Out-of-band No

Database 2 Monitor Proxy No

Database 3 Block In-line No

Database 3 Monitor Host Monitor Yes

• How many Enforcement Points do I need?

You will need to configure one Enforcement Point in Audit Vault Server for eachdatabase secured target. The Enforcement Point tells Audit Vault Server:

– Which Database Firewall is protecting this database secured target

– What protection level to use: activity monitoring (DAM) or policy enforcement/blocking (DPE)

– What are the network traffic sources to this database secured target?

You can compile a list containing the above information to have handy whenconfiguring your Enforcement Points.

• Do I need to configure Database Firewalls for high availability?

To ensure that Oracle Audit Vault and Database Firewall can access securityobjects in the event of a failure, Oracle recommends that you configure OracleAudit Vault and Database Firewall for a high availability environment.

Chapter 4Planning and Rolling Out the Database Firewall

4-9

5Oracle Audit Vault and Database FirewallReports and Alerts

Topics

• Introduction to Oracle Audit Vault and Database Firewall Reports (page 5-1)

• Built-in Reports (page 5-2)

• Custom Reports (page 5-10)

• Alerts and Notifications (page 5-11)

5.1 Introduction to Oracle Audit Vault and Database FirewallReports

As an Oracle AVDF auditor, you can generate built-in audit reports that capture a widerange of audit data. Oracle AVDF reports allow you to examine audit data in aconsolidated fashion, that is, they show audit data collected from various securedtargets, as well as data from Database Firewalls you have deployed. You can use thereports to monitor activities of interest, to meet regulatory requirements, and as a basisfor setting up additional alerts to meet your needs.

The built-in reports are organized into various categories, such as activity reports andcompliance reports. An alerts report allows you to view and respond to alerts. To meetregulatory requirements, you can produce reports such as Sarbanes-Oxley (SOX),Payment Card Industry (PCI), Data Protection Act (DPA), Gramm-Leach-Bliley Act(GLBA), and Health Insurance Portability and Accountability Act (HIPAA) reports(shown in Figure 5-1 (page 5-2)).

You can save or schedule reports in either PDF or Excel format. You can also viewreports online and interactively adjust the online report view by filtering, grouping, andhighlighting data, and selecting the report columns to display. You can save theseinteractive views to see them online later. You can also send a report to other auditorsfor attestation.

5-1

Figure 5-1 Oracle AVDF Built-in Reports - Compliance Reports Section

5.2 Built-in ReportsTopics

• How to Use the Built-in Reports (page 5-2)

• Available Built-in Reports (page 5-3)

• Customizing Built-in Reports (page 5-4)

• Examples of Customizing Built-in Reports (page 5-5)

5.2.1 How to Use the Built-in ReportsYou can run the built-in report immediately, or you can create a schedule to run thereport at a later time. You can specify a list of users who receive notifications of thereport, or who need to attest to the report.

While browsing reports online, you can download them in HTML or CSV format. You can also schedule reports and download them in PDF or XLS format, or send them toother users. When you specify report notifications, you can use your own notificationtemplates to send emails to other users with either a link to a report, or an attachedPDF version of the report.

Figure 5-2 (page 5-3) shows a few of the built-in audit reports.

Chapter 5Built-in Reports

5-2

Figure 5-2 Browsing, Scheduling, or Viewing Previously Generated Reports

5.2.2 Available Built-in Reports

See Also:

Oracle Audit Vault and Database Firewall Auditor's Guide for a complete list ofthe built-in reports.

Table 5-1 (page 5-3) summarizes the different types of reports available.

Table 5-1 Available Types of Built-in Reports in Oracle Audit Vault and Database Firewall

Types of Reports Description

Activity A set of reports that track general database access activities such as audited SQLstatements, application access activities, and user login activities. Some typicalreports are:

• Activity Overview: Displays information about all monitored and audited events• Data Modification: Displays the details of audited data modifications for a

specified period of time• Data Modification Before-After Values: Displays the details of modified data

and lists the values before and after modification. This report can be filtered.• Database Schema Changes: Displays details of audited DDL activity for a

specified period of time• Login Failures: Displays details of audited failed user logins for a specified

period of time

Alert These reports track critical and warning alerts, and also let you respond online toalerts and notify others about them.

Stored Procedure Audit A set of reports that help you keep track the changes made to the storedprocedures, for example:

• Stored Procedure Modification History: Displays details of audited storedprocedure modifications for a specified period of time

• Created Stored Procedures: Displays information about stored procedurescreated within a specified period of time

• Deleted Stored Procedures: Displays information about deleted storedprocedures deleted within a specified period of time


5-3

Table 5-1 (Cont.) Available Types of Built-in Reports in Oracle Audit Vault and DatabaseFirewall

Types of Reports Description

Compliance A set of reports that track possible violations that are defined by the followingcompliance areas:

• Payment Card Industry (PCI)• Gramm-Leach-Bliley Act (GLBA)• Health Insurance Portability and Accountability Act (HIPAA)• Sarbanes-Oxley Act (SOX)• Data Protection Act (DPA)• IRS Publication 1075

Database Firewall For database secured targets that you are monitoring with the Database Firewall,this set of reports gives detailed event information on SQL traffic to thesedatabases. Much of the information is dependent on the firewall policy you haveassigned to a database. For example, you can see details of statements that hadwarnings, or were blocked, according to the policy. You can also see generalinformation about SQL traffic to these databases, for example, statement type(data definition, data manipulation, etc.).

Some example reports are:

• Database Traffic Analysis by Client IP: Displays audit details for statements bythe protected database and client IP address

• Database Traffic Analysis by OS User: Displays audit details for statementsgrouped by protected database and OS user

• Database Traffic Analysis by User Blocked Statements: Displays audit detailsfor blocked statements grouped by protected database and OS use

User Entitlements A set of reports that describe user access and privileges for Oracle Databasesecured targets, for example:

• User Accounts: Displays information such as the secured target in which theuser account was created or the user account name, and whether this accountis locked or expired

• User Privileges: Displays information such as the secured target in which theprivilege was created, user name, and privilege

• Object Privileges: Displays information such as the secured target in which theobject was created, users granted the object privilege, and the schema owner

• Privileged Users: Displays information such as the secured target in which theprivileged user account was created, user name, and privileges granted to theuser

User Correlation For Oracle Database secured targets running on Linux, these reports let youcorrelate events on the database with the original Linux OS user. This is useful incases where this user runs a shell or executes a command on the database asanother user by using su or sudo.

Database Vault Activity If your Oracle Database secured targets have Database Vault enabled, theDatabase Vault Activity report shows Database Vault events, which capture policyor rule violations, unauthorized access attempts, etc.

5.2.3 Customizing Built-in ReportsYou can create customized reports based on the built-in reports and then save thenew report formats to view them online. Oracle AVDF provides tools to filter, group,and highlight data, and define columns displayed in the reports.


5-4

Figure 5-3 (page 5-5) shows an example of filters that you can use to customizebuilt-in reports.

Figure 5-3 Interactively Customizing a Built-In Report

The next topic shows some examples of customizing built-in reports.

5.2.4 Examples of Customizing Built-in ReportsTopics

• Login Failures Report (page 5-5)

• Database Schema Changes (page 5-8)

5.2.4.1 Login Failures ReportYou may want to examine the Login Failures report to see if there are an unusualnumber of failed attempts to access a database, as well as which users or IPaddresses originated those attempts. Figure 5-2 (page 5-3) shows the Failed Loginsreport.


5-5

Figure 5-4 Login Failures Report

Suppose you want to see a visual breakdown of failed logins by client IP address. Youcan use the formatting tools to create a chart type of your choice, as shown in Figure 5-5 (page 5-6).

Figure 5-5 Customizing the Failed Logins Report into a Chart Format by Client IP

In the preceding illustration, we have chosen a horizontal bar chart with each barrepresenting a different client IP address. We have chosen a simple count to show thenumber of failed login attempts. The resulting chart, shown in Figure 5-6 (page 5-7),clearly shows a large number of failed logins from one IP address.


5-6

Figure 5-6 Failed Logins Shown in a Bar Chart by Client IP Address

Similarly, you may want to see failed logins originated by a particular user, using theformatting tools to filter the report as shown in Figure 5-7 (page 5-7).

Figure 5-7 Filter the Failed Logins Report for a Specific User


5-7

5.2.4.2 Database Schema ChangesThe Database Schema Changes report shows audited DDL activities, for example,DROP TABLE or CREATE PROCEDURE. This is useful for finding unauthorized changes andwhen you want to investigate changes to the database schema. For example, you maywant to maintain strict standards for changes to the database, where multiple usersmay implement these changes. Or, an application may stop working, requiring you toinvestigate if a change to the database may be the cause. Figure 5-8 (page 5-8)shows the Database Schema Changes report.

Figure 5-8 Database Schema Changes Report

Using the same techniques used for the Failed Logins report, you can sort and groupthe report in various ways to get the information you want. You can add or removecolumns, filter by user name, client program name or IP address, and many otherfields.

For example, suppose you are interested in investigating SUPER USER DDL commandsfor the user SYS. You can filter the report data for that event name and that user. Figure 5-9 (page 5-9) shows an example of adding the event name filter, and Figure 5-10 (page 5-9) shows the resulting report filtered by both this event nameand the user name SYS.


5-8

Figure 5-9 Filtering a Report by Event Name

Figure 5-10 Database Schema Changes Filtered for a Specific Event Name andUser

As another example of customizing this report, in Figure 5-11 (page 5-10), we havechosen to show schema changes by user name, displayed in a bar chart.


5-9

Figure 5-11 Database Schema Changes Shown in a Bar Chart by User Name

This chart shows you the breakdown of how many DDL changes were done by eachuser.

5.3 Custom ReportsTopics

• Introduction to Custom Reports (page 5-10)

• Tools for Creating Your Own Custom Reports for Oracle AVDF (page 5-11)

5.3.1 Introduction to Custom ReportsThere are two ways of creating custom reports with Oracle Audit Vault and DatabaseFirewall. One way is to interactively customize the built-in reports by filtering data, andthen save these interactive views so you can view them again online later.

See Also:

Examples of Customizing Built-in Reports (page 5-5)

Chapter 5Custom Reports

5-10

The second way is to create your own reports by making simple customizations basedon built-in report templates, or by using a software package (such as Oracle BIPublisher). You can then upload your own custom reports into Oracle Audit Vault andDatabase Firewall. This second method is discussed below.

5.3.2 Tools for Creating Your Own Custom Reports for Oracle AVDFYou can upload your own custom reports to Oracle AVDF by using Oracle BI Publisheror another report authoring tool from a third party. For simple changes to the built-inreport formats, you can also do some customizations without using a report authoringtool.

Oracle AVDF provides two types of files to help you get started creating customreports. The first type of file is a report template in RTF format, which you can open ina tool such as Microsoft Word. The template determines the display of the report, sofor example, you can easily add your own custom logo on the report. The second typeof file is a report definition in XML format, which you can open in a text or XML editor.The report definition file specifies the data in the report.

You can download report definition and template files corresponding to any of the built-in reports, and then you can use these files as a starting point for creating your owncustom report. Oracle AVDF documentation also provides several appendices onevent data collected from different types of secured targets that will help you increating your own reports.

Figure 5-12 (page 5-11) shows how an auditor can download various types of reportdefinition and template files with which to start creating a custom report.

Figure 5-12 Downloading Report Template and Definition Files

5.4 Alerts and NotificationsOracle Audit Vault and Database Firewall lets you define rule-based alerts on auditrecords, whether these records come from the Audit Vault Agent or the DatabaseFirewall. You can also specify notifications for those alerts. For example, you can set

Chapter 5Alerts and Notifications

5-11

up an email to be automatically sent to a user, such as a security officer, or to adistribution list. Alerts can also be forwarded to syslog. This is useful if you want tointegrate them with another system.

Alerts you define are independent of audit policies or firewall policies. For example, infirewall policies, you can specify that certain SQL statements types (clusters) shouldraise an alert when encountered by the Database Firewall. But you may also want todefine a special condition that raises an alert based on factors other than thosespecified in a firewall policy. This can be a quick way to notify a specific person orgroup when that condition is met. Or you may want to be alerted whenever thiscondition is met for all secured targets, whereas the firewall policy may have beenassigned to only one secured target.

Because alerts are rule-based, if the rule definition is matched (for example, User Afails to log in to Database B after three tries), then an alert is raised. The rule is calleda condition in Oracle Audit Vault and Database Firewall. The condition is a Booleanstatement, similar to a WHERE clause in a SELECT statement. For example:

The WHERE clause in this SELECT statement...

SELECT user_name, event_status, event_name from avsys.event_log WHERE event_status='FAILURE' and upper(event_name)='LOGON';

...can be translated into this alert condition:

:event_status='FAILURE' and upper(:event_name)='LOGON'

Alert conditions are flexible and can include more than one event, and the events cancome from different secured targets. For example, an alert can be applied to fourOracle databases. The alert condition can also be a complex statement, for example,User A failed to log in to secured target X and User A also failed to log in to securedtarget Y.

A good way to define an alert condition is to first look at the Oracle Audit Vault andDatabase Firewall All Activity Report, which displays details of all captured auditevents. From this report you can see possible events that may be of interest to you.This can be the starting point for your alert condition.

See Also:

Oracle Audit Vault and Database Firewall Auditor's Guide for more details onwriting alert conditions, monitor and respond to alerts.

Chapter 5Alerts and Notifications

5-12

Index

Aalerts

as part of planning strategy, 4-3Database Activity Monitoring (DAM), 4-3Database Policy Enforcement (DPE), 4-3from Database Firewall, 4-1Host Monitor, 4-2out-of-band mode, 4-1rule based, 3-1unauthorized SQL, 4-8

architectureof Oracle AVDF components, 1-6

archiving, 2-1Audit Vault and Database Firewall

component diagram, 1-11components, 1-6documentation, downloading latest, viiiin network, diagram, 1-13process flow, 1-12

Audit Vault Serverabout, 1-8failover, 2-3high availability

failover, 2-3auditing

audit trail, sensitive data in, 3-5guidelines for security, 3-3historical information, 3-4keeping information manageable, 3-3

BBIG-IP ASM (Application Security Manager)

integration with Database Firewall, 1-15blacklists

about, 4-4clusters, 4-5exception rules, 4-5novelty policies, 4-6session profiles, 4-6

Ccomponents, of Oracle AVDF, 1-6

DDAM

See Database Activity MonitoringDatabase Activity Monitoring (DAM)

about, 4-3Database Firewall

overview, 4-1ways to connect to, 4-1

Database Policy Enforcement (DPE)about, 4-3

documentation, AVDF, downloading latest, viiiDPE

See Database Policy Enforcement

Eemail notifications, 1-12enforcement points

definition, 1-7

Ffailover, Audit Vault Server, 2-3

Gguidelines for security

auditing, 3-3

HHost Monitor

about, 4-2deployment, 4-2

hostsregistering, about, 1-7

Llog files

traffic logs, collected, 2-3logging

blocking SQL statements, 4-3

Index-1

Nnotifications, 1-12

Ooperational modes, defined, 4-3

Pplanning Database Firewall protection level, 4-3process flow, through Oracle Audit Vault and

Database Firewall components, 1-12

Rreport definition file, for creating custom reports,

5-11reports

about, 5-1Access Reports, 5-3data collected for, 5-1formatting, 5-2PDF generation, 5-2scheduling, 5-2sending to other users, 5-2

reports (continued)setting retention time, 5-2specifying auditors to attest to, 5-2

RTF, report template, 5-11

Ssecured targets

hosts, registering, 1-7introduction, 1-6nondatabase sources, about, 1-6

security riskssensitive data in audit trail, 3-5

sizing, 2-1

Ttemplate, for custom reports, 5-11traffic log files, collected, 2-3

Wwhitelists

about, 4-4exception rules, 4-5novelty policies, 4-6session profiles, 4-6

Index

Index-2