SIEM False Positive Reduction: Thresholding for Brute-Force Detection
A security analyst is tuning a SIEM and needs to reduce false positives from a rule that alerts on failed logins. The rule currently triggers on any single failed login. Which modification would best reduce false positives while still detecting brute-force attacks?
Quick Answer
Adding a threshold of 5 failed logins within 5 minutes is the right fix because it targets the specific cause of the false positives described: a rule that alerts on any single failed login is far too sensitive, since ordinary human error, a mistyped password, an expired credential, someone fat-fingering a login on their phone, produces exactly the same event as the opening move of a genuine brute-force attempt. The problem isn't that the SIEM is watching the wrong thing; it's that it's reacting to a single data point instead of a pattern. Requiring a minimum count of failures within a bounded time window changes the rule from did any failure happen to did a burst of failures happen close together, which is a much closer match to what a brute-force attack actually looks like: rapid, repeated attempts concentrated in a short span, rather than isolated failures scattered randomly throughout the day. A single accidental failed login won't reach the threshold within the window and won't trigger an alert, cutting out the bulk of the noise, while a genuine brute-force attempt, which by nature needs many attempts in quick succession to have a chance of succeeding, will still cross the threshold and get caught. This aggregation-based tuning approach, combining a count and a time window, is a standard SIEM tuning pattern. When a question asks how to reduce alert noise from a login-failure rule without losing the ability to catch brute-force activity, look for an answer that adds both a minimum occurrence count and a bounded time window, rather than one that simply raises or lowers a single static number.
⚠ Common exam trap
The SSCP exam often tests the misconception that increasing severity or ignoring specific users reduces false positives, when in fact only time-based thresholding or contextual filtering (e.g., source IP reputation) properly addresses the root cause of noise from isolated events.
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
✓
Add a threshold of 5 failed logins within 5 minutes
Adding a threshold of 5 failed logins within 5 minutes reduces false positives from isolated accidental lockouts while still detecting the sustained pattern of failed attempts characteristic of brute-force attacks. This aligns with SIEM tuning best practices where aggregation over a time window filters out noise without losing signal.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Add a threshold of 5 failed logins within 5 minutes
Why this is correct
A threshold of five failures within five minutes aggregates events, so isolated typos no longer trigger alerts while sustained bursts still do. This directly satisfies the stem's constraint of cutting false positives without losing brute-force detection, unlike disabling the rule entirely.
- ✗
Disable the rule entirely
Why it's wrong here
Disabling the rule removes all detection, so brute-force attacks pass unnoticed; false positives drop to zero only because nothing alerts. It is tempting when alert fatigue is severe and the rule is deemed noisy, and it is correct when the log source is permanently decommissioned or the rule is wholly superseded.
- ✗
Increase the severity level of the alert
Why it's wrong here
Raising severity changes only the alert's priority label; the rule still fires on every single failed login, so false-positive volume is unchanged. It is tempting because severity tuning feels like tuning, and it is correct when genuine detections are being missed in triage queues and need escalation.
- ✗
Ignore failed logins from known users
Why it's wrong here
Excluding known users suppresses the very repeated failures that reveal credential-stuffing or password-spray attacks against real accounts. It is tempting because most single failed logins come from legitimate users mistyping passwords, and it is correct when service accounts generate predictable noise that no attack would target.
About these practice questions
One of 971 original SSCP practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on SSCP
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A security analyst is tuning a SIEM to reduce false positives. Which of the following actions is most likely to reduce false positives while maintaining detection of real threats?
medium- A.Increase the severity of all alerts to high
- ✓ B.Modify correlation rules to require multiple events before alerting
- C.Disable all anomaly-based detection rules
- D.Create a whitelist for known benign IP addresses
Why B: Modifying correlation rules to require multiple events before alerting reduces false positives by ensuring that a single benign event does not trigger an alert. This technique, often called 'thresholding' or 'event correlation,' filters out noise while still detecting multi-step attack patterns, such as a brute-force login attempt that requires multiple failed logins within a time window.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SSCP practice question is part of Courseiva's free ISC2 certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SSCP exam.