📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 299편
이전 글: 298. Alert에서 IOC 추출 · 다음 글: 300. Firewall + IDS + IPS 기반 SOC 탐지/대응
1. 개념
IDS Incident 분석은 개별 Alert 판단을 넘어, 여러 Alert와 로그를 묶어 하나의 사건으로 재구성하고 범위·영향·원인을 밝히는 과정입니다. Alert 한 건의 트리아지는 283. IDS Alert에서, 스캔 사건의 분석과 타임라인은 05 영역 247. Incident Timeline 작성, 248. 네트워크 정찰 Incident 분석에서 다뤘습니다. 이 글은 IDS Alert가 출발점인 사건을 분석하는 절차를 다룹니다.
Alert가 사건으로 전환되는 일반적인 기준입니다(조직의 대응 절차가 우선합니다).
| 기준 | 예 |
|---|---|
| 성공 흔적 | 공격 요청에 대한 정상 처리 응답, 실패 뒤 로그인 성공 |
| 내부 출발 이상 | 내부 호스트의 악성 통신 규칙 일치, 내부 스캔 |
| 연쇄 | 같은 대상에 정찰 → 공격 시도 → 이상 통신 순서로 Alert |
| 중요 자산 | 인증 서버·DB·외부 공개 서버 대상의 정탐 Alert |
| 확산 | 같은 IOC가 여러 호스트에서 관찰 |
2. 동작 원리
사건 분석의 단계입니다.
[1] 전환 Alert → 사건 번호 부여, 최초 Alert·판단 근거 기록
↓
[2] 범위 관련 IP·호스트·계정·기간 확정 (IOC로 과거 로그 재검색)
↓
[3] 수집 IDS Alert·메타데이터, 방화벽 세션, 호스트 로그, 패킷 확보·해시 기록
↓
[4] 타임라인 모든 이벤트를 하나의 시간 기준(UTC 등)으로 정렬
↓
[5] 판단 공격 단계, 성공 여부, 영향 자산, 탐지·차단된 지점과 놓친 지점
↓
[6] 대응 요청 차단, 격리, 계정 조치, 추가 조사 → 담당 조직에 전달
↓
[7] 보고·개선 보고서 작성, 탐지 공백 개선(규칙·센서·로그)관제 조직의 역할은 대개 탐지·분석·대응 요청까지이며, 호스트 격리·포렌식은 대응 조직이나 시스템 담당자와 역할을 나눕니다. 역할 경계는 조직 절차를 따릅니다.
3. 주요 특징
타임라인은 여러 장비의 관점을 한 줄로 합친 것이며, 각 행에 출처를 남겨야 검증할 수 있습니다.
| 타임라인 열 | 내용 | 주의 |
|---|---|---|
| 시각 | 통일된 기준(UTC 또는 KST 하나) | 원본 시간대 표기 병기 |
| 출처 | IDS / 방화벽 / 서버 / HIDS / 패킷 | 원본 로그 위치 기록 |
| 주체·대상 | 출발지·목적지, 계정 | NAT 복원 결과 사용 |
| 사건 내용 | 무엇이 관찰되었는가 | 사실만, 추정은 별도 열 |
| 판단 | 정찰 / 시도 / 성공 / 확산 / 유출 | 근거 연결 |
- 사실과 추정을 분리합니다. "웹 셸 업로드"는 추정이고, "POST /upload.php에 200 응답, 이후 /files/x.php 요청"은 사실입니다.
- 탐지 공백도 결과입니다. 어느 단계에서 Alert가 없었는지 기록하면 개선 과제가 됩니다(286. False Negative).
4. 예시
IDS Alert에서 시작한 사건의 타임라인 형식 예시입니다(값은 환경마다 다름, 시각은 KST로 통일, 실제 사건 아님).
# 형식 예시 — 사건 타임라인 (KST)
시각 출처 주체 → 대상 내용 판단
02:05~07 IDS 203.0.113.150 → 192.168.20.0/24 SYN 스캔 임계치 Alert (sid 1001501) 정찰
02:09:12 IDS 203.0.113.150 → 192.168.20.10 웹 경로 조작 패턴 Alert (allowed) 시도
02:09:12 웹 서버 동일 해당 요청 404 실패
02:11:40 IDS 203.0.113.150 → 192.168.20.10 업로드 경로 POST 관련 Alert (allowed) 시도
02:11:40 웹 서버 동일 POST 200, 이후 새 파일 경로 GET 200 반복 성공 의심
02:30:05 FW 192.168.20.10 → 198.51.100.140 허용, 20분 세션, 서버 송신 바이트 큼 이상 통신
02:30:05 IDS — 해당 연결 Alert 없음 (TLS) 탐지 공백분석 방법 — 이 타임라인은 정찰 → 시도(실패) → 시도(성공 의심) → 내부 서버의 외부 통신으로 이어집니다. 마지막 단계는 IDS Alert가 없고 방화벽 세션 로그로만 드러났으므로, 보고서에 탐지 공백(암호화 외부 통신)과 개선안(서버 발신 정책 강화, 흐름 이상 탐지)을 함께 적습니다. 대응 요청은 서버 격리·파일 조사(시스템 담당), 출발지·목적지 차단(방화벽 담당)으로 나눕니다.
5. 보안 관점
- 사건 분석의 목적은 "무슨 Alert가 났는가"가 아니라 "공격이 어디까지 진행되었는가" 를 밝히는 것입니다.
- 증거(로그·pcap)는 수집 즉시 해시를 기록하고 원본을 보존합니다. 로그 보관 기간이 짧으면 사건 초기 기록이 사라질 수 있습니다.
- 범위를 좁게 잡으면 다른 감염 호스트를 놓칩니다. IOC로 전체 로그를 재검색해 범위를 확인합니다.
6. SOC 관점
관제자가 사건 분석 중 확인할 질문
- 최초 접촉은 언제인가? 첫 Alert보다 앞선 흔적(방화벽·흐름 기록)은 없는가?
- 공격은 어느 단계까지 진행되었고, 각 단계를 어느 장비가 보았는가?
- 같은 IOC가 다른 호스트에서도 관찰되는가?
- 대응 요청은 누구에게, 무엇을, 어떤 근거로 전달했는가?
Alert 전환 → 범위 확정 → 증거 수집(해시) → 타임라인
↓
판단: 단계·성공 여부·영향 자산·탐지 공백
↓
대응 요청(담당별) → 조치 결과 확인 → 보고서 → 규칙·센서·정책 개선오탐 주의: 사건으로 전환한 뒤에도 근거가 약해지면 판단을 수정합니다. 처음 가설에 맞는 증거만 모으는 확증 편향을 경계합니다. 조직 차원의 탐지·대응 흐름은 300. Firewall + IDS + IPS 기반 SOC 탐지/대응에서 정리합니다.
7. 핵심 정리
- IDS Incident 분석은 여러 Alert와 로그를 묶어 하나의 사건으로 재구성하고 범위·영향·원인을 밝히는 과정입니다.
- 성공 흔적, 내부 출발 이상, 연쇄, 중요 자산, 확산이 사건 전환의 일반적인 기준입니다.
- 타임라인은 통일된 시간 기준으로 여러 장비의 이벤트를 정렬하고, 출처와 사실·추정을 구분해 기록합니다.
- Alert가 없었던 단계는 탐지 공백으로 기록해 개선 과제로 연결합니다.
- 대응 요청은 담당별로 근거와 함께 전달하고, 보고 후 규칙·센서·정책 개선으로 마무리합니다.
