How to Send Violations to Splunk HEC, Microsoft Sentinel, or IBM QRadar

Why You Want This

Chainsaw’s violations and audit log are useful inside the dashboard, but the analysts looking for cross-tool correlation live in Splunk / Sentinel / QRadar. Sending them the events is non-negotiable for any org with a real SOC.

Three exporters ship out of the box:

All three are backed by the same durable events table with replay semantics, so a SIEM outage produces a queue, not lost events.

Prerequisites

• Admin role.
• The destination SIEM provisioned and reachable from the Chainsaw control plane.
• For Splunk: an HEC token. For Sentinel/QRadar: the syslog ingestion endpoint and a TLS cert that Chainsaw will present.

Step 1: Decide What to Export

Two streams are exported separately so you can scope retention and ingest cost:

For most SOCs the right setup is “violations always, audit during incident response or as a low-volume background stream”. You can enable both initially and dial back if the ingest cost is an issue.

Step 2: Configure Splunk HEC

Open Settings → SIEM exporters → New and choose Splunk HEC:

Click Test — Chainsaw fires a synthetic event. If you see it land in Splunk within a few seconds, the wiring is correct.

The exporter posts JSON in Splunk HEC envelope format:

{
  "time": 1761969600,
  "host": "chain305.com",
  "source": "chainsaw",
  "sourcetype": "chainsaw:violation",
  "index": "chainsaw_security",
  "event": {
    "violation_id": "v_abc123",
    "package": "lodash",
    "version": "4.17.20",
    "policy": "Block KEV-pinned",
    "action": "block",
    "client_id": "ci-frontend",
    "findings": [...]
  }
}

Step 3: Configure Microsoft Sentinel (CEF over syslog)

Sentinel ingests CEF via the Log Analytics agent or AMA. Chainsaw posts directly over TCP/TLS syslog:

The CEF format used:

CEF:0|Chainsaw|chainsaw|6.1.0|violation|block|7|
  externalId=v_abc123 cs1Label=package cs1=lodash
  cs2Label=version cs2=4.17.20
  cs3Label=policy cs3="Block KEV-pinned"
  cs4Label=client_id cs4=ci-frontend
  rt=1761969600000

Chainsaw maps each violation field to a fixed set of CEF extension keys (the cs1–csN custom-string slots shown above). If your Sentinel parser expects extra fields, raise it with support — the mapping is configurable on the control plane.

Step 4: Configure IBM QRadar (CEF over syslog)

QRadar uses a standard CEF DSM. Configuration is nearly identical to Sentinel:

The CEF payload is the same — QRadar just parses it with its own DSM. Add the Generic CEF DSM in QRadar and the events appear with Vendor=Chainsaw, Product=chainsaw.

Step 5: Durable Replay Semantics

The events table on the control plane is the source of truth. Every event flows through it before being dispatched to any exporter. If an exporter is unreachable, the event sits in the queue with an exponential-backoff retry; when the exporter recovers, the queued events drain.

Default retention on the queue is 7 days. To change:

CHAINSAW_SIEM_QUEUE_RETENTION=30d

A SIEM that’s down for 7 days is an unusual situation; in that case you can manually replay from a specific timestamp:

curl -X POST -H "Authorization: Bearer $CHAINSAW_TOKEN" \
     "https://chain305.com/chainproxy/api/settings/data-sources/splunk-prod/refresh" \
     -d '{"replay_from": "2026-04-22T00:00:00Z"}'

This re-dispatches every event from the timestamp forward. The exporter is idempotent on the event_id field, so re-dispatching events the SIEM already has is safe (your dedup rules will collapse them).

Step 6: Wire the Common SOC Detections

A few rules to ship on day one:

Splunk SPL: spike in blocks

sourcetype="chainsaw:violation" action=block
| timechart span=15m count by package
| where count > 50

A 15-minute window with > 50 blocks of the same package is a strong signal — either a registry compromise (malicious version everyone is now hitting) or a misconfigured policy.

Sentinel KQL: KEV-pinned violations

CommonSecurityLog
| where DeviceVendor == "Chainsaw" and DeviceProduct == "chainsaw"
| extend findings = parse_json(AdditionalExtensions)
| where findings has "kev_pinned"
| summarize count() by package = DeviceCustomString1, bin(TimeGenerated, 1h)

QRadar AQL: bypass attempts

SELECT count(*) FROM events
WHERE Vendor = 'Chainsaw' AND Category = 'bypass.attempted'
GROUP BY clientId
LAST 24 HOURS

Bypass attempts (the metric from tutorial 55) are particularly important to alert on in the SIEM, because they indicate a network-layer drift that the proxy alone can’t detect.

Step 7: Tune the Volume

Audit-stream volume is dominated by:

1. API calls — every /api/intelligence/... query, every dashboard page load.
2. Auth events — every login, every token refresh.
3. Read-only events — /healthz, /metrics, etc. (filtered out by default).

If your SIEM is volume-priced, the audit stream can dominate cost. Three knobs:

# Suppress per-call API audit (still recorded internally for compliance)
CHAINSAW_SIEM_AUDIT_SUPPRESS_API_READS=1

# Sample audit at 10%
CHAINSAW_SIEM_AUDIT_SAMPLE_RATE=0.1

# Send only specific event types
CHAINSAW_SIEM_AUDIT_INCLUDE=auth.*,policy.*,exception.*

The default config is SUPPRESS_API_READS=1 and INCLUDE=auth.*,policy.*,exception.*,bypass.*,siem.* — i.e., the high-signal slice.

Verification

1. The exporter test event appears in the destination SIEM within seconds.
2. A real violation (block / quarantine) appears in the SIEM within seconds.
3. After temporarily blocking the exporter’s network egress, queue depth grows; restoring egress drains the queue.
4. Re-dispatching from a past timestamp produces the expected events.

Related Topics

• How to Use Audit Logs to Track Consumption — the source data the exporters relay.
• How to Send HMAC-Signed Outbound Webhooks — for chat platforms (Slack, Teams, PagerDuty), use webhooks; for SIEM, use this guide.
• How to Detect Bypass Attempts — the bypass-attempted event is one of the highest-value events to forward to the SIEM.