Rules

Rule model

Every detection in CraftedSignal is a rule — a structured object that contains metadata, logic, platform-specific implementations, tests, runbooks, playbooks, and context.

Metadata

MITRE ATT&CK mapping

Every rule maps to one or more MITRE ATT&CK techniques:

mitre:
  - tactic: TA0003    # Persistence
    technique: T1505   # Server Software Component
    subtechnique: ".003"  # Web Shell

This mapping powers coverage reports and gap analysis.

D3FEND defensive coverage

Every rule with an ATT&CK mapping also gets D3FEND defensive categories derived automatically. The platform looks up each technique in an embedded ATT&CK → D3FEND mapping and computes which of the five defensive categories (Detect, Harden, Isolate, Deceive, Evict) the rule contributes to.

D3FEND categories appear as color-coded badges on the rules list and can be used to filter rules by defensive goal (e.g., ?dfend_category=Harden). On the rule edit page, the Defensive Coverage panel shows the derived categories. An Override toggle lets you supply D3FEND technique IDs manually when the auto-mapping doesn’t match the rule’s actual defensive intent.

See D3FEND Defensive Coverage for the full reference.

Platform implementations

A single rule can have implementations for multiple SIEMs:

implementations:
  splunk:
    query: |
      index=web sourcetype=access_combined
      | where uri_path LIKE "%/uploads/%.php"
      | stats count by src_ip, uri_path
    portability_score: 0.85

  sentinel:
    query: |
      W3CIISLog
      | where csUriStem has_any (".php", ".asp", ".jsp")
      | where csUriStem contains "/uploads/"
      | summarize count() by cIP, csUriStem
    portability_score: 0.82

Translation diffs show exactly what differs per platform so reviewers can approve with confidence.

Rule formats

CraftedSignal supports three ways to author detection logic:

The format is controlled per-rule. Admins set the company default under Settings > Rules > Default format, and engineers can override it on individual rules.

When importing existing native SIEM rules, CraftedSignal auto-converts them to Sigma. The original native query is preserved for reference.

When Sigma Auto-Translation is enabled, rules authored in Sigma can compile to the selected target language on save. This keeps Sigma as the portable source while still showing the exact native query that will run on the SIEM.

Rule sources

Threat intelligence feed

CraftedSignal includes a curated TI feed that translates trending and novel threats into ready-to-use detection rules. Applicability filtering shows what’s relevant to your environment and SIEM.

AI-generated rules

Describe what you want to detect in natural language. AI generates the rule, tests, MITRE mapping, and optional runbook/playbook draft. You review and approve before anything ships.

Use the web UI to describe what you want to detect. AI generates the rule, tests, MITRE mapping, and response steps for review.

AI can also use existing runbooks and playbooks as context when refining a rule. That keeps detection logic, tests, and analyst response steps aligned instead of turning the runbook into stale documentation.

Your own repository

Import your existing rules — native SIEM rules are auto-converted to Sigma for cross-platform portability. Use our standard rules repository, or start from scratch. Everything is detections as code — YAML files in a Git repo.

Rule lifecycle

Rules move through defined states:

Draft → Active → Shadow → Monitoring → Active (promoted)
                                     → Paused
                                     → Killed

Versioning

Every change to a rule creates a new version. CraftedSignal tracks:

• What changed (semantic diff on the rule logic, not just text)
• Who changed it
• When and why
• Approval status

Versions are retained up to a configurable limit (default: 5) for audit and rollback. See Configuration to adjust rules.max_version_history.

Rule context

Each rule includes context that helps reviewers and analysts:

• Rationale: Why this detection exists
• Assumptions: What must be true for this rule to work (log sources, data quality)
• Noise expectations: Expected false positive rate and known blind spots
• Runbooks and playbooks: What analysts should validate, collect, escalate, contain, and improve when the rule fires
• Required enrichments: Lookups, threat lists, or data sources the rule depends on

See Runbooks & Playbooks for the response content model, AI draft workflow, and sync behavior.

Dependencies

Rules can depend on shared resources:

• Macros/Saved searches: Shared logic referenced by multiple rules
• Lookups: Threat lists, allowlists, asset inventories
• Parsers: Field extraction definitions

CraftedSignal tracks these dependencies and performs impact analysis — when a shared resource changes, you see which rules are affected before deploying.

Cost expectations

Each rule can define cost expectations:

cost:
  expected_alerts_per_day: 5
  max_alerts_per_day: 50
  ingestion_projection_gb: 0.1

These expectations are validated during shadow evaluation and enforced as noise budgets during deployment.

See Health & Analytics for noise budget monitoring.