이번 글에서는 Sigma 규칙을 Splunk SPL로 어떻게 변환하고 운영에 올려야 하는지 실습 중심으로 정리해드리겠습니다.
Sigma 공식 문서는 Splunk 백엔드가 SPL뿐 아니라 tstats, savedsearches.conf 형식까지 지원한다고 안내하며, sigma-cli에서 백엔드를 설치한 뒤 --target splunk와 --pipeline splunk_windows 조합으로 변환하는 흐름을 권장합니다.
즉, Sigma를 아는 것에서 끝나는 것이 아니라, Splunk에 바로 넣을 수 있는 쿼리로 바꾸는 과정이 핵심입니다.
◎ Splunk에서 Sigma를 쓰는 이유
- Splunk는 검색 유연성이 뛰어난 만큼 쿼리가 길어지고, 팀원마다 문법 스타일도 달라지기 쉽습니다.
- Sigma를 쓰면 탐지 의도는 YAML로 표준화하고, 실제 실행 문법은 Splunk용 SPL로 자동 변환할 수 있습니다.
- 이 방식은 룰 공유와 버전 관리에 특히 강하고, Saved Search까지 포함하면 운영 배포도 훨씬 수월해집니다.
- Splunk 백엔드는 SplunkBackend를 제공하며, Windows 로그 지원용 splunk_windows_pipeline과 Sysmon 가속용 키워드 파이프라인도 포함합니다.
- 따라서 단순 검색뿐 아니라 현업에서 필요한 성능 튜닝까지 고려한 변환이 가능합니다.
- ◎ 준비 단계
먼저 sigma-cli와 Splunk 백엔드를 설치하셔야 합니다. - SigmaHQ 문서와 GitHub 저장소는 sigma plugin install splunk로 Splunk 백엔드를 추가하라고 안내합니다.
- 기본 흐름은 다음과 같습니다.
| pip install sigma-cli sigma plugin install splunk sigma list targets sigma list pipelines |
- 이후 splunk 타깃과 splunk_windows 또는 splunk_windows_sysmon_acceleration_keywords 같은 파이프라인을 선택할 수 있습니다.
- 실무에서는 로그 수집 방식이 WinEventLog인지 Sysmon인지 먼저 확인하신 뒤 파이프라인을 맞추시는 것이 중요합니다.
◎ 첫 번째 Sigma 규칙
- 가장 흔한 예제로 PowerShell 실행 탐지를 보겠습니다.
| title: Suspicious PowerShell Execution id: 11111111-2222-3333-4444-555555555555 status: stable description: Detects PowerShell with suspicious command-line arguments author: Security Team logsource: category: process_creation product: windows detection: selection: Image|endswith: '\powershell.exe' CommandLine|contains: - 'Invoke-WebRequest' - 'DownloadString' - '-EncodedCommand' filter_legit: CommandLine|contains: 'WindowsUpdate' condition: selection and not filter_legit level: high tags: - attack.execution - attack.t1059.001 |
- 이 규칙은 PowerShell 실행 경로와 자주 쓰이는 의심 인자를 함께 보면서, 정상 업데이트 관련 패턴은 필터링하는 구조입니다.
- Splunk에서는 이런 규칙이 명확한 SPL 검색식으로 바뀌게 됩니다.
◎ SPL 변환 실습
- 이제 실제로 변환해 보겠습니다.
| sigma convert -t splunk -p splunk_windows suspicious_powershell.yml |
- 또는 최신 CLI 스타일로 아래처럼 쓰실 수도 있습니다.
| sigma convert --target splunk --pipeline splunk_windows suspicious_powershell.yml |
- Splunk용 기본 출력은 대체로 다음과 같은 구조를 가집니다.
| index=* sourcetype="WinEventLog:Security" EventCode="4688" New_Process_Name="*powershell.exe" CommandLine="*Invoke-WebRequest*" OR CommandLine="*DownloadString*" OR CommandLine="*-EncodedCommand*" NOT CommandLine="*WindowsUpdate*" |
- 이 쿼리의 핵심은 Sigma의 contains, endswith, not 조건이 SPL의 wildcard 검색과 boolean 조합으로 자연스럽게 옮겨진다는 점입니다.
- 다만 실제 필드명은 파이프라인과 환경에 따라 달라질 수 있으므로, 반드시 자신의 Splunk sourcetype과 매핑을 확인하셔야 합니다.
◎ savedsearches.conf로 내보내기
- Splunk 사용자분들께 특히 유용한 부분이 바로 Saved Search 형식입니다.
- Splunk 백엔드는 savedsearches 출력 형식을 지원하며, 운영 환경으로 바로 배포 가능한 구성 파일을 만들 수 있습니다.
| sigma convert -t splunk -p splunk_windows -f savedsearches suspicious_powershell.yml |
- 이렇게 하면 검색 쿼리만이 아니라 Splunk 앱/어플라이언스에 넣을 수 있는 형태로 내보낼 수 있습니다.
- SOC 운영팀에서는 이 형식을 활용해 리뷰된 탐지 규칙을 배포 자산처럼 관리하실 수 있습니다.
◎ 파이프라인이 중요한 이유
- Sigma에서 Splunk 변환이 단순 치환처럼 보이지만, 실제로는 pipeline이 필드 매핑과 로그소스 변환을 담당합니다.
- 예를 들어 같은 Windows 로그라도 Security 로그와 Sysmon 로그는 필드가 다릅니다.
- SigmaHQ의 Splunk backend는 Windows용 파이프라인과 Sysmon acceleration keyword 파이프라인을 제공하여 이 차이를 흡수합니다.
- 즉, Image가 New_Process_Name로 바뀌거나, ParentImage가 Parent_Process_Name으로 매핑되는 과정은 파이프라인 덕분에 자동화됩니다.
- 여기서 실수가 가장 많이 발생하므로, 변환된 SPL을 무조건 눈으로 한 번 확인하시는 습관이 필요합니다.
◎ 실전 예제 두 개
1) CMD에서 PowerShell 실행 탐지
| title: PowerShell Spawned by CMD id: 22222222-3333-4444-5555-666666666666 logsource: category: process_creation product: windows detection: selection: Image|endswith: '\powershell.exe' ParentImage|endswith: '\cmd.exe' condition: selection level: medium |
- 변환 후 SPL은 powershell.exe와 cmd.exe의 부모-자식 관계를 검색하는 형태가 됩니다.
2) 인코딩된 명령줄 탐지
| title: EncodedCommand in PowerShell id: 33333333-4444-5555-6666-777777777777 logsource: category: process_creation product: windows detection: selection: Image|endswith: '\powershell.exe' CommandLine|contains: '-EncodedCommand' condition: selection level: high |
- 이 규칙은 공격자들이 자주 사용하는 명령 인코딩 패턴을 간단하게 잡을 수 있습니다.
- 정규표현식 없이도 꽤 높은 품질의 탐지가 가능하다는 점이 Sigma의 강점입니다.
◎ 흔한 실수와 점검 포인트
- Splunk 변환에서 자주 나오는 실수는 세 가지입니다.
- 파이프라인을 지정하지 않아 필드 매핑이 어긋나는 경우.
- sourcetype이나 index가 환경과 맞지 않는 경우.
- contains와 endswith를 잘못 해석해 검색 범위가 너무 넓어지는 경우.
- 따라서 변환 후에는 반드시 테스트 검색을 돌려보고, 실제 이벤트 필드와 비교해 보셔야 합니다.
- Sigma 규칙은 공통 언어지만, Splunk의 데이터 모델은 조직마다 다르기 때문입니다.
◎ 운영에 붙이는 방법
- 실무에서는 Git 저장소에 Sigma 규칙을 두고, PR 승인 후 sigma convert를 자동 실행하는 방식이 가장 깔끔합니다.
- Sigma 공식 문서도 백엔드를 “변환 드라이버”로 보고 있고, Splunk 백엔드는 저장 형식까지 지원하므로 운영 자동화와 잘 맞습니다.
- 즉, 작성은 Sigma로 하고, 변환은 sigma-cli가 하며, 최종 배포는 Splunk가 담당하는 구조입니다.
- 이 흐름이 자리 잡으면 탐지 규칙의 재사용성과 리뷰 품질이 크게 올라갑니다.
◎ 마무리
- Splunk 사용자 입장에서 Sigma는 쿼리를 대신 쓰는 도구가 아니라, 탐지 의도를 표준화하고 SPL로 일관되게 내보내는 변환 계층입니다.
반응형
'IT > Sigma Rule' 카테고리의 다른 글
| [Sigma Rule] 제10화: QRadar 환경에서 Sigma 활용하기 (0) | 2026.05.01 |
|---|---|
| [Sigma Rule] 제9화: Elastic 및 MS Sentinel 환경에서 Sigma 활용하기 (0) | 2026.04.30 |
| [Sigma Rule] 제7화 Sigma CLI(Sigmac) 설치부터 첫 쿼리 변환까지 한 방에 끝내기 (0) | 2026.04.28 |
| [Sigma Rule] 제6화: 정규표현식보다 쉽다? Value Modifier를 활용한 정밀 패턴 매칭 (0) | 2026.04.27 |
| [Sigma Rule] 제5화: "And? Or?" 탐지 로직의 뼈대, Selection과 Condition 완벽 가이드 (0) | 2026.04.26 |
