3 Planning the Audit Vault Agent Deployment

Topics

3.1 Introduction to Oracle Audit Vault Agent Deployment

Collect and consolidate audit data from various systems (secured targets) by deploying one or more Audit Vault Agents.

Typically, you deploy the Audit Vault Agent on the same host as a secured target, but you can deploy it on a different host as well, depending on the host location. Secured targets can be databases or other systems that Oracle Audit Vault and Database Firewall supports.

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

The following figure shows Oracle Audit Vault Server with Audit Vault Agents deployed on both database and non-database systems. The agents are collecting audit data from these systems, and sending this data to Oracle Audit Vault Server.

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

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

Description of Figure 3-1 follows
Description of "Figure 3-1 Oracle Audit Vault Server with Audit Vault Agents Deployed"

Only one Audit Vault Agent can be installed on a host for a single Oracle 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 audit logs are accessible from the agent. For example, the database can be accessed using a 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 are multiple databases on the same host, the agent can collect from multiple secured targets. For each secured target, you configure one or more audit trails in Oracle Audit Vault and Database Firewall. For example, an agent can be collecting audit data from a database and an operating system. This agent is deployed on a host, and there may be three audit trails configured. For example, two audit trails can be configured to collect data from two different audit data sources on the database (for instance, from REDO logs and from the SYS.AUD$ dictionary table), and one audit trail can be configured for the operating system (for instance, from the audit.log file on a Linux system).

Related Topics

See Also:

3.2 Understanding Audit Data Collection and Audit Policies

Learn about audit data collection and audit policies.

3.2.1 Introduction to Audit Data Collection and Audit Policies

You can apply the philosophy of "trust but verify" by understanding the specific auditing capabilities of your system, and setting its auditing features accordingly.

Whether you are auditing Oracle Database, or another type of database, keep in mind that privileged users are often targeted to infiltrate systems. Understanding the auditing capabilities of your system, you can then deploy Oracle Audit Vault and Database Firewall to collect and consolidate audit information from the various systems you are monitoring.

In addition to consolidating audit data from these heterogeneous systems, Oracle Audit Vault and Database Firewall supports retrieving Oracle Database audit policies, modifying them directly from Oracle Audit Vault Server, and then provisioning the updated policies to Oracle Database.

If you use Oracle Database 12c or later, then you can take advantage of the predefined unified audit policies mentioned for Oracle Database 12c and later releases.

3.2.2 What to Audit

Topics

3.2.2.1 Auditing Relevant Activities

Although auditing is relatively inexpensive, you should limit the number of audited events to those required for your needs.

This minimizes the performance impact on the execution of audited statements and the size of the audit trail, making it easier to analyze and understand. The big impact is on the storage requirements on the Audit Vault Server, especially if the archival period 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 devise an appropriate auditing strategy and avoid unnecessary auditing.

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

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

  2. Use the audit functionality efficiently. Audit the minimum number of statements, users, or objects required to get the targeted information. This prevents clutter from unnecessary audit information from obscuring the meaningful information. Balance your need to gather sufficient security information with your ability to store and process it.

3.2.2.2 Guidance on Auditing for Database Activity

When you first configure auditing for a database, we recommend starting with the database'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 the SYSOPER or SYSDBA administrative privileges, or users who have been granted the DBA role

      For example, for an Oracle Database that has not yet migrated to unified auditing, 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 is attempting to gain access

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

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

  2. Audit only relevant actions.

    At a minimum, audit user access and the use of system privileges. Also audit changes to the database schema structure. These include DDL changes such as the Oracle Database CREATE TABLE or DROP TABLE SQL statements. To avoid cluttering meaningful information with irrelevant audit records and reduce the amount of audit trail administration, only audit the targeted database activities.

    Remember also that auditing too much can affect database performance. For example, auditing DML changes to all tables in a database produces far too many audit trail records and can slow down database performance. However, auditing all DDL 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 audit trail columns, such as SQL text when used in the SQL query. If you have sensitive data 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 privacy laws require businesses to monitor access to personally identifiable information (PII), and monitoring is implemented by auditing. A business-level privacy policy should 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 useful for auditing purposes

    The log files generated by a database may contain useful information that you can use when auditing the database. For example, in Oracle Database, you can audit REDO logs to see before and after values for a particular database object. By enabling the REDO logs in Oracle Database, then creating an audit trail in Oracle Audit Vault and Database Firewall to collect events from redo logs, you will be able to see this information in an Oracle Audit Vault and Database Firewall report (the Data Modification Before-After Values report).

  6. Archive audit records and purge the audit trail.

    After you collect the required information, archive the audit records of interest and then purge the audit trail of this information. Consult the documentation for your database for specific instructions.

See Also:

3.2.3 Predefined Unified Audit Policies for Oracle Database

If you use Oracle Database 12c or later, and have migrated to unified auditing, then you can take advantage of six predefined unified audit policies.

You can enable six predefined audit policies that apply to the Oracle Database 12c and later release unified audit trails. These audit trails capture audit data from several audited components, and place the data in a single location, and in a single format.

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

  • Logon Failures - Tracks failed log ons

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

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

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

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

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

You can enable multiple policies in one database. If you do not have unified auditing enabled, or if your version of Oracle Database is earlier than Release 12c, then you may want to create policies that model these policies. You can find the unified audit policy 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 Oracle Audit Vault and Database Firewall

With the Audit Vault Agent deployed, if a secured target is 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 as add new audit policies, for the following:

  • SQL statements
  • Database schema objects
  • User management
  • Fine-grained auditing
  • Capture rules for redo log activity

See Also:

Oracle Database Security Guide for information on Oracle Database 11g auditing.

3.4 Monitoring Oracle Database Entitlements

An Oracle Database entitlement is a role, permission, or group membership that permits a user account to perform a specific task in Oracle Database.

The set of entitlements in Oracle Database releases can change over time, so it is important for an auditor to be able to track these changes to make sure no unauthorized entitlements have been granted. For example, an auditor may want to check grants of the DBA role or new user accounts and privileges.

With the Audit Vault Agent deployed, Oracle Audit Vault and Database Firewall lets you take snapshots in time of Oracle Database entitlements, and then compare snapshots in a number of reports, as well as see overall Oracle Database entitlement information.

See Also:

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

3.5 Planning and Rolling Out Audit Vault Agent

Learn how to plan and roll out the Audit Vault Agent component of Oracle Audit Vault and Database Firewall.

Before deploying the Audit Vault Agent, you will need to think about the following questions:

  • 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 a secured target in Oracle 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 the secured target host), and get their host names , IP addresses, or both, so that you can register them in Oracle Audit Vault Server.

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

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

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

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

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

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

See Also:

Oracle Audit Vault and Database Firewall Administrator's Guide