286. False Negative

📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 286편
이전 글: 285. False Positive · 다음 글: 287. Snort란 무엇인가

1. 개념

False Negative(미탐) 는 실제 공격이 있었는데 IDS·IPS가 Alert를 만들지 못한 경우입니다. 오탐은 눈에 보이는 문제지만, 미탐은 Alert가 없기 때문에 스스로 드러나지 않는 문제입니다. 보통 다른 경로(호스트 이상, 외부 통보, 사후 조사)로 사건이 발견된 뒤에야 "그때 IDS는 왜 조용했는가"를 묻게 됩니다.

비교	False Positive	False Negative
현상	불필요한 Alert 발생	필요한 Alert 없음
발견 시점	Alert 분석 중 즉시	다른 경로로 사건 발견 후
직접 피해	분석 시간, IPS 오차단	공격 방치
개선 방법	튜닝(범위 축소)	탐지 범위 확대·점검
둘의 관계	줄이려고 튜닝하면 미탐이 늘 수 있음	줄이려고 넓히면 오탐이 늘 수 있음

---

2. 동작 원리

미탐의 원인은 탐지 과정의 어느 단계에서 끊겼는가로 나누어 찾습니다.

[1] 트래픽이 센서에 도달했는가?
     └ 아니오 → 센서 위치·SPAN 설정·경로 밖 통신 (범위 문제)
   ↓ 예
[2] 센서가 패킷을 모두 처리했는가?
     └ 아니오 → 패킷 드롭, 엔진 정지·재시작 (용량·가용성 문제)
   ↓ 예
[3] 엔진이 내용을 해석할 수 있었는가?
     └ 아니오 → 암호화, 비표준 포트, 파싱 실패, 재조립 차이 (가시성 문제)
   ↓ 예
[4] 일치할 규칙이 적재되어 있었는가?
     └ 아니오 → 규칙 없음, 비활성화, 적재 실패, 변수 오류 (규칙 문제)
   ↓ 예
[5] Alert가 기록·전달되었는가?
     └ 아니오 → suppress·threshold, 출력 설정, 수집 누락 (출력 문제)

단계	대표 원인	확인 방법
범위	센서가 없는 구간, 내부 동서 트래픽	네트워크 구성도와 센서 위치 대조
처리	드롭, 엔진 중단	stats.log의 드롭 카운터, 엔진 로그
가시성	TLS, 인코딩·분할 회피	같은 흐름의 app_proto, anomaly 이벤트
규칙	규칙 부재·비활성·적재 실패	규칙 파일의 sid 검색, 시작 로그
출력	억제 설정, 수집 파이프라인 누락	threshold 설정, SIEM 수신 건수 비교

---

3. 주요 특징

• "Alert 없음"은 증거가 아닙니다. 탐지가 동작했다는 것을 확인한 뒤에야 "공격이 없었다"고 말할 수 있습니다.
• 회피 기법은 미탐을 의도적으로 만듭니다. URL 인코딩·대소문자 변형, 패킷 분할과 겹치는 세그먼트, 비표준 포트 사용, 암호화 채널이 대표적입니다. 엔진의 정규화·재조립·프로토콜 자동 식별이 이를 줄이지만 완전하지는 않습니다.
• 튜닝의 부작용으로도 미탐이 생깁니다. 넓게 건 suppress, 오래된 disable 목록, 너무 높은 threshold가 대표적입니다.

---

4. 예시

미탐 원인을 점검하는 실습 예시입니다(Suricata 센서, Rocky/Ubuntu 공통, 경로는 패키지 기본값, 값은 환경마다 다름).

# [규칙] 특정 sid가 적재 규칙 파일에 있는지, 주석 처리(비활성)되었는지
sudo grep -n "sid:1001001;" /var/lib/suricata/rules/suricata.rules /etc/suricata/rules/local.rules
# [규칙] 시작 시 적재 실패 규칙이 있었는지
sudo grep -iE "rules (successfully loaded|failed)" /var/log/suricata/suricata.log | tail -2
# [출력] 억제 설정에 해당 sid가 있는지
sudo grep -n "1001001" /etc/suricata/threshold.config
# [처리] 사건 시간대 드롭 증가 여부
sudo grep "capture.kernel_drops" /var/log/suricata/stats.log | tail -5

사건 당시의 pcap이 보존되어 있다면, 현재 규칙으로 다시 검사해 볼 수 있습니다.

# 보존된 pcap을 오프라인 재검사 (결과는 별도 디렉터리에)
mkdir -p /tmp/retro && sudo suricata -c /etc/suricata/suricata.yaml -r ./incident.pcap -l /tmp/retro
jq -c 'select(.event_type=="alert") | [.timestamp, .alert.signature_id, .alert.signature]' /tmp/retro/eve.json

분석 방법 — 재검사에서 Alert가 나오면 당시에는 규칙이 없었거나 처리 문제가 있었던 것이고, 재검사에서도 없으면 탐지 규칙 자체가 없는 공백입니다. 후자는 로컬 규칙 작성이나 다른 탐지 수단(HIDS, 이상 탐지) 보완 대상입니다.

---

5. 보안 관점

• 미탐은 측정하기 어렵기 때문에 정기적인 탐지 검증이 필요합니다. 알려진 공격 샘플 pcap이나 승인된 모의 훈련으로 "탐지되어야 할 것이 탐지되는가"를 확인합니다.
• 공격 단계별(정찰·침투·확산·유출)로 어떤 탐지 수단이 있는지 탐지 범위 지도를 만들어 두면 공백이 보입니다.
• 센서 상태(드롭, 재시작, 규칙 갱신 실패)는 그 자체로 미탐의 선행 지표이므로 관제 대상에 포함합니다.

---

6. SOC 관점

관제자가 "Alert가 없다"를 판단할 때 질문

• 그 시간대에 센서는 정상 동작했는가(드롭, 재시작, 로그 수집 누락)?
• 해당 트래픽은 센서가 볼 수 있는 경로였는가? 암호화되어 있었는가?
• 탐지할 규칙이 적재되어 있었는가? 억제되지 않았는가?
• 다른 데이터(방화벽 로그, 흐름 기록, HIDS)에는 흔적이 있는가?

다른 경로로 사건 발견 (호스트 이상, 외부 통보)
   ↓ 사건 시간대·관련 IP 확정
   ↓ IDS Alert 검색 → 없음
   ↓ 5단계 점검: 범위 → 처리 → 가시성 → 규칙 → 출력
   ↓ 원인별 개선 요청 (센서 추가 / 용량 / 규칙 작성 / 억제 재검토)

오탐 주의: 미탐을 줄이려고 넓은 규칙을 한꺼번에 추가하면 오탐이 급증합니다. 새 규칙은 탐지 전용으로 관찰한 뒤 확정합니다(285. False Positive). 탐지 공백을 사건 분석에서 기록하는 방법은 299. IDS Incident 분석에서 다룹니다.

---

7. 핵심 정리

• 미탐은 실제 공격에 Alert가 없는 경우로, 스스로 드러나지 않아 다른 경로로 사건이 발견된 뒤에야 확인됩니다.
• 원인은 범위 → 처리 → 가시성 → 규칙 → 출력 단계 중 어디서 끊겼는지로 찾습니다.
• 회피 기법과 과도한 튜닝(suppress·disable·높은 threshold)이 대표적인 미탐 원인입니다.
• 보존된 pcap의 오프라인 재검사로 규칙 공백인지 처리 문제인지 구분할 수 있습니다.
• "Alert 없음"을 "공격 없음"으로 판단하기 전에 센서 상태와 탐지 범위를 확인합니다.