Sigma 룰 YAML 1개가 Splunk, Elastic, Sentinel에서 동시에 동작한다. pySigma 변환 파이프라인의 내부 구조를 해부했다.
댓글은 익명으로 작성되며, 삭제 비밀번호를 설정하면 본인만 삭제할 수 있습니다. 비밀번호를 설정하지 않은 댓글은 누구나 삭제할 수 있습니다.
Splunk에서 Elastic으로 SIEM을 교체하면 기존 탐지 룰 수백 개를 전부 다시 작성해야 한다. 2017년 Florian Roth와 Thomas Patzke가 공개한 Sigma는 이 문제를 정면으로 해결했다. 하나의 YAML 룰을 작성하면 29개 백엔드가 각 SIEM의 네이티브 쿼리로 변환한다. GitHub 스타 10,200개, 커밋 16,742건, 공식 룰 3,000개 이상 — Sigma는 로그 기반 탐지의 사실상 표준이 됐다. 공식 README의 표현을 빌리면, "Snort가 네트워크 트래픽에, YARA가 파일에 하는 것을 Sigma는 로그에 한다."
Sigma는 탐지 로직을 SIEM에 독립적인 YAML로 한 번만 작성하고, 변환기(pySigma)가 각 SIEM의 네이티브 쿼리로 컴파일하는 구조다.
Sigma YAML 1개가 pySigma를 거쳐 Splunk·Elastic·Sentinel 등 29개 백엔드로 변환되는 흐름도
Sigma 룰은 title, id, status, level 등 메타데이터 필드와 함께 3개의 핵심 필드 (logsource, detection, tags) 로 구성된다. SigmaHQ 공식 저장소의 Mimikatz 탐지 룰로 살펴보자.
title: HackTool - Mimikatz Execution
id: a642964e-bead-4bed-8910-1bb4d63e3b4d
status: test
description: Detection well-known mimikatz command line arguments
tags:
- attack.credential_access
- attack.t1003.001
logsource:
category: process_creation
product: windows
detection:
selection_tools_name:
CommandLine|contains:
- 'DumpCreds'
- 'mimikatz'
selection_module_names:
CommandLine|contains:
- 'sekurlsa::'
- 'kerberos::'
- 'lsadump::'
- 'dpapi::'
condition: 1 of selection_*
falsepositives:
- Unlikely
level: high
각 필드의 역할을 분해한다.
logsource는 룰이 적용될 로그 소스를 정의한다. category: process_creation은 프로세스 생성 이벤트를, product: windows는 Windows 운영체제를 지정한다. 이 추상화 덕분에 Sysmon EventID 1이든 Windows Security EventID 4688이든, 파이프라인이 알아서 매핑한다.
detection은 룰의 핵심이다. selection_*으로 시작하는 블록들이 각각 탐지 조건을 정의하고, condition: 1 of selection_*이 이들을 OR로 결합한다. |contains 수정자(modifier)는 필드값에 해당 문자열이 포함되어 있으면 매치한다.
Sigma는 16개 이상의 수정자를 지원한다.
| 수정자 | 동작 |
|---|---|
contains | 와일드카드 매치 (문자열 포함 여부) |
startswith / endswith | 접두사/접미사 매치 |
re | 정규표현식 |
base64 / base64offset | Base64 인코딩 탐지 |
cidr | IP 서브넷 매칭 |
all | OR 리스트를 AND로 전환 |
windash | 대시 변형 허용 (-, /, — 등) |
exists | 필드 존재 여부 확인 |
tags 필드는 attack.t1003.001처럼 MITRE ATT&CK 기법 ID를 직접 태깅한다. SigmaHQ GitHub 기준 process_creation 카테고리에만 1,036개 룰이 있으며, MITRE CAR 커버리지 비교에 따르면 PowerShell 실행(T1059.001)은 181개 룰로 가장 높은 커버리지를 보인다.
2023년 레거시 변환기 sigmac가 pySigma + sigma-cli로 교체됐고, 2024년 8월 sigmac는 공식 EOL(End of Life)에 도달했다. 현재 모든 변환은 sigma-cli로 수행한다.
# 설치
pip install sigma-cli
sigma plugin install splunk
# 변환
sigma convert -t splunk -p splunk_windows rule.yml
위의 Mimikatz 룰을 4개 SIEM으로 변환한 결과를 비교한다.
(CommandLine="*DumpCreds*" OR CommandLine="*mimikatz*"
OR CommandLine="*sekurlsa::*" OR CommandLine="*kerberos::*"
OR CommandLine="*lsadump::*" OR CommandLine="*dpapi::*")
|contains가 ="*...*" 와일드카드로 변환된다. splunk_cim 파이프라인을 사용하면 CommandLine이 Processes.process로 매핑된다.
process.command_line:(*DumpCreds* OR *mimikatz*
OR *sekurlsa\:\:* OR *kerberos\:\:*
OR *lsadump\:\:* OR *dpapi\:\:*)
ecs_windows 파이프라인이 CommandLine을 process.command_line으로 변환한다. 콜론(:)은 Lucene 특수 문자이므로 이스케이프된다.
SecurityEvent
| where EventID == 4688
| where CommandLine has_any ("DumpCreds", "mimikatz",
"sekurlsa::", "kerberos::", "lsadump::", "dpapi::")
sentinelasim 파이프라인은 process_creation을 SecurityEvent(EventID 4688)로 매핑한다. KQL의 has_any 연산자가 OR 매치를 처리한다.
SELECT * FROM events
WHERE devicetype=12
AND (LOWER("Command") LIKE '%dumpcreds%'
OR LOWER("Command") LIKE '%mimikatz%'
OR LOWER("Command") LIKE '%sekurlsa::%'
OR LOWER("Command") LIKE '%lsadump::%')
devicetype=12는 Windows Security Event Log 디바이스 타입이다. AQL은 대소문자를 구분하므로 LOWER()로 감싼다. 필드가 매핑되지 않으면 UTF8(payload) LIKE '%...'로 폴백하며, 전체 페이로드를 풀스캔하므로 성능이 급격히 떨어진다.
4개 SIEM의 출력이 다른 이유는 파이프라인(Processing Pipeline) 때문이다. 파이프라인은 Sigma의 범용 필드명을 각 SIEM의 고유 필드명으로 변환하는 규칙 집합이다.
CommandLine 필드가 파이프라인을 거쳐 SIEM별 고유 필드명으로 매핑되는 과정
파이프라인은 YAML로 정의되며, 우선순위(priority)에 따라 순차 실행된다.
| 우선순위 | 역할 |
|---|---|
| 10 | 로그 소스 정규화 (Sysmon EventID 매핑 등) |
| 20 | 백엔드 전처리 (ECS 필드 매핑 등) |
| 50 | 백엔드 코어 변환 |
| 60 | 출력 포맷 (Kibana NDJSON, Splunk savedsearches 등) |
파이프라인 체이닝도 가능하다. Sysmon 로그를 Splunk로 변환할 때 sysmon 파이프라인(우선순위 10)이 먼저 EventID를 정규화하고, splunk_windows 파이프라인(우선순위 50)이 필드명을 변환한다.
sigma convert -t splunk -p sysmon -p splunk_windows rule.yml
성숙한 SOC 팀은 Sigma를 CI/CD 파이프라인에 통합한다. SANS/Anvilogic 2025 보고서 기준 응답자의 46%가 Detection-as-Code를 핵심 역량으로 식별했다.
1단계 — 작성: Git 저장소에 Sigma YAML 룰 커밋
2단계 — PR 검증(CI): sigma check로 YAML 스키마 검증 후 sigma convert로 컴파일 가능 여부 확인, 샘플 로그 데이터로 단위 테스트
3단계 — 배포(CD): main 브랜치 머지 시 CI/CD 러너가 sigma convert 실행 후 SIEM API로 룰 배포 (Splunk: Saved Search, Elastic: Detection Engine Rule, Sentinel: Analytic Rule)
4단계 — 피드백: 알림 메타데이터가 Sigma 룰 UUID로 연결되어, 룰별 오탐률 추적이 가능하다. 높은 오탐 룰은 Git에서 튜닝 후 재배포한다.
Sigma 룰이 사용하는 필드가 파이프라인의 매핑 테이블에 없으면 변환이 실패한다. QRadar는 매핑 누락 시 UTF8(payload) 풀스캔으로 폴백하지만, 성능이 수십 배 떨어진다. Elasticsearch 백엔드는 --skip-unsupported 플래그 없이 배치 변환하면 매핑 누락 룰 1개가 전체 배치를 중단시킨다.
Sigma 룰의 falsepositives: 블록은 순수한 텍스트 메모다. 어떤 변환기도 이 블록을 파싱해서 제외 조건으로 변환하지 않는다. 오탐 억제는 분석가가 각 SIEM에서 수동으로 추가해야 한다.
Sigma v2 사양은 2024년에 상관 분석 룰을 도입했다. "5분 내 로그인 실패 5회"처럼 다중 이벤트 조건을 정의할 수 있다. 그러나 이 기능을 지원하는 백엔드는 Elasticsearch ES|QL과 Splunk SPL 2개뿐이다. Sentinel KQL, QRadar AQL 등 나머지 백엔드에서는 상관 분석 룰이 변환되지 않는다.
공격자에게 Sigma의 한계는 곧 기회다. 상관 분석이 2개 백엔드에서만 작동한다는 것은, 나머지 SIEM 환경에서는 다단계 공격 시퀀스가 개별 이벤트로만 탐지된다는 뜻이다. 필드 매핑 누락은 특정 SIEM에서 탐지 자체가 누락될 수 있음을 의미한다. Sigma가 커버하지 못하는 ATT&CK 기법 (물리적 유출, 하이퍼바이저 회피 등) 은 로그 기반 탐지의 구조적 사각지대로 남는다.
SIEM 고유 기능 — Splunk의 Risk-Based Alerting, Sentinel의 ML Analytics Rule, QRadar의 Reference Set — 도 Sigma로 표현할 수 없다. Sigma는 탐지 로직의 대부분을 이식 가능하게 만들지만, SIEM 고유 기능은 여전히 각 플랫폼에서 직접 구현해야 한다.