Audit events

Audit events

Audit events are generated for every interaction with Splunk. When auditing is enabled, searches, configuration changes, and file system modifications all get logged into Splunk's audit index. This page outlines the composition and generation of audit events.

Audit event composition

• Timestamp:
  • date and time of the event.
• User information:
  • the user who generated the event.
  • If no user information is present in the event, Splunk's auditing will set the user information 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 of the data including the timestamp and ID.
• Additional attribute/value pairs specific to the type of event.

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 data which is hashed and signed. The string in the second set of brackets is the hash signature.

How audit events are generated

Audit events are generated from monitoring:

• all files in Spunk's configuration directory $SPLUNK_HOME/etc/*
  • files are monitored for add/change/delete using the FSChangeMonitor.
• system start and stop.
• 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 part of the Splunk:preview:AboutRoles:latest.

How audit events are stored

In a single stand-alone instance of Splunk, audit events are stored locally in a special audit index (index=audit), and are logged in the log file: $SPLUNK_HOME/var/log/splunk/audit.log.

When Splunk is configured as a forwarder, audit events are forwarded like any other event. Signing can happen on the forwarder, or on the receiving Splunk instance.

How audit events are processed

The file Splunk:preview:Auditconf:latest 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 an SQLite database. If there is no user information specified when the event is generated, the currently signed user information is used for that event. At this point, if audit event signing is set, the audit event is hashed and encrypted.

• Was this topic useful?
• Post a comment