SIEM Integrations: Splunk, QRadar, and Elasticsearch

When you start an exercise, ThreatLab connects to your configured SIEM destination and ships the exercise log archive so you investigate real events in the tooling you use every day. No manual data loading, no synthetic replays — the logs land in your SIEM index and you work the case from there. Your administrator configures the destination connections; you just hit Start and begin investigating.

​

Supported Drivers

ThreatLab supports three shipping drivers, each targeting a different SIEM stack:

​

Payload Formats

The driver you use determines which log payload format ThreatLab ships: An exercise can carry both LEEF and ECS archives simultaneously. ThreatLab selects the correct format at exercise start based on the payload_format configured on your SIEM destination — so the same exercise works across different analyst environments without any changes.

​

When SyslogCanon is required

ThreatLab uses the SyslogCanon sidecar to canonicalise raw logs and produce LEEF and ECS archive pairs. Authors need SyslogCanon at publish time whenever the raw input does not already cover the format an enabled destination needs:

• Convert to LEEF is enabled. SyslogCanon parses every row and emits both LEEF and (where required) ECS.
• Raw rows are detected as ECS but a LEEF destination is enabled (e.g. splunk_hec, syslog_tcp). SyslogCanon generates the LEEF side.
• Raw rows are detected as LEEF but an ECS destination is enabled (e.g. elastic_bulk). SyslogCanon generates the ECS side.
• Any row is unknown. SyslogCanon canonicalises it — ThreatLab no longer silently labels unknown raw archives as LEEF.

When the publish-time readiness check determines that SyslogCanon is required for a given format and it is either unavailable or fails to dual-parse, the publish is blocked. The error names both the affected SIEM destination and the format (LEEF or ECS) so authors know which side to fix.

​

Syslog TCP Envelope Settings

When your destination uses the syslog_tcp driver, your administrator can configure the syslog envelope on a per-destination basis. These settings control how ThreatLab frames each event before it goes on the wire:

​

QRadar API Management

For syslog_tcp destinations, administrators can optionally enable QRadar API management so ThreatLab calls the QRadar REST API to provision log sources and close offenses tied to wiped sessions. Event delivery still flows over syslog/LEEF — the API token only authorizes management actions. See SIEM resources for the field reference. When Provision log source is enabled, ThreatLab creates one QRadar log source per exercise section, scoped to every enabled QRadar syslog_tcp destination. Each log source is keyed by exercise and section, so the same section never reuses a log source from a different exercise, and rerunning provisioning is idempotent — an already-provisioned section returns its existing log source rather than creating a duplicate. Sectionless exercises continue to provision a single log source per exercise. Provisioning runs per section: if one section’s destination fails (for example, because the QRadar API is unreachable), the other sections still return their own success or failure result. QRadar destinations on the syslog_tcp driver can optionally use the QRadar REST API for two console-side tasks. Both are opt-in and configured per destination by your administrator — see QRadar API management for setup details.

• Provision log source. ThreatLab creates a per-exercise log source on the QRadar console the first time it ships logs, so events route to a dedicated log source instead of a shared one.
• Close offenses on completion. When an analyst finishes an exercise attempt, ThreatLab closes the QRadar offenses that were opened against the exercise log source during the attempt window. Cleanup runs after scoring and never blocks completion — if QRadar is unreachable, the analyst still gets credit and the failure is recorded for administrators.

​

QRadar Log Source Provisioning

When your syslog_tcp destination targets QRadar, your administrator can let ThreatLab manage a dedicated QRadar log source per exercise so every event you investigate is tied back to a single exercise run. Provisioning is configured on the destination — see QRadar log source provisioning for the admin steps.

​

How it works

When Enable log source provisioning is on for the destination, ThreatLab runs the following flow at exercise start:

​

When provisioning is disabled

If Enable log source provisioning is off, ThreatLab loads any previously stored source identity for the exercise and reuses it as the syslog source host. Destinations that have never been provisioned fall back to the default Source identity configured on the destination. When Provision log source is enabled, ThreatLab creates a dedicated QRadar log source for each section of an exercise (not just one per exercise) so staged section release can identify which logs belong to which step of the investigation. Provisioning happens at publish time — when an author toggles an exercise to Active — as a preflight gate:

• Provisioning failed or QRadar requires deploy — the exercise is saved but kept in Draft, and warnings name the destination, the section, and the reason. The author must resolve each warning (re-check QRadar credentials, or run Deploy Changes in the QRadar console) and publish again.
• Provisioning succeeded and QRadar is already deployed — the exercise activates normally.

Cached QRadar log sources that still have requires_deploy set are re-checked against the QRadar API before the preflight short-circuits, so an administrator running Deploy Changes in QRadar is enough to clear the gate on the next publish attempt — no manual cache reset is needed. See QRadar log-source preflight in the authoring guide for the author-facing flow.

​

Per-section log sources

When Provision log source is enabled, ThreatLab provisions one QRadar log source per exercise section so each section’s events arrive under a distinct syslog identity. At exercise start, redo, and Ship logs to SIEM, ThreatLab gates shipping on the readiness of every section’s log source:

• A section is ready when its log source has provisioned status, a QRadar log source ID, and does not require a QRadar deploy.
• A section is not ready when its provisioning is missing, failed, or still pending a QRadar deploy.

If any section is not ready, the operation fails fast with an error that names each blocking section and the reason — for example section 2 (web-access): QRadar deploy required. Trigger the QRadar deploy (or fix the upstream provisioning error) and start the exercise again. Exercises that have no per-section QRadar rows fall back to the legacy exercise-level log source, so older exercises that pre-date per-section provisioning continue to work without change.

​

Offense cleanup across sections

When Close offenses is enabled, session wipe and redo close every offense tied to any provisioned section log source for the exercise — plus any legacy exercise-level log source. Offenses linked to more than one section’s log source are closed once and deduplicated in the cleanup summary.

​

Shipping Models

ThreatLab supports two shipping models for an exercise’s archive sections: Staged shipping is configured per section on the exercise itself — see Section release rules for the model and Authoring exercises for the editor controls. ThreatLab snapshots each shipment per attempt, so a section that already shipped during one attempt is not re-shipped if the analyst hits Ship logs to SIEM again — the platform returns an explicit already_shipped, not_due, waiting_on_artifacts, or similar reason instead.

​

Publish-Time Readiness

Setting an exercise to Active triggers a publish-time readiness check that mirrors the runtime resolution rules. The check derives required formats from enabled SIEM destinations (driver + payload_format + enabled) and the assigned SIEM, and verifies every section has a matching archive in every required format. If SyslogCanon is needed to generate a format and is unavailable or cannot dual-parse, publish is blocked per-format and per-section, with errors that name the affected SIEM and format. This means an exercise can only go live if it is actually shippable to every destination it targets — there is no path that produces a partially-formatted exercise at publish time.

​

Archive Resolution Order

At exercise start, ThreatLab resolves which archive to ship based on whether the exercise has section rows.

​

Sectioned exercises (authoritative)

If the exercise defines any sections, per-section archives are authoritative for the requested payload format. Every section must carry a matching archive in the format your SIEM destination expects (LEEF or ECS).

• If any section is missing an archive in the requested format, shipping fails with a clear error that names the SIEM destination and the sections that are missing the format.
• ThreatLab will not silently fall back to a legacy per-exercise archive or to legacy exercise columns when section rows are present. A partial section set, or a section set that does not cover the requested format, always fails fast.

This applies to both active runs and staged exercises. Staged runs additionally validate against the full set of enabled SIEM destinations, so a staged exercise that targets both LEEF and ECS destinations must have section archives in both formats.

​

Legacy exercises (no section rows)

If the exercise has no section rows at all, ThreatLab falls back to the legacy resolution order: If neither legacy source has an archive in the requested format, shipping fails with an error that names the SIEM destination and the missing format.

​

Publish-Time Guardrail

To prevent the resolution errors above from surfacing at exercise start, ThreatLab enforces a matching guardrail when an exercise is saved or published as a staged run:

• ThreatLab reads every enabled SIEM destination and groups them by payload format.
• For each format with at least one enabled destination, every section must have a matching archive.
• If any section is missing an archive in a required format, the save or publish fails with an error that names the affected SIEM destinations and sections.

The practical effect: a staged exercise cannot be saved with incomplete per-section archives. If you enable an ECS destination, every section needs an ECS archive; if you enable a LEEF destination, every section needs a LEEF archive. To unblock a save, either upload the missing section archives or disable the SIEM destinations that require the format you are not shipping.

​

Wipe and Re-Fire

When you delete an active session, ThreatLab wipes the corresponding SIEM index so the environment is clean for the next attempt. Noise log jobs that have propagate_on_wipe enabled automatically re-fire after a wipe to refill your SIEM with background noise events — keeping the environment realistic for the next analyst who starts the exercise.