Audit Forwarding to SIEM

Athena writes every security-relevant action to an audit trail that you can read and query in the console. When you also need those events in a central SIEM — for long-term retention, correlation, or compliance — turn on audit forwarding and Athena will stream each event to a syslog collector as it happens. Forwarding runs in addition to the local audit log, so you keep the searchable on-box trail and gain an off-box copy at the same time.

How forwarding works#

When forwarding is enabled, every audit event Athena records is also queued for delivery to the syslog target you configure. Events are buffered and sent in batches; once the buffer reaches its configured size the batch is flushed to the collector. The buffer is also flushed when the server shuts down, so pending events are delivered on a clean stop.

Delivery is isolated from the local log. If the collector is unreachable — a dropped UDP packet, a closed TCP port, DNS trouble — the local audit trail is never affected; the forwarding failure is contained and the on-box record stays complete. Because forwarding is one-way and stream-only, it is a write path: you query and browse audit history from the local provider, not from the SIEM connection.

Turning it on#

In the console, open Settings → Logging and find the Audit Forwarding section. Tick Enable syslog forwarding, then fill in where and how to send events:

Click Save to store the settings. Both a host and the enabled toggle are required for forwarding to start — if the host is left blank, forwarding stays off. The two TLS fields appear only when Transport is set to TcpTls.

Choosing a transport#

• UDP (default) — the classic syslog transport. It is lightweight and fire-and-forget: messages are sent without a delivery guarantee, so an occasional packet can be lost under network pressure. Use it when your collector and the server share a reliable local network.
• TCP — a connected transport that gives you ordered delivery and reconnects automatically on the next send if the link drops. Prefer TCP over UDP when events cross network boundaries. Point it at the TCP syslog port your collector exposes. Events are sent in plain text.
• TcpTls — TCP wrapped in TLS 1.2 or 1.3 (RFC 5425 syslog over TLS), so audit events cannot be read or altered on the wire. Use it whenever events leave the server's own network segment, or when your security policy requires encrypted log transport. See Encrypting forwarding with TLS.

Whatever the transport, an event the collector could not receive (connection refused, link down, TLS failure) is not queued for a later resend — the forwarded copy skips it and the next event tries again. The local audit log always keeps the complete record.

Encrypting forwarding with TLS#

Audit events describe who signed in, which settings changed, and what ran on which machine — on a shared network you usually don't want them in clear text. The TcpTls transport sends every event over TLS 1.2 or TLS 1.3 using standard syslog over TLS (RFC 5425) framing — what a TLS syslog input on a collector or SIEM expects.

1. Enable a TLS syslog listener on your collector (the conventional port is 6514) and note the host name its certificate was issued for.
2. In Settings → Logging → Audit Forwarding, set Transport to TcpTls. A hint under the list confirms the connection is encrypted and that nothing is ever sent in plain text if TLS fails.
3. Set Port to the collector's TLS port — Athena keeps whatever port was saved, so a leftover 514 will not work against a TLS listener.
4. Set Syslog Host to the name on the collector's certificate (see Host name check).
5. If the collector's certificate comes from an internal CA, paste that CA into CA Certificate (PEM, optional) (see Which certificates are trusted).
6. Click Save and restart the server.

Which certificates are trusted#

Paste the CA certificate that issued the collector's certificate, not the collector's own certificate, and never a private key — the field holds a public certificate only. Athena checks the PEM when you click Save: text that does not contain a valid certificate is refused and the settings are not stored, so a typo can't silently disable forwarding at the next restart. Certificate revocation is not checked for the syslog connection.

Host name check#

Athena always verifies that the collector's certificate was issued for the value in Syslog Host. Enter the DNS name the certificate lists (for example siem.corp.example), not its IP address — unless the certificate also lists that IP address. A mismatch is treated as a TLS failure.

Skip certificate validation (lab only)#

When TLS fails — no plain-text fallback#

If the TLS connection cannot be established — an untrusted or expired certificate, a host-name mismatch, or a port that doesn't speak TLS — Athena never falls back to plain TCP. The event is not forwarded, the server log records an error beginning Syslog TLS connection to <host>:<port> failed; audit event NOT sent (no plaintext fallback) followed by the reason, and the next event tries TLS again.

The TCP connect and TLS handshake together are limited to 10 seconds. A collector that accepts the connection but never answers the TLS handshake (for example, a plain-TCP syslog port) is reported as no TLS handshake within 10 s, so a misconfigured collector can't stall the server's own audit logging or its startup.

Message formats#

Athena can emit each event in four formats. Pick the one your SIEM parses most cleanly:

Every format includes the standard syslog priority (facility × 8 + severity) so your collector can filter by severity. Athena maps its audit severities to syslog levels as follows:

A forwarded RFC 5424 event looks like this on the wire (a failed login, wrapped for readability):

<132>1 2026-07-19T14:30:00.123Z ATHENA-SRV Athena - a1b2c3d4-… \
  [athena@0 eventType="LoginFailure" eventId="a1b2c3d4-…" success="False" \
  schemaVersion="1.0" user="jsmith" src="10.0.0.42" resourceType="User" \
  resourceId="jsmith" action="Login"] Failed login attempt for user 'jsmith'

Each event carries a schema version and a unique event ID, so downstream searches and correlation rules stay stable as the product evolves.

What gets forwarded#

Forwarding uses the same event catalog as the local trail — there is one stream of audit events, written locally and (when enabled) mirrored to your SIEM. That includes logins and logout, password and role changes, agent registration and revocation, deployment and command execution, scheduled-job changes and runs, token generation, settings changes, and server start/stop, among others. See Audited events for the full list. Each event carries the actor, source IP, affected resource, action, outcome, and severity.

Delivery & buffering#

Events are flushed to the collector once the buffer reaches its configured Buffer Size (default 10), and again when the server shuts down. If you want events to arrive with less delay on a quiet server, lower the buffer size so batches flush sooner; if you would rather send fewer, larger batches, raise it. Whatever the setting, the local audit log is always written immediately — buffering only affects the pace of the forwarded copy.

Configuring forwarding through the REST API#

The same settings are available to scripts and configuration-management tools through the REST API:

PUT /api/settings/syslog
{
  "enabled": true,
  "host": "siem.corp.example",
  "port": 6514,
  "transport": "TcpTls",
  "format": "Rfc5424",
  "facility": 16,
  "bufferSize": 10,
  "tlsCaCertificatePem": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----",
  "tlsSkipCertificateValidation": false
}

As in the console, a change takes effect after the next server restart, and each changed field is recorded in the audit trail. If an environment variable or another configuration source overrides the Audit:Syslog section, the success message says so — see Configuration Override Warnings. By default only the Admin role holds settings.manage; see Permission Model.

The same keys can be set in configuration under Audit:Syslog — including Transport = TcpTls, TlsCaCertificatePem and TlsSkipCertificateValidation — see Configuration. A CA certificate supplied that way is not checked at save time: if it is malformed, the server logs an error at startup and runs with the local audit log only.

Settings Sync#

When you push the Syslog group with Settings Sync, every field travels — including the transport, the CA certificate and the skip-validation flag — and the receiving server keeps none of its own syslog values, because a fleet of servers normally forwards to the same SIEM. The receiving server applies the change at its next restart.

Troubleshooting#

• No events reaching the collector. Confirm the Enable syslog forwarding toggle is on and the Host field is not blank — both are required — and that you restarted the server after saving. On a fresh enable, generate an event (for example, sign in and out) to trigger activity.
• Events appear only in bursts. That is the buffer at work. Lower the Buffer Size to have batches flush sooner.
• Intermittent loss over UDP. UDP is fire-and-forget; switch the Transport to TCP for reliable, ordered delivery across less-reliable links.
• Collector rejects or mis-parses messages. Match the Message Format to what your SIEM expects — Cef for ArcSight, Json for ELK or Splunk HEC, Rfc3164 for legacy syslog servers, Rfc5424 for everything else — and confirm the Facility lines up with any inbound routing rule on the collector.
• Firewall. Make sure the chosen Port and transport are open from the Athena server to the collector.
• TcpTls: nothing arrives. Search the server log for Syslog TLS connection to. The reason that follows tells you what to fix:
  • an untrusted certificate or chain — paste the collector's issuing CA into CA Certificate, or install it in the server's trust store;
  • a certificate name mismatch — set Syslog Host to the name on the collector's certificate;
  • no TLS handshake within 10 s — the port is not a TLS listener (often a leftover 514), or a firewall is silently dropping the traffic.
• Save fails with a TLS CA certificate. The pasted text is not a valid PEM certificate. Copy the whole block, including the BEGIN / END lines.
• Forwarding never starts after a restart. If forwarding cannot be initialised, the server logs Failed to initialize syslog audit provider and keeps running with the local audit log only. The server log location is under Server Logging.

A change to the forwarding settings is itself recorded in the audit trail as a settings change, so you always have a record of who turned forwarding on or off and when. The local audit log remains the source of truth for querying history — see Querying the audit log.

Related#

• Audit & SIEM — the audit trail, the events it records, and how to query it.
• Configuration — server settings that are applied at startup.
• Air-Gapped Operation — running fully on-premises with no outbound calls.
• Roles & Permissions — who can view settings and the audit trail.
• Network Ports & Firewall — outbound syslog ports (514 / 6514).