Splunk® Enterprise

Admin Manual

Download manual as PDF

Splunk version 4.x reached its End of Life on October 1, 2013. Please see the migration information.
This documentation does not apply to the most recent version of Splunk. Click here for the latest version.
Download topic as PDF

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:

06-20-2012 17:22:33.452 -0700 INFO  AuditLogger - Audit:[timestamp=06-20-2012
 17:22:33.451, id=2, user=admin, action=login attempt, info=succeeded]
[GE8BVo5kj0UL8p/0VKN710JiQjIQUwBDXGpCote295NLCK8w7EsR5sCJMk0Ysge
wIGI1Ejq3ejcDXoFahNSD4VAQsHqmfnRLnpkx1VdtDp4hGgKaUYC6Y5QGs6+zUdr
cxnHTJ44jjLBBLcDEBbqz19owArHdDJ+MrVHeCgfyN6E=]

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/*
  • 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.

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:

index=_audit

This search returns all audit events.

  • Pipe your search to the audit command:

index=_audit | audit

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
PREVIOUS
Cryptographically sign audit events
  NEXT
Configure event hashing

This documentation applies to the following versions of Splunk® Enterprise: 4.3, 4.3.1, 4.3.2, 4.3.3, 4.3.4, 4.3.5, 4.3.6, 4.3.7


Was this documentation topic helpful?

Enter your email address, and someone from the documentation team will respond to you:

Please provide your comments here. Ask a question or make a suggestion.

You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters