Audit events

Audit events

With auditing enabled, Splunk logs distinct events to the audit index (index=_audit). Every interaction with Splunk -- search, configuration changes, etc -- generates an audit event. Directories monitored by file change monitoring create audit events as well. This page outlines the composition and generation of audit events.

Note: The punct field is not available for events in the _audit index because those events are signed using PKI at the time they are generated.

Audit event composition

• Timestamp:
  • date and time of the event.
• User information:
  • the user who generated the event.
  • If the event contains no user information, Splunk sets the user to whoever is currently logged in.
• Additional information:
  • available event details -- what file, success/denial, etc.
• ID (only if audit event signing is turned on):
  • a sequential number assigned to the event for detecting gaps in data.
• Hash signature:
  • PKI encrypted SHA256 hash signature, including the timestamp and ID.
• Additional attribute/value pairs specific to the type of event.

Example

The following is a sample signed audit log entry:

11-01-2007 09:23:59.581 INFO  AuditLogger - Audit:[timestamp=Thu Nov  1 09:23:59 2007, id=1, user=admin, action=splunkStarting, info=n/a][NSsJkuZZNn1dKaH3tjgxN/RbGeKaQ/dXArIdK2M97E0Ckv6xqMurYbUVqC6YoICLjW/H113u6FDTPMBGdk29J95X1SecazMf+H1tRqfc+vcJPZH1RcQaiVCcJwRTJuXD4Z5JidyvjVIECIdrhPSAGj7CSEhTdYx4tOEfl5yMckU=]

The information within the first set of brackets ([ ]) is the hashed and signed data. The string in the second set of brackets is the hash signature.

Audit event generation

Audit events are generated from monitoring:

• all files in Splunk's configuration directory $SPLUNK_HOME/etc/*
  • files are monitored for add/change/delete using the file system change monitor.
• system start and stop.
• users logging in and out.
• adding / removing a new user.
• changing a user's information (password, role, etc).
• execution of any capability in the system.
  • capabilities are listed in authorize.conf

Audit event storage

Splunk stores audit events locally in the audit index (index=_audit). Audit events are logged in the log file: $SPLUNK_HOME/var/log/splunk/audit.log.

If you have configured Splunk as a forwarder in a distributed setting, audit events are forwarded like any other event. Signing can happen on the forwarder, or on the receiving Splunk instance.

Audit event processing

The file audit.conf tells the audit processor whether or not to encrypt audit events. As audit events are generated, Splunk's auditing processor assigns a sequence number to the event and stores the event information in a SQLite database. If there is no user information specified when the event is generated, Splunk uses the currently signed user information. Finally, if audit event signing is set, Splunk hashes and encrypts the event.

Search for audit events

Search audit events in Splunk Web or in Splunk's CLI. To do this, pipe your searches to the new audit command. The audit search command is most useful if audit event signing has been configured. However, if you want to search for all audit events where audit event signing has not been configured (or to skip integrity validation) you may search the whole audit index.

• To search for all audit events, specify the _audit index:

This search returns all audit events.

• Pipe your search to the audit command:

This search returns the entire audit index, and processes the audit events it finds through the audit command. Events piped to audit show up with decorations.

Narrow your search before piping to the audit command. However, you can only narrow the time range, or constrain by a single host. This is because each host has its own ID number sequence. Since sequential IDs exist to enable detection of gaps in audit events, narrowing a search across multiple hosts causes false gap detection and decoration in the audit event trail.

• Was this topic useful?
• Post a comment