Deployment Architecture

Distributed Search Validate Audit Events

ephemeric
Contributor

Hi,

Is it possible to validate audit events from a search head on search peers?

index=_audit splunk_server="host" | audit

And as per the docs data blocks can only be validated on the indexer itself?

Thank you.

0 Karma
1 Solution

Ayn
Legend

No, you cannot do this from a search head. Validation of audit events relies on linking events together so they form a chain where each event points to the previous event, and so on. When you issue a search from a search head, the search head is responsible for bringing all events from all search peers together and show them in whatever order you chose. When doing this, events from different search peers can and will be mixed in the search results, which results in that the search head won't be able to validate anything. The alternative would be for the search head to retrieve a bunch of extra events and hope that it has the correct certificates/keys for performing the validation, but that could very quickly get messy, especially considering that more complex searches would include commands that would cause search peers to return their results to the search head early in the search (head is an example of a command that will cause this behaviour for instance).

I agree with you that it would be elegant if the search peers could somehow validate the events before returning them to the search head, however this is as far as I know not currently possible.

View solution in original post

Ayn
Legend

No, you cannot do this from a search head. Validation of audit events relies on linking events together so they form a chain where each event points to the previous event, and so on. When you issue a search from a search head, the search head is responsible for bringing all events from all search peers together and show them in whatever order you chose. When doing this, events from different search peers can and will be mixed in the search results, which results in that the search head won't be able to validate anything. The alternative would be for the search head to retrieve a bunch of extra events and hope that it has the correct certificates/keys for performing the validation, but that could very quickly get messy, especially considering that more complex searches would include commands that would cause search peers to return their results to the search head early in the search (head is an example of a command that will cause this behaviour for instance).

I agree with you that it would be elegant if the search peers could somehow validate the events before returning them to the search head, however this is as far as I know not currently possible.

ephemeric
Contributor

Thank you, great help.

0 Karma
Got questions? Get answers!

Join the Splunk Community Slack to learn, troubleshoot, and make connections with fellow Splunk practitioners in real time!

Meet up IRL or virtually!

Join Splunk User Groups to connect and learn in-person by region or remotely by topic or industry.

Get Updates on the Splunk Community!

Persistent Queue at TcpOut — One of Splunk's Most Practical Features

Splunk introduced persistent queueing at the tcpout layer as one of the most practical resilience features in ...

Skip the Awkward Silence: Have a .conf-ersation at .conf26

Picture this. You arrive at .conf26 already having your socializing and networking plans mapped out. No ...

Rethinking Zero Trust: From Product Purchases to Logical Control Evidence

Implementing Zero Trust (ZT) across complex environments often falters at the very beginning due to a ...