This chapter describes Audit Collection Plug-ins and how to create them.
This chapter covers these topics:
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".
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".
See Also:
"Database Table Collection Plug-ins" for mapper files that retrieve audit records from database audit tables
"XML File Collection Plug-ins" for mapper files that retrieve audit records from XML files
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:
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".
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 |
---|---|---|---|
|
|
|
core field |
|
|
|
core field |
|
|
|
core field |
|
|
|
core field |
|
|
|
core field |
|
|
|
core field |
|
|
|
core field |
|
|
|
core field |
|
|
|
core field |
|
|
|
core field |
|
|
extension field |
extension field |
|
|
extension field |
extension field |
|
|
extension field |
extension field |
|
|
extension field |
extension field |
|
|
marker field |
marker field |
|
|
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.
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."
See Also:
The following is a step-by-step example that shows how to create a mapper file for database table collection plug-in:
Top Level Element
<AVTableCollectorTemplate securedTargetType="DBSOURCE" minSecuredTargetVersion="10.2.0" maxSecuredTargetVersion="11.0" version="1.0" >
The AVTableCollectorTemplate
is the top level element, which marks the start of the mapper file. It 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.
Table Name Information
<TableName>AUD</TableName>
You must provide the TableName
of the audit table. This is a mandatory field.
Secured Target Connection Information
<ConnectionInfo>
<Driver>platform.jdbc.dbsource.DBSourceDataSource</Driver>
</ConnectionInfo>
You must provide the full name for the datasource class implementing javax.sql.DataSource
interface. This is a mandatory field.
Field Mapping Information
<FieldMappingInfo>
FieldMappingInfo
must provide mapping information from secured target fields to various Audit Vault fields, along with the value transformations if any. This is a mandatory element.
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:
<!-- Invalid code <Map> <Name>USER_ID</Name> <MapTo>UserName</MapTo> </Map> <Map> <Name>OS_USER_ID</Name> <MapTo>UserName</MapTo> </Map> -->
The following sections explain mappings for core, large, extension, and marker fields:
Core Fields
<CoreFields>
CoreFields
provides mapping from secured target fields to core fields of Audit Vault Server. The data type of secured target fields specified must belong to either a SQL string
data type or a data type that can convert to a String
.
The following elements contain core fields, which are described in "Core Fields".
<Map> <Name>EVENT_TIME</Name> <MapTo>EventTimeUTC</MapTo> </Map>
EventTimeUTC
provides event time mapping information. It is a mandatory field.
EVENT_TIME
secured target fields must be of the SQL data type Timestamp
.
<Map> <Name>USER_ID</Name> <MapTo>UserName</MapTo> </Map>
UserName
represents the user who performs the action. If the mapping is not provided, Audit Data Collection still starts successfully, but every audit record will be 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> </Map>
CommandClass
contains a Transformation
field with ValueTransformation
values, from secured targets to the Audit Vault 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, such as CommandText
or CommandParam
. 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 Field
<ExtensionField> <Name>DB_ID</Name> <Name>INSTANCE</Name> <Name>PROCESS</Name> <Name>TERMINAL</Name> </ExtensionField>
The ExtensionField
is a secured target field name that must be stored as a name-value pair in the Extension field in Audit Vault Server. Secured target columns specified here should have a String
value or a value that can be converted to String
without loss of information.
See "Extension Field".
Marker Field
<MarkerField> <Name>SESSION_ID</Name> <Name>ENTRY_ID</Name> </MarkerField>
The MarkerField
contains a list of secured target field names that uniquely identify each audit record. The secured target fields specified must be of SQL data type String
or convertible to String
. MarkerField
is mandatory.
The marker field is described in "Marker Field".
End Tags
The field tags must be properly closed in order for the file to be valid. The following are examples of field end tags:
</FieldMappingInfo> </AVTableCollectorTemplate>
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:
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.
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 |
---|---|---|
|
|
core field |
|
|
core field |
|
|
core field |
|
|
core field |
|
|
core field |
|
|
core field |
|
|
core field |
|
|
core field |
|
|
core field |
|
|
core field |
|
extension field |
extension field |
|
extension field |
extension field |
|
extension field |
extension field |
|
extension field |
extension field |
|
marker field |
marker field |
|
marker field |
marker field |
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:
<!-- Invalid code <Map> <Name>USER_ID</Name> <MapTo>UserName</MapTo> </Map> <Map> <Name>OS_USER_ID</Name> <MapTo>UserName</MapTo> </Map> -->
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>
ExtensionField
s 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".
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.
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.
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.
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>
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.
<?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>
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.
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.