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

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

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.

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.

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

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

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

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

Oracle Database Vault

Database Vault

Introduction

93