"경고가 너무 많아서 아무도 더 이상 않아요"
"나는 매일 100건 이상의 알림을 받는데, 거의 모두 오탐이야."
"센티넬을 넣었는데, 수동으로 사건을 알아챘어."
SIEM은 '넣으면 끝'이라는 개념이 아닙니다.
운영 설계의 품질은 "사용 가능한 SIEM"과 "노이즈 장치" 모두가 될 수 있습니다.
1. 센티넬이 왜 "시끄러운가"
Sentinel의 기본 규칙을 모두 활성화하면 환경에 따라 하루에 수백 건의 경고가 올 수 있습니다.
주요 원인은 세 가지가 있습니다.
- 규칙 임계값이 너무 낮음: 일반 연산에서도 트리거됨
- 맥락 고려하지 않음: 비즈니스 시스템의 특성을 무시하는 규칙
- 설계되지 않음을 통보: 모든 경고가 모두에게 전달됩니다
이런 상황이 계속된다면, 영업 담당자들은 '경보 피로'에 빠져 정말 위험한 알림을 간과하게 될 것입니다.
2. 규칙 품질 향상을 위한 세 가지 접근법
(1) 규칙 우선순위 분류
주요 전제는 모든 규칙이 같은 비중으로 다뤄지지 않는다는 점입니다.
Sentinel의 분석 규칙은 심각도로 설정할 수 있습니다.
- 높음: 즉각적인 대응 필요(계정 인수, 랜섬웨어 등)
- 중간: 영업시간 중 확인(비정상적인 로그인 위치 등) *** 낮음/정보 제공**: 주간 리뷰만으로도 충분하다
단순히 High 온콜을 알리고, Low는 Log Analytics Workspace에만 누적되어 노이즈를 크게 줄여줍니다.
(2) 환경에 맞춰 조율하기
기본 규칙을 있는 그대로 사용하는 것은 위험합니다.
예를 들어, 글로벌 기업에서 해외 사이트 접속이 정상일 때 "심야 로그인 감지" 규칙이 활성화됩니다.
각 규칙에 대해 다음 사항을 확인해 봅시다:
- 점화 시기 (트리거 조건)
- 당신 환경에서는 정상인가요, 비정상인가요?
- 예외 목록을 설정할 수 있나요?
3. 알림 디자인: 누가, 무엇을, 어디서 받을 것인지
알림의 목적지 설계는 운영 흐름 자체입니다.
흔한 실수: "모든 알림을 모두에게 이메일로 보내기"
대신 이렇게 설계하세요:
- Microsoft Teams 전용 채널→ 높은 경고 + 담당자에게 직접 언급 + PagerDuty 같은 온콜
- 중간 알림 → Teams 알림만 (다음 영업일에 확인됨) *** 낮은 경고→** 주간 보고서로 집계되어 이메일로 발송됩니다
Logic Apps와 Playbook을 사용하면 알림 내용에 따라 수신자 할당을 자동화할 수 있습니다.
4. 책임의 경계를 정하라
누가 어떤 경고에 몇 분 내에 응답할지 명시하지 않으면 SIEM은 매우 쉽습니다.
센티넬이 경보를 발령한 후 누가 조사하고 누가 시스템을 중단할지 미리 결정하세요.
5. "순환 모니터링"으로 만들기 위한 지속적인 개선
한 번 튜닝했다고 해서 규칙이 영원히 최적일 수는 없습니다.
- 새로운 시스템과 서비스가 추가될 때마다 새로운 오탐 패턴이 생성됩니다
- 공격 방식의 변경으로 탐지 규칙의 범위가 감소합니다
"오탐률", "경고 응답률", "SLO 성취율"을 매월 검토하는 시스템을 구축하세요.
6. 컬러크루 시큐리티의 접근 방식
Colorkrew Security에서는 Sentinel의 "구현 후 지원"에 집중하고 있습니다.
**SIEM은 도구일 뿐입니다. 운영 설계의 힘이 그것을 '회전 모니터링'으로 만듭니다. **
우리는 규칙 설계, 알림 설계, 책임 구분, SLO 수립 등 다양한 시스템을 함께 만들어 갑니다.