정보 링크:
https://www.criminalip.io/ko/knowledge-hub/blog/24628
좋아. 아래는 보안관제(SOC)에서 TI(Threat Intelligence) 정보수집 단계를 실제 프로젝트에 넣을 수 있게 만든 WBS 예시야. 🛡️
기준은 네가 앞에서 정리한 내용(IOC/TTP/CVE/캠페인 수집, SIEM/Snort/EDR 반영 관점) + 업로드한 TI 사이클/소스(OSINT, HUMINT, TECHINT) 개념을 반영했어.
아래는 프로젝트형(초기 구축) 기준 예시야.
운영 단계에서는 4.0~6.0이 반복 수행됨.
| WBS ID | 작업명 | 상세 작업 | 산출물 | 담당(예시) | 기간(예시) | 선행 |
|---|---|---|---|---|---|---|
| 1.0 | TI 정보수집 준비 | 수집 목표/범위 정의 (관제 목적, 자산 범위, 우선 위협) | 수집 범위 정의서 | SOC 리더, TI 담당 | 0.5일 | - |
| 1.1 | 수집 요구사항 정의 | 어떤 위협을 볼지 정의 (웹공격, 계정탈취, C2, 악성 IP 등) | 정보요구사항(IR) 목록 | SOC 분석가 | 0.5일 | 1.0 |
| 1.2 | 수집 항목 분류 | IOC/TTP/CVE/캠페인/취약자산/피싱 분류 체계 수립 | TI 분류 체계표 | TI 담당 | 0.5일 | 1.1 |
| 1.3 | 우선순위 기준 정의 | 신뢰도, 최신성, 우리 환경 연관성 기준 정립 | 우선순위 기준표 | SOC 리더 | 0.5일 | 1.2 |
| 2.0 | 수집 소스 정의 및 등록 | 외부/내부 수집 채널 목록화 | TI 소스 카탈로그 | TI 담당 | 1일 | 1.3 |
| 2.1 | OSINT 소스 등록 | 벤더 블로그, CERT, CVE/KEV, 악성 IOC 피드, 보안 뉴스 등록 | OSINT 목록 | TI 담당 | 0.5일 | 2.0 |
| 2.2 | HUMINT 소스 등록 | 커뮤니티, 내부 공유채널, 협력사 알림 체계 정의 | HUMINT 목록/연락체계 | SOC 리더 | 0.5일 | 2.0 |
| 2.3 | TECHINT 소스 등록 | 샌드박스, 악성코드 분석, 네트워크/EDR 분석 결과 수집 채널 정의 | TECHINT 목록 | IR/TI 담당 | 0.5일 | 2.0 |
| 2.4 | 내부 관제 소스 연계 정의 | SIEM, EDR, FW, WAF, IDS/IPS(Snort)에서 TI 연계 가능한 필드 정의 | 내부연계 필드맵 | SOC 엔지니어 | 0.5일 | 2.0 |
| 3.0 | 수집 파이프라인 구축 | 수집 방식 수동/자동 설계 및 구현 | 수집 파이프라인 설계서 | SOC 엔지니어 | 2일 | 2.4 |
| 3.1 | 수집 템플릿 설계 | 표준 수집 포맷 정의 (IOC type/value/source/time/confidence) | 수집 템플릿(JSON/CSV) | TI 담당 | 0.5일 | 3.0 |
| 3.2 | 자동수집 스크립트/커넥터 구성 | RSS/API/파일수집/메일수집 등 자동화 | 수집 스크립트/커넥터 | 엔지니어 | 1일 | 3.1 |
| 3.3 | 수동수집 절차서 작성 | 수동 등록 기준(긴급 IOC, 사고 공유 등) 정의 | 수동수집 SOP | TI 담당 | 0.5일 | 3.1 |
| 3.4 | 저장소/DB 구성 | TI 임시 저장소(테이블/폴더/인덱스) 구성 | TI Raw 저장소 | 엔지니어 | 0.5일 | 3.2 |
| 4.0 | TI 데이터 수집 실행 | 소스별 실제 데이터 수집 수행 | Raw TI 데이터셋 | TI 담당 | 3일 | 3.4 |
| 4.1 | IOC 수집 | 악성 IP/도메인/URL/해시/이메일/인증서 지문 수집 | IOC Raw 목록 | TI 담당 | 1일 | 4.0 |
| 4.2 | TTP 수집 | MITRE ATT&CK 기반 TTP/행위패턴/공격흐름 수집 | TTP Raw 목록 | TI/IR 담당 | 0.5일 | 4.0 |
| 4.3 | 취약점 정보 수집 | CVE, KEV, PoC 공개 여부, 벤더 권고안 수집 | CVE/KEV 목록 | TI 담당 | 0.5일 | 4.0 |
| 4.4 | 캠페인/그룹 정보 수집 | 산업군 대상 공격 캠페인, 공격그룹/행위자 동향 수집 | 캠페인 보고 요약 | TI 담당 | 0.5일 | 4.0 |
| 4.5 | 내부 탐지 연계 수집 | 최근 7~30일 SIEM/EDR/Snort 경보와 외부 TI 연관 후보 수집 | 내부연계 후보 목록 | SOC 분석가 | 0.5일 | 4.0 |
| 5.0 | 수집 품질 점검 및 인계 | 수집 결과 검수 후 처리단계로 넘김 | 수집결과 검수서 | SOC 리더 | 1.5일 | 4.5 |
| 5.1 | 중복/형식 점검 | 포맷 오류, 중복, 필수 필드 누락 점검 | 품질 점검 결과 | TI 담당 | 0.5일 | 5.0 |
| 5.2 | 신뢰도/최신성 태깅 | source 신뢰도, first_seen/last_seen 기준 태깅 | 신뢰도 태그 적용본 | TI 담당 | 0.5일 | 5.1 |
| 5.3 | 관제 연계 태깅 | SIEM/Snort/EDR/WAF 반영 대상 구분 태깅 | 반영대상 태그 목록 | SOC 분석가 | 0.5일 | 5.2 |
| 5.4 | 처리단계 인계 | 정제/처리 담당에게 인계 (CSV/JSON/API) | 인계 패키지 | TI 담당 | 0.25일 | 5.3 |
| 6.0 | 운영 전환 | 반복 수집 주기/책임/지표 운영화 | 운영 계획서 | SOC 리더 | 1일 | 5.4 |
| 6.1 | 수집 주기 설정 | 실시간/일간/주간 수집 주기 정의 | 주기표 | SOC 리더 | 0.25일 | 6.0 |
| 6.2 | 예외/긴급 수집 절차 | 긴급 CVE/캠페인 발생 시 핫패스 정의 | 긴급수집 SOP | SOC 리더 | 0.25일 | 6.0 |
| 6.3 | KPI 정의 | 수집량, 유효율, 탐지기여율, 오탐유발율 등 정의 | KPI 시트 | TI 담당 | 0.25일 | 6.0 |
| 6.4 | 정기 리뷰 일정 수립 | 주간/월간 품질 리뷰 및 피드백 회의 계획 | 리뷰 캘린더 | SOC 리더 | 0.25일 | 6.0 |
ti_type (IP / domain / url / hash / cve / ttp / campaign)valuesource_namesource_typecollected_atfirst_seenlast_seenconfidence (low/med/high)relevance (우리환경 연관도)descriptionmitre_tacticmitre_techniquerecommended_actiontarget_siemtarget_snorttarget_waftarget_edrtarget_firewallneeds_manual_reviewTI 사이클상 수집 후에 처리(정리/구조화)가 별도 단계인 게 핵심이야.
WBS에서도 5.0에서 품질 점검 + 인계까지만 하고, 정제/분석은 다음 단계로 넘기는 구조가 깔끔함.
실무 SOC에서는 외부 TI만 모으면 활용성이 떨어짐.
src_ip, dest_ip, domain, url, hash)를 같이 정의해야 함.업로드한 자료에도 나온 것처럼 오래된 IoC, 중복 데이터, 신뢰도 문제가 TI 실무의 대표 이슈라서, 수집 단계부터 태깅해두는 게 좋음.
TI 정보수집 단계 WBS는 보안관제 환경에서 활용 가능한 위협 인텔리전스를 확보하기 위해, 수집 요구사항 정의 → 소스 등록(OSINT/HUMINT/TECHINT/내부 연계) → 수집 파이프라인 구축 → IOC/TTP/CVE/캠페인 데이터 수집 → 품질 점검 및 처리단계 인계 → 운영 전환의 순서로 구성하였다.
원하면 다음으로 이어서 “TI 처리단계 WBS”(중복제거, 정규화, 스코어링, 매핑, SIEM/Snort 반영 준비)까지 같은 형식으로 확장해줄게.