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

통합 시나리오 E2E 데모 & 적용 로드맵

페이지: 5 / 6
강의 시간: 70분

들어가며 — M1부터 M4까지 한 화면에서 끝까지

M1은 로그를 받아 알림을 만들었고, M2는 룰셋으로 그 알림을 가렸고, M3는 잔여 신호를 z-점수와 LLM 트리아지로 판정했습니다. M4는 그 판정을 받아 P1(정보 강화) · P2(판단 보조) · P3(승인 후 대응) 세 플레이북을 가동해 실제로 도구를 움직였습니다. M5는 그 모든 것을 한 화면에서 끝까지 재생합니다.

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

run_scenario.sh 한 개로 M1~M4를 한 번에 재생하면서, 같은 사건이 탐지 → 판정 → 대응의 전 과정을 순서로 밟는다는 것을 화면으로 따라갈 수 있습니다.
M0에서 약속한 다섯 지표(MTTD · MTTR · 알림 처리량 · 오탐률 · 자동화 처리율) 중 수치가 나오는 세 지표(MTTD · MTTR · 자동화 처리율)와 기준선이 필요한 두 지표(알림 처리량 · 오탐률)를 가려낼 수 있습니다.
30-60-90일 계획 템플릿으로 자기 조직의 적용 로드맵을 개인·팀별로 작성할 수 있습니다.
현업에서 자동화가 실패하는 다섯 가지 패턴(자산 정보 부재 도입, 룰 튜닝 없는 SOAR, AI 검증 없는 신뢰, 플레이북 유지보수 주체 미지정, 지표 없는 도입)을 짚어 자기 조직의 위험을 가를 수 있습니다.

§A. 통합 데모 (40분) — `run_scenario.sh` 한 개로 끝까지

〔이 데모가 M1~M4의 모든 산출물을 한 화면에 모읍니다. 왼쪽에는 Wazuh 대시보드가, 오른쪽에는 n8n 실행 이력이, 하단에는 터미널이 뜹니다. 알림이 순차 발생하며 워크플로가 자동 발화하고, 마지막에 iptables 룰이 박히는 것까지 같은 화면에서 봅니다.〕

통합 시나리오 — run_scenario.sh

./run_scenario.sh
# T+0s   SSH 브루트포스 8회      → Wazuh 5712  → n8n P1 발화
# T+15s  로그인 성공             → Wazuh 5715  → 스코어 상승
# T+30s  웹 디렉터리 파일 생성    → FIM        → P2 LLM 판정
# T+45s  sudo 권한 상승          → Wazuh 5402  → 스코어 71+ 도달
# T+60s  계정 생성               → Wazuh 5902  → P3 승인 요청

각 이벤트가 이전 모듈의 어떤 산출물과 만나는지 짚어 봅니다.

T+0s · 5712 SSH 브루트포스 8회 — M1에서 정의한 Wazuh 룰 ID 5712가 발화합니다. n8n이 받아서 P1(정보 강화) 의 입력으로 들어갑니다. P1은 AbuseIPDB와 자산 정보를 더해 Slack 카드를 만듭니다.
T+15s · 5715 로그인 성공 — M1의 룰 5715가 발화합니다. P1이 같은 흐름에서 다시 한 번 카드를 만드는데, 이때 스코어가 누적되어 M2의 가중 신호 점수가 한 단계 올라갑니다.
T+30s · FIM 웹 디렉터리 파일 생성 — M1의 파일 무결성 모니터링(FIM) 이벤트가 들어옵니다. M3의 z-점수가 평소 분포에서 벗어남을 잡아내고, M3의 LLM 트리아지가 verdict와 confidence를 냅니다. P2의 분기 조건이 되는 자리입니다.
T+45s · 5402 sudo 권한 상승 — M5에서 처음 등장하는 룰 5402입니다. sudo 권한 상승 이벤트는 점수를 71+ 구간으로 밀어 올립니다 — M3가 정의한 점수 구간(0–40 / 41–70 / 71+)의 71+ 구간에 도달하므로 즉시 사람 검토로 에스컬레이션되고, 검토자는 P3의 “차단” 버튼을 눌러 Active Response로 이어갑니다.
T+60s · 5902 계정 생성 — M1의 룰 5902가 발화합니다. M3의 판정에서 정탐으로 확정되면 P3가 승인 흐름을 시작하고, Wazuh Active Response가 firewall-drop0 명령으로 차단 룰을 박습니다. 터미널에 iptables -L INPUT -n --line-numbers로 박힌 룰이 보일 때 데모가 끝납니다.

화면 구성의 의미 — 한 화면에서 세 흐름이 동시에 보입니다.

통합 데모의 화면 구성 — 세 흐름이 동시에 진행되는 자리

화면 영역보이는 것왜 그 자리인가왼쪽 — Wazuh 대시보드5712 · 5715 · 5402 · 5902 룰 발화와 그에 묶인 호스트M1의 알림이 어떤 식으로 들어오는지 — 룰 ID가 같으므로 M1과 같은 화면입니다오른쪽 — n8n 실행 이력P1 → P2 → P3 노드 그래프와 각 노드의 입출력M4의 플레이북이 실제로 어떤 순서로 발화하는지 — P3는 승인 게이트에서 멈춥니다하단 — 터미널run_scenario.sh 출력과 마지막의 iptables -L 결과“자동화가 진짜로 시스템을 바꿨다”가 박힌 룰 한 줄로 보이는 자리

왜 셸 스크립트 한 개로 끝까지 가는가 — 이 데모는 타이밍이 스크립트로 통제됩니다. 0초에 SSH 브루트포스를 쏘고, 15초에 로그인을 쏘고, 30초에 FIM 이벤트를 쏘는 것이 모두 정해진 시각에 일어나므로 리허설한 그대로 재현됩니다. VM 기반으로 같은 흐름을 만들면 시스템 부하·타이밍 변동 때문에 같은 시각에 같은 이벤트가 일어나지 않고, 데모가 실패할 확률이 이 방식보다 훨씬 높습니다. 수업에서 한 번 실패하면 그날 데모는 끝입니다 — 그래서 셸 스크립트입니다.

이 데모가 보여 주는 것 — 같은 공격 한 건을 M1(알림) → M2(룰) → M3(판정) → M4(대응)으로 끝까지 따라가면서, 각 모듈의 산출물이 다음 모듈의 입력이 된다는 점을 시간순으로 한 번에 봅니다. M0 §A의 “순서를 거꾸로 돌릴 수 없습니다”가 60초짜리 데모 한 번으로 증명됩니다.

§B. M0에서 약속한 지표 회수 — 수동 대응 vs 오늘 만든 자동화

〔M0에서 “M5에서 같은 다섯 지표를 다시 꺼내 수동 대응 대비 자동화 후의 수치로 회수합니다”라고 약속한 자리입니다. M5는 그 약속을 닫는 자리입니다.〕

M0의 다섯 지표 회수 — 셋은 수치로, 둘은 기준선 필요로

단계수동 대응오늘 만든 자동화회수 출처탐지 (MTTD)15분30초5712 SSH 브루트포스 룰이 발화한 시각 → P1 Slack 카드 도달 시각차단 (MTTR)30분+2분 (승인 포함)P3의 승인 버튼 → iptables 룰 박힘까지의 시각자동화 처리율0% (전부 수동)60% (T+0~T+60 5건 중 3건 자동 종결)run_scenario.sh 의 5개 이벤트 별 P1/P2 자동 종결 여부 — 아래 “자동화 처리율 파생” 절에서 산식 공개알림 처리량오늘 만든 자동화로 절대값을 낼 수 없음조직의 SIEM에 따라 단위 시간당 알림 수가 다르고, 자동화 가속비가 다릅니다 — §C의 30일 계획에서 자기 조직 기준선을 먼저 재십시오오탐률오늘 만든 자동화로 절대값을 낼 수 없음오탐률은 룰셋과 LLM 트리아지의 품질에 의존하고, 그 품질은 조직의 데이터에 따라 다릅니다 — §C의 30일 계획에서 자기 조직 기준선을 먼저 재십시오

“오늘 배운 4개 주제가 이 3개 숫자로 수렴” — MTTD 15분 → 30초, MTTR 30분+ → 2분, 자동화 처리율 0% → 60%. 이 세 수치가 M1~M4의 누적 결과를 한 줄로 보여 줍니다. M0의 약속 중 셋은 닫혔고, 둘은 기준선이 필요해 §C의 워크숍으로 넘깁니다.

「판정」은 M0의 다섯 지표가 아닙니다 — 파이프라인 단계(탐지 → 판정 → 대응) 중 하나이며, 위 표의 자동화 처리율과 MTTR 산식 안에 이미 포함되어 있습니다. 본 절의 표에 별도 행으로 두지 않은 이유가 이것이며, 같은 이유로 §B의 「셋은 수치로 회수」에서도 「판정 시간」을 별도 지표로 다루지 않습니다. M0의 다섯 지표와 다른 것을 같은 자리에 섞지 않는다가 M5의 분류 원칙입니다.

셋은 수치로 회수 — 어떻게 잰 것인가

세 지표의 측정 방법 — 같은 공격 한 건에 대해

지표시작점끝점왜 그 자리인가MTTD (탐지)T+0s · SSH 브루트포스 첫 시도Wazuh가 5712 룰을 발화한 시각“탐지”의 정의가 “SIEM이 이벤트를 알림으로 만든 시점”이라 — 룰 발화가 그 자리MTTR (차단)MTTD의 끝점 (룰 발화)iptables 룰이 박힌 시각“차단”의 정의가 “시스템 상태가 바뀐 시점”이라 — 룰 박힘이 그 자리자동화 처리율T+0s · 첫 알림 5712T+60s · 마지막 알림 5902 (5건 전체)“자동화”의 정의가 “사람 개입 없이 종결”이라 — 5건 중 P1/P2 자동 종결이 끝난 건수의 비율이 그 자리

수동 대응 수치(15분 · 30분+ · 0%)는 어디서 왔는가 — 사람 분석가가 같은 정보를 같은 순서로 가져가는 데 걸리는 평균값의 자리입니다. SIEM 콘솔에 들어가서 룰을 확인하고, 분석가 노트를 뒤지고, 같은 AbuseIPDB 조회를 사람이 손으로 하고, 승인 이메일을 보내고 받는 데 걸리는 누적 시간입니다. 수치가 절대적인 진실이라기보다 “사람 손으로 했을 때 보통 이 정도 걸린다”의 자리임을 분명히 합니다.

자동화 처리율 파생 — 산식과 근거

이 수치는 M0에서 약속한 다섯 지표 중 「자동화 처리율」을 회수하기 위해 준거 시나리오에서 파생한 값입니다 — 준거(구글 Docs)에 적힌 수치가 아니라 run_scenario.sh 의 5개 이벤트 결과를 그대로 셉니다.

자동화 처리율 = (P1 자동 종결 + P2 자동 종결) / (T+0~T+60 의 전체 알림)
             = 3 / 5
             = 60%

시각	룰 ID	플레이북	사람 개입 여부	자동 종결
T+0s	5712 SSH 브루트포스	P1 (정보 강화)	없음 — Slack 카드 전송 후 자동 종결	✓
T+15s	5715 로그인 성공	P1 (정보 강화)	없음 — 같은 IP 상관 분석 후 자동 종결	✓
T+30s	FIM 파일 생성	P2 (판단 보조)	없음 — LLM 트리아지가 오탐/conf≥90 시 자동 종결	✓
T+45s	5402 sudo 권한 상승	P2 → 사람 검토	있음 — 71+ 구간으로 즉시 에스컬레이션, 사람이 “차단” 버튼을 눌러야 다음으로 진행	✗
T+60s	5902 계정 생성	P3 (승인 후 대응)	있음 — 승인 게이트에서 멈춤, 검토자가 승인해야 iptables 차단	✗

수동 환경(M4 이전의 사람 손으로만 운영하던 자리)에서는 P1·P2·P3 자체가 존재하지 않으므로 5건 모두 사람 손으로 끝까지 가야 합니다 ⇒ 0%.

수치의 한계 — 두 가지로 읽어 주십시오:

이 수치는 “T+0~T+60 60초 윈도우 안”의 결과다. 운영 환경에서는 알림 빈도와 패턴이 다르므로 같은 비율이 나오지 않습니다.
T+45s와 T+60s는 「사람 검토」가 들어가지만 P3 승인 후 단계는 자동이다. 자동화 처리율을 「사람 검토 포함 / 미포함」 어느 쪽으로 정의해도 결과가 달라지므로, 본 절은 「사람 검토가 발화되면 사람 개입으로 본다」를 정의로 잡습니다 — 이 정의가 §C의 90일 계획에서 승인형 자동 대응 1건의 성공 기준과 직접 연결됩니다.

둘은 기준선이 필요 — 왜 절대값을 못 내는가

기준선이 필요한 두 지표 — 왜 오늘 만든 자동화로 수치가 안 나오는가

지표왜 오늘 만든 자동화로 절대값이 안 나오는가어디서 기준선이 잡히는가알림 처리량단위 시간당 처리한 알림 수는 조직의 SIEM이 받아내는 이벤트 수에 의존합니다 — Wazuh 단일 호스트와 5000 호스트 SIEM은 단위가 다릅니다자기 조직의 SIEM이 어제·오늘 처리한 알림 수를 SIEM 대시보드에서 직접 셉니다오탐률오탐률은 룰셋과 LLM 트리아지의 품질에 의존하고, 그 품질은 조직의 데이터에 의존합니다 — 같은 룰이라도 환경에 따라 오탐률이 다릅니다자기 조직의 SIEM에서 Tier 1이 닫은 알림 중 오탐으로 판정한 비율을 한 달간 집계합니다

이 두 지표는 M0에서 약속한 다섯 지표의 일부이므로 언급을 생략하지 않습니다 — 다만 “오늘 만든 자동화만으로 절대값을 낼 수 없다”는 사실을 명시하고, §C의 30-60-90일 계획에서 각 조직이 자기 기준선을 먼저 재는 것이 정직한 답임을 밝힙니다. M0의 약속을 「없던 것」으로 만드는 것이 아니라 “어느 시점에 어떤 방식으로 회수되는가”를 정확히 표시하는 것이 M5의 의무입니다.

M0의 다섯 지표 — 회수 정리

M0의 다섯 지표 — M5에서의 회수 형태

지표M5에서의 회수 형태MTTD수치로 회수 (15분 → 30초)MTTR수치로 회수 (30분+ → 2분)자동화 처리율수치로 회수 (0% → 60%, 시나리오에서 파생)알림 처리량§C 30일 계획에서 자기 조직 기준선을 재십시오오탐률§C 30일 계획에서 자기 조직 기준선을 재십시오

§C. 적용 로드맵 워크숍 (30분) — 30-60-90일 계획

〔이 워크숍이 M5의 두 번째 절반입니다. 개인·팀별로 30-60-90일 계획을 작성하고, 모듈에서 만든 자동화를 자기 조직에 어떻게 들여놓을지를 합의하는 자리입니다.〕

진행 방법 — 30분

(5분) 템플릿 배포 — 강사가 30일 / 60일 / 90일 각각의 산출물과 성공 기준을 한 장짜리 표로 배포합니다.
(15분) 개인 작성 — 수강생이 자기 조직의 현재 위치를 떠올리며 각 단계의 산출물을 채웁니다.
(10분) 팀 공유 — 인접한 자리 두세 명과 짧게 공유하고, 30일 단계의 “상위 오탐 알림 Top 10” 이 누구에게서도 비슷하게 나오는지 확인합니다.

시간이 부족할 때 — 30일 단계만 채우고 60·90은 “다음 주까지”로 미룹니다. 30일이 가장 구체적이고, 60·90일은 의지를 적는 자리라 30일이 비면 나머지도 의미가 없습니다.

30일 — 로그 소스 정리, 상위 오탐 알림 Top 10 도출 및 튜닝

30일 계획 — 성숙도 1단계 정비

영역산출물성공 기준로그 소스 정리SIEM이 받고 있는 로그 소스 목록 (어떤 호스트 · 어떤 로그 종류 · 일일 볼륨)목록이 1장으로 정리되고, “이 호스트는 로그가 안 온다”가 표시됨상위 오탐 알림 Top 10 도출지난 30일간 Tier 1이 닫은 알림 중 빈도 상위 10개Top 10이 이름으로 나열되고, 각각의 룰 ID가 적혀 있음Top 10 튜닝Top 10 각각에 대한 튜닝 액션 (룰 수정 · 임계값 조정 · 예외 처리)각 알림에 대해 “이 튜닝으로 다음 30일간 몇 건이 줄어드는가”의 예측이 적혀 있음

30일이 성숙도 1단계인 이유 — 자동화 도구를 새로 들이지 않고 기존 SIEM에서 일하는 자리입니다. 자동화 이전에 정리가 먼저라는 것이 30일의 자리이고, 이것을 건너뛰고 자동 차단부터 도입하면 §D의 실패 패턴 1(자산 정보 부재 도입)에 빠집니다.

60일 — 알림 강화 플레이북 1개 운영 투입

60일 계획 — 성숙도 2단계

영역산출물성공 기준P1 알림 강화 플레이북 1개n8n 워크플로 1개 — Wazuh 웹훅 수신 → AbuseIPDB 조회 → 자산 정보 조회 → Slack 카드실제 알림 1건 이상이 P1을 거쳐 Slack에 도달한 이력이 있음dedup · 폴백P1에 dedup 노드(같은 IP·같은 시점 윈도우 안에서 한 번만)와 실패 시 폴백(AbuseIPDB 다운 시 자산 정보만이라도 카드 전송) 노드가 들어 있음두 노드가 실제로 발화한 이력이 n8n 실행 로그에 있음유지보수 주체 지정P1을 운영 중 고장 냈을 때 “누가 본다”가 이름으로 지정됨1차 · 2차 유지보수 주체가 적힌 문서가 1장 있음

60일이 성숙도 2단계인 이유 — M4에서 정의한 자동화 성숙도 다섯 단계의 **2단계(정보 강화)**가 바로 P1입니다. 자동화 가치가 가장 큰 자리가 P1이고, §D의 실패 패턴 2(룰 튜닝 없는 SOAR)에 빠지지 않으려면 30일의 Top 10 튜닝이 먼저 닫혀 있어야 합니다.

90일 — AI 트리아지 파일럿, 승인형 자동 대응 1건

90일 계획 — 성숙도 3~4단계

영역산출물성공 기준AI 트리아지 파일럿M3의 LLM 트리아지를 n8n에 붙여 verdict · confidence를 실제 알림에 대해 냄파일럿 기간(예: 14일) 동안 LLM이 낸 verdict와 사람의 후속 판정이 일치하는 비율이 보고됨승인형 자동 대응 1건P3(승인 후 Active Response) 1건을 운영 환경에서 발화시킴 — Slack 승인 버튼 → Wazuh API → iptables 차단1건 이상 차단된 이력이 있고, 그 차단이 사후 분석으로 검토됨MTTR 측정탐지 → 차단까지 걸린 시간을 M0 §C의 정의대로 측정해 보고§B의 “2분 (승인 포함)“과 비교 가능한 수치가 보고됨

90일이 성숙도 3~4단계인 이유 — M4의 다섯 단계에서 **3단계(판단 보조)**가 AI 트리아지 파일럿이고, **4단계(승인 후 대응)**가 승인형 자동 대응 1건입니다. 자산 정보 정확도와 정책이 충분히 닦인 환경에서만 4단계로 올라가는 것이 정답이고, 그 환경이 안 되면 3단계에서 멈추는 것이 정답입니다 — §B에서 짚었듯 “어디까지 가는가”가 아니라 “어디서 멈추는가”가 현실적 목표입니다.

§D. 마무리 — 현업에서 자동화가 실패하는 5가지 패턴

〔이 5가지가 오늘 강의에서 가장 자주 놓치는 자리입니다. 자동화 도입이 실패하는 사례는 거의 항상 이 5가지 중 하나로 수렴합니다.〕

현업에서 자동화가 실패하는 5가지 패턴

#패턴왜 실패하는가어디서 막히는가1자산 정보 없이 자동 차단부터 도입“차단할 호스트가 무엇인가”가 정리되지 않은 채 차단부터 시작하면, 오탐이 정상 호스트를 막아 사고가 됩니다30일 — 로그 소스 정리와 자산 정보 동기화가 선행되어야 함2룰 튜닝 없이 SOAR 도입 (오탐을 더 빨리 처리할 뿐)SOAR는 “더 빠르게 만드는 도구”라기보다 “같은 입력에 같은 출력을 보장하는 도구”입니다. 입력(룰셋)이 오탐이면 출력(자동화)도 오탐30일 — Top 10 오탐 튜닝이 먼저 닫혀야 함3AI 판정을 검증 없이 신뢰LLM이 verdict === “오탐” && confidence >= 90 으로 자동종료한 사건을 사람이 사후에 한 번도 검토하지 않으면, LLM 오류가 그대로 누적90일 — 파일럿 기간에 LLM verdict와 사람 후속 판정의 일치율을 보고해야 함4플레이북 유지보수 주체 미지정워크플로가 한 번 고장 나면 “누가 본다”가 없어 그대로 멈춤 — 자동화는 운영 문화 없이는 운영되지 않음60일 — P1의 1차 · 2차 유지보수 주체가 이름으로 지정되어야 함5지표 없이 도입 → 효과 입증 실패 → 예산 중단M0의 다섯 지표 중 아무것도 재지 않은 채 자동화를 도입하면, “이게 효과가 있는가”를 답하지 못해 예산이 중단됩니다30일 · 60일 · 90일 — 각 단계에서 지표를 재고 보고해야 함

이 다섯 가지의 공통점 — 모두 **“자동화 도입 이전에 무엇이 닫혀 있어야 하는가”**가 비어 있어서 발생합니다. 30일이 비면 60일이 무너지고, 60일이 무너지면 90일이 무너집니다. §C의 30-60-90 계획이 단순한 로드맵이 아니라 이 다섯 가지 실패를 피하기 위한 순서임을 분명히 합니다.

정리 — M5가 닫는 것

통합 데모 — run_scenario.sh 한 개로 M1~M4를 한 화면에서 60초 안에 재생. 5712 · 5715 · 5402 · 5902가 순차 발화하고 P1 → P2 → P3가 순차 가동되며 마지막에 iptables 룰이 박힙니다.
지표 회수 — M0의 다섯 지표 중 셋(MTTD · MTTR · 자동화 처리율)은 수치로 닫혔고, 둘(알림 처리량 · 오탐률)은 §C 30일 계획에서 자기 조직 기준선을 먼저 재야 함을 명시했습니다.
30-60-90일 워크숍 — 30일(로그 소스 정리 · Top 10 튜닝 · 성숙도 1단계 정비) · 60일(P1 알림 강화 · 성숙도 2단계) · 90일(AI 트리아지 파일럿 · 승인형 자동 대응 1건 · 성숙도 3~4단계).
실패 5가지 패턴 — 자산 정보 부재 도입 · 룰 튜닝 없는 SOAR · AI 검증 없는 신뢰 · 유지보수 주체 미지정 · 지표 없는 도입. §C의 30-60-90이 이 다섯 가지를 피하기 위한 순서입니다.

M0에서 약속한 다섯 지표는 M5에서 셋은 회수되고 둘은 기준선이 필요한 자리로 표시되었습니다. 둘이 “없던 것”으로 만들어진 것이 아니라 “어떤 순서로 회수되는가”가 명시된 것이 M5의 의무이고, 그 의무를 §B · §C가 함께 닫았습니다. M1 → M2 → M3 → M4 → M5의 흐름이 여기서 한 바퀴를 돕니다.