Log forwarding and notifications

What this page covers

Two things: sending audit events to an external log system as they happen, and sending alerts somewhere people will see them. The first is the operational precondition for audit integrity, and the second decides how long an event goes unnoticed.

Syslog forwarding

What you need

A syslog or SIEM collector separate from this system. Checkpoints of the audit chain anchor themselves there; while the audit data and its anchors sit on one host, “whoever holds that host tampers and smooths it over” returns to the undetectable. Retention on the collector is what carries this line.

How to set it up

Go to the log forwarding card on the Security Policies page:

1. Turn on “Enable forwarding”.
2. Fill in the host and port.
3. Choose the protocol: UDP, TCP, or TCP with TLS.
4. Over TLS you can paste a CA certificate in PEM; left empty, the system trust store is used.
5. Press “Send a test message” and confirm at the collector that it really arrived. The test message is a fixed constant and does not change with the language.
6. Save.

The forwarding format is RFC 5424, and the message body is structured JSON. TCP uses length-prefixed framing. Three kinds of event are forwarded: audit records, command alerts, and checkpoint anchoring events. An anchoring event carries the sequence number, the interval’s start and end, the row count, the interval fingerprint, the signature and signing key version, and the sealing time.

Boundaries

External syslog is an additional copy and does not replace the primary audit source inside the platform. Events go through a bounded buffer, a disconnected collector is reconnected with exponential backoff, and a full buffer drops the oldest entry and adds to a drop count that can be looked up and is never zeroed away. A forwarding failure blocks no audit write and affects no connection.

The transmission enforcement level comes from a policy key. At warn and record, saving a cleartext protocol needs a risk acknowledgment and leaves a trail; at strict refusal, a configuration without TLS cannot be saved. Tightening the policy does not interrupt forwarding already running, and marks the deviation on the settings page and in the channel inventory.

Alert notification channels

How to set it up

Go to the notification channels tab of the Alerts page and add a channel:

1. Enter a name and choose a type (webhook or slack).
2. Enter the receiving address.
3. A webhook channel can carry a secret for signing.
4. Choose the notification language (Traditional Chinese, English, or Japanese).
5. Enable it, then press Test send and confirm the receiver gets it.

The secret is never returned; left empty on an update it keeps the existing value, and clearing it is explicit. Both the address and the secret are stored under envelope encryption, and the interface shows only the protocol, the host, and the last four characters of the address.

A webhook receives JSON holding the alert itself, the rule it matched, and the session context; with a secret set, the HMAC-SHA256 signature travels in a request header. Slack receives a plain text message, with control characters escaped first.

A failed delivery retries up to three times with backoff. The delivery outcome affects neither the storage of the alert nor connections in progress.

The enforcement level for notification transport has its own policy key: at warn and record, saving a cleartext address needs a risk acknowledgment; at strict refusal, a cleartext address cannot be saved.

Email goes through a webhook: to receive alerts by email, forward them from the receiving end of a webhook.

Each notification channel has a delivery threshold: all alerts, medium and high, or high only. Alerts skipped for that channel remain in Alert records and still go to syslog. System events and test messages are sent regardless of the threshold.

What auditors can see

• Every change to the forwarding settings and the notification channels leaves a record with the person and what changed, and the secret stays out of it.
• Risk acknowledgments leave a trail recording who accepted which risk items and when.
• A failed forwarding connection and a buffer overflow each produce a named alert event.
• The purge on expiry is an audit record in itself and is forwarded as well; see Retention, purging, and observability.