What Are SIGMA Rules: Beginner’s Guide

世界最大の検出ルールデータセットにアクセス

無料登録

このブログ投稿では、SIGMAを検出言語として推奨し、最も重要なSIGMAルールのコンポーネント（logsourceおよびdetection）、SIGMAの分類、SIGMAルールのテストについて説明し、SIGMAに不慣れなアナリストが最初のルールを書くための準備をします。また、検出エンジニアリングでSIGMAを使用する際のノイズ、アイデア、ログソースなどについての短い議論も提供されます。

SIGMAルールのケース

過去には、SIEM検出はベンダー/プラットフォーム固有の孤立した環境に存在しました。検出コンテンツを共有したいパートナーは、多くの場合、あるベンダーから別のベンダーへのクエリの翻訳を迫られました。これは持続可能ではありません。サイバーセキュリティの防御コミュニティは、常に進化する敵に対抗するために、検出の共有方法を改善しなければなりません。

YARAやSnortルールのように、SIGMAは検出のオープンな共有のための別のツールです。ただし、ファイルやネットワークトラフィックではなくSIEMに焦点を当てています。 SIGMAは、防御者が共通の言語で検出（アラート、ユースケース）を共有できるようにします。

2017年にFlorian RothとThomas Patzkeによって最初にリリースされたSIGMAは、プラットフォームに依存しない検索への道を開いています。SIGMAを使用すると、防御者はベンダーやプラットフォーム固有の検出言語やリポジトリから解放され、コミュニティの力を利用して、重大な脅威や新しい敵のトレードクラフトに迅速に対応できます。

SIGMAを使用する理由はたくさんあります。

• 新しい敵の行動を特定し、検出を共有する方法を望んでいる研究者およびインテリジェンスチーム
• 複数のSIEM / EDR / Log Analyticsソリューションおよびデータ分類/スキーマ（ECS、CEF、CIMなど）に責任を負うMSSP / MDR
• SIGMAでルールを定義することにより、プラットフォーム間をより簡単に移動することができます。
• 攻撃的セキュリティ領域での研究者が、彼らの研究に基づいて検出を作成したい

注意: このブログでは、SIEMがログを収集および検索するために使用されるプラットフォームをすべて指すために使用されています。掲載されている多くのプラットフォームがあなたの「SIEM」の定義に合わないかもしれないことを理解しています。しかし、「プラットフォーム」や「ログプラットフォーム」という用語を使うのはあまりにも曖昧です。

「Sigmaルールは、意思決定と問題解決を向上させるための重要な原則です。データの変動を把握し、強力なプロセスを確立することの重要性を示しています。これらのガイドラインに従うことで、チームは変化に対応できる効果的で柔軟な戦略を開発することができます。」

Ruslan MikhalovSOC Primeの脅威研究責任者フォローする

SIGMAルールの作成

SIGMAルールを書くには、SIGMAのスキーマとタクソノミーに関する基本的な知識を持ち、アイデアを持ち、それをSIGMAに適合させ、テストし、共有し、ルールを維持する可能性があります。

推奨される背景とコンテキスト

このブログの長さにもかかわらず、YAMLと作成者の先見性のおかげで、SIGMAは理解しやすく書きやすいです。SOC Primeでは、「誰でもSIGMAを学べる」と言っています。検出エンジニアリングの技術がもっと複雑になるところです。

他にも多くのリソースがあります。 公式wiki および以下にリストされたSIGMAの専門家が書いたガイドいくつか。適切なワイルドカードの処理 などの特定の罠があります。 or 誤ったフィールド名 が原因で壊れたルールを引き起こす可能性があり、これらの多くはこれらのリソースで対処されています。

SIGMAに関わりたい研究者の場合、SOC PrimeのThreat Bounty Programは始めてお金を稼ぐ素晴らしい機会です。提出されたルールは詳細なレビューを受け、私たちはあなたをガイドし、ミスを理解し、アナリストとして成長するのを助けます。

お勧めのリーディング：

• SIGMAルールの書き方、Florian Roth 2018
• 一般的なログソースのガイド、Thomas Patzke 2019

推奨される観覧：

• 全てがSIGMA – Adam Swan
  
  
  

SIGMAルールが表現できる検出の種類

今日存在する基本的なルールのタイプは2つです：

• 一般的にサポートされているマッチングに基づいたSIGMAルール、書くのが最も簡単
• マッチングと単純な相関に基づいたSIGMAルール、サポートが限られ、書くのがやや難しい

注意: マルチyaml SIGMAルールも存在しますが、特定のログソースに対するルールが一般的です。SOC Prime Teamは、マルチyamlルールを作成しない理由は、ルールのメンテナンスとデプロイメントに不要な複雑さをもたらすからです。2つのSIGMAルールを作成できる人は、マルチyaml SIGMAルールを作成することができます。

シンプルなSIGMAルールを作成しましょう！

アイデア（SIGMAを使用した検出エンジニアリングに関するいくつかの考え）

ユーザーや管理者は、プレーンテキスト文書（テキストファイル、Excel、Wordなど）に機密のパスワードを保存することがあります。そのため敵がこれらのファイルを見つける前に、適切なパスワード保存方法をユーザーに教えたいと考えています。

多くのSIGMAルールでは、著者がアイデアを抽象化し、ターゲットを「適切に」広げることが利益になります。例えば、このようなアイデアでは、プレーンテキストでのパスワード保存にユーザーが使用する可能性がある追加の条件や拡張子に関して、推測を行うことができます。 may 行動を単に観察しただけでなく、似た行動を持つと推測できます。たとえば、ユーザーがプレーンテキストでパスワードを保存するために使用する可能性がある追加の用語や拡張子に関して推測を行うことができます。

ルールを「広げる」というアイデアは、多くのアナリストの直感に反しています。ルールが未知または不慣れな環境で消費されるとき、すべての「偽陽性」を排除することは必ずしも元の著者の目標ではありません。EDRやアンチウイルスのベンダーが偽陽性を持たない検出を作成することを心配させることができます。SIGMAルールは環境でテストされ、簡単に調整できます。

SIGMAは簡単に理解でき、テスト可能で調整可能です。環境で特定の用語（「詳細」など）がノイズが多すぎる場合、ルールを実装する人はルールを調整することに自信を持つべきです。テストせずにルールを一度にすべてデプロイすることは、破滅のレシピです。それらの意図を環境に合わせて消化し調整するのではなくルールをオフにすることは、堅実な検出コンテンツを失わせる原因になります。

私はpsexecの例を挙げるのが好きです。一部の環境では、psexecは管理用のリモートホストのデフォルトであり、完全に普通です。その他の環境では、psexecは（おそらく当然）承認されておらず、ブロックされ、管理者が使用することは行動を起こす暴力行為です。だから、psexecの使用を検出するためのSIGMAルールは「ノイズが多い」のでしょうか、それとも他の環境では優れたものなのでしょうか。何もないとした場合、テストせずにコンテンツをデプロイし、ノイズの調整は常に問題となります。「重要」と認識されたルールだけが、テストなしでも安全に使用できるものとされています。

パスワード漏洩のSIGMAルール作成に戻りましょう。「名前が追加されるファイル名を含めてアイデアを拡大しましょう：

• pw
• psw
• pass
• password
• passwords
• accounts
• account
• info

以下のようなソフトウェアを使用して作成：

• メモ帳
• Notepad++
• Wordpad
• Officeアプリケーション
  
  
  

データソース/ログソース

アイデアができたら、ログソースが必要です。SIGMAは理論的に any ログソースに対応していますが、みなさんが持っているログソースを特定する必要があります。例えば、データ漏洩防止ログソースのルールを書くことができるかもしれませんが、データ漏洩防止はSIEMsに解析されて摂取されることはまれであり、業界には明確なお気に入りはありません。したがって、有効なルールを作成できますが、容易に採用されることはありません。

Windowsのエンドポイントルールの場合、Sysmonが素晴らしい出発点です。Sysmonは多くの環境で常用され、多くのログソースが同義のデータを提供します（EDRsなど）。Sysmonでは、プロセスの作成（SIGMAではprocess_creation）とファイルの作成（SIGMAではfile_event）という2つの主要なオプションがあります。

プロセス作成に基づいた検出を構築するので、より広く採用されています。これにより、ルールが可能な限り有用になることが保証されます。プロセス作成は学ぶための素晴らしいログソースであり、それはエンドポイント検出で使用される最も有用な/人気のあるログソースの1つです。

注意: しばしばアイデアはデータソース自体から直接来ます。あなたのSIEM/ラボで利用可能なデータの種類を確認することで、書く価値のあるSIGMAルールを簡単に特定できます。他のソース（例えばベンダーのドキュメント）を使用することもできます。

sysmonプロセス作成イベント（イベントID 1）では、パスワードを含むファイルにユーザーがアクセスすると次のような興味深いフィールドが含まれている可能性があります：

Image: C:\Windows\System32\notepad.exe
CommandLine: “C:\Windows\System32\NOTEPAD.EXE” C:\Users\John\Desktop\password.txt

検出アイデアをSIGMAに適合させる

アイデアと作業するためのデータソースが整ったので、ルールの構築を開始できます。

これが文書化されていないですが、本当に最小限の コンポーネント ルールを翻訳するために必要なものは logsource と detection （Splunkのような一部のバックエンドでは、detectionだけで十分）。残りはすべて、SIGMAルールの消費者を助けるための「ただ」のメタデータです。開始する際には、最小限のフィールドから始め、ロジックが機能していることを確認し、次に追加のSIGMAフィールドとデータを追加するのが簡単です。自分のルールをパブリックSIGMAリポジトリに公開したい場合、以前の提出物を確認し、それらのフォーマットを模倣する価値があります。

潜在的なパスワード漏洩に対する基本的なSIGMAルール：

title: Potential Password Exposure (via cmdline)
author: Adam Swan
tags:
  - attack.t1552.001 
  - attack.credential_access
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    Image|endswith: 
      - '\notepad.exe'
      - '\word.exe'
      - '\excel.exe'
      - '\wordpad.exe'
      - '\notepad++.exe'
    CommandLine|contains:
      - 'pass' #pass will match on password, including password is redundant
      - 'pwd'
      - 'pw.' #pw.txt, etc. 
      - 'account' #accounts, 
      - 'secret'
      - 'details' #I included plural details based on experience
  condition: selection

Logsourceコンポーネント

The logsource コンポーネントは、SIGMAバックエンドのトランスレータ（SIGMAC）が、ルールを実行するデータの種類を知るのに役立ちます。これにより、ルール作成者は、より一般的なルールを作成できるようになります。例えば、 logsource が「product: windows, category: process_creation」である場合、具体的なイベントIDを指定する必要はありません（Sysmon 1、Windows 4688、ProcessRollupなど）。ルールの消費者は、SIGMAの設定でログソースに関連付けたいイベントID、インデックスなどを指定できます。インデックスやイベントIDなどを指定しない場合、ルールは消費者にとっては不必要に高価（性能上）になる可能性があります。

また、しばしばテレメトリは似たフィールドを含むことがありますが、まったく異なる行動を暗示します。例えば、Sysmonのネットワーク接続イベント（イベントID 3）とプロセス作成（イベントID 1）はともに Image フィールドを共有します。Sysmonのネットワーク接続イベントの Image フィールドにexplorer.exeが存在することは、プロセス作成イベントにexplorer.exeが存在することとは完全に異なります。適切なlogsourceコンポーネントを提供することで、検出に貴重なコンテキストを提供します。

Detectionコンポーネント

detectionコンポーネントは、作成者が検出基準を定義する場所です。これには最低1つの selectionコンポーネント と conditionコンポーネントが含まれます。オプションの timeframeコンポーネント があり、相関ベースのルールに必須とされています。

Selectionサブコンポーネント：

• 通常、これはフィールドA 値Bの形をとります。当然、上記のルールの例で見られるように、作成者が必要とする場合は 値Bの形をとります。当然、上記のルールの例で見られるように、作成者が必要とする場合は 値X、Y、Zのようなロジックを拡張して含めることができます。このロジックは常にケースインセンシティブです。 値Bの形をとります。当然、上記のルールの例で見られるように、作成者が必要とする場合は 値Bの形をとります。当然、上記のルールの例で見られるように、作成者が必要とする場合は Values X, Y, or Z. This logic is always case insensitive. 
  
  
• より高度な「モディファイア」があり、ルールの複雑さを増したり、作成者がより正確になるのを可能にします。例えば、正規表現は演算子によって扱われ、作成者が大文字小文字を区別するクエリを書くことを可能にします。互換性を維持するためには、基本的な正規表現演算子 re を使用するのが最善です。 “ ? + * | { } [ ] () “ 。 選択は名前が付けられます（例: 選択、選択2、選択3、フィルタ）。選択には、ほとんど好きな名前を付けることができます。しばしば
  
  
• 選択 の変形が使用されますが、同様に バナナ と名付けても、ルールは動作します。一般に、フィルタ は除外されるセレクションに使用されます（例： 選択 AND NOT フィルタ 条件サブコンポーネント： 条件コンポーネントには、各選択を最終クエリにどのように含めるかを定義するブール論理（AND、OR、NOT）が含まれています。).
  

例: (

• selection_a OR selection_b) AND NOT filter
  
  
• 相関を含む条件コンポーネントselection_a OR selection_b) AND NOT filter

今日、バックエンドによってサポートされている相関の種類は二つあります。他の相関もSIGMAスキームによってサポートされていますが、まだ利用可能なバックエンドではサポートされていません。: 

Count() by Y:

一意のYフィールド値のインスタンスを数え、静的な数値とその比較（大きい、少ない）を行います。
例：
Count() by src_ip > 2 Count(X) by Y:
1つのY値ごとにXフィールド値の一意のインスタンスをカウントし、Xのカウントを静的な数値と比較（大きい、少ない）します。
例: Count(EventID) by src_ip > 2
Count() by src_ip > 2 共通の相関の使用例：

タイムフレームサブコンポーネント：

タイムフレーム

• The コンポーネントは、相関を含む条件との組み合わせで使用されます。多くのバックエンドはタイムフレームを無視しますが、SOC Primeを含むほとんどのリポジトリでは、一般的に常に含まれており、必ず含める必要があります。 Splunkを使用した完全な例：

ここにSIGMAの例とそのSplunkに対する翻訳があります。Splunkに精通していない場合、アスタリスクはワイルドカードで、アスタリスクで囲まれた用語（例：*term*）は「含む」、先頭にアスタリスクがある用語（例：*term）は「末尾一致」、アスタリスクが続く用語は「末尾一致」（例：term*）です。

• 分類の質問（例えばどのフィールド名を使用するか）

理論上、どんなフィールド名でも使用できますが、誰かがあなたのフィールドから彼らのフィールドに翻訳するためにSIGMAコンフィグを書く時間をかける意志がある限り。

フィールド名は大文字小文字を区別します！

注意: は、異なる値です。 は、異なる値です。 and は、異なる値です。 は既存の分類の一部であり、 は、異なる値です。 はそうではありません。 は、異なる値です。 ということを念頭に置き、SIGMAによって文書化されたフィールド名を使用するのが最善です。パブリックSIGMAリポジトリが分類を文書化する3つの場所があります。

一般的なルールとして、カテゴリ用にwikiで指定されたSIGMAフィールド名を使用します：

wikiは読者にSIGMAが使用するフィールドを公開します

• wikiは読者にSIGMAが使用するフィールドを公開します
• — エンドポイントルールのSYSMONフィールド
  — ウェブサーバー＆プロキシルール用のW3C拡張ログファイルフォーマット
  — ファイアウォール、アンチウィルス用のフィールド
  続いて、既存のルール＆SIGMAコンフィグファイルで指定されたSIGMAフィールド名

本当のフィールドに関する公式のドキュメント。ユーザーは、ルールを翻訳する際に必要に応じてこれを作成/修正できます。

• 本当のフィールドに関する公式のドキュメント。ユーザーは、ルールを翻訳する際に必要に応じてこれを作成/修正できます。
  • 最後に、設定やルールがない場合は、元のログソースのオリジナルのフィールド名を使用します。フィールド名がネストされた値から来ている場合（例：
  • 最後に、設定やルールがない場合は、元のログソースのオリジナルのフィールド名を使用します。フィールド名がネストされた値から来ている場合（例：
    
    

が が にネストされている場合 accountId AWSのCloudTrailでは、フィールドがネストされていることを示すために期間が使用されます。これは異なるSIEM全体で比較的一貫しています（例： が -> accountId が userIdentity.accountId).

テストSIGMAルール

SIGMAルールをテストするのは簡単です。多くの人々は、直接テストせずにコンテンツを提出することさえできることがあります。多くの公的な研究者は、「すべてのSIEMに対するセット」へのルールをテストする多様な環境へのアクセスを持っていません。その代わりに、公的なフィードバック、信頼できるパーティーからのフィードバックなどに頼ることができます。SIGMAの共同発明者Florian Rothでさえ、彼のTwitterを介してフィードバックのために定期的にルールを公開しています。自分のブログやLinkedInに直接公開する人さえ見てきました。あなたが共有するいいルールがあると思ったら、それを出してみてください。信じてください、間違っている（または違う）場合、インターネット上の素晴らしい人々があなたに教えてくれます！深刻に考えすぎずに、変更を受け入れ、何かを学ぶ準備をしてください。

いくつかの基本的な手順があります：

1. ルールが翻訳されることを確認する（uncoderまたはSIGMACを使用）
2. 健全性チェック（例：ルールが元の期待を満たしていることを確認する、正しい分類に従っていることなど） – 落とし穴参照： https://github.com/SigmaHQ/sigma/wiki/Rule-Creation-Guide
3. ラボ環境でのルールの確認
4. SOC Prime Teamを介してTreat Bounty Programを通じてルールを共有/広くテストのためにルールを共有する

注意: ルール作成者の視点からは、通常、ルールのバックエンド実装について心配する必要はありません。翻訳が有効なルールの元の意図に合致していることを確保するのは、SIGMAバックエンドの作成者やSOC Primeのような人々の責任です。バグが識別された場合、GitHubに問題を提出する価値があります。

SOC Primeについて

業界のベテラン

• 2015年にDetection-as-Code業界を創設
• フォーチュン100とグローバルMDRと提携

SOCオペレーションのためのAIインターフェース

• 検出からシミュレーションまでの全パイプラインをカバー
• フィルタの代わりにマジック脅威サーチ

世界で最も大きな検出インテリジェンスデータセット

• 65万以上の検出ルール
• 毎日の新しい脅威

コアリアルタイムパイプラインで100GB/日

• ラインスピードETL検出
• シフトレフト検出、正しく行われた

世界最大の検出ルールデータセットにアクセス

無料登録

Adam SwanSOC Primeのシニア脅威ハンティングエンジニアフォローする

脅威と検出を研究して、それらをエンジニアに説明します。