SIEM·SOAR 실전 - Elastic Security·Splunk·Tines로 수천 건 경보를 사람 수십 명이 감당하게 만들기

들어가며

지난 #135 런타임 위협 탐지에서 Falco·Tetragon으로 Pod 안의 비정상 행동을 잡는 방법을 정리했습니다. 그런데 탐지가 많아질수록 현실적인 문제가 생깁니다. 경보가 하루 수천 건이면 사람이 감당할 수 없습니다.

2024년 IBM Cost of a Data Breach Report는 "경보 평균 처리 시간이 침해 탐지 지연의 1순위 원인"이라고 적시했고, 2025년 Gartner는 대기업 SOC가 받는 경보 중 70~80%가 자동 트리아지 가능하다고 보고했습니다. 문제는 "자동화 파이프라인이 있는가"입니다.

오늘은 그 파이프라인인 SIEM(Security Information and Event Management)과 SOAR(Security Orchestration, Automation and Response)를 Spring Boot + Kubernetes + 보안 스택 위에서 구축하는 현실적 방법을 정리합니다.

• 1부 - SIEM과 SOAR가 각각 해결하는 문제
• 2부 - Elastic Security vs Splunk 선택 기준
• 3부 - 로그 수집 파이프라인과 정규화(ECS)
• 4부 - Detection as Code - 탐지 룰을 코드처럼 관리
• 5부 - Tines·Shuffle로 SOAR 플레이북 짜기
• 6부 - MITRE ATT&CK 매핑과 커버리지
• 7부 - 도입 로드맵과 흔한 실패

1. SIEM과 SOAR가 각각 해결하는 문제

혼용해서 부르는 경우가 많지만 역할이 다릅니다.

축	SIEM	SOAR
주 역할	로그 수집·정규화·상관 분석	대응 워크플로우 자동화
입력	방화벽·Falco·WAF·인증·클라우드 로그	SIEM 경보, 티켓, 외부 피드
출력	경보·대시보드	자동 조치·티켓·사람 의사결정
대표 도구	Elastic Security, Splunk ES, Microsoft Sentinel	Tines, Shuffle, Splunk SOAR, Palo Alto XSOAR
성공 지표	탐지 커버리지, 저오탐	MTTR(Mean Time To Respond), 자동화율

SIEM이 "뭘 봤는가", SOAR가 "그래서 뭘 할 건가"입니다. SIEM만 깔면 경보 폭포만 남고, SOAR만으로는 신호가 없습니다. 두 레이어가 짝으로 움직여야 합니다.

2. Elastic Security vs Splunk 선택 기준

2026년 현재 현실적 선택지는 세 가지입니다.

항목	Elastic Security	Splunk ES	Microsoft Sentinel
과금	리소스(리텐션·클러스터)	데이터 수집량(GB/day)	데이터 수집량 + Azure
오픈 구성	OSS 배포 가능	전면 상용	Azure 종속
쿼리 언어	ES|QL, KQL, Lucene	SPL	KQL
감지 룰	YAML(detection-rules)	SPL 저장 룰	YAML(Sentinel analytics)
러닝 커브	중간	가파름	중간
대표 강점	로그+탐지+XDR 통합	성숙도·파트너 생태계	M365·Azure 네이티브
적합	스타트업~중견, 비용 예측성	대기업·금융·규제 산업	MS 중심 조직

비용 구조가 결정적입니다. Splunk의 GB/day 과금은 트래픽 폭증 시 예측 불가로 튀고, Elastic·Sentinel은 상대적으로 완충됩니다. 2023년 이후 "Splunk에서 Elastic으로" 이전 사례가 늘어난 배경이기도 합니다. 다만 금융·공공처럼 인증·레퍼런스가 까다로운 영역에서는 Splunk가 여전히 기본값입니다.

3. 로그 수집 파이프라인과 정규화

SIEM의 절반은 "로그를 가져오는 일"입니다. 같은 사건도 소스마다 포맷이 다르면 상관 분석이 무너집니다.

3-1. 들어오는 소스

• 애플리케이션 로그 (Spring Boot, OpenTelemetry)
• Kubernetes audit log, kube-apiserver
• Falco·Tetragon 이벤트 (#135)
• Istio 사이드카·앰비언트 접근 로그 (#134)
• CloudTrail·VPC Flow Log·WAF
• Vault audit log (#133)
• IdP(OIDC) 인증 이벤트
• CI 로그, git webhook, image scan

3-2. ECS(Elastic Common Schema) 정규화

{
  "@timestamp": "2026-04-24T01:23:45Z",
  "event": {
    "category": "authentication",
    "action": "user_login",
    "outcome": "failure"
  },
  "user": {"name": "seungwon.kim", "id": "u-4892"},
  "source": {"ip": "203.0.113.10"},
  "http": {"request": {"method": "POST"}, "response": {"status_code": 401}},
  "service": {"name": "auth-api", "environment": "production"},
  "labels": {"tenant": "acme"}
}

포맷을 통일하면 "어떤 소스든 같은 필드로 상관"이 가능해집니다. Falco 경보의 k8s.pod.name과 애플리케이션 로그의 kubernetes.pod.name이 다르면, "이 Pod에서 일어난 일"로 묶는 게 안 됩니다.

3-3. 수집기(Collector) 선택

도구	강점	적합
Elastic Agent	원스톱, 정책 중앙 관리	Elastic 스택 표준
Fluent Bit	경량·고성능	Kubernetes 범용
Vector	로그 변환 풍부	복잡한 파이프라인
Splunk UF/HF	Splunk 공식	Splunk 환경
OpenTelemetry Collector	표준·벤더 중립	멀티 백엔드

2026년 표준 조합은 OpenTelemetry Collector + Elastic Agent입니다. 애플리케이션·인프라 공통 파이프라인을 하나로 두고, 보안 영역만 Elastic Agent로 분기하는 패턴이 많습니다.

4. Detection as Code

탐지 룰을 GUI에서 하나씩 만드는 방식은 곧 통제를 잃습니다. YAML + Git + CI로 관리해야 변경 이력과 검증이 생깁니다.

4-1. Elastic detection-rules 포맷

[metadata]
creation_date = "2026/04/24"
maturity = "production"

[rule]
author = ["seungwon.kim"]
name = "Suspicious shell inside java container"
description = "Spring Boot 컨테이너에서 JVM의 자식 쉘 실행 탐지"
risk_score = 73
severity = "high"
type = "eql"
language = "eql"
query = '''
process where
  process.parent.name == "java"
  and process.name in ("sh", "bash", "zsh")
  and kubernetes.namespace == "production"
'''

[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.tactic]]
id = "TA0002"
name = "Execution"
[[rule.threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"

파일 하나가 룰 정의 + 심각도 + MITRE 매핑 + 성숙도 라벨까지 담습니다. 커밋 기반이라 언제 누가 바꿨는지가 명확합니다.

4-2. CI 파이프라인에서 검증

# .github/workflows/detections.yml
name: detection-rules
on: [pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Lint rules
        run: python -m detection_rules test
      - name: Unit test (sample events)
        run: python -m detection_rules sample-test rules/
      - name: Dry-run vs last 7 days
        run: ./scripts/replay_recent_events.sh

룰 배포 전에 최근 7일치 이벤트에 대해 드라이런하면, 오탐 폭증이 실제 배포 전에 드러납니다. 단위 테스트용 샘플 이벤트도 레포에 함께 둡니다.

4-3. Sigma - 벤더 중립 포맷

title: AWS CloudTrail - 루트 계정 콘솔 로그인
id: 1a2b3c4d-...
status: production
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventName: ConsoleLogin
    userIdentity.type: Root
  condition: selection
level: high
tags:
  - attack.initial_access
  - attack.t1078.004

Sigma 룰은 sigmac로 Elastic·Splunk·Sentinel 쿼리로 컴파일됩니다. SIEM을 교체할 가능성이 조금이라도 있다면 처음부터 Sigma 계층을 두는 것이 장기적으로 안전합니다.

5. SOAR 플레이북 짜기 - Tines/Shuffle

SIEM이 경보를 내면 SOAR가 결정 트리를 따라 조치합니다. 사람이 10초 안에 못 하는 일을 2초 안에, 수백 건을 병렬로 처리합니다.

5-1. 예시 시나리오 - 의심 로그인 자동 대응

1. Elastic에서 "같은 사용자 5분 내 5개 국가 로그인" 경보 발생
2. SOAR가 GeoIP·디바이스·과거 행동을 컨텍스트 수집
3. AbuseIPDB·VirusTotal IP 평판 조회
4. "명백한 악성" 조건 만족 → IdP에 세션 강제 종료 + MFA 재인증 요구
5. "회색" 조건 → Slack 채널에 사람 확인 요청
6. "정상 패턴"이면 경보를 자동 종결
7. 모든 단계가 티켓 하나에 주석으로 기록

5-2. Tines Story 구조

Trigger: Webhook (Elastic Security action)
  ├─ Event Transform: 사건 JSON 정규화
  ├─ HTTP Request: AbuseIPDB 조회
  ├─ HTTP Request: VirusTotal 조회
  ├─ Decision:
  │    ├─ score >= 90 → Okta session revoke → Slack #sec-critical
  │    ├─ 50 ≤ score < 90 → Slack #sec-triage 확인 요청
  │    └─ score < 50 → Elastic case 자동 종결
  └─ Event Emit: 감사 로그

Tines는 노코드 기반이라 보안팀 비개발자도 플레이북을 만들 수 있고, 버전·감사·롤백이 기본 내장입니다. 유료 도구가 부담이면 Shuffle이 오픈소스 대안이고, 조직 내 개발자가 많다면 n8n도 선택지입니다.

5-3. 자동 vs 반자동의 원칙

• 완전 자동 - 공개 IOC 매칭, 명백한 악성 IP 차단, 장기 미사용 토큰 비활성화
• 반자동 - 계정 잠금, Pod 격리, 크리덴셜 로테이션 (사람 1인 승인)
• 사람 결정 - 서비스 전면 차단, 외부 공지, 규제 기관 신고

"판단이 틀렸을 때 피해가 얼마인가"로 나누는 것이 실전 기준입니다. 잘못된 Pod 격리는 복구가 쉽지만, 잘못된 외부 공지는 돌이킬 수 없습니다.

6. MITRE ATT&CK 매핑과 커버리지

룰을 수백 개 만들어도 어떤 공격 단계를 못 보고 있는지 모르면 맹점이 생깁니다. MITRE ATT&CK이 지도 역할을 합니다.

6-1. 14개 전술(Tactic) 체크

전술	대표 기법	우리가 보는 신호
Initial Access	스피어피싱·유출 키	IdP 로그, #133 Secrets 감사
Execution	컨테이너 내 쉘·스크립트	Falco(#135)
Persistence	cron·systemd·K8s CronJob	kube-audit, 파일 변경
Privilege Escalation	컨테이너 탈출·sudo 남용	Tetragon, auditd
Credential Access	/etc/shadow·env 덤프	민감 파일 read 룰
Lateral Movement	사내 네트워크 스캔	VPC Flow, NetFlow
Exfiltration	대량 외부 업로드	egress 바이트, DLP
Impact	랜섬·마이닝·데이터 삭제	crypto miner 룰, DB 이벤트

각 셀에 최소 1개 룰이 없다면 그 구간은 보이지 않는 영역입니다. ATT&CK Navigator를 이용해 조직 커버리지 히트맵을 만들고 분기마다 채워나가는 것이 현실적입니다.

6-2. Purple Team 훈련

이론 커버리지는 Red/Blue 훈련으로 검증합니다.

• Red Canary Atomic Red Team - MITRE 기법별 테스트 스크립트 OSS
• Caldera - MITRE가 배포하는 자동화 공격 프레임워크
• Stratus Red Team - 클라우드(AWS/GCP/Azure/K8s) 특화

훈련에서 "우리 SIEM이 이 기법을 경보로 띄웠는가"를 체크리스트로 돌리면, 어떤 룰이 실제로 동작하는지가 드러납니다.

7. 도입 로드맵

SIEM·SOAR는 "깔면 끝"이 아니라 조직 루틴입니다. 단계적 전환이 정석입니다.

분기	목표	성공 지표
Q1	SIEM 설치, 핵심 소스(IdP·WAF·kube-audit) 연동	ECS 정규화 완료
Q2	Detection-as-Code 레포, 탐지 룰 30개	MITRE 전술 14/14 커버
Q3	SOAR 도입, 완전 자동 플레이북 5개	MTTR 50% 감소
Q4	Purple Team 훈련, 커버리지 히트맵	Atomic Red Team 80% 탐지
다음 해	AI 트리아지, 반자동 플레이북 확대	경보당 평균 처리시간 < 2분

"탐지 커버리지 확보 전에 SOAR부터 도입"이 흔한 실수입니다. 신호가 안 들어오는 채널에 자동화만 걸면, 모든 공격이 블라인드로 통과합니다.

8. 흔한 도입 실패 패턴

• 로그 수집량으로만 예산을 평가 - GB/day에만 집중하다 상관분석에 필요한 로그를 빼버림. 어떤 로그가 탐지에 쓰이는지를 기준으로 설계.
• 탐지 룰을 GUI에서만 관리 - 누가 언제 바꿨는지 모름. 사고 후 리그레션 불가. detection-as-code 원칙을 초기부터.
• 오탐 룰을 끄기만 하고 튜닝 안 함 - 반년 뒤 활성 룰 절반이 꺼진 상태. 폐기·수정·유지 기준을 분기 리뷰로 강제.
• SOAR 자동화를 처음부터 풀 자동 - 잘못된 조치가 장애로 직결. 초기 3개월은 "권고안 + 사람 원클릭 승인" 구조가 안전.
• ATT&CK 커버리지를 체크하지 않음 - 탐지가 많아도 맹점이 많음. 분기마다 Navigator 히트맵 갱신이 최소 루틴.
• 티켓·Slack·PagerDuty가 따로 움직임 - 같은 사건이 세 곳에서 살아 있음. SOAR가 단일 케이스 ID로 묶어야 감사 추적 가능.
• SIEM을 로그 저장소로만 사용 - 검색만 하고 상관·알림이 없음. 단순 장기 보관은 S3/Glacier가 훨씬 싸다. SIEM은 "검색 + 탐지 + 대응 허브"여야 투자 가치.
• AI 자동 트리아지를 경보 품질 개선보다 먼저 - 쓰레기 데이터에 LLM을 붙이면 쓰레기 판정을 빨리 받을 뿐. LLM-as-Judge 로직은 룰 품질이 어느 정도 선 이후에 얹는 것.

9. GPT-5.5 시대의 보안 운영 자동화

지난 #136 GPT-5.5가 "에이전트가 멀티 스텝 작업을 대신 수행"하는 방향을 가속했다면, 이 흐름이 SOC에 들어올 때 구체적 역할은 이렇게 나뉩니다.

단계	AI 역할	사람 역할
경보 수신	중복·유사 경보 병합	감사 샘플링
트리아지	컨텍스트 자동 수집·요약	최종 심각도 판단
조사	관련 이벤트·로그 질의	가설 설정·결론
대응	플레이북 제안 + 실행 초안	변경 승인
보고	타임라인·영향 요약 자동 작성	이해관계자 소통

"AI가 SOC를 대체한다"가 아니라 "AI가 컨텍스트를 모아주고, 사람이 결정한다"가 현실적 디자인입니다. 맹목적 자동 조치는 AI 에이전트 운영 사고에서 본 대규모 실수의 반복일 뿐입니다.

10. 체크리스트

• [ ] SIEM이 핵심 7대 소스(IdP·WAF·Falco·Istio·CloudTrail·Vault·kube-audit)를 수집한다
• [ ] 모든 로그가 ECS 또는 동등 스키마로 정규화된다
• [ ] 탐지 룰이 Git 저장소에서 코드로 관리되고 PR·CI가 있다
• [ ] MITRE ATT&CK 14개 전술에 최소 1개 이상의 룰이 존재한다
• [ ] Sigma 계층이 있어 SIEM 교체 가능성에 대비돼 있다
• [ ] SOAR 플레이북 최소 5개(로그인 이상·피싱·공급망·랜섬·내부 위협)가 가동 중
• [ ] 완전 자동·반자동·사람 결정 경계가 문서화돼 있다
• [ ] 분기마다 Purple Team 훈련으로 커버리지를 실측한다
• [ ] 오탐·폐기 룰 분기 리뷰가 정례화돼 있다
• [ ] MTTR·경보당 처리시간을 월간 지표로 관리한다

11. 보안 시리즈의 위치

레이어	시점	대표 도구	본 글
OWASP 기본기	커밋 전	ZAP·Dependency-Check	#131
공급망 무결성	빌드·배포	SBOM·cosign	#132
시크릿 관리	런타임 주입	Vault·Secrets Manager	#133
서비스 간 통신	요청 시	Istio·SPIFFE	#134
런타임 행동	실행 중	Falco·Tetragon	#135
운영 허브	신호 통합·대응	Elastic·Splunk·Tines	오늘

앞의 다섯 층은 "무엇을 볼지"였고, 오늘 층은 "본 것을 결정과 조치로 바꾸는 허브"입니다. 이 허브 없이는 모든 신호가 흩어진 로그로 남을 뿐입니다.

마치며

SIEM·SOAR 실전의 핵심을 정리합니다.

• SIEM과 SOAR는 한 쌍의 레이어입니다. SIEM만 깔면 경보 피로에 잠식되고, SOAR만 두면 신호가 없어 허공만 돕니다. "무엇을 보는가"와 "그래서 뭘 할 건가"를 두 도구가 각자 맡아야 운영이 돌아갑니다.
• 로그 정규화가 실제 투자의 절반입니다. ECS·Sigma 같은 중립 스키마 없이 모은 로그는 상관 분석이 무너지고, 벤더 종속이 심해져 교체도 어렵습니다. 초기부터 스키마 계층을 두는 설계가 장기적으로 비용을 가장 크게 줄입니다.
• Detection as Code는 선택이 아니라 기본값입니다. GUI 중심 운영은 "누가 언제 뭘 바꿨는지"가 사라져 사고 후 리그레션이 불가능합니다. Git + CI + 단위 테스트 + 드라이런을 첫 분기부터 도입해야 조직이 성장해도 탐지 신뢰성이 유지됩니다.
• SOAR 자동화는 반자동에서 시작해야 합니다. 처음부터 풀 자동 차단을 붙이면 오탐이 그대로 장애가 됩니다. "권고안 + 사람 원클릭" 단계에서 3개월 이상 학습한 뒤, 안정된 플레이북만 완전 자동으로 승격시키는 순서가 안전합니다.
• MITRE ATT&CK 커버리지가 탐지의 지도입니다. 룰 개수보다 14개 전술 전반의 고른 분포가 훨씬 중요합니다. Atomic Red Team·Caldera·Stratus로 분기마다 실측해 맹점을 찾아내지 않으면 "있는 줄 알았던" 탐지가 사고 때 사라집니다.
• AI 트리아지는 룰 품질이 선행되어야 가치를 냅니다. GPT-5.5 수준의 에이전트가 등장했다고 해서 SOC를 통째로 맡길 수는 없습니다. 컨텍스트 수집·요약·플레이북 초안까지가 AI의 영역이고, 최종 결정은 사람이 지는 구조가 2026년의 현실적 합의점입니다.

OWASP(#131) · SBOM(#132) · Secrets(#133) · Zero Trust(#134) · 런타임 탐지(#135) · SIEM/SOAR까지로 애플리케이션 보안 6단 방어선이 구성됐습니다. 다음 편에서는 이 모든 층을 통과한 뒤 남는 마지막 관심사인 개인정보 보호와 데이터 프라이버시 - GDPR·CCPA·PIPA와 암호화·마스킹 실전을 다룰 예정입니다. 보안이 "시스템을 지킨다"였다면, 프라이버시는 "그 시스템 위에 있는 사람의 데이터"입니다.