3 Audit Collection Plug-ins

This chapter describes Audit Collection Plug-ins and how to create them.

This chapter covers these topics:

About Audit Collection Plug-ins
About Mapper Files
Database Table Collection Plug-ins
XML File Collection Plug-ins
Secured Target Collection Attributes
Pre-Processing Audit Data

3.1 About Audit Collection Plug-ins

Collection plug-ins can retrieve audit data stored in either database tables or XML file audit trails, without the need for writing code.

Collection plug-ins are template-based generalized collectors. Users must provide a mapper file to collect audit data from a trail.

These collection plug-ins are created by preparing an XML Mapper file that supplies the mapping information for secured target fields to Audit Vault Server fields and other details for secured target types and audit trails. Model XML Mapper files are provided in "Database Table Collection Plug-in Mapper File" and "XML File Collection Plug-in Mapper File".

This process does not require any coding. Audit Vault contains all the code necessary to interpret Mapper files and use them to collect the audit data from the audit trail appropriately.

Collection plug-ins support two types of audit trails:

Database Table: database table collection plug-ins can collect audit data from an audit table, using the information from the Mapper file.
XML File: XML file collection plug-ins can collect audit data from XML audit files present in a single directory, using the information from the Mapper file.

To use the collection plug-in for Database tables or XML file trails, you perform the following steps:

Create an XML Mapper file for a secured target audit trail. This chapter discusses Mapper files in general and focuses on their creation in "Creating a Database Table Mapper File" and "Creating the XML File Audit Collection Mapper File".
Create a plugin-manifest file for this secured target type. See "Description of Plug-in Manifest File".
Create the collection plug-in by packaging the mapper file and plugin-manifest file. See Chapter 4, "Packaging Audit Collection Plug-ins".

You can now deploy this collection plug-in at the Audit Vault Server and use it to collect audit data after adding the secured target and any necessary collection attributes for this secured target. See "Secured Target Collection Attributes".

3.2 About Mapper Files

Mapper files are XML files which mainly contain information about which secured target fields you must collect from the audit trail and how these secured target fields map to Audit Vault Server fields. Mapper files are specific to a secured target type, and contains secured target information such as securedTargetType and securedTargetVersion, and so on.

Mapper files cover these details:

The supported secure target name and secured target version.
Mapping information from secured target fields to Audit Vault Server fields.
Secured target fields for constructing markers, which uniquely identify each audit record.
Audit table and datasource class names, where the audit trail type is database table.
Event time timestamp format, where the audit trail type is XML file.

Package the mapper files as part of the collection plug-in. Place mapper files in the templates folder during the plug-in packaging process. See "Audit Collection Plug-in Directory Structure".

3.3 Database Table Collection Plug-ins

Database table collection plug-ins support the collection of audit data from the table type of trail. They collect audit data from a single audit table. You can specify details of the audit table in the mapper file. These mapper files must conform to the schema present in "Database Table Collection Plug-in Mapper File".

This section covers these topics:

Requirements for Database Table Collection Plug-ins
Example Audit Trail for a Database Table Collection Plug-in
Creating a Database Table Mapper File

3.3.1 Requirements for Database Table Collection Plug-ins

You can use database table collection plug-ins for reading audit trails from secured target database tables if the following criteria are met:

Audit data must be stored in a single database table.
The secured target system has a user with privileges to read the audit data stored in this table.
The columns in the audit tables can be mapped to various Audit Vault core fields and large fields.

Also single or multiple fields can be mapped to extension and marker fields. Fields mapped to Audit Vault core fields, extension fields, and marker fields must be of String data type or convertible to String. They cannot be of large data type, such as a CLOB. Columns having CLOB data type should use large Audit Vault fields, such as CommandText or CommandParam.
The audit trail must contain fields which map to the CommandClass Audit Vault core fields.

The value of the CommandClass core field must not be null. If it is null, then the record is treated as an invalid record, so you must provide the proper mapping.
The audit file must have a field that can be mapped to the UserName core field. If a record has its UserName field as null, then the record is treated as invalid.
The collection plug-in can collect the text of any command issued, as well as any parameters passed to the command, in large fields. No other fields can be mapped to large fields in AVDF.
The audit trail must contain a field of type Timestamp that is monotonically increasing, that is, the value of the field increases with every new audit record inserted into the trail. This field must mapped to the EventTimeUTC core field in the mapper file. If, for any audit record, this field value becomes null, the collector treats this as an abnormal condition and shuts down.
The audit trail must contain a single column or group of columns that uniquely identify each audit record.

See schemas in Appendix B, "Schemas".

3.3.2 Example Audit Trail for a Database Table Collection Plug-in

This section contains details of an example audit trail, which is used for demonstrating the creation and structure of a sample mapper file throughout the chapter.

Table 3-1 lists the structure for the hypothetical secured target type, DBSOURCE, that generates and stores audit data in a table AUD.

Table 3-1 AUD Audit Table Data Fields and Mappings

Secured Target Field	Data Type	Audit Vault Server Field	Map to Field Type
`USER_ID`	`varchar`	`UserName`	core field
`OS_USER_ID`	`varchar`	`OSUserName`	core field
`ACTION`	`int`	`CommandClass`	core field
`STATUS`	`int`	`EventStatus`	core field
`EVENT_TIME`	`timestamp`	`EventTimeUTC`	core field
`OBJ_NAME`	`varchar`	`TargetObject`	core field
`OBJ_CREATOR`	`varchar`	`TargetOwner`	core field
`USER_HOST`	`varchar`	`ClientHostName`	core field
`SQL_TEXT`	`clob`	`CommandText`	core field
`SQL_BIND`	`clob`	`CommandParam`	core field
`TERMINAL`	`varchar`	extension field	extension field
`DB_ID`	`varchar`	extension field	extension field
`INSTANCE`	`varchar`	extension field	extension field
`PROCESS`	`int`	extension field	extension field
`SESSION_ID`	`int`	marker field	marker field
`ENTRY_ID`	`int`	marker field	marker field

Not all of the secured target fields map to core fields. The secured target fields which do not map to core fields map to extension fields or to designated marker fields, which test the uniqueness of an audit record.

3.3.3 Creating a Database Table Mapper File

This section explains how to create an XML mapper file for a database table collection plug-in. It briefly describes each XML element and attribute used in this type of mapper file. You can read descriptions of all fields in Section A.1, "AVDF Fields."

3.4 XML File Collection Plug-ins

XML file collection plug-ins support collection of audit data from an XML file type of trail. All these XML audit files must be present in single directory. You can specify details of the XML audit data in the mapper file. This XML mapper file must conform to this schema, "Schema for XML File Collection Plug-in Mapper File".

This section covers these topics:

Requirements for XML File Collection Plug-ins
Example Audit Trail for an XML File Collection Plug-in
Creating the XML File Audit Collection Mapper File
XML Transformation for Non-Standard Audit Records

3.4.1 Requirements for XML File Collection Plug-ins

You can use collection plug-ins for reading audit trails from XML audit record files if the XML files meet the following criteria:

The audit trail must be stored in one or more XML files in a single directory path.
The user must have read permission on the directory containing the XML audit files.
XML files in this directory must be valid, well-formed XML documents, within the constraints of the XML 1.0 specification.
The file and record start elements must be as specified in the mapper file.
All the audit record elements should be at the same level in Audit XML files.
All the audit record elements in Audit XML files must be the same.
Under every audit record element, all the field elements must be at the same level and one level below the audit record start element.
The XML audit file must have an element value that can be mapped to the CommandClass core field. If a record has its CommandClass field as null, then the record is treated as invalid.
The XML audit file must have an element value that can be mapped to the UserName core field. If a record has its UserName field as null, then the record is treated as invalid.
In the XML file, each audit record must have a timestamp as one of its element values.

The value of the timestamp element must be monotonically increasing, that is, the value of the field increases with every new audit record inserted into the trail. The timestamp value should be strictly Not Null. Timestamp format must be according to SimpleDateFormat Java class.

This field must mapped to the EventTimeUTC core field in the mapper file. If mapping for event time is not specified in the mapper file, then the collection plug-in shuts down. If the field value for the event time in audit records is found null, then the collection plug-in takes the time of the record last sent from the same XML audit file.
The audit trail must contain a single element value or group of element values in the audit record that uniquely identify each audit record in XML Audit files.
Common information shared by all audit records in XML file should be present in the beginning of the XML file, under the file start element, at the same level as the audit record elements.
If an audit data secured target produces audit files with multiple XML formats, then the user must provide a separate mapper file for each audit file format having a different start element.
XML files in this directory should be of the same locale and encoding as the agent, as described in the examples below:
- Valid: The user has an agent in a Chinese locale (env). XML files are also generated in a Chinese locale with same encoding (for example, ZHS16GBK). This setup is valid.
- Invalid: The user has an agent in a German locale (env). XML files are generated/moved from some other computer, which are Chinese encoded. The collectors fail to start because of an encoding mismatch, as well as a locale mismatch, in this case. This setup is invalid.

3.4.2 Example Audit Trail for an XML File Collection Plug-in

This section contains an example audit trail which is used for the creation and structure of a sample mapper file for an XML file collection plug-in throughout the chapter.

Example 3-1 Sample XML Audit Record

<?xml version="1.0" encoding="UTF-8"?>
<Audit>
    <AuditRecord>
        <Audit_type>1</Audit_type>
        <User_id>scott</User_id>
        <Os_user_id>usr1</Os_user_id>
        <Action>select</Action>
        <Status>0</Status>
        <Event_time>2010-11-11 12:23:59.166</Event_time>
        <Obj_name>emp</Obj_name>
        <Terminal>t1</Terminal>
        <Db_id>136</Db_id>
        <Session_id>170191</Session_id>
        <Entry_id>1</Entry_id>
    </AuditRecord>
    <AuditRecord>
        <Audit_type>3</Audit_type>
        <User_id>scott</User_id>
        <Os_user_id>usr1</Os_user_id>
        <Action>delete</Action>
        <Status>1</Status>
        <Event_time>2010-11-11 12:33:59.166</Event_time>
        <Obj_name>emp</Obj_name>
        <Terminal>t1</Terminal>
        <Db_id>136</Db_id>
        <Session_id>170191</Session_id>
        <Entry_id>2</Entry_id>
    </AuditRecord>
</Audit>

Table 3-2 lists the audit record structure and mappings to Audit Vault Server fields for the hypothetical secured target type, XMLSOURCE, which generates and stores audit data in XML audit files.

Table 3-2 Audit Data Fields in XML Audit Records and Mappings

Secured Target Field	Audit Vault Server Field	Map to Field Type
`USER_ID`	`UserName`	core field
`OS_USER_ID`	`OSUserName`	core field
`ACTION`	`CommandClass`	core field
`STATUS`	`EventStatus`	core field
`EVENT_TIME`	`EventTimeUTC`	core field
`OBJ_NAME`	`TargetObject`	core field
`OBJ_CREATOR`	`TargetOwner`	core field
`USER_HOST`	`ClientHostName`	core field
`SQL_TEXT`	`CommandText`	core field
`SQL_BIND`	`CommandParam`	core field
`TERMINAL`	extension field	extension field
`DB_ID`	extension field	extension field
`INSTANCE`	extension field	extension field
`PROCESS`	extension field	extension field
`SESSION_ID`	marker field	marker field
`ENTRY_ID`	marker field	marker field

3.4.3 Creating the XML File Audit Collection Mapper File

This section describes the process that you must follow to create an XML file collection plug-in mapper file. See "XML File Collection Plug-in Example" for the complete example.

You must describe the collection plug-in mappings in this mapper file as follows:

Top-Level Element
```
<AVXMLCollectorTemplate securedTargetType="XMLSOURCE"
    maxSecuredTargetVersion="11.0" version="1.0">
```
The AVXMLCollectorTemplate is the top level element and has these mandatory attributes: securedTargetType, maxSecuredTargetVersion, and version. The minSecuredTargetVersion attribute is optional.

The accepted format for the minSecuredTargetVersion, maxSecuredTargetVersion, and version attributes uses numbers, separated by dots, such as 12.2,10.3.2, 11.2.3.0.
Header Information
```
<HeaderInfo>
  <StartTag>Audit</StartTag>
</HeaderInfo>  
  
```
HeaderInfo is mandatory. It contains one child element, StartTag, which names the top-level element of the audit record file.
Record Information
```
<RecordInfo>
  <StartTag>AuditRecord</StartTag>    
</RecordInfo>
```
RecordInfo provides the starting element of audit records in XML audit files. RecordInfo is mandatory.

StartTag is the starting element of each audit record in XML audit files.
Field Mapping Information
```
<FieldMappingInfo>  
```
FieldMappingInfo provides mapping information from secured target fields to various Audit Vault fields, contained in these child elements, CoreFields, LargeFields, ExtensionField, and MarkerField.

Field mappings include <Map> elements, which contain <Name> elements that hold secured target field names, and <MapTo> elements that hold Audit Value field names that secured targets are mapped to.

There should be no many-to-one mappings from secured target fields to Audit Vault Server fields. For example, the following is invalid:
```

      
```
- Core Fields
```
<CoreFields>
```
  CoreFields provides mapping from secured target fields to core fields of Audit Vault Server. Secured target fields specified in core field mappings must be of SQL data type, either a string or a data type that can convert to string.
  
  The following elements contain core fields, which are described in "Core Fields".
```
<Map>
 <Name>EVENT_TIME</Name>
  <MapTo>EventTimeUTC</MapTo>
  <TimestampPattern>yyyy-MM-dd HH:mm:ss.SSS</TimestampPattern>
</Map>
```
  EventTimeUTC provides event time mapping information. The value in TimestampPattern specifies the timestamp format for event time. EventTimeUTC and TimestampPattern are mandatory.
  
  When specifying the TimestampPattern, use the supported patterns and characters of the Java SimpleDateFormat class, NOT Oracle Database specific patterns.
  
  For multibyte characters such as Chinese, specific words such as Month should be added into the pattern as characters in SimpleDateFormat. The AM and PM indicators are obtained based on locale, but should be explicitly mentioned in the TimestampPattern that you provide in the mapper file.
```
<Map>
  <Name>USER_ID</Name>
  <MapTo>UserName</MapTo>
</Map>   
  
```
  UserName represents the user who performed the action. If the mapping is not provided, Audit Data Collection still starts successfully, but every audit record is treated as invalid.
```
<Map>
  <Name>OS_USER_ID</Name>
  <MapTo>OSUserName</MapTo>
</Map>  
    
```
```
<Map>
  <Name>ACTION</Name>
  <MapTo>CommandClass</MapTo>
</Map>  
```
  CommandClass represents the action of the event. If the mapping is not provided, Audit Data Collection still starts successfully, but all audit records are treated as invalid.
```
        <Transformation>
          <ValueTransformation from="1" to="CREATE"/>
          <ValueTransformation from="2" to="INSERT"/>
          <ValueTransformation from="3" to="SELECT"/>
          <ValueTransformation from="4" to="CREATE"/>
          <ValueTransformation from="15" to="READ"/>
          <ValueTransformation from="30" to="LOGON"/>
          <ValueTransformation from="34" to="LOGOFF"/>
          <ValueTransformation from="35" to="ACQUIRE"/>
        </Transformation>   
  
```
  CommandClass contains a Transformation field with ValueTransformation values, from secured targets to the Audit Vault Server CommandClass field. These transformations are mandatory.
  
  The to attributes are values for the CommandClass field, as described in the "Actions and Target Types". If you can meaningfully map an event to one of these values, Oracle recommends that you do so. If this is not possible, use a value that appropriately reflects the action that generated the audit event.
```
<Map>
  <Name>OBJ_NAME</Name>
  <MapTo>TargetObject</MapTo>
</Map>
```
```
<Map>
  <Name>USER_HOST</Name>
  <MapTo>ClientHostName</MapTo>
</Map>
```
```
<Map>
  <Name>OBJ_CREATOR</Name>
  <MapTo>TargetOwner</MapTo>
</Map>
```
```
<Map>
  <Name>STATUS</Name>
  <MapTo>EventStatus</MapTo>
        <Transformation>          
          <ValueTransformation from="0" to="FAILURE"/>
          <ValueTransformation from="1" to="SUCCESS"/>
          <ValueTransformation from="2" to="UNKNOWN"/>
        </Transformation>
</Map>
```
  EventStatus contains a Transformation field with ValueTransformation values, from secured targets to Audit Vault EventStatus fields. These transformations are mandatory.
```
</CoreFields>   
 
```
- Large Fields Information
```
<LargeFields>     
  <Map>
    <Name>SQL_TEXT</Name>
    <MapTo>CommandText</MapTo>
  </Map>
```
```
  <Map>
   <Name>COMMAND_PARAMETER</Name>
   <MapTo>CommandParam</MapTo>
  </Map>        
```
```
</LargeFields>
  
```
  LargeFields are secured target fields mapped to large fields in the Audit Vault Server. The specified secured target fields must be of SQL data type CLOB or String, or be convertible to String.
  
  Large fields are described in "Large Fields".
- Extension Fields
```
<ExtensionField>      
   <Name>DB_ID</Name>
   <Name>INSTANCE</Name>
   <Name>PROCESS</Name>
   <Name>TERMINAL</Name>
</ExtensionField>  
  
```
  ExtensionFields are secured target field names that must be stored as a name-value pair in the Extension field in Audit Vault Server. Secured target fields specified must be of SQL data type CLOB or String, or be convertible to String.
  
  See "Extension Field".
- Marker Fields
```
<MarkerField>       
  <Name>SESSION_ID</Name>  
  <Name>ENTRY_ID</Name>
</MarkerField> 
 
```
  MarkerField contains a list of secured target fields that uniquely identify each audit record. The secured target fields specified must be of SQL data type CLOB or String, or be convertible to String. MarkerField is mandatory.
  
  Marker fields are described in "Marker Field".

3.4.4 XML Transformation for Non-Standard Audit Records

If you have audit records in a non-standard audit data format, that is, unlike the audit record example shown in "Example Audit Trail for an XML File Collection Plug-in", you can apply XML transformation using XSL on the XML audit records. To do this, you provide an XSL file that can transform the audit data from its original format to the format currently specified for the XML file collection plug-ins. Doing this means you can enhance file collection plug-ins to support a variety of XML audit data formats.

3.4.4.1 Additional Requirement for XML Transformation Using XSL

To transform non-standard audit records into the current format, the following is required:

The transformer must write to audit files in an incremental order, that is, writing to one audit file until its maximum size is reached and then moving over to another file. Therefore, only one file can be active at a time. The XML file collection plug-in stops if the transformer finds more than one incomplete XML audit file.

3.4.4.2 Changes Required to Transform Non-Standard Audit Records

In order to transform non-standard audit records, you must perform these steps:

Add a section such as this, to the mapper file after <RecordInfo>, as shown in Section 3.4.3, "Creating the XML File Audit Collection Mapper File", specifying the name of XSL file to be used for transformation and the SourceFileStartTag for the file to be transformed, see "Sample Non-Standard XML Audit Data Record".
```
<XslTransformation>
    <XslFile>test_template.xsl</XslFile>
    <SourceFileStartTag>AUDIT</SourceFileStartTag>
</XslTransformation>
```
Provide the XSL file and place it in the templates folder of the plugin directory. For an example, see "Creating an XSL File for Transformation"
You can also make calls to Java functions from within the XSL file. To do this, place the jar file created in the jars folder of the plugin directory.

3.4.4.3 Sample Non-Standard XML Audit Data Record

This section contains an sample of an XML data record that needs to be transformed in the proper XML format required for an XML file collection plug-in. Your source system may produce audit records with a different appearance.

Example 3-2 Audit.xml: Sample XML Audit Record

<?xml version="1.0" encoding="UTF-8"?>
<AUDIT>
 
   <AUDIT_RECORD TIMESTAMP="2013-06-07T08:27:53" NAME="Audit" 
   SERVER_ID="0" VERSION="1" STARTUP_OPTIONS="C:/Program Files/MySQL/MySQL
   Server 5.6/bin\mysqld --defaults-file=C:\ProgramData\MySQL\MySQL Server
   5.6\my.ini" OS_VERSION="x86_64-Win64" MYSQL_VERSION=
   "5.6.11-enterprise-commercial-advanced"/>
 
   <AUDIT_RECORD TIMESTAMP="2013-06-07T08:30:46" NAME="Connect" CONNECTION_ID="1"
   STATUS="0" USER="root" PRIV_USER="root" OS_LOGIN="" PROXY_USER=""  
   HOST="localhost" IP="127.0.0.1" DB=""/>
 
   <AUDIT_RECORD TIMESTAMP="2013-06-07T08:31:21" NAME="Query" CONNECTION_ID="1"
   STATUS="0" SQLTEXT="CREATE USER 'admin'@'localhost' IDENTIFIED BY 
   'welcome_1'"/>
 
</AUDIT>

3.4.4.4 Creating an XSL File for Transformation

This an example of an XSL transformation file that defines transformation rules. You need to create a version that can transform the source audit records that your system creates and place it in the templates folder of the plugin.

Example 3-3 test_template.xsl

<?xml version="1.0"?>
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output indent="yes" />
     <xsl:template match="/">
        <ROOT_DEST>
          <xsl:for-each select="AUDIT/AUDIT_RECORD">
            <Record_Dest>
                <USER><xsl:value-of select="@USER"/></USER>
                <PRIV_USER><xsl:value-of select="@PRIV_USER"/></PRIV_USER>
                <OS_LOGIN><xsl:value-of select="@OS_LOGIN"/></OS_LOGIN>
                <PROXY_USER><xsl:value-of select="@PROXY_USER"/></PROXY_USER>
                <HOST><xsl:value-of select="@HOST"/></HOST>
                <IP><xsl:value-of select="@IP"/></IP>
                <DB><xsl:value-of select="@DB"/></DB>
                <SQLTEXT><xsl:value-of select="@SQLTEXT"/></SQLTEXT>
                <CONNECTION_ID><xsl:value-of select= 
                      "@CONNECTION_ID"/></CONNECTION_ID>
                <STATUS><xsl:value-of select="@STATUS"/></STATUS>
                <TIMESTAMP><xsl:value-of select="@TIMESTAMP"/></TIMESTAMP>
                <NAME><xsl:value-of select="@NAME"/></NAME>
                <SERVER_ID><xsl:value-of select="@SERVER_ID"/></SERVER_ID>
                <VERSION><xsl:value-of select="@VERSION" /></VERSION>
   <STARTUP_OPTIONS><xsl:value-of select="@STARTUP_OPTIONS"/> </STARTUP_OPTIONS>
                <OS_VERSION><xsl:value-of select="@OS_VERSION"/></OS_VERSION>
                <MYSQL_VERSION><xsl:value-of select="@MYSQL_VERSION"/>
                    </MYSQL_VERSION>
            </Record_Dest>
          </xsl:for-each>
         </ROOT_DEST>
        </xsl:template>
  </xsl:stylesheet>

The following file does not appear in your folder. It is just an example showing the result of transforming the Audit.xml file into the required XML format using the XSL transformation file in Example 3-3.

Example 3-4 Transformed Audit Record file

<ROOT_DEST>
     <Record_Dest>
         <USER></USER>
         <PRIV_USER></PRIV_USER>
         <OS_LOGIN></OS_LOGIN>
         <PROXY_USER></PROXY_USER>
         <HOST></HOST>
         <IP></IP>
         <DB></DB>
         <SQLTEXT></SQLTEXT>
         <CONNECTION_ID></CONNECTION_ID>
         <STATUS></STATUS>
         <TIMESTAMP>2013-06-07T08:27:53</TIMESTAMP>
         <NAME>Audit</NAME>
         <SERVER_ID>0</SERVER_ID>
         <VERSION>1</VERSION>
         <STARTUP_OPTIONS>C:/Program Files/MySQL/MySQL Server 5.6/bin\mysqld
             --defaults-file=C:\ProgramData\MySQL\MySQL Server
             5.6\my.ini</STARTUP_OPTIONS>
         <OS_VERSION>x86_64-Win64</OS_VERSION>
         <MYSQL_VERSION>5.6.11-enterprise-commercial-advanced</MYSQL_VERSION>
     </Record_Dest>
     <Record_Dest>
         <USER>root</USER>
         <PRIV_USER>root</PRIV_USER>
         <OS_LOGIN></OS_LOGIN>
         <PROXY_USER></PROXY_USER>
         <HOST>localhost</HOST>
         <IP>127.0.0.1</IP>
         <DB></DB>
         <SQLTEXT></SQLTEXT>
         <CONNECTION_ID>1</CONNECTION_ID>
         <STATUS>0</STATUS>
         <TIMESTAMP>2013-06-07T08:30:46</TIMESTAMP>
         <NAME>Connect</NAME>
         <SERVER_ID></SERVER_ID>
         <VERSION></VERSION>
         <STARTUP_OPTIONS></STARTUP_OPTIONS>
         <OS_VERSION></OS_VERSION>
         <MYSQL_VERSION></MYSQL_VERSION>
     </Record_Dest>
     <Record_Dest>
         <USER></USER>
         <PRIV_USER></PRIV_USER>
         <OS_LOGIN></OS_LOGIN>
         <PROXY_USER></PROXY_USER>
         <HOST></HOST>
         <IP></IP>
         <DB></DB>
         <SQLTEXT>CREATE USER 'admin'@'localhost' IDENTIFIED BY 
                 'welcome_1'</SQLTEXT>
         <CONNECTION_ID>1</CONNECTION_ID>
         <STATUS>0</STATUS>
         <TIMESTAMP>2013-06-07T08:31:21</TIMESTAMP>
         <NAME>Query</NAME>
         <SERVER_ID></SERVER_ID>
         <VERSION></VERSION>
         <STARTUP_OPTIONS></STARTUP_OPTIONS>
         <OS_VERSION></OS_VERSION>
         <MYSQL_VERSION></MYSQL_VERSION>
     </Record_Dest>
</ROOT_DEST>

3.5 Secured Target Collection Attributes

For database table and XML file collection plug-ins, you need to set secured target collection attributes after you have deployed the collection plug-in in the Audit Vault Server and registered the secured target but before the plug-in starts collection from the audit trail.

You define collection attributes using the AVCLI command ALTER SECURED TARGET.

Required secured target attributes are:

av.collector.securedtargetversion (Mandatory): Current version of the secured target. This version information helps in choosing the correct mapper file for the audit trail if there are multiple mapper files in the templates directory of the collection plug-in.
av.collector.atcintervaltime: The collection plug-in writes the time, up to which audit data has been collected from the trail, to a file. This file will be present in the av/atc directory in the agent home. Also, this file contains the time in UTC timezone. This information can help some third party utilities to clean up audit data from a trail. Note that collection plug-in does not perform the audit data clean-up, it just writes this information to a file. atcintervaltime: specifies how frequently the collection plug-in should update the time information in the file. The value of the attribute is in minutes.
av.collector.timezoneoffset (Mandatory): Offset of the secured target event time from UTC timezone. This helps the collector to report event time correctly to the Audit Vault Server by adjusting the timezones. This attribute is not needed for an XML file collection plug-in if the event time itself contains the timezone information.

3.6 Pre-Processing Audit Data

In general, collection plug-ins can only be used to collect audit trails that conform to the requirements presented in this chapter.

However, there may be other reasons why you cannot collect audit records directly with a collection plug-in, but you can do it indirectly.

You may be able to pre-process these audit trails to generate entries in database tables or XML files in a format that allows collection plug-ins to collect them. For example, IBM DB2 on Linux, UNIX, and Windows all require you to execute the db2audit program to extract audit records from a proprietary binary format into a text file. This program must be run periodically, as the user who owns the DB2 software, to extract new records.

While you cannot define a collection plug-in to read the file directly, you may be able to write a program that reads the file periodically, extracts new audit records, and writes them to a new XML file in a directory. Each run of this program may create a new XML file that contains only the new records. You can then define a collection plug-in to read these XML files and collect the audit records into Audit Vault Server.