기업의 보안 시스템은 각각 자신의 위치에서 로그를 만든다. 방화벽은 네트워크 연결 기록을 남기고, IPS와 WAF는 공격으로 판단한 트래픽을 기록한다. 서버와 클라우드에서는 로그인, 권한 변경, 프로세스 실행 같은 이벤트가 발생하고 EDR은 단말에서 나타나는 이상 행위를 탐지한다.
문제는 공격 흔적이 하나의 장비에만 남지 않는다는 점이다. 한 사용자의 로그인 실패만 보면 비밀번호 입력 오류일 수 있다. 그러나 여러 차례 로그인에 실패한 뒤 성공하고, 직후 중요 시스템에 접속하거나 권한 변경까지 이어진다면 의미가 달라진다.
SIEM(Security Information and Event Management)은 이렇게 여러 시스템에 흩어진 보안 데이터를 중앙에서 수집하고 분석하여 보안 담당자가 위협을 탐지하고 조사할 수 있는 정보로 만드는 플랫폼이다.
NIST도 SIEM을 여러 종류의 로그를 중앙에서 관리하는 기능, 또는 정보시스템 구성요소의 보안 데이터를 모아 하나의 인터페이스에서 활용 가능한 정보로 제공하는 도구로 설명한다. 하지만 SIEM을 단순히 ‘보안 로그를 모으는 저장소’로 이해하면 핵심을 놓치게 된다. SIEM의 실질적인 가치는 로그의 양보다 서로 다른 데이터를 연결하고, 의미 있는 보안 이벤트를 찾아내며, 분석가가 조사해야 할 대상을 선별하는 능력에 있다.
1. SIEM이 필요한 이유
기업 환경에서는 하나의 보안 사고와 관련된 흔적이 여러 시스템에 나누어 기록될 수 있다. 예를 들어 공격자가 웹서비스를 대상으로 공격을 수행했다고 가정해보자. 방화벽에는 외부 IP의 연결 기록이 남을 수 있고, IPS나 WAF에서는 공격 패턴이 탐지될 수 있다. 웹서버에는 비정상적인 요청이 기록되고, 공격이 실제 서버까지 이어졌다면 운영체제나 EDR에서도 추가 행위가 확인될 수 있다.
각 장비의 로그를 따로 보면 하나의 이벤트일 뿐이다. 그러나 시간, IP 주소, 사용자, 대상 시스템 등의 정보를 기준으로 연결하면 하나의 공격 흐름으로 볼 수 있다. 보안관제 환경에서 SIEM이 필요한 이유가 여기에 있다.
분석가가 방화벽, IPS, WAF, 서버, EDR, 클라우드 콘솔을 각각 열어 모든 로그를 직접 비교하는 것은 현실적으로 어렵다. 시스템과 로그의 양이 늘어날수록 더 그렇다. SIEM은 이런 데이터를 하나의 분석 환경으로 모으고 검색·탐지·상관분석을 수행할 수 있는 기반을 제공한다.
즉 SIEM의 첫 번째 역할은 단순 중앙 저장이 아니라 분산되어 있는 보안 가시성을 한곳으로 모으는 것이다.
2. SIEM의 기본 구조
제품마다 용어와 기술 구조는 다르지만 SIEM은 크게 다음 영역으로 이해할 수 있다.
데이터 소스 → 수집·변환 → 저장·검색 → 분석·탐지 → 경보·인시던트 → 조사·대응
데이터 소스
SIEM의 시작점은 데이터를 만들어내는 시스템이다. 대표적으로 네트워크, 네트워크 보안장비, 서버, 인증·계정 시스템, 엔드포인트, 클라우드, 애플리케이션, 데이터베이스 등이 있다.
| 영역 | 대표적인 데이터 소스 |
|---|---|
| 네트워크 | Firewall, Router, VPN |
| 네트워크 보안 | IDS, IPS, WAF, Anti-DDoS |
| 서버 | Linux, Windows, Web, WAS |
| 인증·계정 | AD, IAM, SSO, MFA |
| 엔드포인트 | EDR, 안티바이러스 |
| 클라우드 | 감사 로그, API 활동, 인증 이벤트 |
| 애플리케이션 | 업무 시스템, 인증·거래 로그 |
| 데이터베이스 | 접속, 조회, 권한 변경, 감사 로그 |
SIEM이 모든 활동을 직접 관찰하는 것은 아니다. 대부분의 분석은 각 시스템이 생성하거나 SIEM으로 전달한 데이터를 바탕으로 이루어진다. 따라서 필요한 로그가 애초에 생성되지 않거나 수집되지 않는다면 SIEM에서도 해당 행위를 탐지하기 어렵다.
수집과 데이터 변환
각 시스템의 로그는 Syslog, Agent, API, Connector 등의 다양한 방법으로 SIEM에 전달된다. 문제는 제품마다 로그 형식이 다르다는 것이다. 같은 출발지 IP 주소라도 제품마다 필드명과 표현 방법이 다를 수 있고, 사용자명, 이벤트 종류, 결과 코드 역시 서로 다를 수 있다.
따라서 SIEM에서는 로그를 분석할 수 있도록 필요한 값을 추출하고 서로 다른 데이터를 공통 기준으로 사용할 수 있게 변환한다. Microsoft Sentinel도 현재 데이터 커넥터를 통한 수집과 함께 ingestion-time 및 query-time normalization을 지원하고 있다. 다만 파싱과 정규화의 구체적인 원리는 54번 글에서 별도로 다루는 편이 적절하다.
저장과 검색
수집된 데이터는 탐지와 조사에 사용할 수 있도록 저장된다. 보안 담당자는 특정 IP, 사용자 계정, 서버, 시간대 또는 이벤트 종류 등을 기준으로 과거 로그를 검색할 수 있다.
이 기능은 사고 대응에서 특히 중요하다. 공격이 발견된 시점이 실제 공격 시작 시점과 같다는 보장은 없기 때문이다. 며칠 또는 더 오래 전에 시작된 활동을 추적해야 하는 경우 과거 로그가 필요하다. NIST의 로그관리 지침도 로그관리를 단순한 저장이 아니라 생성, 전송, 저장, 접근, 폐기까지 포함하는 전체 과정으로 설명한다.
분석과 탐지
SIEM에 데이터가 모였다고 해서 모든 로그가 보안 이벤트가 되는 것은 아니다. 분석 규칙이나 탐지 로직을 이용해 수많은 이벤트 가운데 조사 가치가 있는 활동을 선별한다. 특정 이벤트 하나를 탐지할 수도 있고 서로 다른 시스템의 여러 이벤트를 연결할 수도 있다.
이 단계가 SIEM을 단순 로그 저장소와 구분하는 핵심 기능이다.
경보와 인시던트
탐지 조건을 충족한 이벤트는 보안 분석가가 확인할 수 있도록 Alert로 만들어질 수 있다. 최근 SIEM에서는 관련된 여러 Alert를 하나의 Incident로 묶어 조사할 수 있도록 하는 기능도 일반적이다.
Microsoft Sentinel의 현재 SIEM 기능도 분석을 통해 관련 Alert를 Incident로 그룹화하고, 조사·위협 헌팅·대응으로 연결하는 구조를 제공한다. 즉 SIEM은 원본 로그 전체를 사람에게 보여주는 시스템이 아니라 분석가가 우선 확인해야 할 사건을 좁혀주는 역할을 한다.
3. SIEM에서 상관분석이 중요한 이유
SIEM을 이해할 때 중요한 개념이 상관분석(Correlation)이다. 공격이 항상 하나의 이벤트만으로 명확하게 드러나는 것은 아니다.
사용자 로그인 실패가 여러 차례 발생하고, 이후 동일 계정으로 로그인에 성공한 뒤 중요 시스템에 접근했다고 가정해보자. 각 이벤트를 독립적으로 보면 정상적인 상황일 수도 있다.
하지만 동일한 계정과 IP, 짧은 시간 범위, 평소와 다른 접근 대상 등의 조건이 추가되면 계정 탈취 가능성을 조사할 가치가 생긴다.
SIEM은 Source IP, Destination IP, 사용자 계정, 호스트, 이벤트 종류, 발생 횟수, 시간 범위, 이벤트 순서, 자산 중요도, 위협 인텔리전스 등의 정보를 이용해 이런 관계를 탐지할 수 있다.
상관분석의 목적은 모든 공격을 자동 확정하는 것이 아니다. 수많은 원본 이벤트 가운데 사람이 우선 조사해야 할 조합을 찾아내는 것에 가깝다. 따라서 탐지 규칙은 ‘사고 판정 공식’보다 ‘조사 대상 선별 기준’으로 이해하는 것이 현실적이다.
4. 보안관제에서 SIEM이 수행하는 역할
여러 시스템의 가시성을 통합한다
보안 분석가가 수많은 장비 콘솔을 각각 확인하면 분석 속도가 느려질 수밖에 없다. SIEM은 네트워크, 서버, 계정, 엔드포인트, 클라우드 등의 데이터를 한곳에서 검색하고 분석할 수 있게 한다. 하지만 단순히 한 화면에 모아 보여주는 것만으로 SIEM의 가치가 만들어지는 것은 아니다. 서로 다른 데이터를 같은 사건의 맥락에서 볼 수 있어야 한다.
탐지해야 할 이벤트를 선별한다
기업 시스템에서는 보안과 직접 관련되지 않은 로그까지 대량으로 발생한다. 사람이 전체 로그를 읽는 방식으로 관제하는 것은 현실적으로 어렵다. SIEM은 탐지 규칙, 행동분석, 위협 인텔리전스 등의 정보를 이용하여 조사할 가치가 높은 이벤트를 선별한다.
결국 분석가는 전체 로그가 아니라 SIEM이 만들어낸 Alert나 Incident를 중심으로 우선순위를 정할 수 있다.
사고 조사를 지원한다
SIEM의 역할은 실시간 탐지에서 끝나지 않는다. 보안 사고가 의심되면 분석가는 과거 이벤트를 검색하면서 공격 이전과 이후의 활동을 추적한다. 최초 의심 활동의 시점, 동일 IP의 다른 접근, 사용자 계정의 추가 이상행위, 공격 이후 프로세스 실행이나 권한 변경 등을 함께 확인할 수 있다.
따라서 SIEM은 탐지 시스템이면서 동시에 사고조사를 위한 데이터 분석 기반이 된다.
대응 자동화와 연결된다
현대 SIEM은 SOAR(Security Orchestration, Automation and Response) 기능과 결합되는 경우가 많다. Microsoft Sentinel 역시 Automation Rule과 Playbook을 통해 반복적인 Incident 처리나 대응 업무를 자동화할 수 있다.
예를 들어 확인된 위협에 대해 담당자에게 알림을 보내거나 티켓을 생성하고, 추가 정보를 조회하거나 일정한 대응 절차를 자동 실행할 수 있다. 하지만 자동화 범위가 넓을수록 잘못된 탐지가 실제 업무에 영향을 줄 가능성도 함께 커진다.
따라서 자동화는 ‘가능한 모든 대응을 자동화한다’가 아니라 반복적이고 판단 기준이 명확한 작업부터 적용하는 방식이 현실적이다.
5. SIEM과 보안장비의 역할 차이
SIEM이 있다고 해서 방화벽, IPS, WAF, EDR 같은 보안 솔루션을 대신할 수 있는 것은 아니다. 각 기술의 역할은 다르다.
| 기술 | 주요 역할 |
|---|---|
| Firewall | 네트워크 통신 허용·차단 |
| IDS·IPS | 공격 트래픽 탐지·차단 |
| WAF | 웹 공격 탐지·차단 |
| EDR | 엔드포인트 행위 탐지·대응 |
| SIEM | 여러 시스템의 데이터를 통합·분석하고 연관성을 탐지 |
예를 들어 IPS는 자신이 관찰하는 네트워크 트래픽에서 공격 패턴을 탐지할 수 있다. SIEM은 IPS 이벤트를 서버 로그나 계정 로그, WAF 이벤트와 함께 분석하여 해당 공격이 어떤 시스템과 연결되어 있는지 확인하는 데 사용할 수 있다.
즉 각 보안장비가 자신의 영역에서 탐지 센서 역할을 한다면 SIEM은 여러 센서의 데이터를 모아 전체 상황을 분석하는 역할에 가깝다.
다만 최근 SIEM은 UEBA, 위협 인텔리전스, 클라우드 분석, SOAR, AI 기반 조사 기능까지 통합하면서 과거의 단순 로그관리 플랫폼보다 범위가 넓어지고 있다. Microsoft Sentinel의 최신 문서도 SIEM을 데이터 수집뿐 아니라 탐지, 조사, 헌팅, 대응과 자동화를 지원하는 플랫폼으로 설명한다.
6. SIEM을 구축해도 보안관제가 자동으로 완성되지 않는 이유
SIEM 프로젝트에서 가장 주의해야 할 부분은 ‘제품을 구축하면 탐지가 완성된다’는 생각이다. 실제로 SIEM의 품질은 제품보다 데이터와 운영 과정에 크게 영향을 받는다.
필요한 로그가 없으면 탐지할 수 없다
SIEM은 존재하지 않는 데이터를 만들어낼 수 없다. 계정 탈취를 탐지해야 하는데 인증 로그가 없거나, 관리자 활동을 분석해야 하는데 권한 변경 기록이 남지 않는다면 탐지에는 한계가 있다. 따라서 탐지 규칙을 만들기 전에 필요한 데이터가 실제로 생성되는지 확인해야 한다.
로그가 들어온다고 정상 수집이라고 볼 수 없다
로그 수집량이 0이 아닌 것만 확인해서는 부족하다. 특정 이벤트가 누락되거나 일부 필드가 빠질 수도 있고 시스템 업데이트 이후 로그 형식이 달라질 수도 있다. 특히 파싱 결과가 잘못되면 탐지 규칙이 정상적으로 실행되는 것처럼 보이면서 실제로는 필요한 이벤트를 놓칠 수 있다.
탐지 규칙은 지속적으로 변해야 한다
기업의 시스템과 업무는 계속 바뀐다. 새로운 서비스가 추가되고 계정체계가 변경되며 공격기법도 달라진다. 한 번 만든 탐지 규칙을 그대로 두면 정상 업무가 지속적으로 오탐으로 발생하거나 새로운 공격을 놓칠 수 있다.
- 신규 로그 연동
- 기존 로그 수집 상태 확인
- 탐지 규칙 추가
- False Positive 분석
- 탐지 조건 조정
- 미사용 규칙 정리
- 신규 시스템 반영
- 사고 사례를 통한 탐지 보완
SIEM 구축은 프로젝트로 끝날 수 있지만 탐지 체계는 지속적인 운영 업무다.
Alert가 Incident를 의미하지는 않는다
SIEM에서 경보가 발생했다고 실제 침해사고가 확정되는 것은 아니다. 탐지된 행위가 정상 업무인지, 실제 공격인지, 공격이 성공했는지 등을 분석해야 한다.
자동화와 AI 분석 기능이 발전하고 있지만 중요한 조사와 대응 판단에서 사람의 역할은 여전히 남는다. 현재 Microsoft Sentinel 역시 AI와 자동화를 확대하면서도 고영향 조사와 전략적 판단에서는 분석가를 중심에 두는 구조를 설명하고 있다.
7. 기업에서 SIEM을 운영할 때 확인해야 할 사항
탐지 목적과 로그가 연결되어 있는가
SIEM 운영에서 가장 먼저 확인해야 할 것은 ‘로그가 얼마나 많이 들어오는가’가 아니다. 왜 이 로그를 수집하고 있는가가 먼저다.
로그 수집 정책은 탐지할 위험 → 필요한 행위 정보 → 필요한 로그 → 수집 방법 순서로 접근하는 편이 효율적이다. 모든 로그를 먼저 수집한 뒤 활용 방법을 고민하면 불필요한 데이터가 늘어날 수 있다.
중요 로그의 수집 중단을 감시하는가
로그 연동은 한 번 설정했다고 계속 정상적으로 유지되는 기능이 아니다. Agent 장애, 인증서 만료, API 변경, 네트워크 문제, 시스템 업그레이드 등으로 수집이 중단될 수 있다.
중요 로그가 사라졌는데 이를 인지하지 못하면 SIEM은 조용히 탐지 기능을 잃는다. 따라서 핵심 시스템은 마지막 로그 수집 시각, 평소 대비 유입량 변화 등을 함께 감시하는 것이 좋다.
탐지 규칙의 품질을 관리하는가
규칙 수가 많다고 탐지력이 반드시 높아지는 것은 아니다. 오탐이 너무 많으면 분석가는 SIEM 경보를 신뢰하지 않게 되고 중요한 이벤트가 경보 속에 묻힐 수 있다. 반대로 오탐을 줄이기 위해 규칙을 지나치게 제한하면 실제 공격을 놓칠 수 있다.
탐지 규칙은 발생 빈도, 정상 이벤트 비율, 대상 자산, 실제 사고와의 연관성, 분석 소요시간, 현재 환경에서의 필요성 등을 지속적으로 검토할 필요가 있다.
로그 보존 기간을 목적별로 구분하는가
모든 로그를 동일한 방식으로 장기간 보관하는 것이 항상 효율적인 것은 아니다. 실시간 탐지에 자주 사용하는 데이터와 과거 사고조사를 위한 데이터는 접근 빈도가 다를 수 있다. 클라우드 SIEM처럼 수집량과 저장량이 비용에 영향을 주는 환경에서는 로그 가치와 보존 기간을 함께 설계해야 한다.
NIST SP 800-92 Rev.1 공개 초안도 로그관리를 생성·전송·저장·접근·폐기에 이르는 전체 관리 과정으로 다룬다. 2026년 9월 현재 이 문서는 2023년 10월 공개된 Initial Public Draft 상태이므로 최종 표준처럼 표현하기보다는 현재 NIST의 로그관리 개선 방향을 참고하는 자료로 활용하는 것이 적절하다.
결론: SIEM의 가치는 로그의 양보다 분석 가능한 맥락에 있다
SIEM은 여러 시스템의 로그와 보안 이벤트를 중앙에 모으는 것에서 시작한다. 하지만 로그를 모으는 것만으로 보안관제가 완성되지는 않는다.
필요한 데이터가 정확하게 수집되고, 분석 가능한 형태로 처리되며, 실제 위협을 찾을 수 있는 탐지 규칙이 운영되어야 한다. 발생한 경보를 분석하고 그 결과를 다시 탐지 정책에 반영하는 과정도 필요하다.
따라서 SIEM의 운영 수준을 수집 로그 건수나 탐지 규칙 개수만으로 평가하기는 어렵다. 중요한 것은 기업이 탐지하려는 위험과 SIEM에 들어오는 데이터, 탐지 규칙, 분석가의 대응 과정이 실제로 연결되어 있는가이다.
잘 운영되는 SIEM은 단순한 로그 저장소가 아니다. 여러 보안 시스템에서 발생한 데이터를 연결하여 분석가가 실제 위험을 판단할 수 있는 맥락으로 바꾸는 보안관제 플랫폼이다.
참고자료
- NIST CSRC — Security Information and Event Management
- NIST — SP 800-92 Rev.1 Cybersecurity Log Management Planning Guide (Initial Public Draft)
- Microsoft Learn — What is Microsoft Sentinel SIEM?
- Microsoft Learn — Microsoft Sentinel Advanced Security Information Model
- Microsoft Learn — Automation in Microsoft Sentinel