Detection Engineering
Build detections that actually work. And stay working.
ManySignal's detection-as-code workflow combines AI-assisted rule authoring with automated backtesting against 90 days of your telemetry, CI/CD deployment, and drift detection that flags stale rules before they become noise.
The detection engineering workflow
Author
Use the AI rule assistant or write YAML directly. Import Sigma or YARA-L rules from open-source libraries. Every rule includes test cases.
Backtest
Automatically tested against 90 days of your telemetry before deployment. Backtest report shows fire rate, FP breakdown, and technique coverage.
Deploy via CI/CD
Rules merge through your Git-based review process. GitHub Actions or the ManySignal CLI deploys to staging, then production with zero downtime.
Monitor drift
Weekly drift analysis flags rules where the alert-to-case conversion rate indicates stale logic. Drifted rules surface for review automatically.
Sample detection rule — Process Hollowing
ManySignal YAML detection format. AI-generated, backtested, CI/CD deployable.
# ManySignal Detection Rule — T1055.012: Process Hollowing
# Generated via AI rule assistant. Backtested against 90 days of telemetry.
# False positive rate: 0.003% | True positive sample: 14 confirmed incidents
detection:
id: ms-win-process-hollowing-001
name: Suspicious Process Hollowing via NtUnmapViewOfSection
technique: T1055.012
severity: HIGH
confidence: rule
query: |
FROM endpoint.process_events
WHERE
api_calls CONTAINS 'NtUnmapViewOfSection'
AND api_calls CONTAINS 'NtAllocateVirtualMemory'
AND api_calls CONTAINS 'WriteProcessMemory'
AND process_name NOT IN (trusted_system_processes)
AND NOT (signed = true AND publisher IN (trusted_publishers))
WITHIN 60s
THRESHOLD: 1
filter_out:
- condition: parent_process IN ['java.exe', 'node.exe']
reason: Known JIT compilation pattern — false positive category
test_cases:
- name: Cobalt Strike hollowing pattern
result: match
- name: JVM class loading (legit)
result: no_match
alert:
title: "Process Hollowing — {process_name} on {host}"
priority: P1
triage_hint: "Check parent process chain and network connections from hollowed process"Coverage against MITRE ATT&CK
ManySignal ships 600+ pre-built rules covering these technique categories. Your custom rules layer on top.
Initial Access
42 rulesT1190, T1566, T1133, T1189
Execution
78 rulesT1059, T1055, T1106, T1047
Persistence
65 rulesT1547, T1053, T1543, T1078
Privilege Escalation
54 rulesT1548, T1134, T1484, T1611
Defense Evasion
89 rulesT1036, T1027, T1562, T1070
Credential Access
71 rulesT1003, T1558, T1621, T1110
Lateral Movement
48 rulesT1021, T1550, T1534, T1080
Exfiltration
39 rulesT1048, T1041, T1567, T1052
Impact
44 rulesT1486, T1490, T1485, T1491
Detection engineering — common questions
Can we manage detection rules as code in our existing Git repository?
Yes. ManySignal's detection-as-code workflow supports Git-based rule management. Rules are authored in YAML, stored in your repository, and deployed via the ManySignal CLI or GitHub Actions integration. Rule changes trigger automatic backtesting before deployment.
How does the AI rule assistant generate detection logic?
The rule assistant accepts an ATT&CK technique ID, a threat description, or a sample indicator of compromise. It generates a detection rule with appropriate query logic, filter conditions for common false positive patterns, and test cases. The output is editable YAML — you own the rule and its rationale.
What backtesting does ManySignal perform before a rule goes live?
Before a rule deploys, it runs against 90 days of your historical telemetry in a shadow mode. The backtest report shows: how many events it would have fired on, the true positive and false positive breakdown (where ground truth is available from prior cases), and a comparison to your existing coverage for the same technique.
How does ManySignal handle detection drift over time?
The drift detection system monitors each deployed rule's alert-to-case conversion rate weekly. Rules where 95%+ of alerts are auto-closed as false positives flag as potentially drifted and are queued for review. This prevents stale rules from contributing to alert fatigue without being noticed.
What formats does ManySignal accept for importing existing detection rules?
ManySignal accepts Sigma (the most common open-source detection format), YARA for file-based detections, and ManySignal's own YAML DSL. Splunk SPL and Microsoft Sentinel KQL rules can be converted via the migration utility with manual review for complex logic.
How many pre-built detection rules does ManySignal ship, and who maintains them?
ManySignal ships 500+ pre-built detection rules maintained by the ManySignal Threat Research team. Rules are updated as new TTPs emerge and ATT&CK techniques evolve. When a new high-profile attack campaign is publicly documented, updated or new detection rules are typically published within 72 hours. Rule updates are deployed automatically to all customers unless a customer has pinned a specific rule version.
Can we test a detection rule against a live environment without generating analyst alerts?
Yes. Rules can be deployed in 'alert-only' mode — they fire and collect results but do not escalate to the analyst queue. The alert-only dashboard shows what the rule would have alerted on, allowing detection engineers to validate precision and tune filters before the rule goes live. Alert-only mode is the standard promotion path for new rules and for tuned variants of existing rules.
How does ManySignal help detection engineers prioritise which ATT&CK gaps to fill?
The coverage gap view overlays your current detection estate against the ATT&CK matrix and ranks gaps by two factors: technique prevalence in recent incidents affecting your industry (from threat intelligence) and technique severity (what the attacker can achieve if undetected). The highest-ranked gaps — frequently exploited, not covered, high potential impact — are surfaced as the recommended detection priorities.
What is the detection-as-code branching and review model?
Detection rules live in a Git repository with the same review workflow as application code: feature branches for new rules, pull request review by a designated approver (typically a senior detection engineer or security lead), automated backtesting in CI that posts results to the PR, and merge to main to trigger deployment. This brings software engineering quality gates to detection development without requiring custom CI tooling.
Build your detection library on a solid foundation
See the AI rule assistant generate a detection for your most common threat scenario — with backtest results — in the first 15 minutes of the demo.