과정 1 — 보안 탐지 및 대응 체계 운영M1

관제 환경 소개 및 SIEM 활용

페이지: 1 / 6
강의 시간: 80분

들어가며 — M0가 예고한 파이프라인의 첫 칸

M0에서 오늘 하루의 지도를 펼쳤습니다. 다섯 모듈은 수집 → 탐지 → 판단 → 대응 → 통합의 한 조각이고, 이전 모듈의 산출물이 다음 모듈의 입력입니다. M1은 그 약속의 첫 칸입니다 — 에이전트가 호스트에서 로그를 받아 SIEM에 올리고, 여기서 만들어지는 것이 알림(alert)입니다. 이 알림이 M2의 룰셋 입력으로 들어가고, M2의 잔여 신호가 M3의 점수 모델로 넘어갑니다. 순서가 거꾸로 갈 수 없습니다.

M0에서는 M1을 “수집 → 정규화·파싱 → 저장·색인 → 상관분석 → 시각화 → 대응”의 한 줄로 예고했습니다. M1에서는 그 줄의 각 칸이 무엇을 하고 무엇을 넘기는지를 화면으로 펼쳐 봅니다. 오늘은 단일 호스트 Wazuh 환경에서 강사가 시연하고 수강생은 흐름을 따라가는 참관형입니다.

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

관제 아키텍처의 여섯 단계를 말할 수 있습니다 — 수집 → 정규화·파싱 → 저장·색인 → 상관분석 → 시각화 → 대응.
SIEM · EDR · NDR · TIP · SOAR의 역할 경계와 연동 지점을 구분할 수 있습니다 — 같은 데이터를 다르게 보고, 그 “다름”이 운영 모델을 가릅니다.
로그 소스 우선순위를 정량 기준이 아니라 “탐지 커버리지 대비 수집 비용”의 관점에서 설명할 수 있습니다 — 인증로그 → Sysmon → 프록시 → 방화벽 순이 왜 자주 정답인지.
M1의 알림이 M2의 룰셋 입력으로 들어가는 연결을 본문에서 가리킬 수 있습니다 — 데모 끝에서 만든 알림이 다음 모듈의 시작점이 됩니다.

§A. 관제 아키텍처 — 여섯 단계로 흐르는 파이프라인

〔M0에서 예고한 파이프라인을 다시 꺼내, 각 칸마다 “무엇이 들어가고 무엇이 나가는가”를 적습니다.〕

관제 파이프라인의 여섯 단계 — 입력·산출물·다음 단계 인계

단계	하는 일	입력	산출물	다음 단계에 넘기는 것
수집	에이전트(Agent) 또는 Syslog로 호스트·네트워크·앱 로그를 모읍니다	원시 텍스트·바이너리 로그	전송 규약이 정한 패킷	정규화 단계의 입력 스트림
정규화·파싱	벤더·포맷이 다른 로그를 같은 필드 이름으로 통일합니다	수집 단계의 패킷	정형화된 이벤트 레코드	저장·색인의 레코드
저장·색인	시간축으로 묶고 검색 가능하게 만듭니다	정규화된 레코드	인덱스된 문서	상관분석 단계의 조회 대상
상관분석	여러 이벤트를 묶어 “한 사건”으로 만듭니다	인덱스된 문서들	알림(alert)	M2의 룰셋 입력 / 시각화 단계의 대시보드
시각화	대시보드·검색 UI로 분석가에게 보여 줍니다	알림·레코드	화면·리포트	사람의 판단·1차 분류
대응	사람 또는 자동화로 차단·격리·에스컬레이션합니다	사람의 결정	차단 사실·증거 보존	M4 플레이북의 분기 조건 / M5의 사후 분석

〔M0에서 “공격을 일으키지 말고 로그를 주입한다”는 첫 번째 설계 원칙을 약속했습니다. 이 원칙이 가장 먼저 발화하는 자리가 이 파이프라인의 첫 두 칸 — 수집 → 정규화·파싱 — 입니다.〕

한 가지 짚고 갈 것 — 상관분석이 만드는 것이 “알림”이다

각 단계가 만드는 산출물의 명칭

단계	산출물 명칭	왜 그 명칭인가
수집	원시 이벤트(raw event)	아직 “한 사건”으로 묶이지 않은 한 줄
정규화	정형 이벤트(parsed event)	필드 이름이 통일된 한 줄 — 그래도 “한 사건”은 아님
상관분석	알림(alert)	“한 사건”으로 묶인 결과 — 사람 또는 룰셋이 볼 단위

정의 알림(alert) 은 상관분석 단계가 만든 산출물입니다. 한 줄짜리 이벤트가 아닙니다 — 여러 이벤트가 한 사건으로 묶이고, 거기에 심각도와 분류가 붙은 단위입니다. M2의 룰셋이 받는 입력은 이 “알림”입니다 — 원시 로그가 아닙니다. 이 구별을 잊으면 M2에서 “룰이 왜 안 발화하지?“를 반복하게 됩니다.

§B. SIEM · EDR · NDR · TIP · SOAR — 다섯 도구의 역할 경계

다섯 도구의 핵심 질문과 연동 지점

도구	핵심 질문	보는 데이터	자동화 범위	M1에서의 위치
SIEM	“지금 무슨 일이 일어나고 있는가”	호스트·네트워크·앱 로그를 통합·상관	알림 생성·대시보드	중심 — M1의 모든 데모가 여기서 일어남
EDR	“이 호스트에서 무엇이 실행되었는가”	프로세스·파일·레지스트리 변화	호스트 격리·프로세스 종료	SIEM에 이벤트를 흘림(Sysmon이 그 통로)
NDR	“이 네트워크에서 무슨 트래픽이 오갔는가”	패킷·흐름(flow)·DNS 질의	이상 트래픽 차단 후보	SIEM과 같은 인덱스로 흘림
TIP	“이 IP·도메인·해시가 알려진 위협인가”	외부 IOC 피드	컨텍스트 부여(알림에 “악성 IP” 태그)	SIEM의 룰셋 입력으로 들어감
SOAR	“이 알림에 대해 무엇을 해야 하는가”	SIEM 알림·TIP 컨텍스트	플레이북 자동 실행	M4에서 다시 펼쳐 봄 — M1에서는 이름만

〔M0에서 “대응은 Wazuh 내장 기능으로”라는 세 번째 설계 원칙을 약속했습니다. Wazuh는 SIEM이면서 EDR의 일부 기능(FIM · syscheck)을 갖고 있고 Active Response로 차단까지 수행합니다. 오늘 환경은 SOAR를 별도로 두지 않고 SIEM 안에서 끝내는 형태입니다.〕

연동 지점 — 같은 데이터, 다른 질문

다섯 도구가 같은 로그를 공유하면서 다른 질문을 던집니다. 이 “다름”이 운영 모델을 가릅니다.

SIEM은 “지금 무슨 일이 일어났는가”를 묻고, 알림을 만듭니다.
EDR은 “이 호스트에서 무엇이 실행되었는가”를 묻고, 프로세스 트리를 그립니다.
NDR은 “이 트래픽이 어디서 어디로 갔는가”를 묻고, 흐름을 그립니다.
TIP는 “이것이 알려진 위협인가”를 묻고, 컨텍스트를 붙입니다.
SOAR는 “이제 무엇을 해야 하는가”를 묻고, 플레이북을 실행합니다.

같은 데이터에 다섯 개의 질문이 붙고, 그 답이 한 화면에 합쳐질 때 분석가는 “정탐인가 오탐인가”를 판단합니다. M3의 LLM 트리아지는 이 합류 지점에서 일합니다.

§C. 로그 소스 우선순위 — “뭘 먼저 켜야 하는가”

운영 환경에 SIEM을 처음 올릴 때 마주치는 질문이 있습니다. “수많은 로그 소스 중 무엇을 먼저 켜야 하는가?” 정답은 한 가지가 아닙니다 — 조직의 자산·위협 모델·예산에 따라 다릅니다. 그래도 자주 등장하는 탐지 커버리지 대비 수집 비용의 관점에서 본 순서가 있습니다.

로그 소스 우선순위 — 왜 이 순인가

순위	소스	탐지 커버리지	수집 비용	왜 이 자리인가
1	인증 로그 (auth.log · Win Security Log)	정탐률 높음 — 성공한 침해의 절반 이상이 여기 흔적을 남김	낮음 — 텍스트 한 줄	성공한 로그인 / 실패한 로그인 / 권한 상승이 한 줄에 다 들어옴
2	Sysmon (Windows) / auditd (Linux)	프로세스 실행·파일 변경·네트워크 연결	중간 — 초당 수십 줄 가능	EDR의 핵심 신호. 인증 로그가 “누가”를 말하면 Sysmon은 “무엇을”
3	프록시 로그	C2 통신·외부 데이터 유출·악성 도메인 접근	중간 — URL 단위	NDR이 안 보던 HTTP 본문의 의도를 알 수 있음
4	방화벽 로그	외부 → 내부 침투 시도·비정상 포트 통신	낮음 — 보통 5-tuple 한 줄	이미 NDR이 대부분을 거른 뒤의 “최후의 문”

유의 이 순서는 정량 비교가 아니라 운영 경험의 압축입니다. 인증 로그 한 줄이 Sysmon 수십 줄보다 정탐률이 높다는 수치는 환경마다 다르고, 이 모듈의 준거에는 그 수치가 실재하지 않습니다. 정당화 근거는 “같은 비용에 더 많은 사건이 잡힌다”는 비용 대비 효율입니다.

〔M1에서는 위 순서 중 1·2·3을 시연합니다. 방화벽 로그는 환경에 따라 NDR과 겹쳐 4번째에 둡니다.〕

§D. 데이터 모델 표준 — ECS와 OCSF, 그리고 SOAR의 전제조건

SIEM이 여러 소스의 로그를 받아 같은 필드 이름으로 다루려면 표준이 필요합니다. 이 자리에 두 가지가 자주 등장합니다.

ECS와 OCSF — 두 데이터 모델 표준의 자리

표준	출처	강점	약점	M1에서의 위치
ECS (Elastic Common Schema)	Elastic	Elasticsearch 생태계에서 사실상의 표준	Elastic 외 SIEM은 그대로 못 씀	Wazuh는 ECS를 부분 수용
OCSF (Open Cybersecurity Schema Framework)	AWS·Splunk 등 다수 벤더 컨소시엄	벤더 중립 — SIEM을 옮겨도 룰이 그대로	아직 일부 카테고리만 안정화	장기적으로 SIEM 교체의 전제조건

왜 중요한가 필드 표준화가 SOAR 자동화의 전제조건입니다. “사용자 이름”이 SIEM A에서는 user.name이고 SIEM B에서는 username이라면, SOAR 플레이북은 매번 매핑 테이블을 들고 다닙니다. 표준이 같으면 같은 플레이북이 그대로 돕니다. M4에서 SOAR 없이 Wazuh Active Response로 끝내는 이유도 필드 매핑을 SIEM 안에서 닫을 수 있기 때문입니다.

§E. MITRE ATT&CK와 Detection-as-Code — 룰셋을 “관리”하는 두 관점

MITRE ATT&CK 기반 커버리지 관리

MITRE ATT&CK이 SOC에서 하는 일

관점	하는 일	출력
탐지 커버리지 맵	“우리 룰이 어떤 전술·기법을 커버하는가”를 시각화	공격 기법 × 룰 ID 매트릭스
갭 분석	“이 전술은 룰이 없다”를 가시화	신규 룰 후보 목록
사고 분류	알림을 ATT&CK 전술·기법으로 태깅	사건 보고서의 표준 어휘

〔M3의 LLM 트리아지에 signals 필드가 들어가는 이유도 ATT&CK 태그 때문입니다 — 분석가는 “이 알림이 어떤 전술에 해당하는가”를 보고 같은 패턴의 다른 사례를 빠르게 찾습니다.〕

Detection-as-Code

Detection-as-Code 는 탐지 룰을 코드로 관리하는 관점입니다. 핵심 약속은 세 가지입니다.

Detection-as-Code의 세 약속

약속	실천 방법	이유
룰은 Git으로 버전 관리	PR 리뷰·롤백·이력 추적	“이 룰이 언제 켜졌고 누가 검토했는가”
룰은 배포 전에 자동 테스트	합성 로그로 발화 여부 확인	운영에서 “왜 안 울리지”를 반복하지 않음
룰은 카탈로그와 함께 진다	룰 ID × ATT&CK 기법 매트릭스	커버리지 갭을 이름으로 가리킴

〔M1의 데모에서 만들 룰은 카탈로그에 들어가는 첫 항목입니다 — 5710(SSH 브루트포스 패턴), 5712(같은 IP에서 다수 계정 대상 반복 실패의 상관분석), 5715(성공한 로그인 — 시나리오 전환점), 5902(계정 생성). M2에서 이 네 룰을 한 번씩 다룹니다.〕

§F. 데모 ① — 아키텍처 투어 (10분)

지금부터 강사가 화면을 켭니다. 수강생은 흐름을 따라가 주세요.

화면 1. 컨테이너 상태

데모 ① — docker compose ps

docker compose ps
# NAME                SERVICE    STATUS    PORTS
# x-wazuh-manager     manager    running   0.0.0.0:55000->55000/tcp
# x-wazuh-indexer     indexer    running   0.0.0.0:9200->9200/tcp
# x-wazuh-dashboard   dashboard  running   0.0.0.0:443->5601/tcp

세 컨테이너가 떠 있습니다.

manager — 룰셋·디코더·에이전트 등록을 담당합니다. M1의 모든 시연이 여기서 발화합니다.
indexer — 정규화된 이벤트를 색인하고 검색을 받습니다. Elasticsearch가 이 자리에 있습니다.
dashboard — 분석가가 보는 화면. Kibana 기반입니다.

화면 2. 에이전트 등록 상태와 실시간 로그 유입

데모 ① — 에이전트 등록과 실시간 로그

tail -f /var/ossec/logs/alerts/alerts.json
# {"timestamp":"2026-...","rule":{"id":"5710","level":10,...},"agent":{...}}
# {"timestamp":"2026-...","rule":{"id":"5712","level":12,...}, ... }

에이전트가 등록된 호스트에서 인증 이벤트가 들어오면 5710 같은 룰 ID가 붙은 알림이 한 줄씩 찍힙니다. 이 한 줄이 M1이 만드는 산출물의 단위입니다 — M2의 룰셋이 받을 입력입니다.

§G. 데모 ② — 공격 로그 주입, 이 과정의 핵심 기법 (15분)

〔M0에서 약속한 “공격을 일으키지 말고 로그를 주입”이 이 구간에서 실천됩니다. 실제 침해를 일으키지 않고 logger 명령만으로 같은 알림을 만들어냅니다.〕

단계 1. SSH 브루트포스 — rule 5710 반복

데모 ② 단계 1 — SSH 브루트포스 8회

for i in $(seq 1 8); do
logger -p auth.info -t "sshd[$$]" \
  "Failed password for invalid user admin from 45.83.66.12 port 51234 ssh2"
sleep 1
done

같은 IP 45.83.66.12에서 1초 간격으로 8회 실패를 주입합니다. 5710 룰이 한 번씩 발화합니다.

단계 2. 상관분석 발동 — rule 5712

8회가 누적되면 상관분석 룰이 발화합니다. 단일 이벤트가 아니라 같은 IP·짧은 시간 안의 반복 실패 패턴을 한 사건으로 묶는 룰입니다.

데모 ② 단계 2 — 5712 알림의 형태

{
"rule": { "id": "5712", "level": 12, "description": "SSH brute force attempt" },
"srcip": "45.83.66.12",
"events": 8,
"window": "8s"
}

5712가 만드는 것이 M1의 알림입니다 — M2의 룰셋이 받는 입력입니다.

단계 3. 성공한 로그인 — rule 5715, 시나리오 전환점

데모 ② 단계 3 — 브루트포스 성공 (시나리오 전환점)

logger -p auth.info -t "sshd[$$]" \
"Accepted password for devops from 45.83.66.12 port 51240 ssh2"

같은 IP에서 devops 계정으로 성공한 로그인이 찍힙니다. 5715 룰이 발화합니다 — 5712와 5715가 같은 IP에서 같은 시간 안에 함께 발화하면 “브루트포스 끝에 성공한 침해” 시나리오로 묶입니다. 이 한 줄이 오늘 데모의 시나리오 전환점입니다. 여기서부터는 M2의 결정적 룰과 M3의 잔여 신호가 갈라집니다.

이 방식을 쓰는 이유

왜 실제 공격 대신 `logger` 주입인가

이유	설명
스크립트 1개로 완전 재현	리허설한 그대로 동작 — 강사가 한 번 실수해도 다시 주입하면 끝
IP·시각·계정 통제	스토리라인 설계대로 진행 — 같은 IP를 유지해 5712·5715가 같은 사건으로 묶이게 함
수강생이 회사에 돌아가 복사 가능	탐지 룰 검증 절차가 그대로 — “우리 환경에서도 5712가 울리는가”를 즉시 확인

§H. 데모 ③ — 실제 시스템 반응 섞기 (10분)

데모 ②가 순수 로그 주입이었다면, 데모 ③은 호스트에서 실제로 무언가가 일어나는 반응을 섞습니다.

FIM — 웹 디렉터리에 의심 파일 생성

데모 ③ 단계 1 — FIM 트리거

echo "SUSPICIOUS-FILE-DEMO" | sudo tee /var/www/html/x.php

tee가 /var/www/html/x.php를 만듭니다. Wazuh의 FIM(File Integrity Monitoring)이 등록된 경로의 파일 변화를 감지합니다. /var/www/html이 ossec.conf의 <syscheck> 블록에 realtime="yes"로 등록돼 있다면 알림이 즉시 발화합니다.

계정 생성 탐지 — rule 5902

데모 ③ 단계 2 — 비인가 계정 생성

sudo useradd backdoor_demo

useradd가 호출되면 PAM·auditd가 이벤트를 만들고, Wazuh의 5902 룰이 발화합니다.

데모 ③ 단계 2 — ossec.conf 의 syscheck 등록 (예고)

<syscheck>
<directories check_all="yes" realtime="yes">/var/www/html</directories>
<frequency>300</frequency>
</syscheck>

강사는 이 등록이 미리 돼 있어야 한다고 미리 짚습니다 — 수강생이 “우리 환경에선 왜 안 울리지”라고 물을 때 답이 됩니다.

§I. 데모 ④ — 룰 구조 해부 및 커스텀 룰 작성 (15분)

〔M1의 마지막 구간이자 참관형에서 가장 반응이 좋은 자리입니다. 화면을 켠 채로 라이브로 룰을 추가합니다.〕

단계 1. 알림 → 이벤트 상세로 들어가기

화면의 알림 목록에서 5715를 클릭합니다. 이벤트 상세가 열리고, 다음이 보입니다.

이벤트 상세에서 보는 것

영역	담는 정보	왜 필요한가
rule.id	5715	“어떤 룰이 발화했는가”의 식별자
rule.level	10–15	심각도 — 대시보드 색·에스컬레이션 정책의 기준
srcip · dstuser	IP · 계정	상관분석의 키 — “누가·어디서”
decoder	sshd	“어떤 파서가 이 한 줄을 정규화했는가”

단계 2. 디코더 파싱 결과 확인

Wazuh는 원본 로그를 디코더로 정규화합니다. 같은 Failed password 한 줄이 디코더를 거치며 srcip, dstuser, agent.id 같은 필드로 갈라집니다. 이 필드 이름이 바로 ECS·OCSF가 표준화하려는 대상입니다 — Wazuh는 자체 디코더 체계를 갖고 있고, ECS와 부분 매핑됩니다.

단계 3. local_rules.xml 구조 설명

데모 ④ — 커스텀 룰 골격 (5분 안에 작성)

<rule id="100001" level="12">
<if_sid>5710</if_sid>
<srcip>45.83.66.12</srcip>
<description>Custom: targeted brute force from known demo IP</description>
</rule>

<if_sid>5710</if_sid>은 부모 룰을 가리키고, <srcip>로 IP를 좁힙니다. <description>은 사람이 읽는 한 줄 — 카탈로그에서 이 룰을 찾을 때의 키워드입니다. 강사는 이 네 줄을 5분 안에 적고 systemctl reload wazuh-manager로 적용합니다.

단계 4. 즉시 탐지 시연

이 룰을 켠 채로 데모 ② 단계 1의 logger 명령을 다시 실행하면 5710과 함께 100001이 동시에 알림에 뜹니다. 같은 입력에 룰이 두 개 발화하는 것이 보입니다 — 룰이 위에서 아래로 평가되고, 같은 이벤트가 여러 룰에 매칭될 수 있다는 룰셋의 핵심 성질입니다.

단계 5. MITRE ATT&CK 대시보드로 커버리지 확인

Kibana의 MITRE ATT&CK 대시보드 화면을 띄웁니다. 오늘 켠 룰들이 어떤 전술·기법을 커버하는지 매트릭스가 그려집니다 — 5710·5712·5715가 Credential Access 영역의 한 칸을 채우고, 5902가 Persistence 영역의 한 칸을 채웁니다. 빈 칸은 다음에 추가할 룰의 후보입니다.

§J. 정리 — M1이 만들고 M2에 넘기는 것

파이프라인 — 수집 → 정규화·파싱 → 저장·색인 → 상관분석 → 시각화 → 대응. M1은 이 여섯 단계가 실제로 돌아가는 모습을 화면으로 보여 줍니다.
다섯 도구의 경계 — SIEM은 중심이고, EDR·NDR·TIP가 각자의 데이터를 흘리고, SOAR는 M4에서 등장합니다.
로그 소스 우선순위 — 인증로그 → Sysmon → 프록시 → 방화벽. 정량 비교가 아닌 비용 대비 효율의 순서입니다.
표준 — ECS와 OCSF가 필드 이름의 표준을 만들고, 그 표준이 SOAR 자동화의 전제조건입니다.
MITRE ATT&CK와 Detection-as-Code — 룰셋을 카탈로그로 관리하고, PR 리뷰로 배포하는 관점입니다.
M1이 만드는 산출물 — 5710·5712·5715·5902의 알림. 이 알림이 M2의 룰셋 입력이 됩니다. M2에서 이 알림을 받아 결정적 룰과 잔여 신호로 갈라 놓습니다.

M2로 넘어갑니다 — M1에서 만든 알림이 M2의 룰셋을 어떻게 통과하는지, 결정적 룰이 발화하면 무엇이 일어나는지를 봅니다.