정/오탐 분석과 룰 튜닝

들어가며 — M1이 만든 알림을 받아 결정하는 자리

M1은 파이프라인의 첫 칸을 화면으로 펼쳐 보였습니다. 에이전트가 호스트에서 로그를 받아 SIEM에 올리고, 상관분석 단계에서 알림이 만들어집니다 — 단일 이벤트가 아니라 여러 이벤트가 한 사건으로 묶이고 심각도와 분류가 붙은 단위입니다. M1의 데모에서 우리는 네 개의 알림을 직접 만들어 보았습니다 — 5710 SSH 브루트포스 패턴, 5712 같은 IP에서 다수 계정 대상 반복 실패의 상관분석, 5715 성공한 로그인(시나리오 전환점), 5902 비인가 계정 생성.

M2는 그 알림을 받아 결정하는 자리입니다. 결정은 두 갈래로 갈라집니다 — 결정적 차단으로 직행하느냐, 잔여 신호로 남겨 다음 단계(M3)로 넘기느냐. 이 갈림을 정확히 긋지 않으면 알림 피로도가 쌓이고, 쌓이면 결국 중요 알림을 무시하는 사고가 납니다. M2의 목표는 그 갈림의 기준을 정탐률과 오탐률의 트레이드오프 속에서 잡는 것입니다.

이 모듈의 학습 목표는 네 가지입니다.

1. 혼동행렬의 네 칸(TP · FP · TN · FN)을 실무에서 읽을 수 있습니다 — 그리고 Precision과 Recall의 트레이드오프가 룰 튜닝에서 어떤 무게로 작동하는지를 말할 수 있습니다.
2. 오탐이 발생하는 네 가지 원인을 구분할 수 있습니다 — 룰 조건의 과광범위, 환경 특수성, 컨텍스트 부재, 자산 분류 미흡.
3. 표준 트리아지 절차의 다섯 단계를 밟을 수 있습니다 — 접수 → 컨텍스트 수집 → 판정 → 에스컬레이션 → 종료 기록.
4. M1에서 만든 알림(5710 · 5712 · 5715 · 5902)이 M2에서 어떻게 정/오탐으로 갈라지는지 화면으로 따라갈 수 있습니다 — 그리고 그 잔여 신호가 M3의 가중합 입력으로 들어가는 연결을 본문에서 가리킬 수 있습니다.

§A. 혼동행렬 — 정탐과 오탐의 네 칸

〔M0에서 약속한 다섯 지표 중 “오탐률”이 여기서 정의됩니다. 정탐률과 오탐률의 트레이드오프가 M2의 중심 문제입니다.〕

정탐(True Positive) 은 “실제 침해가 있었고 룰셋이 그것을 알림으로 잡았다”입니다. 오탐(False Positive) 은 “정상 이벤트가 룰셋에 의해 알림으로 잡혔다”입니다. 미탐(False Negative) 은 “실제 침해가 있었는데 룰셋이 알림을 만들지 못했다”입니다. 진짜정상(True Negative) 은 “정상 이벤트가 룰셋에서도 정상으로 통과했다”입니다 — 일상의 대부분을 차지하고, 보통 명시적으로 다루지 않습니다.

이 네 칸의 비율이 운영의 성격을 가릅니다. 룰을 빡세게 잡으면 정탐(TP)은 늘지만 오탐(FP)도 같이 늘어납니다. 룰을 느슨하게 잡으면 오탐은 줄지만 미탐(FN)이 늘어납니다. 이 줄다리기가 Precision(정밀도)과 Recall(재현율)의 트레이드오프입니다.

Precision과 Recall의 정량 목표는 이 모듈의 준거에 실재하지 않습니다 — 조직의 위험 허용도와 자산 가치에 따라 다릅니다. M2에서는 “두 축이 트레이드오프 관계에 있다”는 사실만 짚고, 환경에 맞는 목표는 운영자가 정합니다.

§B. 왜 오탐이 진짜 문제인가 — 알림 피로도

〔M0에서 다섯 지표 중 “오탐률”을 짚었습니다. 여기서는 왜 오탐률이 낮을수록 좋은지를 작동 메커니즘으로 펼쳐 봅니다.〕

오탐이 쌓이면 세 단계의 연쇄 반응이 일어납니다.

1. 알림 피로도(Alert Fatigue) — 분석가가 하루에 수백 건의 오탐을 처리하면서 판단 근육이 굳습니다. 정상 패턴과 침해 패턴을 가르는 감각이 무뎌집니다.
2. 중요 알림 무시 — 피로도가 임계를 넘으면 새로 들어오는 알림 자체를 무시하기 시작합니다. 이 상태에서 정탐이 한 건 들어오면 그것도 같이 묻힙니다.
3. 실제 침해 누락 — 정탐 한 건이 묻히면 MTTD(평균 탐지 시간)가 그만큼 길어지고, M4의 차단까지의 시간도 같이 늘어납니다. M5의 사후 분석에서 “왜 그 시점에 못 잡았나”를 추적하면 보통 이 연쇄의 끝에 도달합니다.

이 표는 절대 수치가 아니라 작동 메커니즘의 형태입니다. 환경마다 “임계 오탐률”은 다르고, 그 값은 운영자가 자기 팀의 처리량·교육 수준·자동화율에 맞춰 정합니다. M2에서는 **“오탐률이 올라가면 분석가의 판정이 무뎌지고 그 무뎌짐이 정탐까지 같이 묻는다”**는 메커니즘만 짚습니다.

〔M3에서 다룰 “리스크 스코어 누적”은 이 연쇄를 끊기 위한 마지막 안전망입니다 — 단건은 무시하되 같은 패턴이 누적되면 점수를 상향해 사람 검토로 보냅니다. M2에서는 “누적”의 첫 단계만 짚고, 실제 점수 구간은 M3에서 확정합니다.〕

§C. 오탐 발생 원인 — 네 유형

〔이 네 유형은 환경마다 흔한 순서가 다르지만, 거의 모든 환경에서 네 가지가 다 등장합니다. 하나씩 짚고 데모 케이스에서 각각을 봅니다.〕

네 유형은 서로 겹칩니다. 한 건의 오탐이 이 중 어디에 해당하는지 정확히 가르는 것이 트리아지의 출발점이고, 그 가름에 따라 위 네 번째 열의 튜닝 방향이 갈라집니다. 이 가름이 §D의 표준 절차 안에서 일어납니다.

§D. 표준 트리아지 절차 — 다섯 단계

〔M0에서 약속한 “이전 모듈의 산출물이 다음 모듈의 입력”이 여기서 작동합니다 — M1이 만든 알림이 M2의 트리아지 큐로 들어옵니다.〕

컨텍스트 수집 체크리스트 — 단계 2가 M2의 핵심입니다. 이 단계가 비어 있으면 단계 3의 판정이 약해집니다.

〔M1의 5710·5712·5715·5902 알림이 이 체크리스트의 어디에서 정탐이 되고 어디에서 오탐이 되는지를, 데모 구간에서 케이스별로 봅니다.〕

§E. 튜닝 이력 관리 — Git으로, 만료일과 함께

〔M1의 §E에서 “Detection-as-Code”의 세 약속을 짚었습니다 — Git으로 버전 관리, 배포 전 자동 테스트, 카탈로그와 함께. M2에서는 그 약속의 두 번째 — “룰을 튜닝한 기록”을 같은 방식으로 관리합니다.〕

룰을 튜닝할 때는 두 가지를 같이 합니다.

1. 룰 자체를 Git으로 관리 — PR 리뷰, 롤백, 변경 이력 추적. “이 룰이 언제 켜졌고 누가 검토했는가”가 바이트로 남습니다.
2. 예외 처리에는 반드시 만료일 — 만료일 없는 예외는 영구 예외가 됩니다. 영구 예외는 룰셋의 사각지대를 키우는 가장 흔한 경로입니다.

만료일을 다루는 두 패턴:

이 두 패턴을 섞지 마십시오. 일회성 만료를 갱신 패턴으로 다루면 만료일이 무의미해지고, 갱신 패턴을 일회성으로 두면 분기마다 다시 PR을 올려야 합니다. 데모 케이스 B에서 일회성 만료의 예를, 케이스 C에서 자산 태그 기반 억제를 다룹니다.

§F. 데모 ① — 케이스 A, 관리자 배포 스크립트 (10분)

〔M1에서 logger로 같은 알림을 만들어낸 핵심 기법을 그대로 이어갑니다. 여기서는 “M1에서 만든 알림을 M2에서 어떻게 판정하는가”를 화면으로 봅니다.〕

케이스 A의 상황

화면 1. M1에서 만든 알림이 M2 큐에 들어옴

관리자가 배포 스크립트(/opt/deploy/bin/release.sh)를 실행하면, 그 안에서 호출한 명령들이 Wazuh의 명령 실행 룰에 한 줄씩 잡힙니다. M1의 5710과 같은 형태 — 룰 ID가 한 줄씩 찍히지만, 이건 정상 업무 패턴입니다. 관리자가 의도한 배포이고, 명령 실행이 비정상 동작은 아닙니다.

화면 2. §D의 체크리스트를 돌림

이 알림에 대해 §D의 체크리스트를 적용합니다.

• 사용자 — deploy_user, 평소 배포 시간대에 활동 중. 평소 시점.
• 호스트 — 배포 서버, 태그 role=deploy-server.
• 프로세스 — 부모 프로세스가 /opt/deploy/bin/release.sh. 정상 배포 체인.
• 자산 태그 — purpose=release-pipeline 등록돼 있음.
• 시점 — 정기 배포 시간대.

다섯 항목이 모두 “정상 패턴”을 가리킵니다. 이 시점에서 판정은 오탐입니다 — §A의 FP 칸.

화면 3. 판정과 종료 기록

이 알림을 오탐으로 닫습니다. 그런데 닫기 전에 §E의 첫 번째 약속 — 룰 자체를 Git으로 관리 — 을 적용합니다.

<rule id="100010" level="0">
<if_sid>5710</if_sid>
<program_name>/opt/deploy/bin/release.sh</program_name>
<description>Tuning A: deploy script in known release path — suppress</description>
</rule>

여기서 핵심은 두 가지입니다.

1. 조건 정교화 — 부모 프로세스가 /opt/deploy/bin/release.sh인 경우만 level="0"으로 떨어뜨립니다. 같은 5710 알림이라도 부모 프로세스가 다른 경우는 그대로 발화합니다.
2. Git으로 관리 — 이 룰을 PR로 올리고 동료 리뷰를 받습니다. “이 경로가 정말 배포 스크립트인가”를 다른 사람이 확인합니다.

이 케이스는 §C의 “유형 1. 룰 조건 과광범위”의 사례입니다. 룰이 정상 패턴과 비정상 패턴을 가리지 못했던 것이 원인이었고, 부모 프로세스 조건을 추가해 가렸습니다.

〔같은 시간에 M1의 5715 — 브루트포스 끝에 성공한 로그인 — 은 여기서 오탐이 아닙니다. 그건 같은 IP에서 반복 실패 끝에 정탐 시나리오로 묶이므로, 조건 정교화가 아니라 §D의 컨텍스트 수집에서 “같은 IP의 5712가 직전에 발화했는가”를 보는 절차가 필요합니다. 이 절차가 §G의 케이스 B와 다릅니다.〕

§G. 데모 ② — 케이스 B, 백업 에이전트 (10분)

케이스 B의 상황

화면 1. 새벽 시간에 대량 파일 접근이 탐지됨

백업 에이전트(/usr/local/bin/backup-agent)가 새벽 3시에 /data/ 하위 50,000개 파일을 순회하며 읽습니다. 랜섬웨어 룰(5712과 같은 상관분석 계열)이 “짧은 시간 내 다수 파일 접근” 패턴을 잡아 알림을 만듭니다. M1의 5712와 같은 형태 — 한 사건으로 묶인 알림이지만, 이건 정기 백업입니다.

화면 2. 체크리스트 — 환경 특수성을 가림

§D의 체크리스트를 적용합니다.

• 사용자 — backup_user, 평소 새벽 3시 활동.
• 호스트 — 백업 서버, 태그 role=backup-server.
• 프로세스 — 부모가 /usr/local/bin/backup-agent.
• 자산 태그 — purpose=daily-backup 등록돼 있음.
• 시점 — 새벽 3시, 정기 백업 시간대.

여기서 §C의 “유형 2. 환경 특수성”이 발화합니다. 정상 업무 패턴이 공격 패턴과 닮은 경우 — 대량 파일 접근은 랜섬웨어의 전형이지만, 백업 에이전트도 똑같이 대량 접근을 합니다. 케이스 A의 “조건 정교화”만으로는 부족합니다 — 부모 프로세스가 정상이더라도 시간이 지나면 부모 프로세스가 변할 수 있고(업데이트), 경로가 바뀌면 룰이 무력해집니다.

화면 3. 만료일을 가진 예외 처리

§E의 두 번째 패턴 — 일회성 만료 — 로 갑니다.

<rule id="100011" level="0" timeframe="2026-09-01T03:00:00+09:00-2026-12-31T03:00:00+09:00">
<if_sid>5712</if_sid>
<program_name>/usr/local/bin/backup-agent</program_name>
<description>Tuning B: scheduled backup agent — expires Q4 2026</description>
</rule>

두 가지를 같이 박습니다.

1. 프로세스·경로 기반 억제 — program_name이 백업 에이전트인 경우만 level="0"으로 떨어뜨립니다.
2. 만료일 — timeframe에 종료 시각을 박습니다. 만료일 이후에는 룰이 자동으로 다시 발화합니다. 이 시점이 되면 분기 검토 PR이 올라와야 하고, 그때 “이 예외를 연장할 것인가, 정식 룰로 흡수할 것인가, 폐기할 것인가”를 결정합니다.

이 케이스는 §E의 “두 약속”이 둘 다 발화하는 자리입니다. 룰 자체는 Git으로 관리하고(첫 번째 약속), 예외에 만료일을 박아 영구 예외가 되는 것을 막습니다(두 번째 약속).

§H. 데모 ③ — 케이스 C, 내부 취약점 스캐너 (15분)

케이스 C의 상황

화면 1. 평소와 다른 시간에 다수 계정 대상 SSH 실패가 탐지됨

취약점 스캐너(nessusd, openvas-scanner 등)가 주간 점검 시간에 다수 계정에 대해 SSH 로그인을 시도합니다. 같은 IP에서 다수 계정 대상 반복 실패의 패턴은 M1의 5712와 같은 형태로 발화합니다 — 같은 IP, 짧은 시간 안의 반복 실패를 한 사건으로 묶는 상관분석 룰입니다. 이 알림이 정탐인 환경과 오탐인 환경이 갈립니다.

화면 2. 환경에 따라 갈리는 판정

§D의 체크리스트를 적용합니다.

• 자산 태그 — 점검 대상 호스트에 role=vuln-scan-source가 등록돼 있고, policy=periodic-vuln-scan이 박혀 있습니다.
• 사용자 — vuln_scanner 서비스 계정.
• 시점 — 정기 점검 시간대.

자산 태그에 policy=periodic-vuln-scan이 박혀 있는 환경에서는 이 알림을 오탐으로 닫습니다. 그러나 자산 태그가 없는 환경에서는 — 어떤 IP가 어떤 의도로 다수 계정을 시도하는지 모르는 환경에서는 — 이 알림을 정탐 후보로 유지하고 사람 검토로 보냅니다.

이 갈림이 §C의 “유형 3. 컨텍스트 부재”의 사례입니다. 컨텍스트가 있으면 오탐, 없으면 정탐 후보 — 같은 알림이 환경에 따라 다른 판정을 받습니다. 컨텍스트는 §E의 Git 기반 자산 태그로만 들어옵니다.

화면 3. 자산 태그 기반 억제

<rule id="100012" level="0">
<if_sid>5712</if_sid>
<fields>agent.tags</fields>
<match>policy=periodic-vuln-scan</match>
<description>Tuning C: periodic vuln scan from tagged source — suppress</description>
</rule>

여기서 핵심은 “자산 태그가 룰셋에 들어와야 한다”는 것입니다. agent.tags는 Wazuh가 호스트 메타데이터로 받는 필드이고, 이 필드에 policy=periodic-vuln-scan이 박혀 있어야 이 룰이 발화합니다. 자산 태그가 없으면 룰이 작동하지 않고, 알림은 그대로 사람 검토로 갑니다 — 부재가 자동으로 “안전”이 되지 않습니다.

이 케이스가 §C의 “유형 4. 자산 분류 미흡”과 겹치는 지점입니다. 자산 태그가 없으면 자산 분류가 안 된 것이고, 그건 이 환경의 보안 정책 자체가 미흡하다는 뜻입니다 — 단순히 오탐을 닫는 문제가 아니라 자산 인벤토리 자체를 손보는 문제로 이어집니다.

§I. 4가지 튜닝 방식 비교

〔M2의 마지막 구간입니다. §F·§G·§H에서 적용한 세 가지 — 조건 정교화·예외 처리·자산 태그 기반 억제 — 와 함께 “룰 레벨 조정”과 “리스크 스코어 누적”을 합쳐 네 가지를 비교합니다.〕

네 방식의 선택 기준:

• 룰 레벨 조정은 마지막 수단입니다. 다른 세 방식으로 가를 수 없을 때만 씁니다.
• 조건 정교화는 정상 패턴의 부모가 안정적이고(케이스 A의 배포 스크립트처럼) 자산 인벤토리가 깨끗할 때 씁니다.
• 예외 처리는 케이스 B처럼 정해진 기간만 정상인 이벤트에 씁니다. 만료일이 없으면 안 됩니다.
• 리스크 스코어 누적은 단건으로는 가르기 어렵지만 같은 패턴이 반복되면 의미가 있는 신호에 씁니다.

〔“리스크 스코어 누적” 방식은 M3의 스코어링 데모로 직결됩니다 — M3에서 단일 신호의 가중합으로 점수를 만들고, 그 점수를 구간으로 갈라 자동종료·LLM 트리아지·사람 에스컬레이션으로 라우팅합니다. M2에서는 “누적이라는 발상이 있다”까지만 짚고, 실제 점수 구간과 임계값은 M3에서 확정합니다.〕

§J. 정리 — M2가 만들고 M3에 넘기는 것

• 혼동행렬 — TP · FP · TN · FN의 네 칸, Precision과 Recall의 트레이드오프. 정량 목표는 환경마다 다릅니다.
• 알림 피로도 — 오탐이 쌓이면 분석가의 판단이 무뎌지고 정탐까지 같이 묻힙니다. 이 연쇄가 M2가 풀어야 할 문제의 본질입니다.
• 오탐 원인 네 유형 — 룰 조건 과광범위 · 환경 특수성 · 컨텍스트 부재 · 자산 분류 미흡.
• 표준 트리아지 절차 — 접수 → 컨텍스트 수집 → 판정 → 에스컬레이션 → 종료 기록의 다섯 단계.
• 튜닝 이력 관리 — Git으로 룰을 관리하고, 예외에는 반드시 만료일을 박습니다.
• M2가 만든 산출물 — §F·§G·§H의 세 케이스에 적용한 조건 정교화·예외 처리·자산 태그 기반 억제의 세 가지 튜닝과, §I에서 다룬 네 가지 방식의 선택 기준. 이 잔여 신호 — 단일 룰로는 가르기 어려운 패턴들 — 가 M3의 가중합 입력으로 들어갑니다.

M1의 5710·5712·5715·5902 알림이 M2의 트리아지 큐로 들어왔고, M2는 그것을 정/오탐으로 갈라 결정적 차단으로 보내거나 잔여 신호로 남겼습니다. M3로 넘어갑니다 — 잔여 신호가 M3의 점수 모델 안에서 어떻게 다시 라우팅되는지를 봅니다.