詳細検索

How to Use Microsoft Sentinel|What is Automation Design to Avoid Missing Critical Incidents?

Avatar
by 西田
2 min read

How to Use Microsoft Sentinel|What is Automation Design to Avoid Missing Critical Incidents?
Translated from 日本語 • View original
西田
西田

Hello, this is Nishida from Colorkrew Security. When you are operating a SOC, you may be tempted by this.

 

"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.

Related Articles