Enterprise
SIEM Forwarding
Forward audit events to your SIEM platform in near-real-time with at-least-once delivery guarantee. MemorySync pushes events in batches, retries on failure with exponential backoff, and tracks every delivery attempt for full observability.
How SIEM Forwarding Works
When SIEM forwarding is enabled, MemorySync continuously reads new audit events and pushes them to your configured destinations. The pipeline works as follows:
- 1Event capture. Every mutating action writes an audit log entry to the primary store (covered in the Audit Logs page).
- 2Batch collection. New events since the last successful delivery are grouped into batches for efficient delivery to your destination.
- 3Format & deliver. Each batch is formatted to match the destination’s expected schema (Splunk HEC, Datadog Logs API, or webhook JSON) and sent via HTTPS.
- 4Track & retry. Every delivery attempt is logged. Failures trigger automatic retries with exponential backoff. Persistent failures trigger circuit breaker protection.
Delivery guarantee
MemorySync provides at-least-once delivery. In rare cases (e.g., network timeout after the destination received the batch), a batch may be delivered twice. Each batch carries a stable idempotency identifier so your SIEM can safely ignore the duplicate.
Supported Destinations
| Destination | Authentication | Payload Format |
|---|---|---|
| Splunk | HEC token (Authorization header) | HTTP Event Collector format with newline-delimited JSON events. Source type and index are configurable on the destination. |
| Datadog | DD-API-KEY header | Datadog Logs API format. Each event becomes a structured log with environment, service, and event-type tags plus a severity-to-status mapping. |
| Custom Webhook | HMAC signature | JSON payload containing the event batch and a count, signed with a per-destination secret so your endpoint can verify authenticity. |
For Splunk and Datadog, MemorySync formats events to match each platform’s native schema. For Custom Webhooks, the payload is a standardized JSON format that any HTTPS endpoint can consume.
Setup Guide
- 1Go to Settings → Audit Logs → SIEM Forwarding. Make sure the master SIEM forwarding toggle is on (under Retention settings).
- 2Click Add Destination. Select your provider (Splunk, Datadog, or Custom Webhook).
- 3Enter the endpoint URL and credentials. For Splunk: HEC token. For Datadog: API key. For webhooks: HMAC shared secret.
- 4Send a test event. MemorySync sends a synthetic
connection.testevent to validate the endpoint, credentials, and response. The test result shows the HTTP status code, response body, and latency. - 5Enable the destination. Events will begin flowing within seconds.
URL validation
MemorySync validates destination URLs before saving. Private IP addresses, localhost, and non-HTTPS URLs are rejected for safety (HTTP is allowed only in development mode only). This prevents SSRF attacks.
Event Payload Format
Regardless of destination, every forwarded event contains the same core fields:
| Field | Description |
|---|---|
event_id | Globally unique event identifier. |
timestamp | ISO 8601 UTC timestamp of the event. |
tenant_id | Organization’s tenant identifier for multi-tenant filtering. |
category | Event category (auth, data, admin, security, etc.). |
action | Human-readable action name. |
severity | Event severity: info, warning, or critical. |
actor | Object with id, email, name, and type (jwt, api_key, anonymous). |
resource | Object with type, id, and label of the affected resource. |
ip_address | Client IP address. |
user_agent | Client user agent string. |
source | Origin of the event: api, dashboard, system, or test. |
success | Boolean indicating whether the action succeeded. |
metadata | Additional context (HTTP method, path, duration, auth method). |
Splunk and Datadog events include the platform-specific metadata each system expects (such as source type, tags, and severity status), and webhook payloads include a schema version field so your endpoint can evolve safely over time.
Reliability & Delivery
SIEM forwarding is built for production reliability with multiple layers of protection against failures:
| Feature | Details |
|---|---|
| Retry with backoff | Failed deliveries are retried with exponential backoff and jitter so concurrent retries do not pile up on the same endpoint. |
| Smart retry logic | Retries are performed on transient failures (5xx server errors and 429 rate limits). Permanent failures (4xx auth or validation errors) fail immediately without retry. |
| Circuit breaker | Per-endpoint circuit breaker that fast-fails when a destination is persistently unhealthy and probes for recovery automatically. |
| Concurrency control | Bounded concurrency per endpoint so a high-volume burst cannot overwhelm your SIEM. |
| Dead-letter tracking | After persistent failures, the forwarder is marked as dead-lettered and failed batches are recorded in delivery logs for manual replay. |
| Idempotency | Each batch includes a stable idempotency identifier so your SIEM can safely deduplicate if the same batch is delivered twice. |
| Request timeout | 10 seconds per request (configurable). Prevents hung connections from blocking the pipeline. |
Delivery Monitoring
Every delivery attempt — successful or failed — is recorded in the delivery log. This gives you complete visibility into the forwarding pipeline.
| Field | Description |
|---|---|
correlation_id | Unique ID for this batch delivery. Use it to trace a batch from MemorySync to your SIEM. |
event_count | Number of events in this batch. |
first_event_id / last_event_id | ID range of events in the batch. Useful for verifying completeness in your SIEM. |
success | Whether the delivery succeeded. |
status_code | HTTP response code from the destination (200, 401, 429, 500, etc.). |
duration_ms | Round-trip latency in milliseconds. |
attempt_number | Which retry attempt this was (1 = first try, up to 5). |
is_dead_letter | Whether this batch was dead-lettered due to persistent failures. |
error_message | The error details if delivery failed (truncated to 500 chars). |
Access delivery logs in Settings → Audit Logs → SIEM → Delivery History for each configured destination.
Troubleshooting
- Datadog rejecting events. Verify the API key matches the correct Datadog region (US vs. EU). The DD-API-KEY header is region-specific. Check the response body in delivery logs for the exact error.
- Splunk HEC token expired. Generate a new HEC token in Splunk and update the credential in MemorySync. The forwarder picks up the new token without restarting.
- Custom webhook returning 401. Verify the HMAC shared secret configured in MemorySync matches what your endpoint expects. The signature is sent in a dedicated header so your endpoint can verify it.
- Forwarder stuck in “dead letter”. After persistent failures, the forwarder pauses. Fix the underlying issue (credentials, endpoint URL, firewall), then reset the forwarder in Settings → SIEM.
- Events arriving late. Check the destination’s health status in the delivery log. While the circuit breaker is open, MemorySync periodically probes the destination and resumes delivery once it recovers.
- Rate-limited (429). When your SIEM returns 429, MemorySync pauses forwarding for that destination until the next run cycle. Events are not lost — they are picked up in the next batch. Consider increasing your SIEM’s rate limit if this happens frequently.