What Are SIGMA Rules: Beginner’s Guide
目次：
このブログ記事では、SIGMAを検出言語として主張し、最も重要なSIGMAルールの要素（logsourceと検出）、SIGMA分類法、SIGMAルールのテストを取り上げており、SIGMA初心者のアナリストが最初のルールを書くために準備しています。ノイズ、アイデア、ログソースなどに関するSIGMAを使用した検出エンジニアリングに関する簡単な議論も提供されています。
SIGMAルールの重要性
過去には、SIEMの検出はベンダーやプラットフォーム固有のサイロで存在していました。検出コンテンツを共有したいパートナーは、多くの場合、一つのベンダーから別のベンダーへとクエリを翻訳する必要がありました。これは持続的ではなく、防御サイバーセキュリティコミュニティは、進化する対戦相手に対応するため、検出を共有する方法を改善する必要があります。
YARAやSnortルールと同様に、SIGMAは検出のオープンな共有のための別のツールであり、ファイルやネットワークトラフィックではなくSIEMに焦点を当てています。 SIGMAは、防御者が共通の言語で検出（アラート、ユースケース）を共有することを可能にします。
2017年にFlorian RothとThomas Patzkeによって最初にリリースされたSIGMAは、プラットフォームに依存しない検索を進めています。SIGMAを使用すると、防御者はベンダーやプラットフォーム固有の検出言語やリポジトリから解放され、コミュニティの力を活用して重大な脅威や新しい対戦相手の戦術に速やかに対応できます。
SIGMAを使用する理由はたくさんあります：
- 新しい対戦相手の行動を特定し、検出を共有するためのプラットフォームに依存しない方法を望む研究者やインテリジェンスチーム
- 複数のSIEM / EDR / ログ分析ソリューションおよびデータ分類/スキーマ（ECS, CEF, CIMなど）を担当するMSSP / MDR
- SIGMAでルールを定義することにより、プラットフォーム間をより簡単に移動することでベンダーロックインを回避します。
- 研究に基づいて検出を作成したいオフェンシブセキュリティの研究者
注意： このブログでは、SIEMをログを収集し検索するために使用するプラットフォームとして表現しています。一部のプラットフォームがあなたの「SIEM」の定義に合わない場合がありますが、「プラットフォーム」や「ログプラットフォーム」という用語はあまりにも曖昧です。
SIGMAルールの作成
SIGMAルールを書くには、SIGMAのスキーマと分類法に関する基本知識を持ち、そのアイデアをSIGMAに適合させ、テストし、共有し、場合によってはルールを維持する必要があります。
このブログの長さにもかかわらず、YAMLとクリエイターの先見によって、SIGMAは理解しやすく書きやすいです。SOC Primeでは、「誰でもSIGMAを学べる」と言います。ここで検出エンジニアリングの技術が複雑になることがあります。
Despite the length of this blog, thanks to YAML and forward thinking by the creators, SIGMA is easy to understand and write. At SOC Prime we like to say “anyone can learn SIGMA”. The art of detection engineering is where things can get more complicated.
他にも多くのリソースがあります 公式ウィキ や以下に挙げるSIGMAの専門家によって書かれたガイドがあります。トラップもあります。 ワイルドカードの適切な扱い or 誤ったフィールド名 が壊れたルールを引き起こす可能性があり、これらの多くはこれらのリソースで対処されています。
SIGMAに参入したい研究者の場合、SOC PrimeのThreat Bounty Programは始めて現金を稼ぐための素晴らしい機会です。提出されたルールは徹底的なレビュー過程を経て、私たちがガイドし、誤りを理解し、アナリストとして成長する手助けができます。
おすすめの読み物：
- SIGMAルールの書き方、Florian Roth著 2018
- 汎用ログソースのガイド、Thomas Patzke著 2019
おすすめの視聴：
SIGMAルールが表現できる検出の種類
現在、基本的なルールの種類は2つあります：
- 一致に基づくSIGMAルール、広くサポートされ、書きやすい
- 一致と単純な相関に基づくSIGMAルール、サポートが限られ、書きにくい
注意： また、マルチYAMLのSIGMAルールもありますが、一般的にはログソース特定のルールに代わって使用されることが少なくなっています。SOC Primeのチームは一般的にマルチYAMLルールを作成しません。これは、ルールの保守と展開に不必要な複雑さを加えるからです。二つの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
- Notepad++
- Wordpad
- オフィスアプリケーション
データソース / ログソース
アイデアを持ったら、ログソースが必要です。SIGMAは理論的にログソースをサポートしていますが、ほとんどの人が持っているログソースを特定する必要があります。例えば、データ損失防止のログソース用にルールを書くことができるかもしれませんが、データ損失防止はSIEMにパースされて取り込まれることはまれで、業界には明確な好みがありません。したがって、有効なルールを作成することはできますが、容易に採用されることはありません。 any log source theoretically, however we should identify a log source that most folks have. For instance, we might be able to write a rule for a Data Loss Prevention log source but Data Loss Prevention is rarely parsed and ingested into SIEMs, and the industry hasn’t a clear favorite. So, we can create a valid rule, but it will not be as easily adopted.
Windowsエンドポイントルールの場合、Sysmonは素晴らしい出発点です。Sysmonは多くの環境に展開されており、多くのログソースが類似のデータを提供します（EDRs など）。Sysmonには、プロセスの作成（SIGMAでのprocess_creation）やファイル作成（SIGMAでのfile_event）の2つの主なオプションがあります。
プロセス作成をベースに検出を構築することで、より広く採用されているため、ルールが可能な限り有用になることを保証します。プロセス作成は学ぶのに良いログソースであり、エンドポイント検出に使用される最も有用かつ人気のあるログソースの1つです。
注意： アイデアはしばしばデータソース自体から直接来ます。利用可能なデータの種類をSIEM / ラボでレビューすることで、書く価値のあるSIGMAルールを簡単に特定できます。他のソースとしてベンダーのドキュメントを使用することもできます。
sysmonプロセス作成イベント（イベントID 1）で、ファイルにパスワードを含むユーザーが次の興味深いフィールドを含むことがあります：
画像: C:WindowsSystem32notepad.exe
CommandLine: “C:WindowsSystem32NOTEPAD.EXE” C:UsersJohnDesktoppassword.txt
検出のアイデアをSIGMAに適合させる
アイデアがあり、作業するデータソースがあるので、ルールを構築し始めます。
これは文書化されていませんが、真の最小 コンポーネント ルールを翻訳するために必要なのは、わずかに logsource と 検出 だけです（一部のバックエンドでは、検出だけで十分です）。他のすべてはSIGMAルールの消費者を助けるための「メタデータ」にすぎません。最初はこれらの最小のフィールドから始め、論理が機能していることを確認し、追加のSIGMAフィールドとデータを追加することがあなたの利益です。公開SIGMAレポにルールを公開したい場合、以前の提出をチェックしてそのフォーマットを真似る価値があります。
潜在的なパスワード露出の基本的なSIGMAルール（最小コンポーネント）:
タイトル: cmdlineによる潜在的なパスワードの露出
作成者: Adam Swan
タグ:
- attack.t1552.001
- attack.credential_access
logsource:
product: windows
category: process_creation
検出:
selection:
Image|endswith:
- 'notepad.exe'
- 'word.exe'
- 'excel.exe'
- 'wordpad.exe'
- 'notepad++.exe'
CommandLine|contains:
- 'pass' #pass は password に一致します。password を含めるのは冗長です
- 'pwd'
- 'pw.' #pw.txt など
- 'account' #accounts など
- 'secret'
- 'details' #経験に基づいて複数形の details を含めました
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 の存在とは完全に異なります。適切なログソースコンポーネントを提供することで、検出に価値あるコンテキストを提供します。
検出コンポーネント
検出コンポーネントは、著者が検出基準を定義する場所です。これは少なくとも1つの 選択コンポーネント と1つの 条件コンポーネントが含まれます。オプションの タイムフレームコンポーネント は、相関ベースのルールに必要です。
選択サブコンポーネント：
一般的に、これは次の形式をとります フィールドA が含む/で始まる/で終わる/等しい 値Bもちろん、上記の例のルールのように、著者が必要とする場合は、 フィールドA が含む/で始まる/で終わる/等しい 値X, Y, またはZ. のように、論理を拡張して含めることができます。このロジックは常に大文字小文字を区別しません。
ルールの複雑さを増したり、著者がより正確にするためのより高度な「修飾子」もあります。例えば、正式な表現を扱うためにオペレーター re を使用すると、著者は大文字小文字を区別したクエリを書くことができます。互換性のためには、基本的な正式な表現のオペレーターのみを使用するのが最善です . ? + * | { } [ ] () “
選択は名前付きです（例、selection, selection2, selection3, filter）。選択は（ほぼ）何でも名前付け可能です。多くの場合 selection の変形が使用されますが、 banana と命名してもルールは機能します。一般的に filter は除外される選択に使用されます（例： selection AND NOT filter).
条件サブコンポーネント：
条件コンポーネントは、最終クエリに各選択をどのように含めるかを定義するブールロジック（AND, OR, NOT）を含みます。
例：（selection_a OR selection_b) AND NOT filter
条件コンポーネントと相関：：
バックエンドが今日サポートしている相関の種類は2つあります。SIGMAスキーマによっては他の相関もサポートされているが、利用可能なバックエンドではまだサポートされていません。
カウント() by Y：
Yフィールド値のユニークインスタンスの数をカウントし、固定値と比較します（大、少）。
例： カウント() by src_ip > 2
カウント(X) by Y：
Y値ごとにXフィールド値のユニークインスタンスの数をカウントし、Xの数を固定値と比較します（大、小）。
例： カウント(EventID) by src_ip > 2
一般的な相関の使用例：
Count() by src_ip > 10 | Count unique matching events by the source IP. |
Count() by dst_ip > 10 | Count unique matching events by the destination IP |
Count(EventID) by ComputerName | This will let you search for unique instances of eventid. For instance, if you want to chain sysmon event ids 1 (process creation) AND event id 5. e.g. a process is created and terminated in less than 1 min. |
タイムフレームサブコンポーネント：
The タイムフレーム コンポーネントは、相関を含む条件と一緒に使用されます。多くのバックエンドはタイムフレームを無視しますが、通常は常に含まれ、SOC Primeなどほとんどのリポジトリに含まれることが求められます。
Splunkを使用した完全な例：
ここに、Splunk用に翻訳されたSIGMAのいくつかの例があります。Splunkに詳しくない場合、アスタリスクはワイルドカードですので、アスタリスクで囲まれた用語（例：*term*）は「含む」、アスタリスクが先頭についている用語（例：*term）は「で始まる」、アスタリスクが末尾についている用語は「で終わる」です（例：term*）。
SIGMA detection component | Splunk Translation (Asterisk is a wildcard) |
detection: selection: fieldX: 'suspicious' condition: selection | fieldX="suspicious" |
detection: selection: fieldY|contains: - 'suspicious' - 'malicious' - 'pernicious' condition: selection | (fieldY="*suspicious*" OR fieldY="*malicious*" OR fieldY="*pernicious*") |
detection: selection: - fieldX: 'icious' - fieldX: - 'susp' - 'mal' - 'pern' condition: selection | (FieldX="icious" AND (FieldX="susp" OR FieldX="mal" OR FieldX="pern")) |
detection: selection: - FieldX|endswith: 'icious' - FieldX|startswith: - 'susp' - 'mal' - 'pern' condition: selection | (FieldX="*icious" AND (FieldX="susp*" OR FieldX="mal*" OR FieldX="pern*")) |
detection: selection: FieldX|endswith: 'icious' filter: FieldX|startswith: - 'del' - 'ausp' condition: selection AND NOT filter | (FieldX="*icious" AND NOT ((FieldX="del*" OR FieldX="ausp*"))) |
detection: selection: FieldX: 'suspicious' timeframe: 1m condition: selection | count by src_ip > 3 | FieldX="suspicious" | eventstats count as val by src_ip| search val > 3 #notice splunk ignores the timeframe value, the value must be set at search by the user |
detection: selection: FieldX: 'suspicious' condition: selection | count(ComputerName) by src_ip > 3 | FieldX="suspicious" | eventstats dc(ComputerName) as val by src_ip | search val > 3 |
分類法の質問（例：使用するフィールド名）
理論的には、使用したいフィールド名を何でも使用できます、採用するフィールドを自分のフィールドに翻訳するSIGMA構成を書くための時間を惜しまない限り。
注意： フィールド名は大文字小文字を区別します！ CommandLine and commandline は別の値です。 CommandLine は既存の分類法の一部で、 commandline はそうではありません。
とは言え、ドキュメントで記載されたSIGMAのフィールド名を使用するのが最善です。公開SIGMAリポジトリが分類法を文書化しているのは3か所あります。
- 一般規則として、ウィキに記載されたカテゴリのSIGMAフィールド名を使用しています
- https://github.com/SigmaHQ/sigma/wiki/Taxonomy
- ウィキは、SIGMAが
- エンドポイントルールにSYSMONフィールドを使用することを読者に明らかにします
- ウェブサーバーおよびプロキシルールのためのW3C拡張ログファイルフォーマット
- ファイアウォール、アンチウイルス用フィールド
- 次に既存のルールとSIGMA構成ファイルに指定されたSIGMAフィールド名に従います
- https://github.com/SigmaHQ/sigma/tree/master/tools/config
- 実際にはフィールドの公式ドキュメントです。ルールを翻訳する際に必要に応じてユーザーがこれを作成/修正できます。
- https://github.com/SigmaHQ/sigma/tree/master/rules
- https://github.com/SigmaHQ/sigma/tree/master/tools/config
最終的に構成やルールが存在しない場合、元のログソースから元のフィールド名を使用します。フィールド名がネストされた値から来ている場合（例： userIdentity が accountId にネストされているaws cloudtrailで）ネストされていることを示すためにピリオドを使用します。これは異なるSIEM全体で比較的一貫しています（例： userIdentity -> accountId は userIdentity.accountId).
になります
SIGMAルールのテストは簡単です。多くの人は、直接テストすることなくコンテンツを提出することさえ可能です。ほとんどの公的な研究者は、’すべてのSIEM’に対するルールをテストするための多様な環境を直接持っているわけではありません。その代わりに、公のフィードバック、信頼できるパーティからのフィードバックなどを頼りにすることができます。SIGMAの共同作成者であるFlorian Rothでさえ、Twitterで公のフィードバックを得るために定期的にルールを公開しています。個人のブログやLinkedInで直接公開する人もいます。良いルールを共有したいと思うなら、そこに出してください。間違っているか（または違うか）について、インターネットの親切な人々が教えてくれるでしょう！あまり真剣に考え込まず、変更の準備をし、何かを学ぶ準備をしてください。
いくつか基本的なステップがあります：
- ルールが翻訳されることを確認する（uncoderまたはSIGMACを使用して）
- 妥当性チェック（例：ルールが元々の期待を満たしていることを確認する、正しい分類法に従っていることを確認するなど） – 落とし穴を参照： https://github.com/SigmaHQ/sigma/wiki/Rule-Creation-Guide
- ラボ環境でのルールのチェック
- SOC Primeチームを通じてTreat Bounty Programでルールを広くテスト/共有する
注意： ルール作成者の視点からは、一般的にルールのバックエンド実装について心配する必要はありません。ルールの翻訳が元の意図を満たすことを保証するのはSIGMAのバックエンド作成者やSOC Primeのような人々に任されています。バグが見つかった場合は、GitHubにイシューを提出する価値があります。
行動の呼びかけと将来の作業
ここまで読んだなら、あなたは最初のルールを書く準備が十分にできています！このブログが気に入ったなら、SIGMACを使用してコンテンツをカスタマイズすることについてのブログがもうすぐ登場するかもしれません。
