기업의 SIEM(Security Information and Event Management)은 방화벽이나 서버에서 발생한 로그를 단순히 한곳에 저장하는 시스템이 아니다. 서로 다른 시스템에서 생성되는 데이터를 수집하고, 분석할 수 있는 형태로 가공한 뒤, 여러 이벤트의 관계를 분석해 보안 위협으로 판단할 만한 상황을 찾아내는 것이 핵심이다.
따라서 SIEM에서 실제 탐지가 이루어지려면 단순한 로그 수집만으로는 부족하다. 로그가 정상적으로 전달되어야 하고, 필요한 필드가 추출되어야 하며, 서로 다른 형식의 데이터를 비교할 수 있도록 정리한 뒤 탐지 규칙이나 분석 로직에서 사용할 수 있어야 한다.
CISA 역시 보안 로깅에서 서버·방화벽·엔드포인트·클라우드 서비스 등의 로그를 활성화하고 중앙화한 뒤, 위험 이벤트에 대한 모니터링과 경보를 구성하는 과정을 강조한다.
로그 생성 → 수집·전송 → 파싱 → 정규화·보강 → 저장·검색 → 분석·상관분석 → 탐지·경보
이 과정 중 하나라도 제대로 동작하지 않으면 탐지 결과의 품질도 떨어질 수 있다.
1. SIEM 데이터 처리의 시작은 로그 소스다
SIEM 분석의 출발점은 보안 장비가 아니라 로그를 발생시키는 모든 시스템이다.
| 로그 소스 | 주요 데이터 |
|---|---|
| Firewall | 출발지·목적지 IP, 포트, 허용·차단 결과 |
| IDS/IPS | 공격 시그니처, 탐지 대상, 공격 유형 |
| WAF | HTTP 요청, URI, 공격 패턴, 차단 결과 |
| 서버 | 로그인, 프로세스, 계정, 시스템 이벤트 |
| 애플리케이션 | 인증, 사용자 행위, 오류, 업무 이벤트 |
| EDR | 프로세스 실행, 파일 변경, 네트워크 연결 |
| 클라우드 | 계정 활동, API 호출, 구성 변경 |
특히 애플리케이션 로그는 인프라 로그만으로 확인하기 어려운 사용자 인증이나 업무 행위를 보여줄 수 있다. OWASP도 애플리케이션 보안 로그가 다른 시스템의 데이터와 함께 소비·상관분석될 수 있도록 일관된 방식으로 기록하는 것이 중요하다고 설명한다.
따라서 SIEM 구축에서 먼저 해야 할 일은 “얼마나 많은 로그를 받을 것인가”가 아니라 어떤 보안 시나리오를 탐지하기 위해 어떤 로그가 필요한가를 결정하는 것이다.
2. 로그 수집과 전송
로그가 생성되면 SIEM 또는 중간 수집 시스템으로 전달해야 한다. 환경에 따라 Syslog, 에이전트, API, 파일 수집, 메시지 또는 이벤트 스트림 등 여러 방식이 사용될 수 있다. 중요한 것은 특정 전송 기술보다 필요한 로그가 누락되지 않고 지속적으로 전달되는가이다.
예를 들어 방화벽에서 정상적으로 로그를 기록하고 있어도 SIEM으로 전달하는 과정이 중단되면 해당 시간의 보안 이벤트는 분석 대상에서 빠질 수 있다.
- 로그 발생 자체가 정상적인가
- 수집 대상이 실제로 SIEM에 도착하는가
- 수집량이 평소와 비교해 비정상적으로 감소하지 않았는가
- 시간 정보가 정확한가
- 중복 이벤트가 과도하게 발생하지 않는가
- 전송 장애 이후 데이터가 복구되는가
즉, 로그 수집 상태 자체도 모니터링 대상이어야 한다.
3. 파싱을 통해 원본 로그를 데이터로 바꾼다
수집된 원본 로그는 사람이 읽을 수 있다고 해서 바로 분석에 활용할 수 있는 것은 아니다.
2026-10-02 09:15:21 LOGIN_FAIL user01 192.0.2.10사람은 이 문자열을 보고 로그인 실패라는 것을 쉽게 알 수 있다. 하지만 SIEM 탐지 규칙이 이를 이용하려면 발생 시간, 이벤트 유형, 사용자 계정, 출발지 IP, 성공·실패 결과 등 개별 데이터 항목으로 구분할 필요가 있다.
이처럼 원본 로그에서 필요한 값을 식별하고 필드로 분리하는 과정이 파싱(Parsing)이다. 파싱이 잘못되면 로그 자체는 수집됐더라도 탐지에 필요한 값이 존재하지 않는 것처럼 보일 수 있다. 예를 들어 로그인 실패 횟수를 탐지하는 규칙에서 결과 필드가 제대로 추출되지 않는다면 실제 공격이 발생해도 규칙이 동작하지 않을 수 있다.
4. 서로 다른 로그 형식을 정리하는 정규화
기업의 보안 환경에는 제조사와 제품이 다른 여러 시스템이 존재한다. 같은 의미의 출발지 IP도 제품마다 src_ip, sourceAddress, client_ip처럼 서로 다른 필드 이름으로 표현될 수 있다. 이 데이터를 공통된 방식으로 분석하려면 서로 다른 필드와 값을 일정한 구조로 맞출 필요가 있다.
이를 일반적으로 로그 정규화(Normalization)라고 한다.
Microsoft Sentinel의 ASIM과 AWS Security Lake의 OCSF 적용 사례처럼 실제 보안 플랫폼에서도 서로 다른 보안 데이터를 공통 스키마로 변환하거나 해석하기 위한 구조가 사용된다. 다만 모든 SIEM이 동일한 방식으로 처리하는 것은 아니며, 제품에 따라 수집 시점에 변환하거나 조회·분석 시점에 파서를 적용하는 등 구현 방식이 다를 수 있다.
정규화의 구조와 필드 매핑 문제는 별도의 54번 글에서 더 자세히 다룬다.
5. 저장과 검색이 분석 성능을 좌우한다
가공된 데이터는 이후 검색과 분석이 가능하도록 저장된다. SIEM에서는 대량의 이벤트가 지속적으로 발생하기 때문에 단순히 데이터를 보관하는 것만으로는 충분하지 않다. 분석가가 특정 IP, 사용자, 호스트 또는 시간 범위를 기준으로 필요한 이벤트를 빠르게 검색할 수 있어야 한다.
- 필요한 검색 필드를 확보했는가
- 시간 정보가 일관되게 관리되는가
- 데이터 보존기간이 적절한가
- 불필요한 데이터로 저장 공간이 낭비되지 않는가
- 필요한 원본 정보가 분석 과정에서 사라지지 않는가
모든 로그를 무조건 장기간 저장하는 것은 현실적인 전략이 아닐 수 있다. 로그의 보안 가치, 사고조사 필요성, 규제 요구사항, 저장 비용 등을 함께 고려해야 한다.
NIST의 로그 관리 지침 역시 로그 관리가 단순 수집에 그치지 않고 기업 전체의 로그 인프라와 관리 프로세스를 포함하는 활동임을 설명한다.
6. 분석과 상관분석을 통해 의미 있는 패턴을 찾는다
하나의 이벤트만 보면 정상처럼 보이더라도 여러 이벤트를 연결하면 공격 징후가 드러나는 경우가 있다. 예를 들어 한 사용자의 로그인 실패 한 건은 흔한 이벤트다. 하지만 짧은 시간 동안 여러 계정에 로그인 실패가 반복되고 특정 계정에서 성공 이벤트까지 이어진다면 의미가 달라진다.
임계치 기반 탐지
일정 시간 동안 특정 이벤트가 기준 횟수 이상 발생하면 탐지한다.
동일 출발지 IP → 5분 동안 다수의 로그인 실패
조건 기반 탐지
특정 필드나 이벤트 조건이 충족됐을 때 탐지한다.
관리자 계정 → 평소 사용하지 않는 시스템에서 로그인
상관분석
서로 다른 로그 소스에서 발생한 이벤트의 관계를 분석한다.
외부 접속 → 인증 실패 반복 → 로그인 성공 → 중요 시스템 접근
실제 SIEM 제품에서는 탐지 규칙뿐 아니라 통계적 분석이나 행위·이상 탐지 등의 방식을 함께 사용할 수 있다. 그러나 분석 방식이 고도화되어도 입력 데이터가 부정확하면 탐지 결과의 신뢰성을 보장하기 어렵다는 점은 동일하다.
7. 이벤트와 경보는 같은 것이 아니다
SIEM에 들어오는 모든 로그가 보안 사고를 의미하는 것은 아니다. 방화벽 연결 한 건, 정상 로그인 한 건, 파일 접근 한 건은 각각 하나의 이벤트가 될 수 있다. SIEM은 수많은 이벤트 중 탐지 조건에 부합하는 상황을 찾아 보안 담당자가 확인할 수 있는 경보 또는 탐지 결과로 만든다.
원본 로그 → 구조화된 이벤트 → 분석 대상 → 탐지 조건 충족 → 경보 → 분석가 조사
여기서 탐지는 사고 확정과도 다르다. 경보가 발생한 이후 보안 담당자가 관련 로그와 자산, 사용자, 시간대 등의 정보를 확인해 정상 행위인지 실제 공격인지 판단하는 과정이 필요하다.
8. 실제 탐지 시나리오로 보는 처리 과정
웹 서비스에서 계정 탈취 시도를 탐지한다고 가정해 보자. 먼저 웹 또는 인증 시스템에서 로그인 성공·실패 기록이 생성된다.
이 로그가 SIEM으로 전달되고 파싱을 통해 시간 / 사용자 / 출발지 IP / 인증 결과와 같은 데이터가 추출된다. 필요한 경우 다른 시스템의 필드와 비교할 수 있도록 형식을 맞춘다. 이후 SIEM은 일정 시간 범위의 로그인 실패 이벤트를 검색하고 같은 IP에서 여러 계정에 대한 실패가 반복되는지 분석한다.
탐지 규칙의 조건을 만족하면 경보가 발생한다. 보안 분석가는 이후 원본 이벤트, 해당 IP의 다른 활동, 로그인 성공 여부, 대상 계정의 후속 행위 등을 추가로 확인한다.
로그 생성 → 전달 → 파싱 → 데이터 정리 → 저장 → 검색 → 조건 분석 → 경보 → 조사
9. 실무에서는 탐지 규칙보다 데이터 품질을 먼저 봐야 한다
SIEM 운영에서 흔히 발생하는 문제 중 하나는 탐지 규칙만 계속 추가하는 것이다. 하지만 실제 운영에서는 규칙보다 앞단의 데이터 품질 때문에 문제가 발생하는 경우가 많다.
- 장비 설정 변경 이후 로그 수집 중단
- 로그 포맷 변경으로 파싱 실패
- 시간대 또는 시스템 시간 오류
- 필드 매핑 오류
- 동일 이벤트 중복 수집
- 불필요한 로그 증가로 중요 이벤트 식별 어려움
- 탐지에 필요한 핵심 로그 자체가 비활성화됨
이 상태에서 탐지 규칙만 추가해도 보안 가시성은 크게 개선되지 않는다. 실무적으로는 탐지 정책과 함께 로그 수집률, 파싱 오류, 이벤트 발생량 변화, 핵심 필드 존재 여부 등 데이터 파이프라인의 상태를 관리하는 것이 중요하다.
또한 “가능한 모든 로그를 SIEM에 넣는 것”보다 탐지와 조사에 필요한 데이터를 명확히 정의하고 불필요한 이벤트를 조정하는 것이 운영 효율 측면에서 더 중요할 수 있다.
10. SIEM 탐지 품질은 전체 데이터 처리 과정에서 결정된다
SIEM에서 보안 위협이 탐지되는 과정은 탐지 규칙 하나로 설명할 수 없다. 로그 소스에서 필요한 기록이 생성되고, 데이터가 누락 없이 전달되며, 파싱과 정규화를 통해 분석 가능한 형태가 되고, 적절하게 저장된 뒤 탐지 규칙이나 분석 로직이 적용되어야 한다.
따라서 SIEM 운영에서 중요한 것은 단순히 “로그가 들어오고 있는가”가 아니다. 필요한 데이터가 정확한 형태로 들어오고 있으며 실제 탐지 로직에서 정상적으로 사용되고 있는가까지 확인해야 한다.
SIEM의 탐지 성능은 결국 탐지 엔진만이 아니라 로그 생성부터 분석까지 이어지는 전체 데이터 파이프라인의 품질에 의해 좌우된다.
참고자료
- NIST — Guide to Computer Security Log Management (SP 800-92)
- CISA — Use Logging on Business Systems
- OWASP — Logging Cheat Sheet
- Microsoft Learn — Normalization and the Advanced Security Information Model (ASIM)
- AWS — Open Cybersecurity Schema Framework (OCSF) in Security Lake