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 . 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 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. 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