SIEM Integration — All Connectors

Arbitex supports 7 SIEM connectors for forwarding audit events from the platform to your security information and event management system. This guide covers configuration, authentication, event format, and delivery mechanics for each connector.

Source: backend/app/services/siem/

Choosing a delivery path

Arbitex can forward audit events via two independent delivery paths:

Factor	Platform connectors	Outpost direct sink
Deployment	Cloud (SaaS) or Hybrid	Hybrid Outpost only
Event format	OCSF v1.1 (structured, SIEM-native)	Raw JSON (Arbitex native)
Air-gap compatible	No	Yes
Data residency	Events transit Arbitex Cloud	Events never leave your network
Configuration	Environment variables on the Platform	Environment variables on the Outpost
Connectors	Splunk HEC, Sentinel, Elastic, Datadog, Sumo Logic	Splunk HEC, syslog (RFC 5424)
Batching	Up to 100 events / 5 seconds	Ring buffer, drain loop
Retry + dead letter	Exponential backoff, JSONL dead letter	Dead letter file at configured path

Use Platform connectors when your Outpost can reach Arbitex Cloud, you want OCSF-formatted events (no custom parsing), and you need one of the five supported connectors.

Use the Outpost direct sink when your security policy prohibits audit data from transiting Arbitex Cloud, you are operating in air-gapped mode, or you need sub-second latency between event generation and SIEM ingestion.

Both paths can run simultaneously. The Platform relay delivers OCSF-formatted events; the Outpost direct sink delivers raw JSON. Use separate indexes or source types to avoid schema conflicts.

Overview

All platform SIEM connectors:

Operate on the server side — events are forwarded from the Arbitex Platform, not the Outpost
Emit events in OCSF v1.1 format by default (connector-specific envelopes vary)
Batch up to 100 events per delivery with a maximum batch interval of 5 seconds
Retry failed deliveries with exponential backoff (initial 1s, max 300s, 5 attempts)
Write undeliverable events to a JSONL dead letter file at SIEM_DEAD_LETTER_PATH

1. Splunk HEC

Source: backend/app/services/siem/splunk.py

Splunk HTTP Event Collector (HEC) is the primary integration path for Splunk Cloud and Splunk Enterprise.

Configuration

Environment variable	Required	Description
`SPLUNK_HEC_URL`	Yes	HEC endpoint. e.g. `https://splunk.corp.example.com:8088/services/collector/event`
`SPLUNK_HEC_TOKEN`	Yes	HEC authentication token
`SPLUNK_HEC_INDEX`	No	Target index. Default: `arbitex`
`SPLUNK_HEC_SOURCE`	No	`source` field value. Default: `arbitex-platform`
`SPLUNK_HEC_SOURCETYPE`	No	`sourcetype` field value. Default: `arbitex:audit`
`SPLUNK_HEC_TLS_VERIFY`	No	Verify TLS certificate. Default: `true`. Set `false` for self-signed certs (not recommended in production).

Authentication

Bearer token via Authorization: Splunk <token> header. The token is created in Splunk under Settings > Data Inputs > HTTP Event Collector.

Event format

Each delivery is a standard HEC JSON batch:

{
  "time": 1741824000.123,
  "host": "platform.arbitex.ai",
  "source": "arbitex-platform",
  "sourcetype": "arbitex:audit",
  "index": "arbitex",
  "event": {
    "class_uid": 6003,
    "category_uid": 6,
    "activity_id": 1,
    "time": 1741824000123,
    "severity_id": 1,
    "actor": {
      "user": { "uid": "user_abc", "email_addr": "[email protected]" }
    },
    "api": {
      "request": { "uid": "req_xyz" },
      "operation": "chat_completion"
    },
    "metadata": {
      "version": "1.1.0",
      "product": { "name": "Arbitex", "vendor_name": "Arbitex" }
    }
  }
}

Multiple events are sent as newline-delimited JSON objects in a single HTTP POST to the HEC endpoint.

Delivery mechanism

HTTP POST with Content-Type: application/json. Batches of up to 100 events. TLS 1.2+ required.

2. Microsoft Sentinel (DCR API)

Source: backend/app/services/siem/sentinel.py

Microsoft Sentinel integration uses the Data Collection Rules (DCR) API (Logs Ingestion API), which is the current Sentinel ingestion method for custom tables.

Configuration

Environment variable	Required	Description
`SENTINEL_TENANT_ID`	Yes	Azure AD tenant ID
`SENTINEL_CLIENT_ID`	Yes	App registration client ID
`SENTINEL_CLIENT_SECRET`	Yes	App registration client secret
`SENTINEL_DCR_ENDPOINT`	Yes	Data collection endpoint URL (from DCR configuration)
`SENTINEL_DCR_RULE_ID`	Yes	Data collection rule immutable ID (from DCR configuration)
`SENTINEL_DCR_STREAM_NAME`	Yes	Custom stream name in DCR (e.g., `Custom-ArbitexAudit_CL`)

Authentication

OAuth 2.0 client credentials flow against https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token. Scope: https://monitor.azure.com/.default. Access tokens are cached and refreshed 5 minutes before expiry.

The app registration requires the Monitoring Metrics Publisher role on the Data Collection Endpoint resource.

Event format

Events are uploaded as a JSON array matching the custom table schema. The connector maps OCSF fields to the DCR stream schema:

[
  {
    "TimeGenerated": "2026-03-13T00:00:00.123Z",
    "EventId": "req_xyz",
    "UserId": "user_abc",
    "UserEmail": "[email protected]",
    "Operation": "chat_completion",
    "ModelId": "gpt-4o",
    "PolicyAction": "allow",
    "DlpLabels": "[]",
    "TokensInput": 512,
    "TokensOutput": 256,
    "SeverityId": 1,
    "RawOCSF": "{...}"
  }
]

RawOCSF contains the full OCSF v1.1 event as a JSON string for use in Sentinel analytics rules that need the complete event.

Delivery mechanism

HTTP POST to the DCR endpoint at {endpoint}/dataCollectionRules/{rule_id}/streams/{stream_name}?api-version=2023-01-01. Maximum payload: 1 MB per batch. Batches exceeding 1 MB are split automatically.

3. Elastic (Bulk API)

Source: backend/app/services/siem/elastic.py

Elastic integration uses the Elasticsearch Bulk API for high-throughput ingestion to Elastic Cloud or self-hosted Elasticsearch.

Configuration

Environment variable	Required	Description
`ELASTIC_URL`	Yes	Elasticsearch base URL. e.g. `https://my-cluster.es.io:9243`
`ELASTIC_API_KEY`	Yes	Base64-encoded Elasticsearch API key (`id:api_key` format)
`ELASTIC_INDEX`	No	Target index or data stream name. Default: `arbitex-audit`
`ELASTIC_PIPELINE`	No	Ingest pipeline to apply. Optional.
`ELASTIC_TLS_VERIFY`	No	Verify TLS. Default: `true`.

Authentication

Authorization: ApiKey <base64(id:api_key)> header. Create the API key in Kibana under Stack Management > API Keys with index privilege on the target index.

Event format

Bulk API format with index action and OCSF event body:

{ "index": { "_index": "arbitex-audit" } }
{ "class_uid": 6003, "time": 1741824000123, "actor": {...}, ... }
{ "index": { "_index": "arbitex-audit" } }
{ ... }

Each batch is a newline-delimited bulk request body. The @timestamp field is added automatically from the OCSF time field (Unix milliseconds converted to ISO 8601).

Delivery mechanism

HTTP POST to {ELASTIC_URL}/_bulk. Content-Type: application/x-ndjson. Batch size: up to 100 events or 5 MB, whichever is smaller. The connector checks the errors field in the Bulk API response and routes failed documents to the dead letter file.

4. Datadog (Logs Intake v2)

Source: backend/app/services/siem/datadog.py

Datadog integration uses the Logs Intake v2 API (/api/v2/logs).

Configuration

Environment variable	Required	Description
`DATADOG_API_KEY`	Yes	Datadog API key
`DATADOG_SITE`	No	Datadog site. Default: `datadoghq.com`. Options: `datadoghq.com`, `us3.datadoghq.com`, `us5.datadoghq.com`, `datadoghq.eu`, `ap1.datadoghq.com`
`DATADOG_SERVICE`	No	`service` tag. Default: `arbitex`
`DATADOG_SOURCE`	No	`ddsource` tag. Default: `arbitex-audit`
`DATADOG_TAGS`	No	Comma-separated key:value tags. e.g. `env:production,team:security`

Authentication

DD-API-KEY: <api_key> header. The API key is created in Datadog under Organization Settings > API Keys.

Event format

Array of Datadog log objects:

[
  {
    "ddsource": "arbitex-audit",
    "ddtags": "env:production,service:arbitex",
    "hostname": "platform.arbitex.ai",
    "service": "arbitex",
    "message": "{\"class_uid\":6003,\"time\":1741824000123,\"actor\":{...}}"
  }
]

The message field contains the full OCSF event as a JSON string. Datadog Log Management will parse it as JSON when a JSON parsing processor is configured in a Datadog pipeline.

Delivery mechanism

HTTP POST to https://http-intake.logs.{DATADOG_SITE}/api/v2/logs. Content-Type: application/json. Maximum payload: 5 MB. Maximum 1000 log entries per batch (Datadog limit). The connector respects the 429 Too Many Requests response and applies backoff.

5. Sumo Logic (HTTP Source)

Source: backend/app/services/siem/sumo.py

Sumo Logic integration uses an HTTP Source (HTTP Logs & Metrics Collector).

Configuration

Environment variable	Required	Description
`SUMO_HTTP_SOURCE_URL`	Yes	HTTP Source URL from Sumo Logic. e.g. `https://endpoint.collection.sumologic.com/receiver/v1/http/<token>`
`SUMO_CATEGORY`	No	Source category override. Default: `arbitex/audit`
`SUMO_HOST`	No	Source host override. Default: `platform.arbitex.ai`

Authentication

The HTTP Source URL contains the authentication token embedded in the path. No additional headers required. The URL is generated when you create the HTTP Source in Sumo Logic and acts as the credential.

Event format

Newline-delimited OCSF JSON events. Sumo Logic parses each newline as a separate log message:

{"class_uid":6003,"time":1741824000123,"actor":{"user":{"uid":"user_abc"}},...}
{"class_uid":6003,"time":1741824000456,"actor":{"user":{"uid":"user_def"}},...}

Delivery mechanism

HTTP POST to the HTTP Source URL. Content-Type: application/x-www-form-urlencoded is not used — the connector sends application/json with newline-delimited JSON. The X-Sumo-Category and X-Sumo-Host headers are set from the configuration. Maximum payload: 1 MB per request.

6. IBM QRadar (CEF/syslog)

Source: backend/app/services/siem/qradar.py

IBM QRadar integration uses CEF (Common Event Format) over syslog (RFC 5424). This is the native QRadar log source protocol for custom event sources.

Configuration

Environment variable	Required	Description
`QRADAR_SYSLOG_HOST`	Yes	QRadar Console or Event Collector IP/hostname
`QRADAR_SYSLOG_PORT`	No	Syslog port. Default: `514` for UDP, `6514` for TLS
`QRADAR_SYSLOG_PROTOCOL`	No	Transport: `udp`, `tcp`, or `tls`. Default: `tcp`
`QRADAR_CEF_DEVICE_VENDOR`	No	CEF DeviceVendor. Default: `Arbitex`
`QRADAR_CEF_DEVICE_PRODUCT`	No	CEF DeviceProduct. Default: `ArbitexPlatform`
`QRADAR_CEF_DEVICE_VERSION`	No	CEF DeviceVersion. Default: `1.0`
`QRADAR_TLS_CA_BUNDLE`	No	Path to CA bundle for TLS syslog. Required when `QRADAR_SYSLOG_PROTOCOL=tls`.

Authentication

No application-level authentication for UDP/TCP syslog. For TLS, mutual TLS is used when QRADAR_TLS_CA_BUNDLE is configured; otherwise, server-only TLS certificate validation is performed.

Event format

CEF over RFC 5424 syslog. Each event is a syslog message with a CEF-formatted message body:

<134>1 2026-03-13T00:00:00.123Z platform.arbitex.ai ArbitexPlatform - req_xyz - CEF:0|Arbitex|ArbitexPlatform|1.0|6003|chat_completion|3|rt=1741824000123 [email protected] duid=user_abc act=allow model=gpt-4o tokenIn=512 tokenOut=256 cs1Label=PolicyAction cs1=allow cs2Label=DlpLabels cs2= cs3Label=GroupIds cs3=finance-team

CEF extension field mapping:

CEF Extension Key	OCSF / Arbitex field
`rt`	`time` (Unix ms)
`suser`	`actor.user.email_addr`
`duid`	`actor.user.uid`
`act`	Policy action (allow/block/redact/warn)
`model`	Model identifier
`tokenIn`	Input token count
`tokenOut`	Output token count
`cs1` / `cs1Label`	Policy action (labeled)
`cs2` / `cs2Label`	DLP labels detected (comma-separated)
`cs3` / `cs3Label`	User group IDs (comma-separated)

Delivery mechanism

Syslog over TCP (default), UDP, or TLS. Events are sent individually — CEF/syslog does not batch natively. The connector maintains a persistent TCP/TLS connection and reconnects on failure with exponential backoff. UDP has no delivery confirmation.

QRadar log source setup

In QRadar, create a Universal DSM log source pointing to the Arbitex Platform’s egress IP:

Navigate to Admin > Data Sources > Log Sources > Add.
Set Log Source Type to Universal DSM.
Set Protocol Configuration to Syslog.
Set the IP to the Arbitex Platform egress IP.
Apply the Arbitex DSM extension (available from the QRadar app exchange) for normalized parsing.

7. Cortex XSIAM (HEC + XSIAM envelope)

Source: backend/app/services/siem/xsiam.py

Palo Alto Cortex XSIAM integration uses the XSIAM HTTP Event Collector endpoint, which wraps standard HEC with an XSIAM-specific envelope for automated playbook triggering and XDR correlation.

Configuration

Environment variable	Required	Description
`XSIAM_URL`	Yes	XSIAM instance URL. e.g. `https://api-tenant.xsiam.paloaltonetworks.com`
`XSIAM_API_KEY`	Yes	XSIAM API key
`XSIAM_API_KEY_ID`	Yes	XSIAM API key ID (numeric)
`XSIAM_LOG_TYPE`	No	Log type identifier. Default: `arbitex_audit`
`XSIAM_DATASET`	No	XSIAM dataset name for routing. Default: `arbitex_audit_raw`

Authentication

x-xdr-auth-id: <api_key_id> and x-xdr-nonce: <nonce> and x-xdr-hmac-sha256: <hmac> headers. The connector computes the HMAC-SHA256 signature over {api_key_id}{nonce}{api_key} with the API key as the key, matching the Cortex XSIAM authentication scheme.

Event format

XSIAM HEC format with envelope fields for XSIAM routing:

{
  "events": [
    {
      "_time": "2026-03-13T00:00:00.123Z",
      "_vendor": "Arbitex",
      "_product": "ArbitexPlatform",
      "_dataset": "arbitex_audit_raw",
      "log_type": "arbitex_audit",
      "event_id": "req_xyz",
      "user_id": "user_abc",
      "user_email": "[email protected]",
      "operation": "chat_completion",
      "model_id": "gpt-4o",
      "policy_action": "allow",
      "dlp_labels": [],
      "tokens_input": 512,
      "tokens_output": 256,
      "severity": "informational",
      "raw_ocsf": "{...}"
    }
  ]
}

The _vendor, _product, _dataset, and log_type fields are used by XSIAM for automatic data routing and normalized schema mapping. raw_ocsf contains the full OCSF v1.1 event for use in XSIAM XQL queries.

Delivery mechanism

HTTP POST to {XSIAM_URL}/logs/v1/event. Content-Type: application/json. Batches of up to 100 events. The XSIAM endpoint returns a 202 Accepted for asynchronous ingestion. The connector treats non-2xx responses as failures and applies exponential backoff.

Dead letter handling

When an event cannot be delivered after all retries, it is written to the dead letter file:

SIEM_DEAD_LETTER_PATH=/var/log/arbitex/siem-dead-letter.jsonl

Each line is a JSONL record:

{
  "timestamp": "2026-03-13T00:00:00Z",
  "connector": "splunk",
  "error": "Connection refused",
  "event": { ... }
}

Replay dead letter events by posting them to the Platform’s dead letter replay endpoint:

POST /api/v1/admin/siem/replay-dead-letter

Connector comparison

Connector	Auth method	Event format	Delivery	Batching
Splunk HEC	Bearer token	HEC JSON / OCSF	HTTP POST	100 events / 5s
Microsoft Sentinel	OAuth 2.0 client creds	DCR table schema + raw OCSF	HTTP POST	100 events / 1 MB
Elastic	API Key	Bulk API ndjson / OCSF	HTTP POST	100 events / 5 MB
Datadog	API Key header	Log objects / OCSF in message	HTTP POST	100 events / 5 MB
Sumo Logic	Token in URL	ndjson / OCSF	HTTP POST	100 events / 1 MB
IBM QRadar	mTLS / none	CEF over syslog	TCP/UDP/TLS	1 event per message
Cortex XSIAM	HMAC-SHA256	XSIAM HEC + OCSF	HTTP POST	100 events

Outpost direct sink — Splunk HEC

The Outpost direct sink delivers events from the Outpost process directly to Splunk HEC without routing through Arbitex Cloud.

SIEM_DIRECT_ENABLED=true
SIEM_DIRECT_TYPE=splunk_hec
SIEM_DIRECT_URL=https://splunk.corp.example.com:8088
SIEM_DIRECT_TOKEN=<YOUR_SIEM_TOKEN>
SIEM_DIRECT_BUFFER_CAPACITY=10000
SIEM_DIRECT_DEAD_LETTER_PATH=/var/log/arbitex/siem-dead-letter.jsonl

The sink appends /services/collector/event to SIEM_DIRECT_URL automatically. Each event is a single HTTP POST with this body:

{
  "event": { "...audit event fields..." },
  "time": 1741478400.123,
  "sourcetype": "arbitex:audit",
  "source": "arbitex-outpost"
}

Events delivered via the direct sink are raw JSON, not OCSF-formatted. If you are ingesting into the same Splunk index as Platform SIEM events, use a distinct source type or index to avoid schema conflicts.

Outpost direct sink — syslog (RFC 5424)

The Outpost can deliver audit events over syslog to any RFC 5424-compatible receiver.

Configuration

SIEM_DIRECT_ENABLED=true
SIEM_DIRECT_TYPE=syslog
SIEM_DIRECT_URL=udp://syslog.corp.example.com:514
SIEM_DIRECT_DEAD_LETTER_PATH=/var/log/arbitex/siem-dead-letter.jsonl

Use tcp:// for TCP syslog delivery:

SIEM_DIRECT_URL=tcp://syslog.corp.example.com:514

RFC 5424 message format

Each event is formatted as a single RFC 5424 syslog message:

<134>1 {timestamp} - arbitex-outpost {event_id} - - {json_body}

Field	Value
PRI	`134` (facility `local0` = 16, severity `informational` = 6; 16×8+6=134)
VERSION	`1`
APP-NAME	`arbitex-outpost`
PROCID	Event ID from the audit record
MSG	Full audit event serialized as JSON

Example message:

<134>1 2026-03-11T08:30:00.000Z - arbitex-outpost req_01jnx4 - - {"request_id":"req_01jnx4","timestamp":"2026-03-11T08:30:00.000Z","user_id":"usr_abc","action":"chat_completion","model_id":"claude-sonnet-4-6","provider":"anthropic","token_count_input":312,"token_count_output":847}

UDP vs TCP: UDP sends single datagrams per event with no delivery confirmation — events may be silently dropped if the receiver is unavailable or if the datagram exceeds the network MTU. TCP confirms delivery at the transport layer but has higher per-event overhead; connection errors cause dead-lettering.

CEF format mapping

Common Event Format (CEF) is a structured syslog message format used by ArcSight, IBM QRadar, and other SIEMs. Arbitex does not emit CEF natively, but the audit event fields map directly to CEF headers and extensions.

CEF message structure:

CEF:0|Vendor|Product|Version|DeviceEventClassId|Name|Severity|Extensions

Mapping Arbitex OCSF fields to CEF

Use a syslog pipeline processor (Logstash, Fluentd, or a proprietary transformer) to convert OCSF events to CEF before ingestion.

CEF header mapping:

CEF Field	Source	Value
`Version`	constant	`0`
`DeviceVendor`	`metadata.product.vendor_name`	`Arbitex`
`DeviceProduct`	`metadata.product.name`	`Arbitex`
`DeviceVersion`	`metadata.version`	`1.1.0`
`DeviceEventClassId`	`class_uid`	e.g., `6003`
`Name`	`class_name` + `api.operation`	e.g., `Api Activity: prompt_sent`
`Severity`	`severity_id` × 2 (CEF 0–10 scale)	`2` for Informational (severity_id=1)

CEF extension field mapping:

CEF Extension	OCSF Source Field	Notes
`rt`	`time`	Millisecond epoch → CEF receipt time
`suser`	`actor.user.uid`	User ID of the actor
`src`	`src_endpoint.ip`	Source IP address
`cs1`	`actor.user.org_uid`	Tenant/org ID
`cs1Label`	constant	`tenantId`
`cs2`	`api.service.uid`	Model identifier
`cs2Label`	constant	`modelId`
`cs3`	`api.service.name`	Provider name
`cs3Label`	constant	`provider`
`cn1`	`unmapped.token_count_input`	Input token count
`cn1Label`	constant	`tokenCountInput`
`cn2`	`unmapped.token_count_output`	Output token count
`cn2Label`	constant	`tokenCountOutput`
`cn3`	`unmapped.latency_ms`	Request latency (ms)
`cn3Label`	constant	`latencyMs`
`act`	`api.operation`	Action performed

Example CEF output for a chat completion event:

CEF:0|Arbitex|Arbitex|1.1.0|6003|Api Activity: prompt_sent|2|rt=1741564800000 suser=usr_01HZ_ALICE src=198.51.100.42 cs1=org_acme cs1Label=tenantId cs2=claude-sonnet-4-6 cs2Label=modelId cs3=anthropic cs3Label=provider cn1=312 cn1Label=tokenCountInput cn2=847 cn2Label=tokenCountOutput cn3=1840 cn3Label=latencyMs act=prompt_sent

ArcSight CEF ingestion

ArcSight SmartConnectors can ingest CEF-formatted syslog messages directly. Configure a Syslog Daemon SmartConnector pointed at the port where your syslog pipeline emits the transformed CEF stream. Map cs1 (tenantId), cs2 (modelId), and act to ArcSight Active Channel columns for dashboard filtering.

Dead letter recovery

When a connector fails after all retry attempts, events are written to a JSONL dead letter file. Each line is a complete JSON object.

# Replay Splunk dead letter after SIEM is restored
jq -c '.event' /var/log/arbitex/siem-dead-letter.jsonl | while read -r event; do
  curl -s -X POST "$SPLUNK_HEC_URL" \
    -H "Authorization: Splunk $SIEM_DIRECT_TOKEN" \
    -H "Content-Type: application/json" \
    -d "{\"sourcetype\": \"arbitex:audit\", \"index\": \"arbitex\", \"event\": $event}"
done

The dead letter file has no automatic size cap. Monitor disk usage and set up rotation if the SIEM endpoint is unavailable for an extended period.

SIEM integration overview — OCSF schema, connector comparison
SIEM admin API — connector configuration via admin API
Audit Log Management — audit event structure and OCSF schema
Outpost SIEM direct sink — ring buffer, monitoring, and dead letter behavior

SIEM Integration — All Connectors

Choosing a delivery path

Overview

1. Splunk HEC

Configuration

Authentication

Event format

Delivery mechanism

2. Microsoft Sentinel (DCR API)

Configuration

Authentication

Event format

Delivery mechanism

3. Elastic (Bulk API)

Configuration

Authentication

Event format

Delivery mechanism

4. Datadog (Logs Intake v2)

Configuration

Authentication

Event format

Delivery mechanism

5. Sumo Logic (HTTP Source)

Configuration

Authentication

Event format

Delivery mechanism

6. IBM QRadar (CEF/syslog)

Configuration

Authentication

Event format

Delivery mechanism

QRadar log source setup

7. Cortex XSIAM (HEC + XSIAM envelope)

Configuration

Authentication

Event format

Delivery mechanism

Dead letter handling

Connector comparison

Outpost direct sink — Splunk HEC

Outpost direct sink — syslog (RFC 5424)

Configuration

RFC 5424 message format

CEF format mapping

Mapping Arbitex OCSF fields to CEF

ArcSight CEF ingestion

Dead letter recovery

Related pages