Detection Engine
Rules that prove themselves before they page anyone
ManySignal's detection engine runs deterministic streaming rules, threshold rules, and multi-event sequence rules over normalized telemetry. New rules deploy in alert-only mode — collecting signal, not generating noise — until you promote them to active.
Compiled rule — internal format
Rules compile to an optimized evaluation graph
At deploy time, rule YAML compiles to an internal JSON graph that the engine evaluates against the stream. Compilation validates field references, window arithmetic, and entity graph queries — so invalid rules fail fast at deploy time, not at 3 am.
{
"rule_id": "brute-force-auth-threshold",
"version": "2.1.0",
"mode": "active",
"eval_type": "threshold",
"window_seconds": 300,
"group_by": ["entity.user_id", "entity.source_ip"],
"filter": {
"event.type": "authentication",
"event.outcome": "failure"
},
"threshold": { "count": 5 },
"dedup": {
"key": ["entity.user_id"],
"window_seconds": 3600
},
"finding": {
"severity": "high",
"title": "Brute-force authentication attempt",
"mitre": ["T1110.001"]
}
}Three evaluation modes for every detection pattern
Streaming evaluation
Single-event rules evaluate every normalized event as it arrives. Latency from ingest to finding is under 200 ms in the p99 case. Streaming rules reference entity graph properties — blast radius, criticality, open vulnerabilities — enriched at evaluation time, not stored inline.
- Sub-200 ms p99 latency from ingest to finding
- Entity graph enrichment at evaluation time
- Field-level filtering compiled to bitset operations
Streaming evaluation
Threshold and windowed evaluation
Count-based rules accumulate events in a time window, grouped by entity attributes. The engine maintains sliding windows in memory with configurable eviction policies. Threshold rules can reference multiple event types within the same window — e.g., 3+ failed logins followed by a successful one.
- Sliding and tumbling window support
- Multi-event type sequences within a window
- Configurable minimum data volume before rule fires
Threshold and windowed evaluation
Temporal sequence rules
Ordered-event rules detect attack patterns that span hours or days: a credential enumeration followed by a successful login from a new geography, followed by a high-volume data access within 48 hours. Each stage can have its own window and filter, and stages can span multiple sessions.
- Ordered stage matching with per-stage time bounds
- Cross-session entity correlation
- MITRE ATT&CK stage annotations per sequence step
Temporal sequence rules
Detection Engine — FAQ
What is alert-only mode?
A rule in alert-only mode evaluates against live data and records findings internally, but suppresses pages and tickets. You can review the finding stream, tune thresholds, and measure false-positive rate before promoting the rule to active.
How does deduplication work?
Each rule declares a dedup key — typically entity ID and a finding type slug — and a dedup window. The engine suppresses subsequent findings for the same key within the window, so a brute-force attack on one account doesn't generate 500 tickets.
Can I reference entity graph properties in rules?
Yes. Rules can filter or score against any property available on the entity at evaluation time: `entity.blast_radius`, `entity.days_since_password_change`, `entity.is_privileged`, `entity.open_critical_vulnerabilities`. Graph traversal depth is capped at 3 hops to bound latency.
What happens when a rule has a field mapping error?
Rule compilation validates all field references against the normalized event schema. If a field doesn't exist, compilation fails with a descriptive error before the rule is deployed. Silent mismatches are not possible.
Are shipped detections customizable?
Yes. Every shipped detection is expressed in the same rule YAML as custom rules. You can fork a shipped rule, adjust thresholds, change the MITRE annotation, or add entity graph conditions. Forks are tracked as first-class versioned objects.
How many shipped detection rules are included and how are they maintained?
ManySignal ships 600+ detection rules mapped to MITRE ATT&CK, maintained by the detection engineering team. Rules are updated when new techniques emerge, new data sources are added, or precision improvements are identified. Updates are pushed to all tenants automatically and visible in the rule changelog.
Can detection rules be tested against historical data before going live?
Yes. The detection sandbox runs any rule against your historical event data and returns a sample of matching events, estimated daily alert volume, and precision indicators. This lets teams validate new rules and tune thresholds before they produce live findings.
What rule languages or formats does the detection engine support?
Rules are defined in a YAML-based declarative format that supports event filter conditions, entity graph references, behavioural baseline comparisons, and MITRE ATT&CK annotations. Sigma-format rules can be imported and converted automatically. Raw SQL is not used.
How does the detection engine handle high-volume sources without generating alert storms?
Per-rule deduplication windows, rate-limited escalation, and alert-only staging together prevent alert storms. Rules are also evaluated in order of entity criticality, so high-priority entities are processed first under load. The triage agent further suppresses noise by closing low-confidence findings before they reach the queue.
Ship your first detection in minutes
The detection sandbox lets you test rules against historical data before they touch live telemetry.