보안 팀이 사후 분석 보고서를 작성하고 있다. 공격자가 처음 침투한 것은 6개월 전이었다. 초기 침투는 스피어 피싱 이메일을 통한 인증 정보 탈취였고, 그 계정으로 VPN에 처음 접속한 시각은 새벽 2시 14분이었다. 이후 공격자는 3개월 동안 내부를 조용히 탐색했다. LDAP 쿼리로 서비스 계정 목록을 수집했고, 관리자 권한이 있는 계정들을 차례로 장악했다. 5개월 차부터는 소량의 데이터를 외부로 반출하기 시작했다.
분석가가 로그를 열어보자 모든 흔적이 있었다. 비정상적인 시간대의 VPN 접속, 평소와 다른 서브넷 스캔, LDAP 열거 패턴, 외부 IP로의 비정기 HTTPS 연결. 개별 이벤트로 보면 하나하나는 이상해 보이지 않았다. 조합해보면 누군가 시스템 안에서 움직이고 있었다는 것이 분명했다. 단지 아무도 그 조합을 실시간으로 하지 않았을 뿐이다.
SIEM(Security Information and Event Management)이 해결하려는 문제가 정확히 이것이다. 개별 이벤트를 기록하는 것이 아니라, 시간과 공간에 분산된 이벤트들 사이의 패턴에서 위협을 찾는 것.
SIEM이 등장한 배경: 로그가 있어도 보지 못하는 이유
보안 이벤트는 항상 기록됐다. 방화벽은 허용/차단 로그를 남겼고, 인증 시스템은 로그인 성공과 실패를 기록했으며, 서버는 프로세스 실행 내역을 남겼다. 문제는 기록이 없는 것이 아니었다. 기록이 너무 많고, 너무 흩어져 있고, 각기 다른 언어로 쓰여 있다는 것이었다.
방화벽 로그와 IAM 로그와 애플리케이션 로그는 각각 독립된 시스템에 별도 형식으로 저장된다. 중간 규모의 조직도 하루 수억 건의 이벤트를 생성한다. 분석가가 수동으로 이 로그들을 연결해 패턴을 찾는 것은 구조적으로 불가능하다.
여기서 핵심 질문이 생긴다. 흩어진 이벤트들을 어떻게 하나의 타임라인으로 만들 것인가? 그 타임라인에서 위협 패턴을 어떻게 자동으로 탐지할 것인가?
SIEM의 아키텍처는 이 두 질문에 대한 공학적 답변이다.
파이프라인 전체 구조
SIEM은 단일 제품이 아니라 네 개의 처리 단계가 연결된 파이프라인이다. 수집(Collection) → 파싱과 정규화(Parsing & Normalization) → 상관분석(Correlation) → 경보(Alerting). 각 단계는 서로 다른 설계 문제를 해결한다.
이 구조에서 수집 레이어의 설계가 탐지 범위를 결정한다. 수집하지 않은 소스에서 일어나는 일은 볼 수 없다. SIEM은 전지전능한 시스템이 아니라, 연결된 소스의 시야각을 가지는 시스템이다.
수집 레이어: 어떻게 받느냐가 품질을 결정한다
이벤트를 수집하는 방식은 크게 세 가지다. 각각 다른 상황에 맞는 트레이드오프를 가진다.
- 에이전트 기반 수집은 대상 호스트에 경량 소프트웨어를 설치하고, 로컬에서 로그를 읽어 SIEM으로 전송한다. 가장 높은 가시성을 제공한다. 파일 시스템 이벤트, 프로세스 실행, 네트워크 연결 같은 세밀한 이벤트를 수집할 수 있다. 단점은 설치와 관리 부담이다. 에이전트 버전이 달라지거나 호스트에서 에이전트가 중단되면 수집에 공백이 생긴다. 또한 Device Posture 측정과 마찬가지로, 에이전트가 없는 기기는 보이지 않는다.
- Syslog 기반 수집은 RFC 5424 표준 형식의 로그 메시지를 중앙 수신기에 전달한다. 방화벽, 라우터, 스위치 같은 네트워크 장비는 에이전트 설치가 불가능하기 때문에 Syslog가 사실상 유일한 선택이다. UDP 514 기반 전통 Syslog는 패킷 손실 위험이 있어, 신뢰성이 필요한 환경에서는 TCP 기반 Syslog(RFC 6587)로, 암호화가 추가로 필요하면 Syslog over TLS(RFC 5425, TCP 6514)로 전환한다.
- API 기반 수집은 클라우드 서비스에서 지배적인 방식이다. AWS CloudTrail, Azure Activity Log, Okta System Log는 모두 API 엔드포인트를 제공한다. 폴링(pull) 방식은 주기적으로 새 이벤트를 가져오고, 웹훅(push) 방식은 이벤트 발생 시 즉시 전달한다. 폴링은 지연이 생길 수 있고, 웹훅은 수신 실패 시 재전송 메커니즘이 필요하다.
대규모 환경에서는 수집 레이어 자체가 단일 장애점이 되지 않도록 설계해야 한다. Kafka나 Kinesis 같은 메시지 큐를 중간에 두면, SIEM 처리 레이어가 재시작되더라도 이벤트 손실 없이 재처리할 수 있다.
파싱과 정규화: 다른 언어를 말하는 로그들
수집된 로그는 원시 문자열이다. Cisco ASA 방화벽 로그와 AWS CloudTrail JSON과 Linux auth.log는 구조도 다르고 필드명도 다르다. 이것을 하나의 공통 구조로 변환하는 것이 파싱과 정규화다.
파싱 단계에서는 비정형 텍스트를 구조화된 필드로 분해한다. Grok 패턴으로 정규표현식 기반 파싱을 하거나, JSON/XML 구조를 그대로 파싱하거나, Key-Value 쌍으로 된 로그를 파싱한다. 이 단계에서 발생하는 파싱 실패율이 데이터 품질의 첫 번째 지표다. 새로운 소스를 추가하거나 벤더가 로그 포맷을 변경하면 파싱 규칙을 업데이트해야 한다.
파싱 이후 보강(enrichment) 단계가 있다. IP 주소를 GeoIP 데이터베이스로 위치 정보와 ASN(자율 시스템 번호)으로 변환하고, 호스트명을 자산 관리 DB와 조회해 해당 기기의 중요도와 소유자를 붙인다. IP가 알려진 위협 인텔리전스 목록에 있는지 확인한다. 이 정보들이 나중에 상관 규칙이 작동하는 컨텍스트가 된다.
정규화는 이 파싱·보강된 이벤트를 공통 스키마로 변환한다.
공통 스키마: ECS와 OCSF
현재 업계에서 경쟁하는 두 개의 공통 스키마가 있다.
ECS(Elastic Common Schema)는 Elastic이 주도하는 오픈 스키마다. user.name, source.ip, event.action, process.pid 같은 표준 필드 계층을 정의한다. Okta의 actor.alternateId와 CloudTrail의 userIdentity.userName은 모두 user.name 필드로 매핑된다. 이 변환이 일어나야만 두 시스템에 걸친 동일 사용자의 행동을 단일 쿼리로 조회할 수 있다.
OCSF(Open Cybersecurity Schema Framework)는 AWS, Splunk, CrowdStrike 등이 주도하는 더 최근의 표준으로, 이벤트 카테고리별 스키마를 더 세밀하게 정의한다. 네트워크 활동(4001), 프로세스 실행(1007), 인증(3002) 같은 이벤트 클래스 ID로 분류하며, 클래스 번호가 곧 이벤트 유형을 식별하는 기준이 된다. ECS가 필드명 중심의 플랫 스키마라면, OCSF는 이벤트 유형별로 독립적인 스키마를 정의하는 계층 구조를 취한다.
정규화에는 항상 손실이 있다. 표준 스키마에 없는 벤더 특화 필드는 버리거나 커스텀 네임스페이스에 보존해야 한다. 실무에서는 핵심 상관 분석에 필요한 필드는 표준 필드로 매핑하고, 포렌식 조사에 필요한 원본 로그는 별도로 보존하는 이중 전략을 사용한다. 원본 로그 없이 정규화된 데이터만 보존하면, 나중에 조사 시 "이 이벤트의 정확한 원문이 무엇이었는가"를 확인할 수 없는 상황이 생긴다.
상관분석 엔진: 패턴을 찾는 방법
정규화된 이벤트 스트림에서 위협을 찾는 것이 상관분석 엔진의 역할이다. 기술적으로는 CEP(Complex Event Processing) 엔진이라고 부른다. 연속된 이벤트 스트림에서 미리 정의된 패턴과 일치하는 이벤트 조합을 실시간으로 탐지한다.
상관 규칙의 유형은 탐지하려는 위협의 성격에 따라 달라진다.
임계값 규칙 (Threshold Rules)
가장 단순한 형태다. "같은 소스 IP에서 5분 안에 로그인 실패 10회 이상이면 경보를 발생시킨다." 구현이 쉽고 설명하기 쉽다. 브루트포스 공격 같은 노이즈가 많은 공격을 탐지하는 데 적합하다.
이 규칙의 구조적 약점은 두 방향에서 나온다. 하나는 false positive다. 비밀번호를 잊어버린 직원이나 잘못 설정된 자동화 스크립트도 동일한 규칙에 걸린다. 다른 하나는 회피 가능성이다. 공격자가 속도를 늦추면 임계값 아래를 유지하면서 공격을 이어갈 수 있다. 이른바 "느린 브루트포스(low-and-slow)" 공격이 임계값 규칙을 우회하는 이유다.
시퀀스 규칙 (Sequence Rules)
여러 이벤트가 특정 순서로 발생했을 때만 경보를 발생시킨다. "로그인 실패 5회 → 성공 → 이례적인 데이터 접근" 패턴이 60분 안에 동일 사용자에게 발생하면 위협으로 판단한다.
시퀀스 규칙은 공격의 내러티브를 반영한다. 개별 이벤트가 아니라 일련의 행동이 의미를 가진다는 것을 전제한다. MITRE ATT&CK 프레임워크의 전술 체인과 직접 대응된다 — 내부 탐색(Discovery) → 권한 탈취(Privilege Escalation) → 내부 이동(Lateral Movement) → 유출(Exfiltration). 여기서 Discovery는 초기 침투 이후 내부 자산을 열거하는 전술이다. 침투 전 외부 정보 수집 단계인 Reconnaissance와는 다르다. SIEM이 탐지할 수 있는 범위는 공격자가 이미 내부에 들어온 이후, 즉 Discovery 전술부터다.
베이스라인 이탈 규칙 (Baseline Deviation Rules)
"이 사용자의 평소 로그인 시간대는 오전 9시~오후 7시인데, 새벽 2시에 로그인했다." 이 규칙은 절대적 기준이 아니라 개인별 기준선과의 편차를 측정한다.
임계값 규칙이 정적 기준을 사용하는 것과 달리, 베이스라인 이탈 규칙은 사용자별 정상 행동 모델이 필요하다. 이 모델을 구축하고 유지하는 것이 UEBA(User and Entity Behavior Analytics)다. UEBA가 산출한 이탈 점수를 SIEM 상관 규칙의 입력으로 사용하며 이 지점에서 연결된다.
IOC 매칭 규칙
이벤트에 등장하는 IP 주소, 도메인, 파일 해시가 알려진 위협 인텔리전스 목록과 일치하는지 확인한다. "이 이벤트의 목적지 IP가 알려진 C2 서버 목록에 있다." 이것은 위협 인텔리전스 피드와 SIEM의 연동 방식이다.
IOC 매칭은 이미 알려진 위협에 대해서만 동작한다. 새로운 C2 인프라나 0-day 공격에는 반응하지 않는다. 이 한계가 IOC 외에 TTP(Tactics, Techniques, and Procedures) 기반 탐지가 필요한 이유다.
Alert Fatigue: 경보가 너무 많으면 경보가 없는 것과 같다
SIEM 운영에서 가장 흔히 마주치는 실패 패턴은 도구의 결함이 아니라 경보의 과잉이다. 잘못 튜닝된 SIEM은 하루 수백에서 수천 건의 경보를 발생시킨다. 분석가들은 경보 큐가 소화되지 않는 상황에서 중요한 경보를 놓치기 시작하고, 결국 경보 자체를 신뢰하지 않게 된다.
이 문제는 MTTD(Mean Time to Detect)와 MTTR(Mean Time to Respond) 지표로 측정된다. Alert Fatigue 환경에서는 MTTD와 MTTR이 모두 악화된다. 자동화 규칙이 경보를 생성했더라도, 분석가가 그것을 노이즈 속에서 인지하고 조사를 시작하기까지 걸리는 시간이 지연되기 때문이다. IBM Security의 「Cost of a Data Breach Report 2023」에 따르면, 침해를 식별하기까지 평균 204일, 봉쇄까지 추가로 73일이 소요됐다. 이 수치의 이면에는 경보가 기술적으로 발생했어도 실제 위협을 제때 인식하지 못하는 구조적 실패가 있다.
Alert Fatigue를 구조적으로 다루는 방법은 세 가지 방향에서 접근한다.
- 규칙 튜닝(Rule Tuning): 경보 발생 후 분석가의 False Positive 표시를 누적해 규칙을 조정한다. 특정 IP 범위에서 오는 스캔은 내부 보안 도구의 정기 점검임을 확인하면 해당 소스를 억제(suppression) 목록에 추가한다. 단, 억제는 "이 패턴은 항상 무해하다"고 확인된 것에만 적용해야 한다. 과도한 억제는 공격자가 정상 행동으로 위장하는 채널을 만든다.
- 우선순위 기반 트리아지(Priority-based Triage): 모든 경보를 동등하게 처리하는 것이 문제의 출발점이다. 자산 중요도(critical asset), 사용자 리스크 프로필(Trust Score), 공격 전술 단계를 조합해 경보 우선순위를 산출한다. 내부 결제 시스템의 관리자 계정에 대한 경보와 개발 환경의 테스트 계정에 대한 경보는 같은 심각도 레이블이 붙어있어도 처리 우선순위가 달라야 한다.
- SOAR 연동(SOAR Integration): SOAR(Security Orchestration, Automation and Response)는 SIEM 경보를 수신해 반복적인 초기 트리아지를 자동화한다. 경보가 발생하면 SOAR 플레이북이 실행된다. 관련 사용자의 최근 로그인 이력을 자동 수집하고, Threat Intelligence 피드로 IP 평판을 조회하며, Slack이나 이메일로 담당 분석가에게 컨텍스트가 포함된 알림을 보낸다. 낮은 심각도의 경보는 자동으로 티켓을 생성하고 큐에 넣는다. 높은 심각도는 즉시 에스컬레이션한다.
현대 SIEM 아키텍처: 스토리지와 처리의 분리
전통적인 SIEM은 스토리지와 처리 엔진이 결합된 단일 어플라이언스였다. 데이터가 늘어나면 어플라이언스를 교체하거나 추가해야 했다. 스케일 단위가 크고 비용이 예측하기 어려웠다.
이 구조의 근본적인 비효율은 모든 데이터를 동일한 비용의 스토리지에 저장한다는 데 있다. 6개월 전 방화벽 로그와 30분 전 인증 이벤트는 서로 다른 접근 패턴을 가진다. 전자는 월 1~2회 포렌식 조사 때 필요하고, 후자는 실시간 상관분석의 입력이 된다. 같은 스토리지 계층에 두는 것은 낭비다.
현대 SIEM 아키텍처는 이 두 필요를 분리해 처리한다.
두 가지 데이터 흐름이 동시에 진행된다는 점이 핵심이다. 처리 파이프라인은 정규화된 이벤트를 Hot으로 색인하면서, 원본 로그를 변경 없이 동시에 Cold로 아카이브한다. 정규화 과정에서 정보가 손실될 수 있기 때문에 원본 보존은 포렌식 조사의 선행 조건이다.
Hot 계층은 최근 7~30일의 정규화된 이벤트를 역색인(inverted index) 형태로 저장한다. 상관분석 엔진이 실시간으로 소비하는 데이터다. SSD 기반 스토리지를 사용하고 단위 비용이 높다. Hot 보존 기간이 끝난 데이터는 압축해 Warm으로 이전한다.
Warm 계층은 Hot에서 에이징된 데이터를 압축 인덱스 형태로 유지한다. 실시간 상관분석에는 사용하지 않지만, 분석가가 수주~수개월 전 구간을 수동 조사할 때 접근한다. Warm 보존 기간이 끝나면 Cold로 이전된다.
Cold 계층은 두 종류의 데이터를 보관한다. 처음부터 직접 아카이브된 원본 로그와, Hot/Warm에서 에이징된 압축 인덱스다. Parquet 같은 컬럼형 포맷으로 저장 비용을 최소화하면서, Apache Spark 같은 분산 쿼리 엔진으로 필요할 때 전체 기간을 쿼리할 수 있다.
이 계층 분리는 위협 헌팅(Threat Hunting)을 가능하게 만드는 핵심 설계다. 위협 헌팅은 경보를 기다리지 않고 분석가가 능동적으로 가설을 세우고 데이터에서 증거를 찾는 활동이다. "지난 1년간 새벽 2~4시 사이에 외부 IP와 443 포트로 연결한 내부 호스트 목록"을 SQL로 조회하고, 이 목록 중 평소에 외부 통신이 없던 서버가 있는지 확인한다. Cold 계층이 없으면 이 쿼리는 Hot 보존 기간(30일)으로 제한된다.
SIEM의 시야각과 한계
SIEM이 탐지할 수 있는 것은 수집된 소스 범위 안에서 발생하는 이벤트의 패턴이다. 이 문장에는 두 가지 내재된 한계가 있다.
- 첫 번째는 수집 공백(Coverage Gap)이다. 로그를 전송하지 않는 레거시 시스템, 에이전트 설치가 어려운 OT/ICS 환경, 에이전트가 종료된 기기, 암호화된 트래픽 내부에서 일어나는 일은 보이지 않는다. 공격자가 에이전트를 먼저 비활성화하는 이유가 여기 있다.
- 두 번째는 상관 규칙의 한계(Rule Coverage Gap)이다. SIEM은 미리 정의된 패턴만 탐지한다. 규칙에 없는 새로운 공격 기법은 탐지되지 않는다. 이것이 SIEM이 단독으로 동작하지 않고 UEBA(이상 행동 탐지), 위협 인텔리전스(알려진 위협 피드)와 함께 사용되는 이유다.
임계값 규칙과 IOC 매칭은 알려진 위협에 대해 높은 정확도를 보이지만, 새로운 TTP에는 반응하지 않는다. UEBA 기반 탐지는 알려지지 않은 위협에도 작동하지만, 기준선이 안정화되기까지 시간이 필요하고 false positive 관리가 더 복잡하다. 두 접근을 병행하는 것이 커버리지를 높이는 방법이다.
Zero Trust에서 SIEM의 위치: Continuous Verification 루프
앞의 포스트에서 PDP가 접근 결정을 내린다고 설명했다. 그 다음 Gateway가 그 결정을 트래픽 수준에서 집행한다고 다뤘다. 그런데 접근이 허용된 이후에는 무슨 일이 일어나는가?
Zero Trust의 세 번째 원칙 — Assume Breach — 은 "이미 침해됐다고 가정하라"는 것이다. 접근이 허용된 사용자도 내부에서 이상한 행동을 할 수 있다. 인증 시점에는 정상이었던 세션이 이후에 침해될 수 있다.
SIEM은 이 원칙을 구현하는 Continuous Verification 레이어의 핵심 컴포넌트다.
접근 허용 후 모든 활동이 SIEM으로 전송되고, SIEM은 UEBA와 연계해 이상 행동을 감지한다. 임계값을 초과하면 PDP에 컨텍스트를 업데이트하고, PDP는 세션 재평가를 트리거한다.앞 선 포스트에서 다룬 Step-up 인증이 여기서 실행된다.
이 루프가 "네트워크에 한 번 들어오면 신뢰"하는 Castle-and-Moat 모델과 Zero Trust가 근본적으로 다른 지점이다. 접근 허용은 일회성 결정이 아니라 지속적으로 재평가되는 조건부 상태다.