SIEM Integration Overview

Arbitex generates a structured audit event for every request processed through the gateway, every DLP trigger, every authentication event, and every account change. These events can be streamed in real time to your SIEM using one or more SIEM connectors running inside the Arbitex platform.

---

Architecture

                     ┌──────────────────────────────────────────┐
                     │            Arbitex Platform               │
                     │                                           │
  Requests ─────────►│  Gateway → Policy Engine → DLP → Audit   │
                     │                 │                         │
                     │         Event Publisher                   │
                     │                 │                         │
                     │   ┌─────────────┼──────────────┐         │
                     │   │             │              │          │
                     │   ▼             ▼              ▼          │
                     │  Splunk     Sentinel        Elastic       │
                     │  HEC       (DCR/DCE)       Bulk API       │
                     │   │             │              │          │
                     │  Datadog    Sumo Logic                    │
                     │  Logs API   HTTP Source                   │
                     └──────────────────────────────────────────┘

When an audit event is generated, it is dispatched to every configured and healthy SIEM connector. Connectors operate independently — a failure in one connector does not affect delivery to others. Each connector maintains its own in-memory buffer, retry queue, and dead letter file.

---

OCSF v1.1 event format

All events are formatted as Open Cybersecurity Schema Framework (OCSF) v1.1 JSON. OCSF provides a vendor-neutral, normalized schema that allows events from different systems to be correlated and analyzed in a consistent structure without per-source parsing rules.

Why OCSF matters

Most SIEM platforms require custom parsers or mapping rules for each log source they ingest. OCSF removes this step by providing a schema that maps directly to common SIEM data models. When Arbitex events arrive in OCSF format, your SIEM can apply standard detection rules and dashboards designed for OCSF-compliant sources without additional transformation.

Core OCSF fields present in every Arbitex event

Field	Description
class_uid	OCSF event class integer identifier
class_name	Human-readable event class name
category_uid	OCSF category integer identifier
category_name	Human-readable category name
activity_id	Activity type within the class
activity_name	Human-readable activity name
severity_id	Severity integer (0=Unknown, 1=Informational, 2=Low, 3=Medium, 4=High, 5=Critical)
severity	Human-readable severity
status_id	Outcome integer (0=Unknown, 1=Success, 2=Failure)
status	Human-readable outcome
time	Event timestamp, epoch milliseconds
message	Human-readable event description
metadata.version	OCSF schema version (1.1.0)
metadata.product.name	Always Arbitex

Actor and principal fields

Field	Description
actor.user.uid	Internal user ID
actor.user.email_addr	User email address
actor.user.name	User display name
actor.org.uid	Organization ID
actor.org.name	Organization name

Source endpoint and geo fields

Field	Description
src_endpoint.ip	Source IP address of the request
src_endpoint.location.country	ISO 3166-1 alpha-2 country code
src_endpoint.location.city	City name (GeoIP enrichment)
src_endpoint.location.lat	Latitude (GeoIP enrichment)
src_endpoint.location.long	Longitude (GeoIP enrichment)
src_endpoint.is_anonymous	True if the IP is a known VPN/proxy/Tor exit

---

Event types streamed

OCSF class	class_uid	Trigger
API Activity	6003	Every request proxied through the gateway
Security Finding	2001	DLP rule trigger — BLOCK, REDACT, CANCEL, or SKIP
Authentication	3002	Login, SSO callback, token exchange, logout
Account Change	3001	User invite, group membership change, role assignment

API Activity (class 6003) additional fields

Field	Description
api.operation	The Arbitex audit action (e.g., prompt_sent, response_received)
api.service.name	AI provider name
api.service.uid	Model identifier
unmapped.token_count_input	Input token count
unmapped.token_count_output	Output token count
unmapped.cost_estimate	Estimated cost in USD
unmapped.latency_ms	End-to-end latency in milliseconds

Security Finding (class 2001) additional fields

Field	Description
finding.title	Finding description (e.g., DLP: dlp_block)
finding.uid	Unique finding ID
finding.types	["DLP"]
finding.related_events	Linked rule IDs and CredInt hit data
unmapped.credint_confidence	CredInt hit confidence score

---

Available connectors

Connector	ID	Protocol	Authentication	Format	Status
Splunk HEC	splunk_hec	HTTPS POST	HEC token	OCSF JSON in HEC envelope	P0 — Fully functional
Microsoft Sentinel	sentinel	HTTPS POST (DCR Log Ingestion API)	Azure AD client credentials	OCSF JSON array	P0 — Fully functional
Elasticsearch	elastic	HTTPS Bulk API	API key or basic auth	OCSF NDJSON	P0 — Fully functional
Datadog	datadog	HTTPS Logs Intake API v2	API key	OCSF JSON in log envelope	P0 — Fully functional
Sumo Logic	sumo_logic	HTTPS HTTP Source	URL-embedded auth	OCSF NDJSON	P0 — Fully functional
IBM QRadar	qradar	Syslog CEF over TLS	TLS client cert	CEF	Stub — not delivering
Palo Alto Cortex XSIAM	xsiam	HTTPS	API key	OCSF JSON	Coming soon

Multiple connectors can be active simultaneously. Events are delivered to all healthy connectors.

---

Global vs. per-org SIEM configuration

Global connectors

Global connectors are configured at the platform level using environment variables on the Arbitex platform deployment. They receive events from all organizations. This is the default and most common configuration — set once, stream everything.

Configure global connectors by setting the connector-specific environment variables described in each connector guide.

Per-org connectors

Any organization can configure dedicated SIEM connectors that receive only that org’s audit events, independently of the global connector configuration. Per-org connectors are stored in the siem_configs database table with Fernet-encrypted credential payloads.

Per-org connectors support all seven connector types: Splunk HEC, Microsoft Sentinel, Elasticsearch, Datadog, Sumo Logic, Cortex XSIAM, and IBM QRadar.

For full configuration reference including config schema per connector type, Fernet encryption, and delivery status tracking, see the Per-org SIEM configuration guide.

Organizations on dedicated Outpost deployments can also configure connector-level SIEM sinks inside the Outpost. See the Outpost deployment guide.

---

Admin UI — SIEM settings

Navigate to Admin → SIEM to manage connectors.

Connector list

The connector list shows all registered connectors with:

• Current health status (Healthy / Degraded / Error / Not configured)
• Connector type and non-sensitive config summary (URL, index, batch size — never secrets)
• Send test event button

Overall health summary

The SIEM health card at the top of the page shows aggregate counts:

{
  "healthy": 5,
  "degraded": 0,
  "error": 0,
  "not_configured": 1,
  "total": 6
}

Use this to confirm that your configured connectors are reachable before going to production.

API endpoints

Method	Endpoint	Description
GET	/api/v1/admin/siem/connectors	List all connectors with status
GET	/api/v1/admin/siem/health	Aggregate health summary
POST	/api/v1/admin/siem/test/{connector_id}	Send a test event to a connector

All SIEM endpoints require an admin API key.

# List connectors
curl https://api.arbitex.ai/api/v1/admin/siem/connectors \
  -H "Authorization: Bearer <YOUR_API_KEY>"

# Send a test event to Splunk HEC
curl -X POST https://api.arbitex.ai/api/v1/admin/siem/test/splunk_hec \
  -H "Authorization: Bearer <YOUR_API_KEY>"

---

Delivery guarantees and retry behavior

All connectors share the same delivery model:

• Buffering: Events are accumulated in memory and flushed when the buffer reaches the configured batch size (default: 100 events) or the flush interval elapses (default: 5 seconds).
• Retry: On transient HTTP errors (429, 503) or connection failures, the connector retries with exponential backoff: 1s, 2s, 4s, up to the configured maximum retries (default: 3 attempts).
• Dead letter queue: Events that cannot be delivered after all retries are written to a JSONL file on the platform host. Each connector has its own dead letter path. Dead letter events are not automatically replayed — they require manual intervention.
• Independence: Each connector runs independently. A failure in one connector does not affect delivery to other connectors or block request processing.

There is no cross-connector deduplication or ordered delivery guarantee. Events may arrive slightly out of order if a connector retries a batch while a subsequent batch is already delivered.

---

Dead letter recovery

When a connector fails to deliver events after all retries, events are written to a dead letter JSONL file on disk. Each line is a JSON object:

{
  "event": { ... },
  "error": "HTTP 503: Service Unavailable",
  "connector": "splunk_hec",
  "timestamp": 1741564800.0
}

To replay dead letter events after the SIEM is restored, use the platform replay endpoint:

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

For Splunk, you can re-submit events from the dead letter file manually:

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 $SPLUNK_HEC_TOKEN" \
    -H "Content-Type: application/json" \
    -d "{\"sourcetype\": \"arbitex:audit\", \"index\": \"arbitex\", \"event\": $event}"
done

Contact Arbitex support for assisted bulk recovery if the dead letter file is large.

---

Connector guides

• Splunk HEC — configure the HTTP Event Collector connector
• Microsoft Sentinel — configure the Azure Monitor DCR ingestion connector
• Elasticsearch — configure the Elastic Bulk API connector
• Datadog — configure the Datadog Logs Intake connector
• Sumo Logic — configure the Sumo Logic HTTP Source connector
• Per-org SIEM configuration — configure per-organization connectors stored in the database