이번 글에서는 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로 일관되게 내보내는 변환 계층입니다.

 

 

 

반응형

+ Recent posts