Applied Oracle Security: Developing Secure Database and Middleware Environments- P12 pptx

84 Part I: Oracle Database Security New Features
Customized Alert Handling
You can develop your own alert response mechanism into the Audit Vault alert life cycle by
developing an Audit Vault alert subscriber based on the Oracle Java Message Service (JMS)
technology. The subscriber can de-queue alerts from the Audit Vault alert queue and respond
in a customized manner. This customized response could incorporate existing notification and
monitoring capabilities in your organization. The Audit Vault Server installation includes an
example Java program that de-queues alerts from the Audit Vault alert queue and sends alert
information in an e-mail to a specified user. This example program is described in the file
$ORACLE_HOME/av/demo/alert/README.txt of your AV Server installation.
Managing Audit Policy for Source Databases
The Audit Vault console allows the Audit Vault auditor to retrieve the current audit policy
(settings) for a source database into the Audit Vault warehouse. Once the baseline version of
the audit policy is retrieved, the Audit Vault auditor can augment and refine the policy for any
of the following types of audit areas:
SQL statements SELECT, DML, and DDL statements that are not necessarily specific to
any individual object in an object-owner account
Schema objects SELECT, DML, AUDIT, and privilege management (GRANT, REVOKE)
statements that are specific to individual objects in an object-owner account
■
■
FIGURE 3-7 Alert drill-downs allow auditors to detect and respondquickly to suspicious activity.
Chapter 3: Applied Auditing and Audit Vault 85
Privileges Audit policy options for the use of system ANY privileges, such as UPDATE
ANY TABLE or security-relevant system privileges such as ALTER USER
Fine-grained auditing Audit policy controls that allow you to define specific conditions
that must exist for the audit to occur
Capture rules DDL, DML, or both statements from redo log files that occur for any
object in a specific object-owner account or a specific object in the account
The AV console also allows you to view summary information of the candidate audit policy
and verify the policy for accuracy, as shown in Figure 3-8. Once the audit policy has been

defined, verified, and saved in the Audit Vault warehouse, it can be provisioned back to the
source database either by generating a SQL file for manual deployment or remotely using the
Audit Vault collector account defined for the source database.
■
■
■
FIGURE 3-8 Audit policies can be created centrally and then deployed and verified across the
enterprise.
86 Part I: Oracle Database Security New Features
One of the most interesting features of the Audit Vault audit policy management and
provisioning features is the ability to copy the audit settings from another source database. This
allows you to define one or more nonoperational source databases that have a template audit
policy for your production databases. Using this approach and the Audit Vault policy provisioning
feature within the console, you can increase your level of assurance that the same version of an
audit policy is applied to all of your production databases.
Audit Maintenance Operations
One of the byproducts of auditing is that you collect a lot of data over time. The older the data
gets, the less sensitive it is generally and the less valuable it becomes. Oracle Audit Vault includes
two primary areas of maintenance: source audit trails and collector audit logs.
One of the events in the life cycle of audit trail records is the archival and purging of older
audit records from the source databases. This event is driven not only by audit retention requirements
that are common to most compliance regulations, but by integrity and performance requirements
as well.
Removing Audit Data from the Database
Over time, the database and operating system can potentially reach a maximum capacity for
storing new audit records. If auditing is enabled for some time, the security administrator will
want to delete records from the database audit trail to free audit trail space and to facilitate audit
trail management. However, it’s critical that the administrator not delete data that hasn’t yet been
transferred to Oracle Audit Vault.
Before deleting audit data from the database, you must determine the last record inserted into

Audit Vault Server. You can do this by using Audit Vault’s Activity Overview Report. Open the
Activity Overview to view the date of the summary data. Remember that Audit Vault report data
is displayed based on the last completed ETL warehouse job.
Moving the source audit records off the real-time processing storage area to a secured storage
area, possibly with Transparent Data Encryption’s tablespace encryption and Oracle Secure
Backup of those tablespaces, will not only increase the integrity/safety of the raw data but will
allow for improved performance querying the real-time audit records that remain in primary storage.
The Audit Vault product team developed an auxiliary PL/SQL package named DBMS_AUDIT_
MGMT that can be deployed to most source databases that are part of your Audit Vault collection
environment to perform this function. With this package, you can create database jobs to archive
and purge the audit trail data for all the Oracle-supported audit trail formats. The package also
provides logic to move the primary/real-time database audit trails to a tablespace that has been
optimized for the audit record generation profile your database exhibits.
TIP
Refer to Note 731908.1 on Oracle Metalink for details on how you
can obtain the PL/SQL package for your OS platform and database
release. Refer to Chapter 14 of the “Oracle Audit Vault Administrator’s
Guide” for details on using this package.
Oracle Audit Vault Utilities Maintenance Periodic maintenance of Audit Vault is important
for maintaining optimal performance. Audit Vault generates numerous logs and trace files during
normal day-to-day operations. The following information regards the contents of the log files,
their purpose, and how and when the files can be removed.
Chapter 3: Applied Auditing and Audit Vault 87
Much like the Oracle Database, the Audit Vault server generates log files that provide current
status and diagnostic information. The log files should be monitored and periodically removed to
control the amount of disk space used. These files can be found at <Audit_Vault_Server_Home>/
av/log.
Server Log File Description
avorcldb.log Tracks the commands issued by the avorcldb facility used during the initial
configuration of audited sources and Audit Vault agents and collectors.

It is safe to delete this file at any time.
avca.log Tracks the creation of collectors and the starting and stopping of Audit Vault
agents and collectors. This file may be deleted only after the Audit Vault
Server is shut down.
Enterprise Manager stores its logs in the directory <Audit Vault_Server_Home>/<Host_
Name>_<SID>/sysman/log. The file emdb.nohup in this directory contains a log of activity for
the Audit Vault web application, including GUI conversations, requests from the avctl utility,
and communication with the various Audit Vault collection agents. This can be used to debug
communication issues between the server and the agents.
The Audit Vault collection agent creates several log files and also must be maintained to
control the amount of disk space used. These files can be found at <Audit_Vault_Collection_
Agent_Home>/av/log.
Agent Log File Description
agent.err Logs all errors encountered in agent initialization and
operation. It is safe to delete this file at any time.
agent.out Logs all primary agent–related operations and activities.
This file may be deleted only after the Audit Vault Collection
Agent is shut down.
avca.log Logs all Audit Vault collection agent commands that have
been run and the results of each command. It is safe to
delete this file at any time.
avorcldb.log Logs all AVORCLDB commands that have been run and the
results of running each command. It is safe to delete this file
at any time.
av_client-%g.log.n Logs the agent operations and errors returned from those
operations. The %g is a generation number that starts from
0 (zero) and increases once the file size reaches the 10MB
limit. A concurrent existence of this file is indicated by a .n
appended to the file type name, such as av_client-%g.log.
n, where n is an integer issued in sequence—for example

av_client-0.log.1. The files that contain a .log.n extension
may be deleted at any time.
<CName><SName><SId>.log
CName = Collector Name
SName = Source Name
SID = Source ID
Logs collection operations for the DBAUD and OSAUD
collectors. This file may be deleted only after the Audit Vault
collection agent is shut down.
88 Part I: Oracle Database Security New Features
The directory <Audit_Vault_Collection_Agent_Home>/oc4j/j2ee/home/log contains the logs
generated by the collection agent OC4J. In this directory, the file AVAgent-access.log contains
a log of requests the agent receives from the Audit Vault Server. This can be used to debug
communication issues between the server and the agent.
Summary
In today’s world, auditing is growing in importance and is significant to most IT discussions.
We now live in an era of Governance, Risk, and Compliance (GRC) and issues related to data
sensitivity are vast. PII, PHI, PCI, and other highly sensitive data are deeply integrated and
embedded into existing and new applications. GRC often requires the centralization of both audit
policies—what to audit—and the actual audit data—records created to track usage of data. The
ability to correlate audit data from multiple sources has been viewed as the holy grail by many
security conscious professionals. Databases are viewed as the most important sources because
they contain sensitive information. The goal then is to achieve, at an enterprise level, a complete
understanding of access to critical databases.
While GRC is a driving factor in executing auditing activities, many organizations are learning
that audit data can be more valuable than serving simply as a mandatory checkbox to meet their
compliance initiatives. Auditing paints a picture of who is accessing what, from where, when, and
potentially how. This intelligence can be used for resource optimization and consolidation issues,
hardware sizing discussions, and increasing an organization’s stand on cyber security, to name a
few.

Auditing in Oracle involves more than just reporting on who works in a certain job or who is
a member of a group. In this chapter, we showed that database auditing records provide the who,
what, when, where, and how on actual information access as opposed to what someone might
theoretically be doing or be able to do.
The importance of this style of auditing cannot be overstated. Knowing exactly when a data
breach has occurred allows administrators to ask a variety of questions: What resource was
accessed? From where was this data/resource accessed? We can often get other useful information
about the context of the breach. What networks channels were involved? What users were
involved? What was the system state at the time of breach? What SQL statements were issued?
What applications were running? All these pieces of information can help you narrow down the
execution of a data breach and find both the perpetrator and the vulnerability used to commit
the breach.
The audit features of the Oracle Database—standard auditing, extended auditing, and fine-
grained auditing—provide the basic mechanics for capturing useable data for a specific database
instance. One of the limiting factors of audit data has historically been making it a priority to
regularly review and analyze the database being generated by these auditing tools. Since the
audit features made available in the database are limited to the scope of that particular database,
a holistic audit approach has been difficult to employ.
Audit Vault can best be thought of as a secure data warehouse of audit data. It is secure
because it is locked down by Oracle Database Vault. Audit data is first collected at a source
database and is based on centrally controlled audit policies. The collection processes are
executed by various collection agents that support Oracle databases, SQL Server, Sybase, and
IBM. The audit data from these source databases is then transmitted across an encrypted network
to the Audit Vault Server.
Chapter 3: Applied Auditing and Audit Vault 89
The Audit Vault Server acts as the data warehouse repository. Audit Vault provides you access
to a variety of reports that show system and object access. The reports are neatly organized by
categories. The consolidated view provided by Audit Vault Server can provide a variety of reports
that can satisfy the requirements of compliance initiatives such as Sarbanes-Oxley, HIPAA, and
PCI. As the Audit Vault data warehouse schema is exposed, you can create your own reports

using the provided Oracle tools or using your favorite report-writing tools. This will allow you
to incorporate application-specific accesses into your enterprise auditing view.
In addition, an administrator can configure Audit Vault Server to implement organizational
security policies and generate warnings (called alerts) when these conditions are met. Oracle
Audit Vault can generate alerts on specific system or user-defined events, acting as an early
warning system against insider threats and helping you detect changes to baseline configurations
or activity that could potentially violate compliance. Oracle Audit Vault continuously monitors
the audit data collected, evaluating the activities against defined alert conditions. The result is
that Oracle Audit Vault provides IT security personnel with the ability to detect and be alerted
to suspicious activity, attempts to gain unauthorized access, and abuse of system privileges.
Oracle Audit Vault is important to enterprise security as it fulfills the detect and response
phases of the Prevent-Detect-Respond-Remediate security life cycle.
This page intentionally left blank
PART
II
Oracle Database Vault
This page intentionally left blank
CHAPTER
4
Database Vault
Introduction
93