なぜこれが画期的なのか。従来、ログから攻撃を探す検索クエリは、SIEM製品ごとに“方言”が違いました。Splunkには SPL、Elasticには独自のクエリ、Microsoft Sentinelには KQL……。ある会社が苦労して作った「この攻撃を見つけるロジック」は、別のSIEMを使う会社にはそのまま渡せず、知見が分断されていたのです。Sigmaはここに「共通語」を持ち込みました。ロジックをSigmaで一度書けば、変換ツールが各SIEMの方言へ翻訳してくれる——だから検知の知識を、世界中で“持ち寄り、使い回せる”ようになったのです。

この“持ち寄り”の力は、想像以上に大きいものです。世界のどこかで新しい攻撃が観測され、誰かがそれを検知するSigmaルールを書いてSigmaHQに公開すれば、翌日にはあなたの環境でも、その攻撃を見張れるようになります。1万5千本という数字は、単なるルールの山ではなく、世界中の防御者が積み上げてきた“集合知”。無料で、誰でも、その恩恵にあずかれるのです。

これは、潤沢な予算やチームを持たない組織にこそ朗報です。高価な専用ルールを買わなくても、世界水準の検知ロジックを無料で取り込み、自分の環境に合わせて育てていける。しかも一度Sigmaに慣れれば、その知識はSIEMを乗り換えても無駄になりません。Sigmaは、検知という“守りの最前線”を、規模を問わず誰の手にも開いた——そう言える存在です。

SigmaルールはYAMLという、人にやさしい書式で書かれます。中身は大きく「メタ情報（何のルールか）」と「検知ロジック（何を見つけるか）」の2つ。まずは代表的なフィールドを押さえましょう。

logsource は地味に見えて、検知の“当たり外れ”を左右する要です。「どのログを見るか」を取り違えれば、どんなに良いルールも空振りします。たとえばWindowsのプロセス起動を細かく追うなら、標準ログだけでなくSysmonのような“詳しく記録する仕組み”を入れておく必要があります。「検知したい手口は、どのログに痕跡を残すか」——ここを最初に押さえるのが、検知設計の出発点です。

このうち必須なのは title ・ logsource ・ detection の3つ。実際の1本を見てみましょう。下は「ネットワークからコードを取得して実行する、不審なPowerShell」を検知するルールです。

▲ 読み方：logsourceで「Windowsのプロセス作成ログ」を対象に指定し、detectionで「powershell.exeが、DownloadString等を含むコマンドで起動された」という条件を定義。tagsでMITRE ATT&CKの手口（T1059.001）に紐づけています。

注目してほしいのは、このルールに「Splunk」や「Elastic」という言葉が一切出てこないこと。Sigmaは“何を検知したいか”という意図だけを書きます。それを実際のSIEMの検索式へ翻訳するのは、次章で見る変換ツールの仕事です。だから同じ1本が、環境を問わず使い回せるのです。

detection は、1つ以上の「selection（条件のかたまり）」と、それらをどう組み合わせるかを決める「condition」でできています。selectionの書き方には、覚えやすい3つのパターンがあります。

さらに、フィールド名の後ろに「修飾子（モディファイア）」を付けると、一致のしかたを細かく指定できます。これがSigmaの表現力の源です。

ちなみに、selection や filter_legit といった名前は自由に決められます。selection_powershell でも susp_cmd でも構いません。大切なのは、condition でその名前を呼び出して論理を組み立てること。条件を複数のselectionに分けて名前を付けておくと、1 of selection_*（いずれか一つ）のように、柔軟で読みやすいルールが書けるようになります。

そして仕上げが condition。複数のselectionやfilter（除外条件）を、and / or / not や 「1 of（いずれか）」「all of（すべて）」で論理的に組み合わせます。下は「whoami の実行を検知。ただしマシンアカウント等による正規実行は除外する」という、実戦的な例です。

▲ not filter_legit で“正常な状況”を引き算するのが、誤検知を減らすコツ。|re を使いこなすには正規表現の基礎が効いてきます。

Sigmaルールは、そのままでは“レシピ”にすぎません。実際に動かすには、各SIEMの検索式へ変換する必要があります。その標準ツールが、Python製のpySigmaと、それを使うコマンドsigma-cliです（かつての sigmac を置き換えた新世代）。

▲ -t splunk を -t elasticsearch などに変えれば、同じルールが別のSIEM向けに翻訳されます。これが「一度書けば、どこでも動く」の正体です。

ただし、変換すれば即・完成ではありません。自動翻訳されたクエリは、環境のフィールド名や癖によって、そのままでは過剰に光ったり、逆に空振りしたりします。だから変換後は必ず、自分の環境のログでテストを。「攻撃の再現ログでちゃんと光るか」「平常時に鳴りすぎないか」を確かめてから本番へ——この一手間が、信頼できる検知と“オオカミ少年”を分けます。

翻訳の精度を上げる仕組みが「プロセッシング・パイプライン」です。現場ごとにログのフィールド名は微妙に違います（同じ「プロセス名」でも、環境によって呼び名が異なる）。パイプラインは、そのズレを吸収して正しくマッピングしてくれます。さらにうれしいのは、Sigmaを“読める”ツールがSIEM以外にも広がっていること。

個々のルールを作る技術の先に、「組織を守る検知の仕組みを設計・運用する」営みがあります。これを検知エンジニアリング（ディテクション・エンジニアリング）と呼びます。その基本の流れを押さえましょう。

もう一つ、検知エンジニアリングの醍醐味が「カバレッジ（網羅度）の可視化」です。各ルールにMITRE ATT&CKの tags を付けておくと、「自分たちは攻撃のどの段階を見張れていて、どこが手薄か」を一枚の地図（ヒートマップ）にできます。闇雲にルールを増やすのではなく、“穴”を見つけて、そこを優先的に埋める——この地図思考こそ、限られた人手で守りを最大化するコツです。

Sigmaを学ぶうえで、日本の私たちには心強い味方がいます。Hayabusa（隼）——日本のセキュリティ集団Yamato Securityが開発する、Rust製の高速ツールです。Windowsのイベントログ（.evtx）を、Sigmaベースのルールで一気にスキャンし、「いつ・何の不審な出来事が起きたか」をタイムラインにまとめてくれます。日本語ドキュメントが整っているのも、入門に最適な理由です。

▲ サーバ構築も不要。集めた .evtx にこれを走らせるだけで、Sigma検知の“効き”を体験できます。出力CSVを表計算で開けば、怪しい時刻が浮かび上がります。

さらに、Hayabusa向けに整備されたhayabusa-rulesは、前章で紹介したVelociraptorでも利用されています。「同じSigmaルールが、複数のツールで使い回せる」——この記事の冒頭で語った価値を、まさに地で行く好例です。日本語で書かれた解説や、JPCERT/CCのカンファレンス「JSAC」での検知エンジニアリング講座など、学びの足場も着実に増えています。

学び方として一番おすすめなのは、「本物のルールをたくさん読む」ことです。SigmaHQには1万本を超える実戦ルールがあり、その一つひとつが「プロはこの手口を、どう表現したか」の生きた教科書です。気に入ったルールを真似て書き換え、自分のラボで動かし、慣れてきたらコミュニティへ還元する。世界中の防御者が同じように積み上げてきたからこそ、Sigmaは強くなりました。あなたの1本も、その一部になれます。

ここまでに登場した言葉の“答え合わせ”として、用語集とFAQをまとめました。Sigmaは奥が深い分野ですが、入口はこの記事の範囲で十分です。あとは手を動かしながら、少しずつ守備範囲を広げていきましょう。最初の1本を書き上げたとき、ログの見え方がきっと変わります。

📖 用語集

❓ よくある質問（FAQ）

🧭 次に読む