SIEM / XDR Forwarding
What this screen is for
SIEM / XDR Forwarding is where you declare the security tooling that receives the platform's audit events. It is one of the three cards under Observability & Audit that hold no configuration value: it administers destinations, each one a named record with a wire format, a transport, filters, a credential and an on/off state.
A separate internal service does the delivering. It consumes the platform's unified audit-event stream in its own consumer group, so forwarding never competes with the audit trail's own consumer and a failing destination cannot slow it down. That service is internal-only and publishes no host port.
Two planes exist, in one list. A deployment destination is inherited by every tenant. A tenant destination belongs to one tenant and is added to what it inherits. A tenant cannot remove an inherited deployment destination: every deployment destination receives every tenant's events, and a tenant's effective set is the deployment destinations plus its own.
The Per tenant tab behaves unlike its siblings. Standing on the platform plane there is no tenant roster here and no picker: a tenant's own destination is reached from inside that tenant's own operating context, and the tab says so rather than showing you an empty plane.
What must exist first
This is a platform screen, reached in the platform context and served only to the platform tenant. The permissions are this subsystem's own, and holding platform-configuration read does not carry them:
- The permission to read forwarding destinations, which lists the deployment plane.
- The permission to manage forwarding destinations, for creating, editing, enabling, disabling or deleting one on the deployment plane.
- For a tenant's own destination, the tenant-plane read and override permissions instead. They are different permissions, not the same ones applied to a tenant.
Decisions you make here
Declaring a destination
Add destination starts with a sink tile, and the sink then fixes the shape of the form. Four are offered: Syslog, Splunk HEC, Microsoft Sentinel and a webhook signed as Standard Webhooks. Independently, the wire format is CEF or OCSF — the format decides what the record looks like, the sink decides how it travels, and the two are chosen separately.
A name is unique within its plane, so a tenant may reuse a deployment destination's name. Each HTTP sink takes an endpoint; Syslog takes a host and a port and a transport choice of UDP, TCP or TLS over TCP.
Credentials, and the Syslog client key
Three sinks carry a write-only credential: a HEC token, a Sentinel client secret, or a webhook signing secret of at least 32 characters. The platform seals it and returns a mask on every read, so the console never holds a copy.
After a webhook secret is saved, the console shows its whsec_ form once, for your receiver's Standard Webhooks library; copy it then. Leaving the field empty on an edit means unchanged; typing a real value rotates it. A deployment destination's credential is sealed under the deployment key and a tenant's under that tenant's own key.
Syslog takes a credential only for mutual TLS. On TLS over TCP, a collector that requires a client certificate gets one: paste the certificate chain, leaf first, and its private key, unencrypted PEM. The key is the destination's only credential: sealed, never shown again, and replaced only by pasting a new one; the screen shows its public-key fingerprint instead.
A renewed certificate for the same key is saved without the key, while changing the host, the port or the trust anchors needs the key again, and the screen says so before you save. Saving the destination on UDP or plain TCP removes the certificate and its key.
Every sink, Syslog included, may also carry trust material: up to five PEM-encoded certificate authorities, which are public material, stored and returned unmasked, and carry no password; left empty, the destination keeps the default trust.
Filtering — and what the default actually is
Every destination forwards every event by default, across all four planes, including the authentication plane and events that carry personal data. The filters are an exclusion mechanism and nothing else, so leaving them empty is a decision and not an omission.
Four filters compose. A minimum severity drops anything below the floor. An event-type allow list, when non-empty, admits only matching types. An event-type deny list drops matching types. A key-id allow list, when non-empty, admits only events referencing one of those keys — including an attempt that was denied against a watched key. An event filtered out for one destination still reaches every other destination that admits it.
A failed or refused operation is rated at least Medium, whatever its event type, so a Medium floor still delivers every refusal while dropping routine successes.
Event-type matching accepts a full type, a plane token, or a prefix. Every token is tried as an exact match and then as a dot-prefix, whether or not you wrote a trailing wildcard, so auth.login and auth.login.* behave identically here.
When a change reaches the forwarder
The forwarder never reads the destinations table. Saving one re-projects the resolved effective list into a signed, permanent cache entry and announces it on a channel the forwarder subscribes to, which is what makes a change take effect without a restart. A deployment write re-projects the deployment set and only the tenants actually affected; a tenant write re-projects that tenant alone.
What happens when a destination is unreachable
Nothing is dropped, and that is the contract. A retryable failure is retried up to four attempts in total, with a backoff that starts at half a second and doubles up to a ceiling of thirty seconds. When the attempts are exhausted — or the failure is permanent — the event and the destination are written to a dead-letter topic with a confirmed, blocking send, and a signed audit event records the delivery failure so the trail itself carries the evidence.
If even that write cannot be confirmed, or the destination is saturated with work, the event is not acknowledged and is redelivered later rather than lost. Ordering is preserved and the offset never advances past a destination that has not been durably handled.
Reading the Health and DLQ views, accurately
The Health view lists each deployment destination and its configured state, active or disabled. It is not live delivery telemetry: latency and error rate are not measured here yet, and the view says so. The DLQ view explains the dead-letter behaviour and does not show a live depth. Neither view is evidence that delivery is currently succeeding — for that, read the audit trail.
There is no test action on this surface.
How it relates to other screens
This surface sits inside the Observability & Audit group, beside the two other subsystems that administer records rather than values:
The events forwarded here are the same ones the audit surfaces query, and where they go is drawn on the integration map.