UPDATED · 21 JUN 2026 · EDIT ON GITHUB
GUIDES · DEPLOY

Migrating a SIEM detection ruleset.

You do not rebuild a detection library by hand. Import your existing Sigma or vendor rules as detection-as-code, fix the handful that need human judgment, and validate the entire batch against real history before any of it ships.

15 min read Intermediate By P. Sundar

Import the ruleset

The importer reads Sigma and the common vendor formats, converting each rule into a threatDefendr detection plan you can review in your own repository.

SHELLimport
$ td detect import --from sigma ./sigma-rules/ --out ./detections/ -> 412 rules read -> 381 converted clean -> 31 need review (unsupported constructs) ok wrote ./detections/ . review the 31 flagged plans

Map the gaps

Most rules convert cleanly. The ones that do not usually lean on a SIEM-specific construct that the fabric models differently — and differently is often better.

SIEM constructthreatDefendr equivalent
Index / sourcetypeA fabric stream (identity.signin, endpoint.process).
Lookup tableA custom enrichment on entity_id.
Stats / transactionA windowed join with a sequence.

Validate against history

Never trust a bulk conversion blind. Back-test the whole batch over 30 days and read the aggregate false-positive count before you promote.

SHELLvalidate the batch
$ td detect backtest ./detections/ --since 30d --summary -> 412 detections . 1.84B events -> 9 over the false-positive budget (retune) ok 403 clean . report at /detections/_preview/import
Do not import the noise. A migration is the moment to drop the rules your old SIEM only kept because deleting them was scary. Import, read the backtest, and retire anything with no true positives in 30 days rather than carrying it forward.

Where to go next

← PREV GovCloud / FedRAMP High NEXT → Connector deploy in 5 minutes