SOAR 개념 습득 및 플레이북 구축

들어가며 — M3의 판정을 받아 실제로 움직이는 자리

M3는 잔여 신호들을 가중합으로 점수화하고, 그 점수를 0–40(자동종료) / 41–70(LLM 트리아지) / 71+(즉시 에스컬레이션) 의 세 구간으로 갈라 라우팅했습니다. M3가 그 점수와 verdict(오탐 / 판단보류 / 정탐)를 낼 때까지가 M3의 몫이었고, 그 결과가 M4 플레이북의 분기 조건으로 들어옵니다. M4는 그 분기 조건을 받아서 자동으로, 또는 사람 승인 후, 실제로 도구를 움직이는 자리입니다.

〔M0에서 예고한 “다섯 단계의 정의”는 여기서 다시 펼쳐 봅니다 — M0에서는 이름을 예고만 했습니다. M4에서 그 표를 실제로 꺼내 어디에 우리가 서 있는지를 정량으로 짚습니다.〕

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

1. SOAR의 세 요소(Orchestration · Automation · Response)를 자동화 성숙도 다섯 단계 위에 놓고, 우리 팀이 어디에 서 있는지를 말할 수 있습니다.
2. 자동화 대상 선정 공식(발생빈도 × 건당 소요시간 ÷ 판단 난이도)으로 자동화할 가치가 있는 케이스를 가려낼 수 있습니다.
3. 플레이북을 세 개(P1 알림 강화, P2 AI 트리아지 접목, P3 Active Response) 시연하면서 반드시 설계해야 할 다섯 가지(승인 게이트, 롤백 절차, 감사 로그, dedup, 실패 시 폴백)를 짚을 수 있습니다.
4. M3의 점수 구간(0–40 / 41–70 / 71+)이 M4의 분기 조건으로 어떻게 소비되는지를 P2에서 직접 따라갈 수 있습니다.

§A. SOAR 3요소 — Orchestration · Automation · Response

〔M0의 다섯 지표 중 “자동화 처리율”이 M4의 출력입니다 — 자동종료·자동 차단 비율이 올라가면 MTTR이 짧아지고, M5에서 수동 vs 자동의 수치 대조로 회수합니다.〕

SOAR(Security Orchestration, Automation, and Response)는 도구 연결과 반복 제거와 대응 실행의 세 축을 한 프레임으로 묶는 이름입니다. 세 축은 서로 다른 문제를 풀고, 운영 성숙도가 올라가면 세 축이 모두 채워집니다.

세 축이 모두 채워져야 자동화의 가치가 나옵니다. Orchestration 없이 Automation만 있으면 도구 안에서만 돌아가는 닫힌 자동화이고, Response 없이 Orchestration만 있으면 데이터만 자동으로 흐르되 아무것도 바뀌지 않습니다. M4의 플레이북 세 개는 이 세 축을 순서대로 채워 가는 예시입니다.

§B. 자동화 성숙도 — 다섯 단계

〔M0에서 “다섯 단계의 정의는 M4에서 다시 한번 펼쳐 봅니다”라고 예고한 자리입니다. M0 §C의 “자가 진단 — 우리 조직은 지금 어디에”가 이 표를 가리킵니다.〕

다섯 단계를 한 줄씩 짚겠습니다.

현실적 목표는 “어디까지 가는가”가 아니라 “어디서 멈추는가”입니다. 단계 5는 자산 정보 정확도와 정책이 충분히 닦인 환경에서만 작동하고, 그 외의 환경에서는 단계 4에서 멈추는 것이 정답입니다. 단계 2(정보 강화)는 대부분 조직의 1차 목표 — M4의 P1 플레이북이 바로 그 자리입니다. 단계 3(판단 보조)은 2차 목표 — P2가 그것을 다룹니다. 단계 4(승인 후 대응)는 자산 정보 정확도가 전제입니다 — P3가 그 전제를 보여 줍니다.

자동화 대상을 고르는 공식

자동화 가치 ∝ (발생빈도 × 건당 소요시간) ÷ 판단 난이도. 빈도가 낮거나 소요시간이 짧거나 판단이 너무 결이 갈리면 자동화 가치가 낮습니다. M4의 P1은 빈도 높음 · 시간 짧음 · 난이도 낮음이라 자동화 가치가 가장 큰 자리입니다.

반드시 설계해야 할 다섯 가지

자동화는 “동작”이 아니라 “안전 장치”를 같이 설계해야 합니다. 다음 다섯 가지를 하나라도 빠뜨리면 자동화는 사고로 이어집니다.

이 다섯 가지는 M4의 세 플레이북에서 각각 어디에 박히는지가 보입니다. P1은 dedup와 폴백을, P2는 LLM의 verdict·confidence를 분기에, P3는 승인 게이트와 롤백을 보여 줍니다.

§C. 도구 비교 — n8n · Shuffle · TheHive+Cortex · Tines/Splunk SOAR

n8n을 채택한 이유 — 오늘 환경은 단일 호스트 Wazuh + n8n이고, M3의 LLM 트리아지(Code 노드로 구현)도 n8n 안에서 돌아갑니다. n8n의 LLM 노드와 HTTP Request 노드가 SOAR 세 축(Orchestration · Automation · Response)을 한 워크플로 안에서 다룰 수 있어, 도구를 갈아탈 필요 없이 동일한 그래프에서 플레이북이 자랍니다.

TheHive + Cortex는 케이스 관리에 강하지만 오늘 환경의 “이력 관리 개념”은 Google Sheets나 n8n 내장 저장소로도 충분히 전달됩니다. M4에서는 그 개념을 짚고 넘어가고, 별도 도구 도입은 후속 과정에서 다룹니다.

§D. 플레이북 P1 — 알림 강화 (15분, 성숙도 2단계)

〔M1의 5710·5712·5715·5902 알림 중 하나를 n8n이 받아서 IP 평판과 자산 정보를 더해 Slack으로 보내는 흐름입니다. 이 흐름이 성숙도 **2단계(정보 강화)**의 정중앙입니다.〕

목표 — Tier 1이 5분간 하던 검색을 3초로 줄입니다. 같은 정보를 같은 화면에서 봅니다.

화면 1. n8n 워크플로의 노드 그래프

[Wazuh Webhook] → [n8n 수신 노드] → [AbuseIPDB IP 평판 조회]
                                       → [자산 정보 조회]
                                       → [Slack 카드 전송]

Wazuh Webhook이 알림을 n8n으로 보내면, n8n이 그 IP를 AbuseIPDB에 조회하고, 그 IP가 박힌 자산을 내부 CMDB에서 찾아, 둘을 한 카드에 묶어 Slack에 보냅니다. 사람이 SIEM 콘솔을 번갈아 보지 않아도 같은 정보를 같은 자리에서 봅니다.

화면 2. dedup와 실패 시 폴백 — P1의 안전장치

P1은 “정보 강화”라 파괴적 액션이 없습니다. 그래서 P1에 필요한 안전장치는 두 가지입니다.

• dedup — 같은 IP가 같은 알림으로 두 번 들어오면 한 번만 AbuseIPDB에 조회합니다. AbuseIPDB의 호출 제한을 지키고, 같은 카드가 두 번 오는 것을 막습니다.
• 실패 시 폴백 — AbuseIPDB가 죽었거나 응답이 늦으면, 자산 정보만이라도 Slack에 보냅니다. 자동화를 멈추고 사람 큐로 넘기는 것보다, 부분 정보라도 보내는 편이 분석가의 시간을 덜 먹입니다. 단, 정보가 “성공한 줄 알고” 닫혀선 안 됩니다 — 폴백 경로의 알림은 “강화 실패” 라벨을 명시적으로 달아 사람 검토로 보냅니다.

이 두 가지가 §B의 안전장치 다섯 가지 중 dedup와 폴백이 P1에서 박히는 자리이고, P1은 §B의 자동화 대상 공식에서 빈도 높음 · 시간 짧음 · 난이도 낮음에 해당해 자동화 가치가 가장 큽니다.

화면 3. Slack에 도착한 카드

Slack에 도착한 카드는 분석가가 보는 화면의 풍성해진 형태입니다. SIEM 알림의 한 줄에 AbuseIPDB 평판과 자산 정보가 붙어 있고, 그 자산이 운영 호스트인지 개발 호스트인지를 즉시 볼 수 있습니다. 같은 검색을 반복하는 시간(5분)이 한 번의 카드 보기(3초)로 줄어듭니다.

§E. 플레이북 P2 — AI 트리아지 접목 (20분, 성숙도 3단계)

〔P2가 M2의 “리스크 스코어 누적”과 M3의 “LLM 트리아지”를 M4의 플레이북 안에서 합치는 자리입니다. P2의 분기 조건이 **M3의 점수 구간(0–40 / 41–70 / 71+)**을 그대로 소비합니다.〕

목표 — M1 + M2에서 만든 알림을 받아 P1의 정보 강화를 거친 뒤, M3의 LLM 트리아지로 1차 판정을 받고, 판정 결과에 따라 자동 종료 또는 사람 검토로 갈라 보냅니다.

화면 1. P1 + M3 데모 B(스코어링) + M3 데모 C(LLM 판정) → 분기

[P1 알림 강화] → [M3 스코어링] → 점수 구간 분기
                                       ├ 0–40  → 자동 종료 (LLM 호출 없음)
                                       ├ 41–70 → LLM 트리아지 → verdict / confidence
                                       │           ├ verdict === "오탐" && confidence >= 90 → 자동 종료
                                       │           └ 그 외 → 사람 검토(analyst-review) 에스컬레이션
                                       └ 71+   → 사람·SOAR 즉시 개입

여기서 M3의 점수 구간이 M4의 분기 조건으로 소비됩니다. 점수 구간은 M3에서 확정된 값이고, M4는 그 값을 재정의하지 않고 그대로 읽습니다.

화면 2. 오탐 강신뢰 분기 — 자동 종료 + 판정 근거 기록

LLM이 verdict === "오탐" 이고 confidence >= 90 인 사건은 자동 종료합니다. 이때 반드시 판정 근거를 로그에 남깁니다 — rationale_bullets를 Slack 카드와 n8n 실행 로그에 같이 저장합니다. 이 로그가 두 가지로 쓰입니다.

• 재학습 데이터로 축적 — 같은 패턴의 오탐이 누적되면 그 자체가 룰셋의 정정 후보가 됩니다.
• 사후 추적 — M5의 사후 분석에서 “왜 그 시점에 이게 자동 종료됐는가”를 답할 수 있는 단서가 됩니다.

〔verdict의 축은 오탐 / 판단보류 / 정탐 입니다. ANOMALY나 normal은 다른 축(M3 데모 A의 z-점수 결과)이고, M4는 그것을 정탐/오탐으로 옮기지 않습니다.〕

화면 3. 정탐 판정 — 티켓 생성 + 담당자 배정

verdict === "정탐" 또는 confidence < 90인 사건은 사람 검토(analyst-review) 로 에스컬레이션되고, 그 검토 결과를 받으면 티켓이 생성되어 담당자에게 배정됩니다. 케이스 관리는 TheHive 대신 Google Sheets 또는 n8n 내장 저장소로 대체 — 오늘 환경은 단일 호스트이고, “이력 관리 개념”을 전달하는 것이 목적이라 그 정도면 충분합니다.

이 분기가 M2의 “리스크 스코어 누적”이 M3·M4의 분기로 실현되는 자리입니다. M2는 “누적의 발상이 있다”까지만 짚었고, P2가 그 발상을 받아 점수 구간으로 갈라 자동종료·사람 검토로 라우팅하는 형태로 완성합니다.

P2의 안전장치 — 분기마다 무엇이 박히나

• dedup — P1과 같은 dedup 노드를 그대로 이어받습니다.
• 승인 게이트 — P2는 아직 파괴적 액션(차단, 격리)이 없습니다. P2의 산출물은 티켓과 자동종료라 사람 손이 닿는 곳에서 마지막 결정이 일어납니다. 그래서 P2에는 승인 버튼이 없습니다. 승인 버튼은 P3에서 박힙니다.
• 감사 로그 — verdict · confidence · rationale_bullets를 n8n 실행 로그와 Slack 카드에 같이 남깁니다.
• 실패 시 폴백 — LLM 호출이 실패하면 자동종료로 가지 않고 사람 큐로 넘깁니다. “LLM이 실패한 사건”을 자동 종료로 흡수하면 오탐이 누적되고, 그 누적이 M5의 사후 분석에서야 드러납니다.

§F. 플레이북 P3 — Active Response (25분, 성숙도 4단계)

〔P3가 M4의 임팩트 구간입니다 — 워크플로가 실제로 시스템 상태를 바꾸는 자리이고, “자동화가 진짜로 시스템을 바꿨다”가 화면에 보입니다.〕

목표 — 방화벽·EDR 없이 Wazuh Active Response로 실제 차단을 합니다. Slack 승인 버튼을 사람이 누르면, n8n이 Wazuh API를 호출해 차단 룰이 박히고, 그 룰이 iptables에 실제로 들어간 것을 터미널로 확인합니다.

화면 1. Slack 승인 버튼 — 사람 게이트

P2의 정탐 사건이 사람 검토를 거치면, 검토자가 “차단” 버튼을 누릅니다. 이게 P3의 승인 게이트입니다. 자동화는 이 버튼이 눌린 뒤에만 다음 노드로 진행합니다. 버튼이 눌리기 전까지는 아무 일도 일어나지 않습니다.

화면 2. Wazuh API 호출 — 토큰 획득 → Active Response 발화

Slack 버튼이 눌리면 n8n이 두 단계로 Wazuh API를 호출합니다.

POST /security/user/authenticate
→ JWT 획득

PUT /active-response?agents_list=001
{ "command": "!firewall-drop0", "arguments": ["45.83.66.12"] }

여기서 두 가지가 핵심입니다. 첫째, 토큰은 승인 게이트 뒤에만 요청합니다 — 승인 전 토큰 요청은 실패 시 재시도 노이즈만 늘립니다. 둘째, firewall-drop0은 Wazuh이 내장한 차단 명령이고, Wazuh 에이전트가 호스트에 설치돼 있어야 동작합니다. 오늘 환경의 단일 호스트 Wazuh에는 이 명령이 기본으로 들어 있습니다.

화면 3. 임팩트 구간 — 워크플로 → 터미널 → iptables 룰 확인

워크플로가 Active Response를 발화한 직후, 강사가 터미널로 전환해 iptables 룰을 직접 확인합니다.

sudo iptables -L INPUT -n --line-numbers
# 차단 룰이 실제로 박혀 있음

2초짜리 화면 전환이지만, “자동화가 진짜로 시스템을 바꿨다” 가 보이는 자리입니다. P1·P2에서는 “정보가 자동으로 흐른다”까지만 보였고, P3에서는 시스템 상태가 자동으로 바뀐 결과를 같은 화면에서 봅니다. 이 구간이 M4의 학습 목표 4(플레이북이 실제로 도구를 움직이는 것)를 단적으로 보여 줍니다.

P3의 안전장치 — P2와 무엇이 다른가

P3는 파괴적 액션이 있는 첫 번째 플레이북이라 안전장치가 한 단계 더 단단해집니다.

• 승인 게이트 — Slack 버튼이 눌려야만 Active Response가 발화합니다. 버튼이 없으면 자동화는 시작조차 하지 않습니다.
• 롤백 절차 — P3의 워크플로에는 차단 해제 노드가 같이 들어 있습니다. 같은 IP에 대해 차단 해제 명령을 발행할 수 있고, 오탐으로 정상 트래픽이 막혔을 때 사람의 클릭 한 번으로 룰을 들어낼 수 있습니다. 롤백이 없으면 차단은 사고를 만듭니다.
• dedup — 같은 IP에 대한 Active Response 요청이 중복으로 들어와도 차단 룰은 한 번만 박힙니다. dedup 노드가 같은 IP·같은 시점에 이미 발화했는지를 보고, 이미 발화했다면 추가 발화를 생략합니다.
• 감사 로그 — 누구의 승인이 있었는지(사용자명 + 시각), 어떤 IP가 차단됐는지, 어떤 명령이 발화됐는지를 n8n 실행 로그와 Slack 카드에 같이 남깁니다. M5의 사후 분석에서 이 로그가 결정적입니다.
• 실패 시 폴백 — Wazuh API가 죽었거나 응답이 늦으면 자동화는 멈추고 사람 큐로 넘깁니다. P3에서 “부분 성공”을 허용하면 차단이 안 된 상태를 성공한 줄 알고 알림이 닫혀 사고가 됩니다. P3의 폴백은 명시적으로 “차단 실패”를 사람 큐에 남기는 것입니다.

§G. P3와 함께 다룰 운영 주제 — 다섯 가지

P3의 임팩트 구간에서 짚고 넘어가야 할 운영 주제 다섯 가지입니다. 모두 P3와 짝을 이루는 “자동화 = 도구 + 안전장치 + 운영 문화”의 운영 문화 축입니다.

이 다섯 가지가 §B의 안전장치 다섯 가지를 운영 문화로 펼친 자리입니다. 안전장치는 도구 안에 박는 것이지만, 운영 문화는 사람의 손에서 자라고, M4의 학습 목표 4(플레이북이 실제로 도구를 움직이는 것)가 이 운영 문화 위에서만 성립합니다.

§H. P1·P2·P3의 비교 — 같은 워크플로 안에서 자라는 세 플레이북

P3의 자동화 공식 값이 가장 낮은데도 P3를 다루는 이유 — 자동화 가치가 빈도·시간·난이도의 곱이 아니라 “MTTR 단축”으로 측정되기 때문입니다. P3가 자동으로 차단해 주면, 같은 침해가 더 짧은 시간 안에 멈추고, M5의 MTTR 지표가 그만큼 짧아집니다. M0에서 약속한 “다섯 지표로 측정한다”는 약속이 P3에서 가장 강하게 실현됩니다.

§I. 정리 — M4가 만들고 M5에 넘기는 것

• SOAR 3요소 — Orchestration · Automation · Response. 세 축이 모두 채워질 때 자동화의 가치가 나옵니다.
• 자동화 성숙도 다섯 단계 — 1 알림 전달 / 2 정보 강화 / 3 판단 보조 / 4 승인 후 대응 / 5 완전 자동 대응. 오늘 다룬 P1·P2·P3는 2·3·4단계를 각각 시연합니다.
• 자동화 대상 공식 — (발생빈도 × 건당 소요시간) ÷ 판단 난이도. P1이 가장 큰 자리.
• 반드시 설계해야 할 다섯 가지 — 승인 게이트, 롤백 절차, 감사 로그, dedup, 실패 시 폴백. P1·P2·P3에 분산되어 박힙니다.
• 세 플레이북 — P1 알림 강화 / P2 AI 트리아지 접목 / P3 Active Response. P2가 M3의 점수 구간(0–40 / 41–70 / 71+)을 분기 조건으로 소비합니다.
• M4가 만든 산출물 — 세 플레이북의 n8n 워크플로, dedup 노드, 폴백 노드, 승인 버튼, 롤백 노드. 이 산출물이 M5의 사후 분석 입력으로 들어갑니다 — “누가 · 언제 · 어떤 입력으로 · 무엇을 발화했는가”가 M5의 첫 단서입니다.

M3의 판정(0–40 자동종료 / 41–70 LLM 트리아지 / 71+ 에스컬레이션)이 M4의 분기 조건으로 들어왔고, M4는 그 분기에서 세 플레이북을 가동해 도구를 움직였습니다. 자동화의 가치는 지표(MTTD · MTTR · 자동화 처리율)에 남고, 그 지표는 M5에서 사후 분석으로 회수됩니다. M5에서 M1~M4의 누적 로그를 묶어 보고서로 닫는 자리로 넘어갑니다.