"This alert is a false positive every time, so I want to close it automatically."
"It will be easier if you automate everything with a playbook."
"I want to set up auto-close to reduce noise."
I understand how you feel.
However, automatic closing is a "poison" that misses serious incidents if used incorrectly.
1. Accident Patterns Caused by Auto Closing
This is a failure case that is actually likely to happen.
Pattern A: Looks normal but actually attacks
Set a rule called "Access from known IPs will be automatically closed".
However, if the IP was a VPN server compromised by an attacker, all compromised access will be automatically closed.
Pattern B: False positive rules are too broad
I set it to "close 〇〇 operations during business hours", but the conditions are too broad, and the real unauthorized operations are also closed.
Pattern C: Loss of Audit Trail
Automatically closed alerts are not recorded in the audit log, making it impossible to track "what happened" later.
2. 3 Principles for Using Auto Close Safely
Principle (1): Target only "Low/Informational" false positives first
Limit auto-close to those with low Severity.
Automatic closing to High/Medium alerts is risky unless there is a lot of confirmation, so start with the less important ones.
Safe Auto Closing Candidates:
- Known false positives generated by periodic batch processing
- Alerts with the monitoring tool's own health check
- Communication from the test environment
Principle (2): Always Log the Reason for Closing
Auto-closed alerts should be able to see why they were closed later.
In Sentinel playbooks, be sure to record the following information as comments when closing:
- Auto-close reason (rule name)
- Conditions applied (IP address, username, etc.)
- Close execution time
Principle (3): Review the number of auto-closed cases on a weekly basis
Check weekly to see if the auto-close continues to increase.
A spike is a sign of a "misconfigured rule" or "intentional mass outbreak by an attacker."
3. Colorkrew Security's Approach
At Colorkrew Security, we'll work together to "draw the boundaries" of automation design.
**Automation is a productivity weapon, and if you design it wrong, it can be a blindfold to threats. **
We support the design of stages that safely proceed with automation and the design of records that can withstand audits.