EDR 경보 피로를 줄이는 운영 규칙: 더 많이 울리게 하지 말 것
EDR을 도입했지만 대응 속도가 느려지는 조직을 위해 경보 등급, 억제 조건, 튜닝 회의를 설계하는 방법을 제시한다. EDR·Alert Fatigue·SOC 관점에서 공격 경로를 쉬운 예로 풀고 예방, 탐지, 대응 순서로 확인할 항목을 제시한다.
핵심 요약
EDR 경보 피로는 단순히 알림이 많은 상태가 아니라 중요한 경보가 대기열 속에서 늦게 처리되고, 분석가마다 판단이 달라지며, 억제 규칙이 탐지 공백으로 바뀌는 상태다. 등급 기준, 필수 문맥, 중복 상관분석, 억제 만료일, 튜닝 검증, 텔레메트리 건강 지표를 함께 운영해야 한다.
EDR을 도입했는데 대응 속도가 느려졌다면 제품의 탐지 수가 부족해서가 아닐 가능성이 크다. 한 행위가 프로세스, 파일, 레지스트리, 네트워크 이벤트로 나뉘어 여러 번 울리고, 자산 중요도나 사용자 역할이 붙지 않은 채 대기열에 쌓이면 분석가는 매번 같은 조사를 반복한다. 결국 실제 침해 신호도 “또 하나의 흔한 경보”로 취급된다.
경보 피로를 줄인다는 이유로 규칙을 끄거나 광범위한 예외를 추가하는 것도 위험하다. 좋은 운영은 경보를 조용하게 만드는 것이 아니라, 같은 공격 흐름을 하나의 사건으로 묶고, 필요한 문맥을 자동으로 붙이며, 조치 우선순위를 일관되게 만드는 것이다.
먼저 경보와 사건을 구분한다
경보(alert)는 하나의 탐지 조건이 충족된 기록이고, 사건(case 또는 incident)은 여러 경보와 증거를 묶어 사람이 판단하는 단위다. EDR 콘솔에서 경보 하나마다 티켓을 만들면 중복 작업이 폭증한다. 다음 기준으로 상관분석 키를 정한다.
- 같은 호스트·사용자·프로세스 트리에서 짧은 시간 안에 발생한 이벤트
- 동일 파일 해시, 명령줄, 원격 목적지, 자격증명 사용 흔적
- 한 공격 단계에서 다음 단계로 이어지는 행위 체인
- 이미 격리된 호스트에서 반복 발생한 동일 탐지
- 소프트웨어 배포나 관리 작업처럼 승인된 변경 창과 일치하는 이벤트
상관분석은 단순 중복 제거와 다르다. 원본 경보를 버리지 않고 사건 아래에 연결해 시간순으로 볼 수 있어야 한다. 그래야 억제 규칙이 잘못됐을 때 원본을 재분석할 수 있다.
등급은 탐지 이름이 아니라 영향과 확신으로 정한다
경보 등급을 제품의 기본 심각도에 그대로 맡기지 않는다. 최소한 다음 네 축을 사용한다.
- 자산 중요도: 일반 단말, 관리자 단말, 빌드 서버, 도메인·신원 인프라 등
- 행위 영향: 실행, 자격증명 접근, 권한 상승, 지속성, 외부 통신, 데이터 접근 등
- 탐지 확신: 단일 약한 신호인지, 여러 독립 신호가 일치하는지
- 현재 통제 상태: 호스트 격리, 프로세스 종료, 계정 잠금이 이미 완료됐는지
예를 들어 “PowerShell 실행”은 흔하지만, 빌드 서버에서 새 관리자 계정 생성과 외부 업로드가 이어졌다면 높은 우선순위다. 반대로 알려진 배포 도구가 승인된 변경 창에 같은 명령을 실행했다면 낮은 우선순위로 묶을 수 있다. 중요한 것은 제품 이름이 아니라 조직의 자산과 업무 맥락이다.
| 등급 예시 | 판단 기준 | 첫 조치 예시 |
|---|---|---|
| 긴급 | 중요 자산에서 침해 가능성이 높고 피해가 진행 중 | 즉시 담당 호출, 격리·계정 통제 검토 |
| 높음 | 복수 신호가 일치하거나 자격증명·지속성 행위 포함 | 정해진 시간 안에 분석 시작, 범위 확인 |
| 중간 | 의심 행위지만 업무 활동과 구분 필요 | 관련 변경·사용자 확인, 추가 증거 수집 |
| 낮음 | 정보성·기준선 이탈 또는 이미 통제된 반복 | 배치 검토, 튜닝 후보로 분류 |
구체적인 응답 시간은 인력과 서비스 중요도에 맞춰 정한다. 모든 경보에 15분 목표를 붙이면 지켜지지 않는 SLA만 늘어난다. 대신 긴급·높음 등급의 대기열 상한과 야간 호출 기준을 명확히 한다.
분석가 화면에 자동으로 붙여야 할 문맥
- 호스트 소유자, 자산 등급, 운영체제, EDR 에이전트 상태
- 사용자 부서·권한·최근 인증·MFA·계정 변경 이력
- 프로세스 트리, 부모·자식 명령줄, 파일 해시와 서명 상태
- 최초·최종 관찰 시각, 다른 호스트에서의 빈도, 유사 사건
- 네트워크 목적지, DNS, 프록시·방화벽 기록, 외부 평판 정보
- 변경 티켓, 소프트웨어 배포, 취약점 스캔 등 정상 작업과의 연관
- 현재 자동 조치와 성공 여부, 되돌리기 방법
이 정보가 없으면 분석가는 여러 콘솔을 오가며 같은 질문을 반복한다. 데이터 필드는 보안 로그 파이프라인의 최소 요건에 맞춰 공통 식별자와 시간 기준을 통일하는 편이 좋다.
억제와 허용 목록은 만료되는 코드처럼 관리한다
억제 규칙에는 최소한 소유자, 근거, 적용 범위, 생성일, 만료일, 검토 샘플, 롤백 방법이 있어야 한다. “이 프로그램은 정상”이라는 이유로 파일명이나 디렉터리 전체를 제외하면 공격자가 같은 경로를 악용할 수 있다. 가능한 한 다음처럼 좁힌다.
- 서명자와 해시, 배포 도구, 부모 프로세스를 함께 조건으로 사용
- 특정 사용자·호스트 그룹과 변경 시간대에만 적용
- 탐지 자체를 끄기보다 낮은 등급 또는 사건 묶음으로 전환
- 관찰 모드에서 실제 데이터에 미치는 영향을 확인한 뒤 적용
- 만료 전에 자동 알림하고, 재승인 없으면 원래 상태로 복구
튜닝 회의에서 확인할 숫자
경보 총량 감소만 목표로 삼으면 위험한 규칙을 끄는 팀이 좋은 성과를 얻는다. 대신 다음 지표를 본다.
- 긴급·높음 등급의 평균보다 상위 백분위 첫 확인 시간
- 사건 대기열의 최대 연령과 SLA 초과 건수
- 경보가 사건으로 묶이는 비율과 사건당 중복 경보 수
- 분석 후 정상으로 종결된 비율과 근거가 불충분한 종결 비율
- 재개된 사건, 후속 사고에서 놓친 것으로 확인된 경보 수
- 억제 규칙 수, 만료 초과 수, 규칙별 마지막 적중 시각
- 호스트별 텔레메트리 지연·누락, 에이전트 비정상·비활성 비율
- 자동 격리·프로세스 종료·파일 삭제의 성공률과 오작동률
탐지 품질은 실제 사고를 역으로 재생해 검증해야 한다. 사고 타임라인의 각 단계가 어떤 경보로 잡혔는지, 왜 등급이 낮았는지, 어떤 로그가 없었는지 확인한다. MITRE ATT&CK의 탐지 전략은 기술별로 필요한 데이터와 분석 논리를 점검하는 공통 언어로 활용할 수 있다.
자주 발생하는 실패 모드
| 실패 모드 | 결과 | 개선 방법 |
|---|---|---|
| 모든 경보를 티켓으로 생성 | 중복 티켓과 수동 복사가 폭증한다 | 사건 단위 상관분석과 원본 연결을 사용한다 |
| 기본 심각도만 신뢰 | 중요 자산의 약한 신호를 놓친다 | 자산·사용자·행위 맥락으로 재등급한다 |
| 파일명·폴더 전체 제외 | 공격자가 허용 경로를 악용한다 | 서명·해시·부모 프로세스·범위를 결합한다 |
| 경보량만 성과 지표로 사용 | 규칙을 꺼서 숫자를 줄인다 | 대기시간, 재개율, 놓친 탐지를 함께 본다 |
| 에이전트 상태를 별도 운영 | “경보 없음”을 “안전”으로 오해한다 | 텔레메트리 건강을 보안 경보로 취급한다 |
| 자동 격리를 검증하지 않음 | 업무 중단 또는 격리 실패가 반복된다 | 대상군별 시험과 되돌리기 절차를 둔다 |
예시: 정상 관리 도구와 침해 행위 구분
원격 관리 도구가 cmd.exe와 PowerShell을 실행해 파일을 내려받는 경보가 매일 발생한다고 하자. 단순히 도구 경로를 허용하면 공격자가 해당 도구나 경로를 악용할 때 놓칠 수 있다.
대신 정상 배포는 승인된 서비스 계정, 서명된 부모 프로세스, 관리 서버 IP, 변경 시간대, 예상 명령 패턴과 일치할 때 하나의 낮은 우선순위 사건으로 묶는다. 이 조건에서 벗어나거나, 자격증명 덤프·새 서비스 생성·외부 전송이 이어지면 즉시 높은 등급으로 승격한다.
이처럼 디셉션 자산에서 발생한 접근은 정상 업무 가능성이 낮으므로 강한 신호가 될 수 있다. 허니팟과 디셉션 기술을 EDR 사건과 연결하면 낮은 오탐의 조기 경보 채널을 만들 수 있다.
운영 체크리스트
- 경보와 사건의 정의, 상관분석 기준이 문서화돼 있는가.
- 등급 기준에 자산 중요도와 현재 통제 상태가 포함되는가.
- 분석가 화면에 사용자·호스트·프로세스·변경 문맥이 자동으로 붙는가.
- 억제 규칙마다 소유자와 만료일, 롤백 방법이 있는가.
- 신규 튜닝을 관찰 모드와 과거 사건 재생으로 검증하는가.
- 텔레메트리 지연과 에이전트 비활성을 별도 경보로 보는가.
- 자동 대응 실패와 오작동을 측정하는가.
- 월별 튜닝 회의에서 놓친 탐지와 재개 사건을 함께 검토하는가.
- 긴급 사건은 클라우드 사고 대응 플레이북 같은 공통 대응 체계로 넘길 수 있는가.
참고 기준
최종 판단
EDR 경보 피로의 해결책은 알림을 더 많이 자동 종료하는 것이 아니다. 어떤 경보를 사건으로 묶고, 어떤 문맥으로 우선순위를 바꾸며, 어떤 억제를 언제 되돌릴지 운영 규칙을 만드는 일이다. 가장 먼저 확인할 것은 하루 경보 수가 아니라 긴급 사건이 대기열에서 얼마나 오래 머물고 있는지, 그리고 경보가 없는 호스트에서 텔레메트리가 실제로 정상인지다.
전체 댓글 0개