Hi all,
We are testing the latest Auditd Logs integration, version 3.24.1, on an Elastic Stack running 9.3.3.
The integration now has the experimental option:
Use auditd parser (experimental)
The description sounds interesting because the parsing happens on the Elastic Agent before the event is sent to Elasticsearch, and it appears to populate additional auditd.* fields while skipping some of the normal ingest pipeline parsing.
However, when enabling the option, the agent policy fails to compile with:
Error while compiling agent template: Missing helper: "semverSatisfies"
Environment:
Elastic Stack: 9.3.3
Auditd Logs package: 3.24.1
Use auditd parser: Enabled
Result: Agent template compilation fails
With the option disabled, the integration works normally.
A few questions:
-
Is Auditd Logs 3.24.1 expected to support the auditd parser option on Elastic Agent 9.3.3, or does this feature require a newer Agent version?
-
Is the
semverSatisfieserror a known compatibility issue between this integration version and 9.3.x? -
What is the longer-term goal of the new auditd parser?
We noticed that enabling it appears to produce additional and more structured audit fields. We are particularly interested in whether this is a step toward bringing Auditd Logs closer to the event model produced by Auditd Manager.
This is relevant for us because we have customers where taking over management of the host audit configuration with Auditd Manager is not desirable or allowed. They already manage their own auditd configuration and rules, and we only want Elastic Agent to collect and normalize the resulting audit logs.
At the moment this creates a bit of a gap. Elastic provides a large set of built-in Linux detection rules, but many of them expect the event structure produced by Auditd Manager. As a result, customers using the Auditd Logs integration do not necessarily benefit from the same built-in detection content, even though the underlying Linux audit events are available.
Ideally, we would like a model where:
-
the customer keeps ownership of
/etc/audit/rules.d/and their audit policy; -
Elastic Agent collects the existing audit log;
-
Auditd Logs parses it into an event structure as close as reasonably possible to Auditd Manager;
-
the same or at least substantially more of the built-in Linux detection rules can operate on both sources.
Is that one of the objectives of this experimental parser, or is its scope mainly performance / moving parsing from the ingest pipeline to the Agent?
Also interested to hear whether there are plans to improve compatibility of the built-in Linux detection rules with Auditd Logs data in general.
Thanks!
Willem