아무도 보지 않는 알람 3,000건

보안 관제실에 들어가서 처음 묻는 질문은 늘 같습니다. "어제 알람이 몇 건이었고, 그중 몇 건을 보셨습니까?" 답이 "3,000건 정도 왔고 주요한 것만 봤습니다"라면, 사실상 아무것도 보지 않은 것입니다.

왜 알람이 쌓이는가

대부분의 SIEM 은 도입 시 제조사 기본 룰셋을 그대로 켭니다. 기본 룰은 모든 고객사 환경에서 동작해야 하므로 가장 넓게 잡혀 있습니다. 특정 조직에서는 정상 업무인 행위가 다른 조직에서는 공격 징후이기 때문입니다.

결과적으로 기본 룰은 그 조직에서 정상인 행위까지 전부 잡아냅니다. 운영자는 며칠 안에 그 룰을 무시하는 법을 배우고, 진짜 탐지가 그 사이에 묻힙니다.

알람을 줄이는 잘못된 방법

임계값을 올리는 방식은 대개 실패합니다. 실패 로그인 5회를 20회로 바꾸면 알람은 줄지만, 공격자는 애초에 임계값 아래에서 움직입니다. 저속 대입 공격은 시간당 3회로도 충분합니다.

자산 중요도를 먼저 넣는다

같은 이벤트라도 자산에 따라 의미가 다릅니다. 개발 서버의 실패 로그인 20회와 결제 승인 서버의 실패 로그인 3회는 전혀 다른 사건입니다. 그런데 대부분의 SIEM 룰은 자산을 구분하지 않습니다.

실무에서는 자산을 세 등급으로만 나눕니다. 다섯 등급으로 나누면 아무도 유지하지 못합니다.

• Tier 1 — 핵심 데이터를 직접 다루거나 인증을 담당하는 자산
• Tier 2 — Tier 1 으로 이동 가능한 경로 위의 자산
• Tier 3 — 그 외

Tier 1 은 임계값을 낮추고 Tier 3 은 상관 분석에만 씁니다. 이 작업만으로 알람이 절반 아래로 떨어지는 경우가 많습니다.

시나리오에서 룰을 역산한다

다음 단계는 공격 시나리오를 먼저 쓰고 그 시나리오를 탐지할 룰을 만드는 것입니다. "외부에서 유출된 계정으로 VPN 접속 → 내부 스캔 → 관리자 계정 탈취 → 데이터 반출" 같은 문장을 쓰고, 각 단계에서 남는 로그를 확인합니다.

로그가 남지 않는 단계가 있으면 그것이 룰 문제가 아니라 로그 수집 범위 문제입니다. 이 구분이 중요합니다. 없는 로그로는 어떤 룰도 만들 수 없습니다.

관찰 모드를 반드시 거친다

새 룰은 바로 알람으로 올리지 않습니다. 2주간 기록만 하고, 발생 건수와 정탐 비율을 확인한 뒤 승격합니다. 이 절차를 건너뛰면 운영팀이 다시 알람을 무시하기 시작하고, 원점으로 돌아갑니다.

정리

목표는 알람 건수를 줄이는 것이 아니라 모든 알람에 대해 판단할 수 있는 상태를 만드는 것입니다. 하루 40건이 오고 40건 모두 검토된다면 그 관제는 작동하는 것입니다.