Detection Workflows

The problem

Many detection changes still move like manual production edits. A rule is copied into a SIEM, adjusted until it runs, and trusted because someone experienced looked at it. Cross-SIEM work adds another layer of risk: the same logic has to survive different query languages, field mappings, and platform limits.

That makes every change feel like a gamble. Junior engineers wait on senior reviewers, seniors cannot preview the full impact, and rollback depends on whether someone saved the previous version.

How CraftedSignal changes the workflow

CraftedSignal treats detection content as governed code. Engineers can author in Sigma or keep a rule in a native SIEM language when that is the better fit. The platform compiles, validates, and shows translation diffs so reviewers know what will actually ship to each platform.

Rules can carry generated or manually written tests. Positive tests confirm known-bad behavior fires. Negative tests confirm expected benign behavior stays quiet. Tests run against live SIEMs, because the real question is not whether the YAML parses; it is whether the rule works against the data shape you actually have.

Rules and hunts can also carry runbooks and playbooks. The runbook gives analysts the concrete triage path: alert intent, evidence to collect, false-positive checks, and escalation criteria. The playbook covers broader response work such as containment, recovery, communications, and follow-up detection work.

Those response steps stay connected to the detection. CLI sync preserves them with the rule, rule edits can mark them stale for review, and hunt promotion carries them into the resulting detection. AI can draft runbooks and playbooks from rule logic, tests, ATT&CK mapping, and threat context. It can also use existing response steps when refining rule logic or tests, but the content remains editable and reviewable before analysts rely on it.

Approval and impact preview

Before deployment, reviewers can see the rule change, compiled output, severity, layer, tenant, expected hit count, and recent impact. Critical rules can require stricter approval. Stale requests can escalate automatically so work does not disappear in a queue.

Every decision is audit-logged. The record shows who changed the rule, who approved it, what tests ran, what shipped, and what happened after deployment.

Deployment and rollback

Deployments are versioned. If a change goes wrong, rollback uses the previous known-good version rather than a human trying to reconstruct history from a SIEM screen. Drift detection later verifies the deployed version is still the one CraftedSignal expects.

For teams that prefer detections-as-code, csctl supports push, pull, bidirectional sync, validation, and CI/CD integration. That means local repositories, GitHub Actions, and platform review can all work together instead of competing for ownership.