Auditd turns the Linux Audit subsystem into a managed, first-class feature of the Artica appliance. It has two complementary halves that share a single Enable switch:
- Audit service & CIS rules — installs, supervises and hardens the Linux Audit daemon (
auditd) and loads a best-practice, CIS-aligned rule set so the kernel records the security-relevant events an auditor expects (identity changes, privilege escalation, logins, kernel-module loads, time and network changes, file-permission changes, and more).- Monitoring & SIEM forwarding — a built-in collector reads the audit log in real time, normalises every record into a structured event, classifies it by category and severity, and forwards the events you care about to external systems (a local JSON file, an HTTP/HTTPS endpoint, or a syslog server), governed by policies, exclusions and routes.
The feature lives under Your system → Security → Auditd.
¶ Why use it — Benefits
- Compliance out of the box.
Installing the feature loads a CIS-aligned audit rule set automatically, so a freshly enabled appliance already records the events required by the CIS Debian benchmark (controls 4.1.3 – 4.1.16) instead of an empty rule list.
- Real-time security telemetry.
Events are captured, normalised and classified the moment they are written — you see identity changes, sudo usage, kernel-module loads and failed accesses live, without tailing raw logs.
- Native SIEM integration.
Forward normalised events straight to Splunk, an ELK/Wazuh stack, QRadar or any syslog collector — over plain syslog, syslog-over-TLS (RFC 5424) or HTTPS JSON — with no external agent to install.
- Signal, not noise.
Policies pick exactly which events leave the appliance; exclusions drop or downgrade the chatty ones; routes fan high-severity events to a dedicated destination. Your SIEM receives what matters.
- Delivery you can trust.
A persistent queue with exponential back-off retries transient failures and parks permanently-failing events in a dead-letter queue you can inspect and replay — events are never silently lost.
- Operable and observable.
Live counters, per-category and per-severity statistics, a searchable event stream and a queue console make the whole pipeline transparent to the administrator.
¶ Use cases
- Regulatory audit trail.
PCI-DSS, ISO 27001, HIPAA and ANSSI all require host-level auditing of privileged actions and identity changes. This feature provides the rules and the delivery to a central store.
- Centralised SIEM collection.
Ship appliance audit events to the same SIEM as the rest of the estate, in a structured, already-categorised form, so correlation rules and dashboards work immediately.
- Insider-threat & change detection.
Alert on privilege escalation, new user creation, sudoers edits or kernel-module loads on the gateway itself.
- Tamper-evident forensics.
The audit log records who did what and when at the syscall level — invaluable when reconstructing an incident on the appliance.
- Compliance evidence for the appliance itself.
Pair it with the CIS Benchmark feature: the benchmark scores your posture, auditd proves that security-relevant activity is being recorded and shipped.
¶ The tabs at a glance
The page is organised as a set of tabs. Each has its own detailed guide:
- Status — service lifecycle: install, enable, start/stop, version, and the count of loaded CIS rules.
- Dashboard — monitoring & forwarding state and live event counters, with one-click toggles.
- Policies — decide which events are forwarded and to which destinations.
- Exclusions — drop or downgrade noisy or irrelevant events before forwarding.
- Destinations — where events are sent: local file, HTTP/HTTPS endpoint or syslog server.
- Routes — send events matching a condition to a specific destination.
- Events — the live, searchable stream of normalised audit events.
- Queue — forwarding queue, retries and the dead-letter queue.
- Statistics — event breakdown by category and by severity.
¶ How the pipeline works
- Capture. The Linux Audit daemon writes records to
/var/log/audit/audit.logaccording to the loaded rules. - Collect. A built-in collector tails the log with an inode+offset cursor, so it survives log rotation, truncation and a daemon restart without losing or re-reading events.
- Normalise. Multi-line audit records are correlated into a single structured event with a stable hash, resolved user, executable, path and arguments. (The parser understands the ENRICHED log format used by modern auditd.)
- Classify. Every event is assigned a category (authentication, account management, privilege escalation, kernel module, network change, audit configuration, …) and a severity from 0 to 5.
- Evaluate. Exclusions are applied first, then policies and routes decide the destinations. Only events that match leave the appliance.
- Deliver. Selected events are enqueued and sent to each destination. Failures are retried with exponential back-off; permanently-failing events land in the dead-letter queue for inspection and replay.
¶ Getting started
- Open
Your system → Security → Auditd. - On the Status tab, click Enable. The appliance installs the audit daemon (if needed), loads the CIS best-practice rule set and starts the service.
- On the Dashboard tab, enable Monitoring to start the collector, then Forwarding once you have defined at least one destination.
- On the Destinations tab, add your SIEM (syslog/TLS or HTTPS JSON) and use Test to confirm connectivity.
- On the Policies tab, create a policy selecting the events to forward and pointing at your destination.