048. SIEM·로그 수집 — 수집·정규화 장애 대응 절차

SIEM SIEM · 보안관제 SIEM장애 Soc Wazuh 보안관제 장애대응

SIEM · 보안관제 › A. SIEM 구조와 로그 수집 · 48/50편
학습 단계: 검색·대시보드·운영
실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Wazuh 4.x 올인원 / Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

047. SIEM·로그 수집 — SIEM 운영 체크리스트 — 일일·주간 점검

1. 개념

SIEM 장애는 그 자체로 보안 사고의 위험을 높입니다. 장애 중에 공격이 있었다면 볼 수 없었기 때문입니다. 그래서 SIEM 장애 대응은 "복구"로 끝나지 않고, 공백 기간에 무슨 일이 있었는지 보완 확인까지 포함해야 합니다.

SIEM 장애 대응 절차
 ① 감지      : 점검·대시보드·사용자 문의
 ② 영향 평가 : 어떤 호스트·소스·기간이 안 보이는가(040편 지도)
 ③ 임시 조치 : 중요 자산은 로컬 로그 직접 확인 체계로 전환
 ④ 복구      : 끊긴 구간 수리(설정·서비스·자원)
 ⑤ 데이터 보완: 원본에서 재수집·재전송 가능 여부 확인
 ⑥ 공백 검토 : 공백 기간의 로컬 로그·네트워크 로그로 이상 여부 확인
 ⑦ 보고·개선 : 원인·영향·재발 방지(점검·룰·자동화)

핵심: 복구 후 "공백 기간에 무엇이 있었나"까지 확인해야 종료

장애 원인이 공격자의 의도적 차단(에이전트 중지·로그 전송 차단)일 수도 있으므로, ⑥ 공백 검토 단계에서 방어 회피 가능성을 반드시 함께 봅니다.

2. 왜 중요한가

SIEM 공백은 곧 관제 사각입니다.
영향 범위를 정확히 알아야 보완 조사 범위를 정할 수 있습니다.
원인이 공격일 가능성을 배제하지 않아야 합니다.

3. 핵심 명령어 / 설정

단계	산출물
영향 평가	영향 호스트·소스·기간 표
임시 조치	대체 확인 방법 기록
데이터 보완	재수집 여부·범위
공백 검토	로컬·네트워크 로그 확인 결과
보고	원인·영향·개선

4. 실습 (실습 예시)

# 공백 기간 로컬 로그 보완 확인 예 (분석 방법)
GAP_START="2026-10-09 02:00"; GAP_END="2026-10-09 05:00"
# 중요 호스트의 공백 기간 인증 이벤트를 직접 확인
ssh web01 "sudo journalctl -u sshd --since '$GAP_START' --until '$GAP_END' | grep -E 'Accepted|Failed' | tail"
# 원본 로그가 남아 있으면 재전송 검토(에이전트는 기본적으로 새 로그만 읽음 → 별도 수집 필요)
ssh web01 "sudo ls -la /var/log/secure*"

5. 정상 상태

공백 03시간, 영향: db01 audit 소스
보완 확인: 공백 기간 로컬 audit.log 에 의심 이벤트 없음
원인: 디스크 부족으로 auditd 일시 중지 → 증설·경보 추가

영향 범위·보완 확인 결과·원인·개선이 모두 기록되면 장애 대응이 완료된 상태입니다.

6. 이상 상태

복구 후 바로 종료 처리
→ 2주 뒤 사고 조사에서 공백 기간 중 web01 외부 로그인 성공 발견

공백 검토 생략 → 공백 중 침투를 2주간 모름
SIEM 장애 = 잠재적 보안 사고로 다뤄야 함
종료 조건에 공백 검토를 필수로 둬야 함

7. 로그 분석 (분석 방법)

장애 대응 판단 흐름입니다(가상의 예시).

[장애 감지]
   ↓
[영향 평가] 범위(호스트·소스·기간) · 자산 중요도
   ↓
[원인 분류] 인프라 / 설정 변경 / 의도적 차단 의심
   ↓
[복구 + 데이터 보완]
   ↓
[공백 검토] 로컬·네트워크 로그 → 이상 있음? → 보안 사고 절차로 전환
   ↓
[종료·보고]

원인	추가 조치
인프라	자원·이중화
설정 변경	변경 관리·회귀 시험
의도적 차단 의심	보안 사고로 전환

"장애 중 아무 일도 없었다"는 결론은 근거가 있어야 합니다. 공백 기간을 어떤 로그로 어떻게 확인했는지를 보고서에 남기는 것이 그 근거입니다.

8. SOC 관제 포인트

SIEM 장애를 보안 관점의 이벤트로 기록합니다.
장애 종료 조건에 공백 검토를 포함합니다.
반복 장애 원인은 체크리스트·자동 점검에 반영합니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,siem_a,">
  <rule id="110470" level="12">
      <if_sid>110190</if_sid>
      <if_matched_group>authentication_success|privilege_escalation</if_matched_group>
      <timeframe>3600</timeframe>
      <description>로그인·권한 상승 직후 소스 침묵 발생(장애 vs 의도적 차단 확인 필요)</description>
      <mitre><id>T1562</id></mitre>
    </rule>
</group>

침묵(110190) 직전 1시간 안에 로그인·권한 상승이 있었다면 단순 장애보다 의도적 차단 가능성을 높게 보는 예시입니다. 같은 호스트 조건은 침묵 점검 결과 필드에 맞춰 추가합니다.

10. 대응 방법

초기 확인 — 장애 감지 시점과 영향 범위를 평가합니다.
범위 확인 — 원인을 분류하고 의도적 차단 가능성을 확인합니다.
증거 확보 — 공백 기간 로컬·네트워크 로그를 확보합니다.
차단/조치 — 복구·데이터 보완 후 공백 검토 결과에 따라 사고 절차로 전환합니다.
재발 방지 — 원인·영향·개선을 보고하고 점검에 반영합니다.

11. 핵심 정리

단계	핵심
영향 평가	무엇이 안 보였나
복구	끊긴 구간 수리
공백 검토	그 사이 무슨 일이
종료	근거 있는 결론
면접 포인트	"SIEM 장애는 잠재적 보안 사고 — 복구 후 공백 기간에 무엇이 있었는지까지 확인해야 끝난다"

12. 다음 편 예고

다음 편 049. SIEM·로그 수집 — 실전 시나리오 — 신규 서버 SIEM 편입부터 첫 Alert까지 에서는 신규 웹 서버(web02)를 SIEM에 편입하는 과정을 수집 인벤토리→에이전트 등록→소스 설정→디코딩 검증→대시보드 확인→첫 정탐 Alert까지 가상의 실습 시나리오로 따라갑니다.

이전 편: 047. SIEM·로그 수집 — SIEM 운영 체크리스트 — 일일·주간 점검
📚 시리즈 전체 보기: SIEM · 보안관제