[Sigma Rule] 제9화: Elastic 및 MS Sentinel 환경에서 Sigma 활용하기

이번 글에서는 Sigma를 Elastic Security와 Microsoft Sentinel 환경에서 어떻게 활용하는지 실무 관점으로 정리해드리겠습니다.

Sigma 공식 문서는 백엔드가 Sigma 규칙을 SIEM 호환 쿼리로 바꾸는 “드라이버” 역할을 한다고 설명하며, Elastic 백엔드는 Lucene, EQL, Kibana NDJSON까지 지원하고, Sentinel 계열은 KQL 및 관련 파이프라인을 통해 변환을 수행합니다.

즉, Sigma를 한 번 작성해 두면 두 플랫폼 모두에서 탐지 자산으로 재사용할 수 있습니다.

 

◎ 왜 Elastic과 Sentinel을 함께 봐야 할까요

• Elastic과 Microsoft Sentinel은 모두 클라우드와 엔터프라이즈 환경에서 많이 쓰이지만, 쿼리 방식과 운영 철학이 다릅니다. 
• Elastic은 Lucene, EQL, Kibana Detection Rule 형식 등 여러 출력 포맷을 지원하고, Sentinel은 KQL 기반의 탐지와 Microsoft 365 Defender 계열의 파이프라인 연계가 강점입니다. 
• Sigma를 쓰면 이런 차이를 규칙 수준에서 흡수할 수 있어서, 탐지 의도는 하나로 유지하고 실행 환경만 바꾸는 운영이 가능해집니다.

 

• 실무적으로는 “Elastic 전용 룰”, “Sentinel 전용 룰”을 따로 관리하면 중복이 커집니다. Sigma는 이 중복을 줄이고, 탐지 로직의 일관성을 유지하는 데 적합합니다.

 

◎ Elastic에서 Sigma를 쓰는 방법

 - Elastic 백엔드는 pySigma의 Elasticsearch backend로 제공되며, Lucene 쿼리를 기본으로 EQL, Kibana NDJSON, DSL 내장 쿼리까지 생성할 수 있습니다. 

 - 즉, 단순 검색식뿐 아니라 Kibana의 탐지 규칙이나 저장된 검색 형태로도 내보낼 수 있습니다.

 

 - 예를 들어 Windows 프로세스 탐지 규칙을 Sigma로 작성하면, Elastic 쪽에서는 다음과 같은 흐름으로 변환됩니다.

• Sigma YAML 작성.
• sigma plugin install elasticsearch 실행.
• sigma convert --target elasticsearch --pipeline ecs_windows rule.yml처럼 변환.
• 결과를 Kibana 탐지 룰 또는 검색 쿼리로 적용.

 

 - Elastic 백엔드는 ecs_windows, ecs_zeek_beats, ecs_kubernetes 같은 파이프라인도 제공하므로, Windows 로그뿐 아니라 네트워크·클라우드 로그까지 확장하기 좋습니다.

 - 이 점이 Elastic을 쓰는 조직에서 Sigma를 도입할 때 큰 장점입니다.

 

◎ Sentinel에서 Sigma를 쓰는 방법

 - Microsoft Sentinel은 KQL 중심의 탐지가 핵심입니다. 

 - Sigma 생태계에서는 KQL 계열 백엔드와 Microsoft 365 Defender용 백엔드, Sentinel 관련 파이프라인들이 사용되며, Sigma 규칙을 Microsoft 환경에 맞는 검색문으로 변환할 수 있습니다.

 

 - 특히 Microsoft 365 Defender용 pySigma 변환 예시는 SigmaRule.from_yaml로 규칙을 읽은 뒤 Microsoft365DefenderBackend로 KQL을 생성하는 방식입니다.

 - Sentinel 운영에서도 유사한 방식으로 KQL 기반 룰을 표준화할 수 있습니다.

 - 실제로는 아래와 같은 흐름으로 이해하시면 편합니다.

• Sigma로 탐지 의도를 작성합니다.
• Sentinel용 백엔드 또는 KQL 파이프라인을 선택합니다.
• 변환된 KQL을 Sentinel 분석 규칙으로 배포합니다.

 

 - 이 방식은 Defender와 Sentinel을 함께 운영하는 조직에서 특히 유리합니다. 규칙의 본체는 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

 

• 이 규칙은 Elastic에서도, Sentinel에서도 같은 탐지 의도를 유지한 채 변환될 수 있습니다.
• Elastic 쪽에서는 EQL 또는 Lucene 쿼리로 바뀌고, Sentinel 쪽에서는 KQL 기반 탐지로 바뀌게 됩니다.

 

 

 

◎ Elastic 변환 시 포인트

• Elastic에서는 파이프라인 선택이 중요합니다. 
• Windows 로그라면 ecs_windows, Zeek라면 ecs_zeek_beats, Kubernetes라면 ecs_kubernetes처럼 로그소스별 매핑을 맞춰야 합니다. 
• 백엔드가 Lucene, EQL, Kibana NDJSON 등 여러 형식을 지원하므로, 단순 검색용인지 탐지 룰용인지 먼저 정하시는 것이 좋습니다.

 

• 예를 들어 EQL 기반 탐지를 원하신다면 다음과 같은 결과를 기대할 수 있습니다.

sigma convert --target elasticsearch --format eql --pipeline ecs_windows rule.yml

 

• 이후 Kibana Detection Engine에 직접 넣기 쉬운 형태로 활용할 수 있습니다.

 

◎ Sentinel 변환 시 포인트

 - Sentinel은 KQL의 문법과 데이터 테이블 구조를 이해하는 것이 중요합니다. 

 - Sigma에서 Sentinel용 변환을 할 때는 파이프라인이 KQL에 맞게 필드 이름과 로그소스를 맞춰 줍니다.

 

 - 실무에서는 다음을 꼭 점검하셔야 합니다.

• 테이블 이름이 Sentinel 워크스페이스와 맞는지.
• 필드명이 KQL에서 실제 수집 필드와 일치하는지.
• Defender와 Sentinel을 같이 쓰는 경우 파이프라인이 중복되지 않는지.

 

 - Sigma는 이 과정을 자동화하는 데 강점이 있지만, 최종 검증은 반드시 KQL 화면에서 하셔야 합니다. 변환이 맞더라도 데이터 온보딩이 빠져 있으면 룰이 동작하지 않기 때문입니다.

 

◎ 운영 전략

• Elastic과 Sentinel을 함께 쓰는 조직에서는 “공통 Sigma 저장소”를 두고, 각 환경용 변환 파이프라인만 분리하는 방식이 가장 효율적입니다. 
• 예를 들어 Git 저장소에는 Sigma YAML만 보관하고, CI/CD에서 Elastic용 쿼리와 Sentinel용 KQL을 각각 생성하는 구조입니다. 
• Sigma 공식 문서가 말하는 백엔드·파이프라인·출력 형식의 분리 개념이 바로 이 운영 방식과 잘 맞습니다.

 

• 이렇게 운영하면 탐지 로직의 수정은 한 번만 하면 되고, Elastic과 Sentinel 모두에 반영할 수 있습니다.
• SOC 관점에서 보면 룰 유지보수 비용을 크게 줄이는 방식입니다.

 

◎ 실무에서 자주 하는 실수

• 가장 흔한 실수는 Elastic과 Sentinel을 같은 규칙처럼 다루는 것입니다. 
• Elastic은 EQL, Lucene, Kibana NDJSON 등 출력 형식이 다양하고, Sentinel은 KQL 중심이라는 차이가 있습니다. 
• 따라서 “변환된다”와 “운영에 바로 넣을 수 있다”는 다릅니다. 
• 변환 후에는 항상 각 플랫폼의 데이터 스키마와 대시보드를 기준으로 재검증하셔야 합니다.

 

• 또 다른 실수는 파이프라인을 생략하는 것입니다.
• Windows 로그를 다루는데 ECS 매핑이나 KQL 필드 변환이 없으면, 쿼리가 맞아도 데이터가 안 잡힐 수 있습니다.

 

◎ 마무리

• Sigma는 Elastic과 Microsoft Sentinel을 하나의 탐지 언어로 묶어 주는 실전 도구입니다. 
• Elastic에서는 Lucene, EQL, Kibana 형식으로, Sentinel에서는 KQL과 Defender 연계 흐름으로 변환할 수 있어 운영 효율이 높습니다.