Audit Splunk activity

Audit Splunk activity

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 topic outlines the composition and generation of audit events.

Note: The punct field is not available for events in the _audit index.

What's in an audit event?

• 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/dXArIdK2M97E0
Ckv6xqMurYbUVqC6YoICLjW/H113u6FDTPMBGdk29J95X1SecazMf+H1tRqfc+vcJPZH1RcQaiVCcJwRTJuXD4Z5
JidyvjVIECIdrhPSAGj7CSEhTdYx4tOEfl5yMckU=]

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.

What activity generates an audit event?

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

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.

The field that contains the status of the event is called "validity". Values can be:

• VALIDATED - no gap before this event and event signature matches
• TAMPERED - event signature does not match
• NO SIGNATURE - the signature was not found

The field that contains the gap status is called "gap". Values can be:

• TRUE - a gap was found
• FALSE - no gap was found
• N/A - no id was found

• Was this topic useful?
• Post a comment