easyMultiple Choice
CRISC Practice Question: Refer to the exhibit
Exhibit
2024-03-01 10:15:23 ERROR [SIEM] Correlation rule 'Brute_Force_SSH' triggered 1500 times in the last hour. Source IPs: 10.0.0.34, 10.0.0.56, 10.0.0.78. Investigation reveals these are internal monitoring servers.
Refer to the exhibit. A SIEM correlation rule 'Brute_Force_SSH' has fired excessively due to traffic from internal monitoring servers. What is the BEST course of action?
⚠ Common exam trap
Test-takers frequently confuse 'tuning' with 'disabling' or 'threshold adjustment', failing to recognize that a targeted exception is the most precise and least risky way to handle known false positives from trusted internal sources.
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 an exception in the rule to exclude internal monitoring server IPs.
The excessive alerts are caused by legitimate traffic from internal monitoring servers, not by an actual brute-force attack. Adding an exception to exclude these known IP addresses in the SIEM correlation rule preserves the rule's detection capability for real threats while eliminating the false positives. This is a standard tuning practice for SIEM rules to maintain operational efficiency without disabling security controls.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Disable the correlation rule to stop false alerts.
Why it's wrong here
Disabling the rule removes detection of genuine brute-force attempts against SSH, not just the monitoring-server noise. The rule exists to alert on repeated authentication failures; tuning it to exclude the monitoring servers' source addresses preserves that coverage. Disabling suits a rule that is wholly obsolete or superseded, not one generating false positives from known internal hosts.
- ✗
Increase the threshold to reduce false positives.
Why it's wrong here
Raising the threshold suppresses alerts for genuine brute-force attempts against SSH, not just the monitoring traffic, weakening detection. It is tempting because tuning thresholds is standard false-positive management, and it would be correct if the rule were merely noisy across benign, non-security traffic rather than a known authorised source.
- ✗
Investigate the monitoring servers for compromise.
Why it's wrong here
The monitoring servers are the known, authorised source generating the alerts, so investigating them for compromise treats expected behaviour as an incident and wastes effort. It is tempting because brute-force alerts warrant investigation generally; that applies when the source is unexpected, not when it is an internal monitoring system.
- ✓
Add an exception in the rule to exclude internal monitoring server IPs.
Why this is correct
Adding an exception for the internal monitoring server IPs suppresses the noisy false positives at source, so the rule still detects genuine brute-force attempts elsewhere. This is more precise than disabling or lowering the rule's severity, preserving detection coverage.
Go deeper
Related to this question
About these practice questions
One of 1,062 original CRISC 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 →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CRISC practice question is part of Courseiva's free ISACA 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 CRISC exam.