SIEM · 보안관제 › A. SIEM 구조와 로그 수집 · 49/50편 학습 단계: 실전 시나리오·종합 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Wazuh 4.x 올인원 / Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 048. SIEM·로그 수집 — 수집·정규화 장애 대응 절차 1. 개념 A영역의 내용을 하나의 작업으로 엮어 봅니다. 상황은 "신규 웹 서버 web02를 오늘 운영에 투입하니, 관제 대상으로 편입해 달라"는 요청입니다. 공격 재현이 아니라 편입 절차와 검증, 그리고 편입 직후 실제로 잡힌 이벤트를 판단하는 과정 에 집중합니다. 편입 시나리오 타임라인(가상의 예시) 09:00 요청 접수: web02(Rocky 9, nginx, 192.168.56.23) 09:10 수집 인벤토리 작성: secure·audit·nginx access/error·방화벽 로그 (003편) 09:20 에이전트 등록 → Active (006편) 09:30 그룹 linux-rocky·web 적용 → Analyzing file 확인 (008·009편) 09:40 테스트 이벤트: 실패 로그인·sudo·웹 404 → 기대 룰 확인 (009·012·025편) 09:50 수집 상태 대시보드·히트맵에 web02 추가 확인 (045편) 10:05 nginx 로그 형식이 JSON → 기본 웹 룰 미매칭 발견 → 커스텀 룰 (012·024편) 11:30 첫 고위험 Alert: 외부 출발지 웹 스캔 + SSH 대입 시도 핵심: "에이전트 Active"가 아니라 "테스트 이벤트가 기대 룰로 나옴"이 편입 완료 이 시나리오에서 가장 중요한 장면은 10:05입니다. 에이전트는 붙었고 로그도 들어왔지만, 로그 형식 차이로 웹 탐지가 안 되는 상태 였습니다. 테스트 이벤트 검증이 없었다면 그대로 운영에 들어갔을 것입니다. 2. 왜 중요한가 편입 절차가 실제로 어떤 순서로 연결되는지 확인할 수 있습니다. "수집된다"와 "탐지된다"의 차이를 구체적으로 보여 줍니다. 면접에서 SIEM 편입 경험을 구조적으로 설명하는 틀이 됩니다. 3. 핵심 명령어 / 설정 시각 확인 결과 09:20 agent_control Active 09:30 Analyzing file 4개 소스 등록 09:40 테스트 로그인 5716·5715 정상 09:40 테스트 웹 404 미매칭 → 조치 09:50 히트맵 web02 행 채워짐 11:30 첫 고위험 스캔+대입 4. 실습 (실습 예시) # 편입 검증 명령 모음 (실습 예시) sudo /var/ossec/bin/agent_control -l | grep web02 ssh web02 "sudo grep 'Analyzing file' /var/ossec/logs/ossec.log | tail -4" # 테스트 이벤트 후 기대 룰 확인 sudo jq -r 'select(.agent.name=="web02") | [.timestamp,.rule.id,.rule.description] | @tsv' /var/ossec/logs/alerts/alerts.json | tail -5 # JSON nginx 로그 디코딩 확인 ssh web02 "tail -n1 /var/log/nginx/access.json" | sudo /var/ossec/bin/wazuh-logtest -q 2>/dev/null | grep -E "name:|status|uri|id:" 5. 정상 상태 web02 Active · 소스 4개 Analyzing 테스트: 5716(실패) · 5715(성공) · 5402(sudo) · 110xxx(JSON 웹 404 커스텀 룰) 히트맵: web02 모든 소스 수신 모든 소스가 테스트 이벤트로 기대 룰을 만들고 수집 상태 대시보드에 나타나면 편입 완료로 판단합니다. 6. 이상 상태 11:30~11:42 web02 · 203.0.113.44 → 웹 404 1,820건(서로 다른 경로 1,700개) · 같은 출발지 SSH 실패 96회(계정 41개) · 성공 로그인: 없음 편입 2시간 만에 외부 스캔·대입 시도 포착 서로 다른 경로 다수 → 디렉터리 스캔, 계정 다수 → spraying 성공 없음 → 시도 단계로 판단, 출발지 차단 요청 7. 로그 분석 (분석 방법) 첫 Alert 판단 흐름입니다(가상의 예시). [고위험 Alert] web02 SSH 대입 + 웹 404 급증 ↓ [집계] 출발지 Top · 경로 수 · 계정 수(042편) ↓ [성공 여부] 같은 출발지 Accepted·200 응답 확인 → 없음 ↓ [판정] 정탐(공격 시도) · 침투 없음 ↓ [조치] 출발지 차단 요청 · 노출 서비스 점검(SSH 외부 노출 여부) ↓ [편입 보고] 편입 결과 + 첫 탐지 내역 판단 근거 결과 경로 1,700개 디렉터리 스캔 계정 41개 spraying 성공 없음 시도 단계 신규 서버가 외부에 노출되면 수 시간 안에 자동화된 스캔이 들어오는 일은 흔합니다. 편입 직후 이런 시도를 잡아낸 것 자체가 수집·디코딩·룰이 제대로 연결됐다는 증거이기도 합니다. 8. SOC 관제 포인트 편입 완료 기준을 "테스트 이벤트 기대 룰 확인"으로 둡니다. 편입 직후 첫 24시간은 해당 호스트 Alert를 집중 확인합니다. 편입 보고서에 소스별 검증 결과를 남깁니다. 9. 탐지 규칙 <!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 --> <group name="local,siem_a,"> <rule id="110480" level="13"> <if_matched_group>authentication_failed</if_matched_group> <if_group>web</if_group> <same_source_ip /> <timeframe>1800</timeframe> <description>동일 출발지 30분 내 웹 공격·스캔과 SSH 인증 실패 동시 발생(다중 서비스 공격)</description> <mitre><id>T1595</id></mitre> </rule> </group> 같은 출발지가 웹과 SSH를 함께 공격하는 패턴을 하나로 묶는 상관 예시입니다. 웹 로그와 인증 로그가 모두 srcip 로 정규화되어 있어야 동작합니다(026편). 10. 대응 방법 초기 확인 — 편입 소스별 테스트 결과와 첫 Alert를 확인합니다. 범위 확인 — 출발지·대상 범위와 성공 이벤트 여부를 확인합니다. 증거 확보 — 편입 검증 기록과 Alert를 보존합니다. 차단/조치 — 출발지 차단과 노출 서비스 점검을 요청합니다. 재발 방지 — 편입 체크리스트와 첫 24시간 집중 감시를 운영합니다. 11. 핵심 정리 단계 완료 기준 등록 Active 수집 Analyzing file 탐지 테스트 → 기대 룰 운영 히트맵·첫 Alert 판단 면접 포인트 "에이전트 Active는 시작일 뿐 — 테스트 이벤트가 기대 룰로 나와야 편입 완료" 12. 다음 편 예고 다음 편 050. SIEM·로그 수집 — SIEM 구조와 로그 수집 종합 정리 에서는 A영역 50편을 수집·정규화·저장·운영 네 축으로 종합하고, 다음 B영역 「탐지 룰 엔지니어링」으로 이어지는 흐름을 정리합니다. 이전 편: 048. SIEM·로그 수집 — 수집·정규화 장애 대응 절차 📚 시리즈 전체 보기: SIEM · 보안관제
SIEM · 보안관제 › A. SIEM 구조와 로그 수집 · 50/50편 학습 단계: 실전 시나리오·종합 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Wazuh 4.x 올인원 / Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 049. SIEM·로그 수집 — 실전 시나리오 — 신규 서버 SIEM 편입부터 첫 Alert까지 1. 개념 A영역 50편을 정리합니다. 한 문장으로 요약하면 "Alert를 믿으려면, 그 Alert가 만들어진 데이터부터 믿을 수 있어야 한다" 입니다. 수집·정규화·저장·운영의 네 축이 이 신뢰를 만듭니다. A영역 50편 지도 [구조·환경 001~008] SIEM 5계층 · Wazuh 구성요소 · 에이전트 등록·상태 · localfile [로그 소스 009~020] 인증 · journald · auditd · 웹 · DB · 방화벽 · IDS · Windows syslog · 네트워크 장비 · 컨테이너 · 수집 누락(침묵) [디코딩·정규화 021~030] 3단계 처리 · 기본/커스텀/JSON 디코더 · logtest 회귀 공통 스키마 · 시간 · 식별자 · 보강 · 품질 지표 [저장·파이프라인 031~040] 인덱스·매핑 · 보존(ISM) · EPS 용량 · Filebeat·Logstash 백프레셔 · 전송 보안 · 무결성 · 종합 점검 [검색·운영 041~048] DQL · 집계 · 시각화 · SOC 대시보드 · 수집 상태 · 튜닝 체크리스트 · 장애 대응 [종합 049~050] 편입 시나리오 · 종합 정리 신뢰의 4축 수집됐는가 → 해석됐는가 → 저장·검색되는가 → 계속 그런가(운영) B영역에서는 이렇게 신뢰할 수 있게 된 데이터 위에 탐지 룰을 설계·검증·튜닝 하는 방법(룰 구조, 빈도·상관 룰, Sigma, MITRE 매핑, 오탐 관리)을 다룹니다. 2. 왜 중요한가 A영역은 이후 모든 탐지·분석·대응 영역의 전제 조건입니다. 수집 품질을 설명할 수 있는 관제원은 Alert 판단의 신뢰도도 높습니다. 면접에서 "SIEM을 어떻게 운영하나"에 구조적으로 답할 수 있습니다. 3. 핵심 명령어 / 설정 축 핵심 질문 대표 지표 수집 로그가 오는가 에이전트 상태·소스 침묵 해석 필드로 나뉘는가 디코딩 실패율·필드 채움률 저장 검색·보존되는가 cluster status·지연·보존일 운영 계속 그런가 체크리스트 수행·장애 대응 4. 실습 (실습 예시) # A영역 종합 점검 루틴 (분석 방법) — 10분 점검 sudo /var/ossec/bin/wazuh-control status | grep -c 'is running' sudo /var/ossec/bin/agent_control -l | grep -cE 'Disconnected|Never' sudo grep -oP "events_dropped='\K[0-9]+" /var/ossec/var/run/wazuh-analysisd.state curl -sk -u 'admin:<비밀번호>' https://localhost:9200/_cluster/health | grep -oP '"status":"\K[a-z]+' tail -n 1 /root/siem-ops/daily_check.log 5. 정상 상태 running 6 · 끊김 0 · drop 0 · green · 일일 점검 오늘 기록 있음 네 축의 대표 지표가 모두 기준값이면 이 SIEM이 만드는 Alert를 신뢰하고 탐지 개선(B영역)에 집중할 수 있습니다. 6. 이상 상태 running 6 · 끊김 2 · drop 1,204 · yellow · 일일 점검 4일 전 여러 축에서 동시에 이상 → Alert 신뢰도 낮음 이 상태에서 룰을 튜닝하면 잘못된 데이터로 잘못된 결론 수집·운영 축부터 복구한 뒤 탐지 작업으로 넘어가야 함 7. 로그 분석 (분석 방법) 「SIEM · 보안관제」 시리즈 흐름입니다(가상의 예시). A SIEM 구조와 로그 수집 데이터를 믿을 수 있게 만든다 ← 완료 ↓ B 탐지 룰 엔지니어링 믿을 수 있는 데이터로 무엇을 잡을지 정한다 ↓ C 보안 이벤트 분석·트리아지 울린 Alert를 판단한다 ↓ D 위협 헌팅·MITRE ATT&CK 울리지 않은 것을 찾는다 ↓ E 침해사고 대응(IR) 확인된 사고를 처리한다 ↓ F SOC 운영·보고 이 모든 것을 반복 가능하게 만든다 영역 관제 질문 A 데이터를 믿을 수 있나 B 무엇을 잡을까 C 이 Alert는 진짜인가 D~F 놓친 것·처리·운영 각 영역은 앞 영역의 결과를 전제로 합니다. A영역에서 만든 점검 지표는 B영역 이후에도 "이 결론을 믿어도 되는가"를 판단하는 기준으로 계속 쓰입니다. 8. SOC 관제 포인트 10분 종합 점검을 교대 시작 루틴으로 씁니다. 네 축 지표를 주간 보고의 첫 페이지에 둡니다. 탐지 개선 작업 전에 수집 신뢰도를 먼저 확인합니다. 9. 탐지 규칙 <!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 --> <group name="local,siem_a,"> <rule id="110490" level="3"> <if_sid>110000,110190,110300,110360,110390</if_sid> <description>A영역 수집·저장 신뢰도 관련 이벤트(종합 대시보드 집계용)</description> </rule> </group> A영역에서 만든 수집·저장 관련 룰을 하나로 묶어 대시보드에서 "데이터 신뢰도" 패널을 만드는 집계용 예시입니다. if_sid에 여러 룰 ID를 쉼표로 나열할 수 있습니다. 10. 대응 방법 초기 확인 — 네 축의 대표 지표를 확인합니다. 범위 확인 — 이상 축의 영향 범위를 확인합니다. 증거 확보 — 점검 결과를 기록합니다. 차단/조치 — 수집·운영 축을 우선 복구합니다. 재발 방지 — 종합 점검을 교대 루틴과 주간 보고에 반영합니다. 11. 핵심 정리 축 질문 수집 오는가 해석 나뉘는가 저장 찾을 수 있는가 운영 계속 그런가 면접 포인트 "Alert를 믿으려면 데이터부터 믿을 수 있어야 한다 — 수집, 해석, 저장, 운영의 네 축" 12. 다음 편 예고 A영역 「SIEM 구조와 로그 수집」 50편이 이 글로 마무리됩니다. 다음 B영역 「탐지 룰 엔지니어링」 에서는 Wazuh 룰 구조와 레벨 설계, 빈도·상관 룰, Sigma 룰 변환, MITRE ATT&CK 매핑, 오탐 관리와 룰 회귀 시험을 다룹니다. 전체 목록은 아래 시리즈 링크에서 확인할 수 있습니다. 이전 편: 049. SIEM·로그 수집 — 실전 시나리오 — 신규 서버 SIEM 편입부터 첫 Alert까지 📚 시리즈 전체 보기: SIEM · 보안관제
SIEM · 보안관제 › A. SIEM 구조와 로그 수집 · 47/50편 학습 단계: 검색·대시보드·운영 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Wazuh 4.x 올인원 / Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 046. SIEM·로그 수집 — SIEM 성능 튜닝 — 노이즈 로그 필터링 1. 개념 지금까지의 점검 항목을 주기별 체크리스트 로 정리합니다. 체크리스트의 목적은 사람이 바뀌어도 같은 기준으로 SIEM 상태를 확인하게 만드는 것입니다. SIEM 운영 체크리스트 [교대 시작 / 매일] □ 매니저 데몬 running · events_dropped 0 (005·037) □ Disconnected 에이전트 0 · 끊긴 사유 확인 (007) □ 소스 침묵 0 (호스트×소스 수신량) (020) □ 클러스터 green · 오늘 인덱스 생성 · 저장 지연 (031·035) [매주] □ 디코딩 실패율·필드 누락률 (030) □ 상위 노이즈 룰 · 튜닝 예외 만료 (046) □ 용량 증가·고갈 예상일 (034) □ 신규 자산 편입 여부 · 수집 인벤토리 갱신 (003) [매월] □ 인증서 만료(30일 이내) (038) □ 보존 정책·가장 오래된 인덱스 (033) □ 위협 인텔·자산 CDB 갱신 (029) □ 회귀 시험 샘플 갱신 (025) 핵심: 점검 결과는 "확인함"이 아니라 수치로 남긴다 체크리스트 결과를 수치와 함께 기록하면 월별 추세를 볼 수 있고, 운영 개선의 근거가 됩니다. "이상 없음"만 적힌 기록은 나중에 아무것도 증명하지 못합니다. 2. 왜 중요한가 사람이 바뀌어도 같은 품질로 SIEM을 운영할 수 있습니다. 조용한 장애(침묵·드롭·만료)를 정기적으로 걸러냅니다. 점검 기록이 운영 성과와 개선 근거가 됩니다. 3. 핵심 명령어 / 설정 주기 핵심 근거 편 매일 데몬·에이전트·침묵·저장 005·007·020·031 매주 품질·노이즈·용량·자산 030·046·034·003 매월 인증서·보존·인텔·회귀 038·033·029·025 변경 시 문법 검사·회귀 시험 005·025 4. 실습 (실습 예시) # 일일 점검 결과를 수치로 남기기 (분석 방법) { echo "date=$(date +%F) shift=day" echo "daemons=$(sudo /var/ossec/bin/wazuh-control status | grep -c 'is running')" echo "disconnected=$(sudo /var/ossec/bin/agent_control -l | grep -c Disconnected)" echo "dropped=$(sudo grep -oP "events_dropped='\K[0-9]+" /var/ossec/var/run/wazuh-analysisd.state)" echo "cluster=$(curl -sk -u 'admin:<비밀번호>' https://localhost:9200/_cluster/health | grep -oP '"status":"\K[a-z]+')" } | tee -a /root/siem-ops/daily_check.log 5. 정상 상태 date=2026-10-09 shift=day daemons=6 disconnected=0 dropped=0 cluster=green 모든 항목이 수치로 기록되고 기준값을 만족하면 그날의 SIEM 상태는 신뢰할 수 있습니다. 6. 이상 상태 daily_check.log 최근 5일: 기록 없음 그 사이 인증서 만료로 filebeat 전송 중단 3일 점검 중단 → 조용한 장애 장기화 만료 예정 항목(월간 점검)이 누락되어 사고로 이어짐 체크리스트 수행 여부 자체를 감시해야 함 7. 로그 분석 (분석 방법) 체크리스트 운영 흐름입니다(가상의 예시). [수행] 주기별 점검 → 수치 기록 ↓ [판단] 기준 위반 항목 → 티켓 생성 ↓ [추세] 주간·월간 수치 비교 ↓ [개선] 반복 위반 항목 → 자동 점검·룰화 ↓ [수행 감시] 기록 누락일 확인 상태 조치 기준 위반 티켓·복구 반복 위반 자동화·근본 개선 기록 누락 수행 확인 반복해서 수동으로 확인하는 항목은 점검 스크립트와 룰(이번 영역의 check=* 예시들)로 자동화해, 사람은 판단에 집중하도록 바꿔 갑니다. 8. SOC 관제 포인트 일일 점검 결과를 수치 로그로 남깁니다. 기준 위반은 반드시 티켓으로 추적합니다. 체크리스트 기록 누락도 점검 대상으로 둡니다. 9. 탐지 규칙 <!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 --> <group name="local,siem_a,"> <rule id="110460" level="10"> <decoded_as>json</decoded_as> <field name="check">^daily_ops$</field> <field name="last_run_hours" type="pcre2">^(2[6-9]|[3-9][0-9]|[1-9][0-9]{2,})$</field> <description>SIEM 일일 운영 점검 26시간 이상 미수행</description> </rule> </group> 일일 점검이 실행되지 않은 상태 자체를 경보하는 예시입니다. 점검이 멈추면 조용한 장애가 길어지므로, 점검 수행 여부도 감시 대상에 넣습니다. 10. 대응 방법 초기 확인 — 주기별 체크리스트 수행 결과를 확인합니다. 범위 확인 — 기준 위반 항목과 영향 범위를 확인합니다. 증거 확보 — 점검 수치 기록을 보존합니다. 차단/조치 — 위반 항목을 티켓으로 처리하고 복구합니다. 재발 방지 — 반복 항목 자동화와 수행 감시를 운영합니다. 11. 핵심 정리 주기 대표 항목 매일 데몬·에이전트·침묵·저장 매주 품질·노이즈·용량 매월 인증서·보존·인텔 원칙 수치로 기록 면접 포인트 "점검은 확인함이 아니라 숫자로 남긴다 — 점검이 멈춘 것도 감시 대상이다" 12. 다음 편 예고 다음 편 048. SIEM·로그 수집 — 수집·정규화 장애 대응 절차 에서는 수집 중단·파싱 실패·저장 차단 같은 SIEM 장애가 발생했을 때 영향 평가·임시 조치·복구·누락 데이터 보완·보고까지의 대응 절차를 정리합니다. 이전 편: 046. SIEM·로그 수집 — SIEM 성능 튜닝 — 노이즈 로그 필터링 📚 시리즈 전체 보기: SIEM · 보안관제