탐지정책수립 및 탐지정책대장 작성

설동윤·2026년 2월 23일

머하지

목록 보기
2/2

좋아. 네가 잡은 큰 흐름은 이미 좋고, 실무적으로 필요한 단계(검증/배포/변경관리)가 중간에 빠져 있어서 그 부분을 보완하면 훨씬 탄탄해져. 🛠️

아래는 네 초안을 기반으로 세분화 + 선행작업(의존성) + 시기(예시)까지 반영해서 정리한 탐지정책개발 중심 WBS야.

WBS 재구성 방향

네 초안 기준으로 구조를 이렇게 다듬는 게 좋아:

  • 2.1 로그 수집체계 운영 (기반)
  • 2.2 이벤트 정규화 및 분류 (정책개발 준비)
  • 2.3 탐지 정책 개발 및 수립 (핵심)
  • 2.4 정책 검증/배포/변경관리 ✅ (추가 권장)
  • 2.5 이벤트 분석 및 대응 운영 (운영)
  • 2.6 성능평가 및 지속개선 ✅ (추가 권장)

이유: 정책은 “만들기”만 하면 끝이 아니라, 검증 → 배포 → 운영 피드백 → 재튜닝까지 돌아야 함.

2.x AI 기반 공격 이벤트 탐지 및 대응 WBS (세분화본)

2.1 로그 수집체계 운영 (기반 단계)

2.1.1 수집 요구사항 및 범위 정의

  • 2.1.1.1 수집 대상 자산 정의

    • 서버(웹/WAS/DB)
    • 방화벽, WAF, IDS/IPS(Snort/Suricata), EDR
    • 인증/VPN/AD(있으면)

  • 2.1.1.2 수집 목적/탐지 유스케이스 매핑

    • 어떤 공격을 탐지할지 기준으로 로그 우선순위 정의
    • 예: SQLi → WAF/웹서버/DB 로그 필요

  • 2.1.1.3 필수 필드 정의

    • 시간, src/dst IP, Port, Protocol, User, Action, URI, Status Code 등

  • 2.1.1.4 보존주기/저장정책 정의

    • 원본 보관 기간, 압축/아카이브, 개인정보 마스킹 정책

2.1.2 로그 수집 파이프라인 설계/구성

  • 2.1.2.1 수집 방식 정의

    • Agent / Syslog / API / Filebeat / Forwarder 등

  • 2.1.2.2 전송 경로 및 보안 설정

    • TLS 적용, 계정/권한 최소화

  • 2.1.2.3 시간 동기화(NTP) 점검

    • 타임라인 분석 정확도 확보

  • 2.1.2.4 버퍼/재전송 정책 정의

    • 수집 실패 시 재시도, 큐 적체 대응

2.1.3 로그 포맷 표준화 (JSON 변환 포함)

  • 2.1.3.1 공통 스키마 정의

    • 예: event_time, src_ip, dst_ip, event_type, severity

  • 2.1.3.2 원본 로그별 파싱 규칙 정의

    • Apache/Nginx, Windows Event, Snort alert, Firewall syslog 등

  • 2.1.3.3 JSON 변환/정규화 구현

  • 2.1.3.4 파싱 실패 처리 규칙

    • unknown 필드 처리, raw 로그 보존

2.1.4 수집 품질 모니터링 및 누락 점검

  • 2.1.4.1 수집 성공률 모니터링 대시보드

  • 2.1.4.2 수집 지연/적체 감시

  • 2.1.4.3 로그 누락 점검(자산별 heartbeat)

  • 2.1.4.4 수집 실패 알림 연동

    • Slack/메일/관제알람

2.2 이벤트 정규화 및 분류 (정책개발 준비 단계)

2.2.1 이벤트 파싱 및 필드 추출

  • 2.2.1.1 핵심 필드 추출

    • IP, Port, Protocol, URI, Method, User, Process, Hash 등

  • 2.2.1.2 자산/서비스 메타데이터 결합

    • 자산 중요도, 서비스명, 운영환경(Dev/Prod)

  • 2.2.1.3 TI 정보 결합(Enrichment)

    • 악성 IP/도메인 평판, CVE 연관성, 캠페인 태그

2.2.2 이벤트 정규화

  • 2.2.2.1 시간/타임존 표준화

  • 2.2.2.2 IP/Port/Protocol 포맷 통일

  • 2.2.2.3 사용자/호스트명 표준화

  • 2.2.2.4 중복 이벤트 제거 기준 정의

    • 동일 이벤트 반복 처리(디듀프)

2.2.3 공격 유형 분류 체계 수립

  • 2.2.3.1 분류 Taxonomy 정의

    • 인증 공격, 웹 공격, 악성코드, C2, 권한상승, 내부이동 등

  • 2.2.3.2 MITRE ATT&CK 매핑 기준 정의

  • 2.2.3.3 심각도 기준 정의

    • 영향도 + 자산 중요도 + 신뢰도

  • 2.2.3.4 오탐 가능 이벤트 태그 기준

    • 스캐너, 백업작업, 배치성 트래픽 예외 태그

2.2.4 AI 보조 분류(프롬프트 기반) 정의 ✅

  • 2.2.4.1 AI 입력 포맷 정의

    • 로그 요약/이벤트 묶음 형식

  • 2.2.4.2 AI 프롬프트 템플릿 설계

    • 1차 분석, IOC 추출, MITRE 매핑, 대응 권고

  • 2.2.4.3 AI 출력 스키마 정의

    • risk, reason, iocs, next_checks, confidence

  • 2.2.4.4 사람 검토 기준(Human-in-the-loop) 정의

    • AI 판단 단독 차단 금지 등

2.3 탐지 정책 개발 및 수립 (핵심 단계)

네가 말한 “정책개발”의 중심 구간이 여기야. 🎯

2.3.1 탐지 유스케이스 정의

  • 2.3.1.1 우선 탐지 시나리오 선정

    • 예: Brute Force, SQLi, XSS, 웹쉘 업로드, C2 통신, 내부 스캔

  • 2.3.1.2 시나리오별 탐지 목표 정의

    • 탐지 조건, 기대 경보, 대응 필요 수준

  • 2.3.1.3 데이터 소스 매핑

    • 각 유스케이스에 필요한 로그 소스 연결

  • 2.3.1.4 성공 기준 정의

    • 탐지율/오탐률/응답시간 목표

2.3.2 탐지 로직 설계 (룰/상관분석/행위기반)

  • 2.3.2.1 시그니처 기반 탐지 설계

    • 패턴 매칭, 키워드, 정규식

  • 2.3.2.2 임계치/빈도 기반 탐지 설계

    • 예: 5분 내 로그인 실패 N회

  • 2.3.2.3 상관분석 규칙 설계

    • 실패 로그인 → 성공 로그인 → 관리자 기능 접근

  • 2.3.2.4 행위 기반 탐지 설계

    • 정상 프로파일 대비 이상행위

  • 2.3.2.5 예외 조건 설계

    • 백업서버, 취약점 스캐너, 모니터링 서버 예외

2.3.3 IDS/IPS 룰 개발 및 튜닝 (Snort/Suricata)

  • 2.3.3.1 기존 룰셋 검토/선별

  • 2.3.3.2 환경 맞춤 커스텀 룰 작성

  • 2.3.3.3 룰 충돌/중복 점검

  • 2.3.3.4 룰 성능 영향 점검

    • 과도한 pcre, broad match 등

  • 2.3.3.5 룰 튜닝 (오탐 감소 / 미탐 보완)

2.3.4 SIEM 탐지 정책 개발 (쿼리/상관분석)

  • 2.3.4.1 탐지 쿼리 초안 작성

    • SPL/ELK Query 등

  • 2.3.4.2 상관분석 룰 구현

    • 멀티 로그 소스 연계

  • 2.3.4.3 알림 임계치 및 우선순위 설정

  • 2.3.4.4 알림 메시지 표준화

    • 어떤 정보가 포함되어야 1차 분석이 가능한지

2.3.5 AI 분석 프롬프트 정책 개발 ✅

  • 2.3.5.1 이벤트 유형별 프롬프트 템플릿

    • 로그인 공격용 / 웹공격용 / 악성코드용

  • 2.3.5.2 출력 형식 표준화

    • 요약, 위험도, 근거, 추가확인로그, 대응권고

  • 2.3.5.3 금지/제약 정책 정의

    • “차단 자동실행 금지”, “불확실하면 추정 표기”

  • 2.3.5.4 프롬프트 버전관리

    • v1, v1.1 변경 이력 관리

2.3.6 오탐/미탐 분석 기준 수립

  • 2.3.6.1 오탐 판정 기준 정의

  • 2.3.6.2 미탐 식별 기준 정의

    • 사고 후 역추적, 재생 테스트

  • 2.3.6.3 튜닝 요청 프로세스 정의

  • 2.3.6.4 KPI 정의

    • Precision, Recall, MTTD, MTTR 등

2.3.7 정책 문서화 및 승인

  • 2.3.7.1 정책 명세서 작성

  • 2.3.7.2 운영 절차서(SOP) 연결

  • 2.3.7.3 변경 승인 프로세스 정의

  • 2.3.7.4 버전관리 저장소 등록

    • Git / 문서관리시스템

2.4 정책 검증 / 배포 / 변경관리 (필수 보완 단계)

2.4.1 테스트 데이터셋 준비

  • 2.4.1.1 정상 트래픽 샘플 확보

  • 2.4.1.2 공격 시나리오 샘플 확보

    • ZAP, 테스트 로그, Snort PCAP 등

  • 2.4.1.3 라벨링 데이터셋 구성

    • 정상/공격/의심

2.4.2 정책 검증 (정확도/성능)

  • 2.4.2.1 탐지 정확도 검증

    • 탐지율, 오탐률

  • 2.4.2.2 성능 검증

    • 지연, 리소스 사용량

  • 2.4.2.3 AI 출력 품질 검증

    • 근거 타당성, 환각 여부

  • 2.4.2.4 검증 결과 리포트 작성

2.4.3 단계적 배포

  • 2.4.3.1 시험환경 배포

  • 2.4.3.2 부분 운영(파일럿) 적용

    • 특정 자산/네트워크 구간

  • 2.4.3.3 운영 배포

  • 2.4.3.4 롤백 절차 준비/테스트

2.4.4 변경관리 운영

  • 2.4.4.1 변경 요청 등록
  • 2.4.4.2 영향도 분석
  • 2.4.4.3 승인/배포 일정 관리
  • 2.4.4.4 변경 이력/감사 로그 관리

2.5 이벤트 분석 및 대응 (운영 단계)

2.5.1 1차 분석 (Tier1)

  • 2.5.1.1 알림 확인 및 중복 여부 판단

  • 2.5.1.2 기본 컨텍스트 확인

    • 자산 중요도, 사용자, 시간대

  • 2.5.1.3 AI 보조분석 실행

    • 요약/IOC 추출/추가확인 로그 추천

  • 2.5.1.4 초기 판정

    • 오탐 / 의심 / 정탐 후보

2.5.2 2차 정밀 분석 (Tier2/IR)

  • 2.5.2.1 패킷 분석 (PCAP)
  • 2.5.2.2 엔드포인트/프로세스 분석
  • 2.5.2.3 타임라인 재구성
  • 2.5.2.4 공격 경로/영향 범위 식별
  • 2.5.2.5 MITRE ATT&CK 매핑

2.5.3 대응 조치 수행

  • 2.5.3.1 IP/도메인 차단

  • 2.5.3.2 계정 잠금/비밀번호 초기화

  • 2.5.3.3 호스트 격리/포트 차단

  • 2.5.3.4 증거 보존

    • 로그, 메모리, PCAP, 해시

  • 2.5.3.5 유관부서 통보

    • 서버팀/개발팀/관리자

2.5.4 사고 이력 및 보고

  • 2.5.4.1 사고 티켓 생성/업데이트
  • 2.5.4.2 IOC/TTP 기록
  • 2.5.4.3 대응 내역 및 결과 기록
  • 2.5.4.4 재발방지 권고안 작성

2.6 성능 평가 및 지속 개선 (운영 안정화)

2.6.1 탐지 정책 성과 측정

  • 탐지율, 오탐률, 미탐사례, MTTD/MTTR

2.6.2 오탐/미탐 피드백 반영

  • 룰 튜닝, 예외 조정, 상관규칙 개선

2.6.3 신규 공격 패턴 반영

  • TI 기반 신규 IOC/TTP/CVE 반영
  • Snort 룰/쿼리/프롬프트 업데이트

2.6.4 정기 리뷰 및 버전 업데이트

  • 주간 운영 리뷰, 월간 정책 릴리즈
  • 변경 이력 정리 및 감사 대응

선행작업(의존성) 고려한 일정 예시 (8주 기준)

아래는 프로젝트형 구축 기준 예시야.
(운영 들어가면 2.5~2.6은 반복 사이클로 감)

기간주요 작업선행 필요 작업
1주차2.1.1 수집 요구사항/범위 정의없음
2주차2.1.2 수집 파이프라인 설계, 2.1.3 표준화 설계2.1.1
3주차2.1.3 구현, 2.1.4 수집 품질 모니터링2.1.2
4주차2.2 이벤트 파싱/정규화/분류체계2.1.3, 2.1.4
5주차2.3.1 유스케이스 정의, 2.3.2 탐지 로직 설계2.2 완료
6주차2.3.3 IDS 룰 개발, 2.3.4 SIEM 정책, 2.3.5 AI 프롬프트 정책2.3.2
7주차2.4 테스트 데이터셋 구성, 정책 검증/튜닝2.3.3~2.3.6
8주차2.4 배포/변경관리, 2.5 운영 전환, 2.6 KPI 측정 시작2.4.2

핵심 선행관계 요약 (중요 포인트)

1) 로그 수집 품질이 먼저

  • 2.1(수집/표준화)가 불안정하면
    → 2.2 정규화/분류 품질이 깨지고
    → 2.3 탐지정책 정확도도 무너짐

2) 정규화/분류가 정책개발의 선행조건

  • 정책은 결국 필드 기반으로 동작하니까
  • src_ip, user, action 같은 공통 필드 표준화가 먼저 필요함

3) 정책개발 후 검증/배포 단계는 필수

  • 이 단계 없이 바로 운영 넣으면 오탐 폭증 가능성 큼
  • 특히 Snort 룰/상관분석/AI 프롬프트는 검증셋 기반 튜닝 필수

4) 운영 결과가 다시 정책개발로 돌아가야 함

  • 2.5 → 2.6 → 2.3 피드백 루프가 있어야 실무형 WBS가 됨

네 초안 기준으로 바꾸면 좋은 표현 (문서용)

네가 쓴 문장을 약간 더 실무형으로 바꾸면 이렇게 좋아:

기존

  • 로그 파싱 (IP, Port, Protocol 추출)
  • 공격 유형별 분류

개선

  • 로그 파싱 및 공통 필드 정규화(IP/Port/Protocol/User/URI 추출 및 스키마 표준화)
  • MITRE ATT&CK 기반 공격 유형 분류 체계 및 심각도 기준 수립

추가 팁 (네 프로젝트에 특히 유용)

네가 Snort, ZAP, WAF, Splunk까지 같이 보는 스타일이라서, 탐지정책 WBS에 아래 항목을 꼭 넣는 걸 추천해:

  • 테스트 데이터셋 구성 (정상/공격 로그 분리)
  • Snort 룰 성능 점검 (과도한 룰로 지연 발생 방지)
  • AI 프롬프트 출력 형식 표준화 (보고서 자동화 연계)
  • 변경관리/버전관리 (학기/프로젝트 발표 때 설명 포인트 좋음)

원하면 다음 답변에서 내가 이 WBS를 그대로 바탕으로
“WBS + 담당자(RACI) + 주차별 마일스톤” 형태로 더 실무적으로 확장해줄게.

profile
설동윤
c++
이전 포스트

ti정보수집

0개의 댓글