Use Case: Detection Engineering
Detection rule tuning
Rule 4821 has fired 2,300 times this month. 2,287 were false positives. ManySignal identified the condition that differentiates the 13 true positives and suggested an exclusion that would cut noise by 99% without dropping a single real alert.
Detection engineers can't tune what they can't measure
Detection rule tuning is one of the most impactful investments a security team can make — reducing noise without reducing coverage. But it requires systematic measurement: which rules fire most, what percentage are false positives, what conditions separate true positives from false ones. Most teams don't have this measurement infrastructure, so tuning happens reactively when analysts complain loudly enough about a specific rule.
ManySignal tracks every alert's triage outcome and builds a continuous measurement layer over your detection estate. The output is a ranked list of rules to tune, specific suggested exclusion conditions, and back-test validation before any change goes live.
workflow: detection_rule_tuning
continuous_measurement:
per_rule:
- alert_volume: daily / weekly / monthly
- fp_rate: closed_as_fp / total_alerts
- tp_rate: escalated_as_tp / total_alerts
- auto_suppressed: pre_triage_noise
- mttr_contribution: time_spent_per_rule
noise_ranking:
flag_for_review_when:
- fp_rate > 80% over 30 days
- volume > 100/day with tp_rate < 5%
- analyst_feedback: "noisy" tag > 5 instances
tuning_suggestion:
- analyze: fp_population vs tp_population
- identify: differentiating_fields (ip_range, user_group, time, asset_tag)
- suggest: exclusion_condition in rule syntax
- back_test: apply_to_90_day_history
- report: fps_suppressed, tps_preserved, net_noise_reduction
approval:
- one_click: apply_tuning (if back_test clean)
- override: required if any tp_would_be_suppressedTuning candidates this week
Coverage gaps by ATT&CK tactic
MITRE ATT&CK relevance
Detection tuning FAQ
How does ManySignal identify which detection rules are generating the most noise?
ManySignal tracks every alert through its triage outcome: closed as false positive, escalated as true positive, or auto-suppressed. Rules with false positive rates above configured thresholds (default 80%) are flagged for review. ManySignal shows which rules fire most frequently, their FP rate, their true positive rate, and the specific conditions that most commonly produce noise.
Can ManySignal suggest specific tuning changes to reduce false positives?
Yes. For each high-noise rule, ManySignal analyzes the population of false positive alerts and identifies the common differentiating factors: specific source IPs, user groups, time-of-day patterns, asset types. It then suggests adding exclusion conditions that would have suppressed the false positives while leaving true positives intact. Analysts can apply suggested tuning in one click.
Does ManySignal track coverage gaps — threats that have no detection rule?
Yes. Coverage gap analysis cross-references your active detection rules against the MITRE ATT&CK matrix and identifies techniques with no coverage. ManySignal also shows which attack techniques are commonly used against your industry vertical based on threat intelligence, allowing you to prioritize coverage additions.
How does ManySignal prevent regression when tuning rules?
Before applying any tuning change, ManySignal runs a back-test against the past 90 days of alert history to show how the change would have affected historical alerts. The back-test report shows false positives suppressed, true positives suppressed (should be zero), and net noise reduction. Tuning changes that would have suppressed any true positive require explicit override.
Cut alert noise 4x without removing a single true positive
Continuous FP measurement, suggested exclusions, and back-test validation before any rule change goes live.