이번 글에서는 Sigma Rule의 YAML 기본 구조를 필드 하나하나 해부하며, 5분 만에 핵심을 익히실 수 있도록 실전 공략으로 정리해드리겠습니다.
SigmaHQ 공식 문서에 따르면, 규칙은 메타데이터, logsource, detection, condition으로 구성되며, YAML의 가독성과 유연성이 핵심입니다.
복잡해 보이지만, 이 구조를 알면 SIEM 쿼리 작성 시간을 80% 줄일 수 있습니다.
◎ Sigma YAML의 전체 구조 개요
- Sigma Rule은 완전한 YAML 파일로, 아래 4대 섹션으로 나뉩니다:
- Metadata: 제목, ID, 태그 등 규칙 정보.
- Logsource: 어떤 로그를 분석할지 지정 (필수).
- Detection: 탐지 조건 정의.
- Condition: 조건 조합 논리.
- 간단한 예시부터 보시죠 (PowerShell LOLBIN 탐지):
| title: Suspicious PowerShell via CMD id: abc123-4567-8900-1234-567890abcdef status: stable description: Detects PowerShell launched by cmd.exe author: Your SOC Team logsource: category: process_creation product: windows detection: selection: Image|endswith: '\powershell.exe' ParentImage|endswith: '\cmd.exe' condition: selection level: medium tags: - attack.execution |
- 이 YAML 하나로 Splunk, Elastic 등 변환 가능합니다.
◎ Metadata 필드: 규칙의 정체성
- Metadata는 규칙을 식별하고 관리하는 헤더 정보입니다. GitOps에서 버전 추적과 검색에 필수적입니다.
- 필수/권장 필드:
- title: 간결한 제목 (10-20자, "Suspicious PowerShell Execution").
- id: UUID v4 (고유 식별자, uuidgen 명령으로 생성).
- status: experimental | test | stable (운영 준비도).
- description: 탐지 목적 설명 (2-3문장).
- author/date: 작성자/생성일.
- tags: MITRE ATT&CK (attack.t1059.001), TTP.
- level: low | medium | high | critical (알림 우선순위).
- references/falsepositives: 참고 자료/오탐 사례.
- 실전 팁: 태그로 커버리지 분석 (e.g., grep -r "attack.execution" rules/), level로 SOC 부하 관리.
◎ Logsource: 로그 소스 지정 (가장 중요!)
- Logsource는 탐지 대상 로그를 정의하는 필수 섹션입니다. SIEM이 모든 로그를 스캔하지 않고 특정 소스만 검색하게 해 효율을 높입니다.
- 3대 필드:
- category: process_creation | registry | file_event | network_connection (20+ 표준).
- product: windows | linux | aws-cloudtrail | azure-audit (50+ 지원).
- service: system | security (세부 분류).
- 예시 테이블:
| Category | Product | Service | 탐지 예시 |
| process_creation | windows | security | LOLBIN 실행 |
| registry | windows | - | Persistence |
| aws-cloudtrail | aws | - | IAM 변경 |
| network_connection | linux | - | C2 통신 |
- 변환 시 역할: 백엔드가 logsource를 SIEM 필드/소스 타입으로 매핑 (e.g., windows.process_creation → EventCode=4688).
- 공략: SigmaHQ rules/ 디렉토리에서 비슷한 logsource 검색해 재사용.
◎ Detection: 조건 정의의 심장
- Detection 섹션에서 실제 탐지 로직을 씁니다. YAML 딕셔너리/리스트로 AND/OR/NOT 표현.
- 구조:
| detection: selection_img: # 이름은 자유 Image|endswith: '\powershell.exe' selection_parent: ParentImage|endswith: '\cmd.exe' filter_benign: Image: ['legit_script.ps1'] |
Modifier (|): endswith, startswith, contains, regex, base64decode 등 10+ 종류.- 리스트: OR 의미 (- value1, - value2).
- 딕셔너리: AND 의미.
- Modifier 실전:
| Modifier | 예시 | 용도 |
| endswith | Image|endswith: '\calc.exe' | LOLBIN |
| contains | CommandLine|contains: 'net user' | Discovery |
| regex | CommandLine|regex: '^whoami.>temp' | 출력 리다이렉트 |
| all | ParentImage: ['cmd.exe', 'powershell.exe'] | 모든 값 AND |
- 오탐 필터: filter_legit처럼 별도 정의 후 NOT.
◎ Condition: 논리 조합 마스터
- Condition 한 줄로 detection 하위 조건을 연결합니다. YAML 리스트/딕셔너리의 논리적 의미를 활용.
- 주요 패턴:
- selection: 모든 키 AND.
- selection1 and selection2: 명시 AND.
- 1 of selection_*: OR 그룹 (1개 이상).
- all of selection_*: OR 그룹 전체.
- selection and not filter.
- 실전 예시 (멀티스테이지):
| detection: discovery: CommandLine|contains: ['net user', 'net group'] execution: Image|endswith: ['powershell.exe', 'cmd.exe'] c2: DestinationPort: [80, 443] condition: 1 of discovery or execution and c2 |
- 의미: (net user OR net group OR powershell/cmd) AND (80/443 포트).
◎ 완전한 규칙 작성: 5분 템플릿
- 빈 YAML 템플릿 (복사해서 사용):
| title: [제목] id: [uuidgen] status: stable description: [설명] author: [이름] tags: - attack.[tactic] logsource: category: [process_creation 등] product: [windows 등] detection: selection: Field|modifier: value filter: Field: benign_value condition: selection and not filter level: medium falsepositives: - [사례] |
- 테스트: sigma validate rule.yml.
- Before/After 비교 (제공 팁대로 ):
- Before (Splunk SPL): 100자 복잡 쿼리.
- After (Sigma): 20줄 YAML → 변환 1초.
◎ 고급 팁: 실무 최적화
- 변수 사용: selection_img: $powershell_paths (globals.yml 정의).
- Fields: 알림 강조 필드 (fields: [CommandLine, User]).
- References: CVE 링크 (e.g., CVE-2023-XXXX).
- Validator: sigma check rules/로 일괄 검증.
- CVE 연계 예: 최근 PrintNightmare (CVE-2021-34527) 탐지 규칙 작성.