mediumMultiple Select

False Positive Reduction Techniques in Intrusion Detection Systems

Which TWO actions are recommended when tuning IDS signatures to reduce false positives?

⚠ Common exam trap

200-201 often tests the misconception that disabling noisy signatures is a valid tuning method, but the recommended approach is to tune thresholds and whitelist, not disable.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Modify signature thresholds to match typical traffic patterns

Option C is correct because tuning a signature's threshold (for example, raising a detection count or time window so it only fires after N matches within T seconds) aligns the rule with the normal baseline of your environment, so benign traffic bursts no longer trigger alerts. Option E is correct because whitelisting known good behavior—such as trusted source IPs, internal vulnerability scanners, or approved application flows—suppresses alerts for activity you have verified as legitimate, directly cutting false positives without losing coverage. Options A, B, and D are not recommended: raising severity for all signatures only increases noise and does not reduce false positives; replacing the IDS with a next-generation firewall is an architectural change, not a signature-tuning action; and disabling frequently alerting signatures removes detection capability and can create blind spots rather than properly tuning the rule.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Increase alert severity for all signatures
Why it's wrong here
Raising severity changes how alerts are triaged and escalated, not whether the signature fires, so false-positive volume stays identical. It is tempting because severity tuning genuinely helps when analysts are drowning in low-priority noise, but that addresses alert handling rather than the signature matching logic itself.
✗
Replace IDS with a next-generation firewall
Why it's wrong here
Swapping the IDS for a next-generation firewall replaces the detection platform rather than tuning signatures, and NGFW inspection does not eliminate the underlying pattern matches causing false positives. It is tempting because NGFWs do perform intrusion prevention, but that is a platform migration decision, not a signature-tuning action.
✓
Modify signature thresholds to match typical traffic patterns
Why this is correct
Adjusting signature thresholds to reflect normal traffic baselines reduces alerts triggered by legitimate activity. This satisfies the false-positive constraint because thresholds set above routine peaks stop benign traffic from matching signatures while genuine anomalies still fire.
✗
Disable signatures that generate frequent alerts
Why it's wrong here
Disabling noisy signatures removes detection coverage entirely, including the true positives those signatures would catch, rather than refining them. It is tempting because the alerts do stop, and disabling is legitimate for signatures proven irrelevant to the environment, but tuning thresholds or exceptions preserves detection instead of discarding it.
✓
Whitelist known good behavior
Why this is correct
Whitelisting known good behaviour excludes trusted applications and hosts from signature evaluation, satisfying the false-positive constraint. This suppresses alerts caused by legitimate traffic without weakening detection of genuinely malicious activity elsewhere on the monitored network.

Go deeper

False Positive Reduction Techniques in Intrusion Detection Systems

Why each option matters

Option-by-option breakdown

Related to this question