シグマ ルール: ユニバーサル検出ロジックと SIEM 変換
防御型サイバーセキュリティの世界では、常に最も根深い問題の 1 つは次のとおりです。 の 検出言語の断片化: 各 SIEM には独自の構文があります 独自仕様であるため、プラットフォームごとに異なるクエリと Splunk 用に作成されたルールが必要です Elastic では動作しないため、Microsoft Sentinel と互換性がありません。 その結果、SOC チームは書き換えに膨大な時間を費やすことになります。 本当に重要なことに焦点を当てるのではなく、各ツールの検出ロジックを使用します。 被害を引き起こす前に脅威を発見します。
Le シグマの法則 まさにこの問題を解決するために生まれました。 Florian Roth と Thomas Patzke によって導入された Sigma は、今日では事実上の標準フォーマットとなっています。 移植可能でプラットフォームに依存しない方法で検出ルールを作成します。 一度作成したシグマルールは自動的にクエリに変換できます。 Splunk SPL、Elasticsearch KQL、Microsoft Sentinel KQL、IBM QRadar、Chronicle YARA-L、 その他40以上のターゲット。この記事では、Sigma 構文を詳しく調べます。 ログソースのマッピング パターン、編集および変換手法、統合方法 最新の Detection-as-Code パイプラインの Sigma。
この記事で学べること
- シグマ ルールの完全な構造: タイトル、ログソース、検出、条件
- ログソースのマッピング: カテゴリ、製品、サービス、およびそれらが SIEM に変換される方法
- 高度な修飾子: contains、startswith、endswith、re、base64offset
- 集計条件: 検出統計のカウント、合計、最小、最大
- sigma-cli による Splunk、Elastic、Sentinel への自動変換
- 横方向の動き、持続性、漏洩を検出するためのパターン
- 合成データを使用したシグマ ルールのテストと検証
- ベストプラクティスによる会社の Sigma リポジトリの管理
シグマとは何か、なぜそれが標準になったのか
Sigma は、検出パターンを記述するためのオープンな YAML ベースの形式です プラットフォームに依存しない方法でセキュリティ ログを監視します。次のように考えてください ログ用の YARA: YARA でルールを作成できるのと同じように あらゆるスキャナーで動作する悪意のあるファイルに対して、Sigma では次のような書き込みが可能です。 あらゆる SIEM で機能する検出ルール。
SigmaHQ プロジェクトは今日、さらに多くのイベントを主催します 3,000のコミュニティルール 継続的なメンテナンスの対象となり、MITRE ATT&CK フレームワークにマッピングされ、準備完了 変換されること。成長は爆発的で、ニッチなツールから 脅威ハンター、シグマは検出エンジニアの共通言語となっています 専門家。主な利点は次の 3 つです。
- 携帯性: ルールを作成し、それを N 個の異なる SIEM にデプロイする
- コラボレーション： ルールは、使用している SIEM に関係なく、誰でも読むことができます。
- オートメーション： 変換は CI/CD で完全に自動化できます
シグマ ルールの構造
シグマ ルールと、明確に定義されたフィールドを含む YAML ファイル。構造を見てみましょう mimikatz の使用法を示す実際の例が完成しています。 Windowsイベントログ:
title: Mimikatz Detection via Windows Security Events
id: 0d82df6e-0e4e-4fbb-a12b-6e7a00a9c7c3
status: stable
description: Detects mimikatz usage patterns via LSASS access events
and command-line indicators
references:
- https://github.com/gentilkiwi/mimikatz
- https://attack.mitre.org/techniques/T1003/001/
author: Federico Calo
date: 2026/03/01
modified: 2026/03/09
tags:
- attack.credential_access
- attack.t1003.001
- attack.defense_evasion
logsource:
category: process_access
product: windows
detection:
selection_lsass:
TargetImage|endswith: '\lsass.exe'
GrantedAccess|contains:
- '0x1010'
- '0x1038'
- '0x1400'
- '0x143a'
selection_mimikatz_cli:
CommandLine|contains|all:
- 'sekurlsa'
- 'logonpasswords'
filter_legitimate:
SourceImage|startswith:
- 'C:\Windows\System32\'
- 'C:\Program Files\Windows Defender\'
condition: (selection_lsass and not filter_legitimate) or selection_mimikatz_cli
falsepositives:
- Legitimate security tools performing LSASS inspection
- Antivirus and EDR solutions
level: high
各セクションを詳しく分析してみましょう。
必須フィールドとメタデータ
ルールの先頭にあるメタデータ ブロックはドキュメント用です。 管理自動化の場合:
- タイトル： ルールの読みやすい名前。ユニークなものでなければなりません そして説明的。規則: 「動詞 + 主語 + 文脈」
- ID: 一意の UUID v4。それは時間が経っても決して変わらない、許してください バージョンの追跡と誤検知レポート
-
状態： ルールのライフサイクル。有効な値は次のとおりです。
stable,test,experimental,deprecated,unsupported -
レベル： 重大度。値:
informational,low,medium,high,critical -
タグ: MITRE ATT&CK タグリスト (.format)
attack.t<ID>テクニックとか、attack.<tactic>戦術用
ログソース: 移植性の核心
ブロック ログソース そしてシグマをポータブルにする魔法。 SIEM 固有のインデックスまたはデータ ストリームを指定する代わりに、以下を定義します。 ログの種類は次の 3 つのフィールドを通じて抽象化されます。
# Esempio 1: Windows Security Events
logsource:
category: process_creation
product: windows
# Esempio 2: Linux Authentication
logsource:
category: process_creation
product: linux
# Esempio 3: Web Server Logs
logsource:
category: webserver
# nessun product specifico: generico
# Esempio 4: Log specifico di un servizio
logsource:
product: windows
service: security
# Esempio 5: Log di rete
logsource:
category: network_connection
product: windows
# Esempio 6: Cloud Trail
logsource:
product: aws
service: cloudtrail
sigma-cli パイプライン システムは、これらの抽象ログソースを
各SIEMの具体的なパス。例えば、 category: process_creation
su product: windows は次のようになります:
| SIEMターゲット | ログソースの翻訳 |
|---|---|
| スプランク | source="WinEventLog:Security" EventCode=4688 |
| エラスティックサーチ (ECS) | event.category:process AND event.type:start |
| マイクロソフト センチネル (KQL) | SecurityEvent | where EventID == 4688 |
| クロニクル（YARA-L） | $event.metadata.event_type = "PROCESS_LAUNCH" |
検出: 選択と条件
ブロック 検出 検出ロジックが定義されている場所。 これは 2 つの部分で構成されます。 選択 (ログフィールドのフィルタ) そして 状態 (選択を組み合わせるブール ロジック)。
detection:
# Selection con match esatto su campo singolo
selection_exact:
EventID: 4625
# Selection con lista di valori (OR implicito)
selection_multi_value:
CommandLine|contains:
- 'net user'
- 'net localgroup'
- 'whoami'
# Selection con match su tutti i valori (AND implicito con |all)
selection_and_all:
CommandLine|contains|all:
- '-enc'
- 'powershell'
# Selection con regex
selection_regex:
CommandLine|re: '(?i)(invoke-mimikatz|sekurlsa::)'
# Selection con wildcard
selection_wildcard:
TargetFilename|startswith: 'C:\Users\'
TargetFilename|endswith: '.exe'
# Filter per ridurre i falsi positivi
filter_system_processes:
ParentImage|startswith: 'C:\Windows\System32\'
# Condition: logica booleana
condition: selection_exact and (
selection_multi_value or selection_and_all
) and not filter_system_processes
高度な修飾子
I 修飾子 これらはフィールド名に追加される接尾辞です。
パイプ文字を使用した場合 | マッチタイプを変更します。
効果的なルールを作成するには、それらをすべて理解することが不可欠です。
| 修飾子 | 説明 | Esempio |
|---|---|---|
contains |
部分文字列一致 (両側のワイルドカード) | CommandLine|contains: 'mimikatz' |
startswith |
値の先頭で一致 | Image|startswith: 'C:\Users\' |
endswith |
値の末尾で一致 | Image|endswith: '\cmd.exe' |
re |
正規表現 PCRE | CommandLine|re: '(?i)sekurlsa' |
base64offset |
オフセット 0、1、2 による Base64 デコード | CommandLine|base64offset|contains: 'IEX' |
wide |
Unicode ワイド文字列での一致 | CommandLine|wide|contains: 'sekurlsa' |
all |
リスト内のすべての値が一致する必要があります | CommandLine|contains|all: ['-enc', 'bypass'] |
windash |
ダッシュとスラッシュの両方を一致させます | CommandLine|contains|windash: '-Enc' |
cidr |
IP の CIDR 範囲の一致 | DestinationIp|cidr: '10.0.0.0/8' |
lt, lte, gt, gte |
数値比較 | EventID|gte: 4624 |
集計条件: 統計的検出
一部の検出では、特定の時間間隔でイベントをカウントする必要があります。 単一のイベントと一致しないこと。シグマサポート 集計条件 これらのユースケースの場合:
# Rilevare brute force: più di 10 login falliti in 60 secondi
title: Windows Brute Force Login Attempt
logsource:
product: windows
service: security
detection:
selection:
EventID: 4625
LogonType: 3
condition: selection | count() > 10
timeframe: 60s
falsepositives:
- Users with expired passwords
level: medium
---
# Rilevare data exfiltration: upload anomalo per destinazione
title: Potential Data Exfiltration by Volume
logsource:
category: network_connection
product: windows
detection:
selection:
Initiated: 'true'
DestinationPort:
- 443
- 80
condition: selection | count(DestinationHostname) by SourceIp > 50
timeframe: 1h
level: high
---
# Port scan detection: molte porte diverse dallo stesso sorgente
title: Network Port Scan Detection
logsource:
category: network_connection
detection:
selection:
EventID: 5156
condition: selection | count(DestinationPort) by SourceAddress > 30
timeframe: 10m
level: medium
sigma-cli による変換: 実践ガイド
シグマ-cli ルールを変換するための公式ツール SIEM クエリ言語のシグマ。基本的なインストールと使用:
# Installazione
pip install sigma-cli
pip install pySigma-backend-splunk
pip install pySigma-backend-elasticsearch
pip install pySigma-backend-microsoft365defender
# Verifica backend disponibili
sigma list backends
# Conversione base: Sigma -> Splunk SPL
sigma convert -t splunk -p splunk_windows rules/mimikatz.yml
# Output atteso:
# (source="WinEventLog:Microsoft-Windows-Sysmon/Operational"
# EventCode=10 TargetImage="*\\lsass.exe"
# GrantedAccess IN ("0x1010", "0x1038", "0x1400", "0x143a"))
# NOT (SourceImage="C:\\Windows\\System32\\*"
# OR SourceImage="C:\\Program Files\\Windows Defender\\*")
# Conversione con pipeline personalizzata
sigma convert \
-t splunk \
-p splunk_windows \
-p my_custom_field_mapping.yml \
rules/
# Conversione per Elasticsearch con ECS
sigma convert \
-t elasticsearch \
-p ecs_windows \
-f lucene \
rules/credential_access/
# Conversione per Microsoft Sentinel (KQL)
sigma convert \
-t microsoft365defender \
-p microsoft365defender \
rules/lateral_movement/
# Output in formato JSON per automazione
sigma convert \
-t splunk \
-p splunk_windows \
--format-output json \
rules/ > converted_rules.json
注意: パイプラインとフィールドのマッピング
各組織には独自のログ正規化があります。あなたのログが 標準パターン (Windows 用 Sysmon など) に従っていない場合は、 カスタムパイプライン シグマフィールドをフィールドにマッピングします SIEM の実際のデータ。このマッピングがないと、変換されたルールは機能しません。
カスタムパイプラインの作成
Sigma パイプラインは、Sigma 抽象フィールドをフィールドにマッピングする方法を定義します。 SIEM の具体的な要素。使用するインフラストラクチャ用に作成する方法は次のとおりです。 カスタム ログ形式:
# custom_pipeline.yml
name: Custom Windows Pipeline
priority: 20
transformations:
# Rinominare campo Sigma -> campo reale nel SIEM
- id: field_mapping_process
type: field_name_mapping
mapping:
CommandLine: process.command_line
Image: process.executable
ParentImage: process.parent.executable
User: user.name
TargetImage: target.process.executable
GrantedAccess: target.process.granted_access
rule_conditions:
- type: logsource
category: process_creation
# Aggiungere condizioni all'index di destinazione
- id: index_condition
type: detection_item_keyword
keyword: 'index=windows_events'
rule_conditions:
- type: logsource
product: windows
# Sostituire valori nei campi
- id: winlog_channel_map
type: field_value_mapping
field_name: winlog.channel
mapping:
'Security': 'security'
'System': 'system'
'Application': 'application'
一般的な使用例の検出パターン
優先度の高いユースケースに対応できるシグマ ルールのコレクションを見てみましょう。 最も悪用されている MITRE ATT&CK テクニックにマッピングされています。
横方向の移動: パス・ザ・ハッシュ
title: Pass-the-Hash Attack Pattern
id: 6571d552-4c16-4f50-b5f6-11ae9d1b0a38
status: stable
description: Detects Pass-the-Hash attacks via anomalous NTLM authentication
tags:
- attack.lateral_movement
- attack.t1550.002
logsource:
product: windows
service: security
detection:
selection:
EventID: 4624
LogonType: 3
AuthenticationPackageName: NTLM
KeyLength: 0
filter_local:
IpAddress:
- '127.0.0.1'
- '::1'
filter_machine:
SubjectUserName|endswith: '