シグマのルールについて知りたいことすべて。パート3

この記事は、シグマルールの構文に関する一連の資料（第1部、第2部）の完成です。先ほど、単純なSigmaルールの例を見て、ルールの最も重要な部分（イベントソースを説明するセクションと検出ロジックを説明するセクション）について詳しく説明しました。これで、複雑なシグマルールを作成および解析するときに必要になる可能性のあるほとんどすべての知識が得られました。メタ情報を含む属性を検討し、ルールのコレクションとは何か、およびそれらをどのように操作するかを理解する必要があります。サイクルの最後の部分は、これらの質問に専念しています。

メタ情報を持つ属性

タイトル（タイトル属性）

タイトルは、ルールの本質を簡単に説明しています。このテキストフィールドの長さは最大256文字です。ここでは、最短で最も容量の大きい説明を入力する必要があります。次のガイドラインに従ってください。

• 「Detects ...」のような構成要素を見出しとして使用しないでください。そしてこれがなければ、ルールが何かを検出することは明らかです。
• 50文字以内の容量のあるタイトルを使用してください。
• 説明フィールドに説明と重要なコメントを記入します（さらに検討します）。

ルールの詳細な説明と追加の説明（説明属性）

タイトルにその目的の一般的な理解のためにルールの簡単な説明が含まれている場合、説明フィールドで、作成者がこのルールに入れるすべてのニュアンスと機能を指定できます。また、このルールを使用して検出することが提案されている攻撃についても簡単に説明します。このフィールドの最大長は65,535文字です。

ルールの一意の識別子と関連するルールの識別子（id、relative）

タイトル属性と説明属性の特定の値は任意である可能性があり、2つの異なるルールの場合も同じであるため（これは絶対に行わないでください）、ルールを一意に識別するのには適していません。より正式で一意の識別子が必要です。この問題を解決するために、ほとんどの製品でユニバーサル一意識別子（UUID）が使用されています。 Sigmaの作成者は、ルール開発者に同じパスに従うようにアドバイスしていますが、プライベートルールには任意の識別子生成スキームを使用できます。パブリックリポジトリでは、前述のUUIDが識別子を作成するためのスキームとして選択されています。記事の最初の部分のルール例でも同じアプローチに従いました。将来的にルールを公開したり、公式リポジトリに追加するリクエストを送信したりする場合は、次に、ルール識別子を作成するために同じスキームに従うことをお勧めします。



一意の識別子はさまざまな方法で生成できます。Windowsでは、次のPowerShellコードを実行するのが最も簡単な方法です。

PS C:\> "id: $(New-Guid)"                               
id: b2ddd389-f676-4ac4-845a-e00781a48e5f

Linuxカーネルベースのオペレーティングシステムでは、uuidgenユーティリティを使用できます。

$ echo “id: `uuidgen`”
id: b2ddd389-f676-4ac4-845a-e00781a48e5f

ルールに大幅な変更を加える場合は、その識別子を変更する必要があります。新しい識別子を作成する状況：

• ルールのロジックを変更する。
• 元のルールを保持しながら既存のルールからルールを継承する（ルールの改善の状況にも当てはまります）。
• ルールのマージ。

ルールの継承とマージの場合、タイプの4つの可能な値（type属性）に関連する特別な識別子があります。



関連する識別子を使用すると便利な場合があると思われる状況を考えてみましょう。わかりやすくするために、UUID形式の長い識別子の代わりに、単にX、Y、Zと記述します。



最初のケースでは、新しいルール（id：X）は既存のルール（id：Y）から派生します。これは、新しいルールで作業のロジックを改善した場合に発生する可能性がありますが、何らかの理由で古いルールを維持したいと考えています。したがって、ルールには保存され、将来使用できる親ルールがあります。







2番目のケースは、1つの事実を除いて、最初のケースと同様です。古いルールは保持されません。つまり、ルールを根本的に書き直し、新しい識別子を割り当てる必要があり、古い識別子は廃止され（廃止され）、使用されなくなります。そのため、書き直したルール（id：Y）があり、もう必要ないと判断しました。新しいルールは識別子（id：X）を受け取りました。シグマルールでは、同様の状況は次のようになります。







3番目のケースでは、2つ以上の既存のルールをマージした結果として新しいルールが表示された状況を考えてみます。新しいルール（id：X）は、2つのルール（id：Y、Z）をマージした結果です。マージに関係した両方の親ルールが保持され、さらに使用できることに注意することが重要です。シグマルールでは、同様の状況が







次のようになります。マージ中にルールの順序は定義されませんが、コメントではわかりやすくするために番号を付けています。



4番目のタイプは名前変更です。名前が示すように、識別子間のこのタイプの関連付けは、古いルールの名前を変更するときに適用されます。実際、このタイプは実際には使用されていません。使用例として、著者は識別子を作成するためのスキームを変更するケースを引用しています（UUIDが唯一の可能な命名スキームではないことに注意してください）。

ルール準備完了ステータス（ステータス属性）

仕様によれば、ルールは次の3つの状態のいずれかになります。

• 安定-ルールを実際のインフラストラクチャで使用して攻撃を検出できます。変更は必要ありません。
• テスト-ルールはほぼ安定していますが、少し調整が必要です。
• 実験的-このようなルールは多数の誤検知を生成する可能性がありますが、同時に興味深いイベントを明らかにします。

通常、実際のインフラストラクチャでルールを実行する前は、エラーが発生する頻度が正確にわからないため、ルールには実験的なステータスがあります。さらに、数か月のテストの後、ルールが適切に記述されていてエラーが生成されない場合（またはエラーが無視できる場合）、安定したカテゴリに転送されます。それ以外の場合は、修正が行われ、再度チェックされます。公式のSigmaリポジトリにはテストステータスのルールはありません。

ルールが配布されるライセンス（ライセンス属性）

ルールが配布されるライセンス。この分野はフリーソフトウェアの世界から来ました。指定されることはめったにありませんが、指定する場合は、SPDXID仕様に準拠している必要があります。

ルール作成者（作成者属性）

このフィールドには、ルールのすべての作成者が一覧表示されます。ルール自体を書いた人だけでなく、検出の元のアイデアの作者も示すことは良い形であると考えられています。

ルールの作成に役立った研究へのリンク（参照属性）

シグマルールを作成するときは、ルールの作成を支援または刺激した元の記事、ツイート、および調査へのリンクを含めるのが通例です。他の誰かの仕事への敬意を表すことに加えて、そのようなリンクは後でルールがどのように機能するかを理解するのに役立ちます。

ルールがトリガーされたときに表示する分析に役立つイベントフィールド（フィールド属性）

ルールの作成者は、攻撃アルゴリズムとその実行中に生成されるイベントを深く理解しているため、SOCオペレーターまたは情報セキュリティチームの別の従業員がインシデントを理解するのに役立つフィールドのリストをイベントから選択できます。

ルールの誤検知のケース（属性誤検知）

誤検知フィールドは、検出ルールではかなり珍しいものです。イベント検証の過程にはまったく影響しませんが、2つの便利なことを行います。

• 特定のルールトリガーがエラーであるかどうかをユーザーが判断できるようにします。
• ルールの開発者に、ルールが誤ってトリガーされる可能性があることをもう一度思い出させてください。このような考えは、開発者がより正確なルールを作成するのに役立ちます。

さまざまなタグとタグ（タグ属性）

通常、このフィールドはMITRE ATT＆CKおよびCARタグに使用されます。このようなマークアップにより、Sigmaルールを他の情報セキュリティプロジェクトと統合できるため、ルールをすぐに分類することを強くお勧めします。ただし、この形式では、ルールの作成者をそのようなラベルのみに制限するのではなく、任意のラベルを付けることができます。

ルールのコレクション

YAML標準によれば、1つのファイル（用語ストリーム内）に複数のYAMLドキュメントを含めることができます。これは、YAMLドキュメントタグ（3つのハイフン（「---」））のおかげで実現されます。Sigma形式の場合、これらのドキュメントは独立したSigmaルールまたはアクションドキュメントにすることができます。



最初のケースでは、すべてが単純です。1つのファイルに完全なSigmaルールが含まれています。 YAMLドキュメントラベル（ルールの例/ proxy / proxy_ursnif_malware.yml）で互いに分離されている



2番目のケースは、より複雑です。最上位のアクション属性に次の3つの値のいずれかがある場合、YAMLドキュメントはアクションドキュメントとして扱われます。

• global — , YAML- . action- . : , Sigma- ;
• reset — , action-;
• repeat — repeat .

注：action属性は、ルールのどこにでも表示できます。



ルールのコレクションの最も一般的な使用例は、Windows Security EventID4688やSysmonEventID 1など、同様のイベントに対して複数のSigmaルールを定義することです。どちらのイベントもプロセス作成の結果として表示され、ソースが異なるだけです。特定のシナリオのSigmaルールのコレクションには、次の3つのアクションドキュメントを含めることができます。

1. 一般的なメタデータフィールドと検出インジケータを定義するグローバルアクションドキュメント。
2. WindowsセキュリティイベントログおよびイベントEventID = 4688のソースを定義するルール。
3. WindowsSysmonイベントログおよびイベントEventID = 1のソースを定義するルール。

別の解決策は次のとおりです。

1. 一般的なメタデータフィールドを定義するグローバルアクションドキュメント。
2. Windows Security Event Log ( EventID=4688) .
3. Action- repeat, logsource EventID , . 2.

action-

このセクションでは、アクション属性の値に基づいてSigmaがサマリールールを生成する方法について詳しく説明します。値がglobalのaction属性を含むYAMLドキュメントは、このファイル内のグローバルドキュメントと見なされ、それらのフィールドは他のすべてのドキュメントに追加されます。



注：現在のドキュメントにリセット値のアクション属性が含まれている場合、グローバルドキュメントフィールドは追加されません。



グローバルドキュメントを操作するためのロジックは次のとおりです。パーサーがグローバルドキュメント（グローバル値を持つアクション属性を含むドキュメント）を検出するとすぐに、そのフィールドを特別なバッファーに追加し、次のドキュメントに進みます。この特別なバッファをGLOBALYAMLと呼びましょう。将来、図で参照するのに役立ちます。



重要：ドキュメントの境界は「---」マークで定義されているため、これらのマークをファイルに正しく配置することが重要です。



以下の例では、最初のYAMLドキュメントに値globalのアクション属性が含まれています。このドキュメントの境界は、最初のドキュメントマークまで拡張されます。したがって、最初のドキュメント全体がグローバルバッファに書き込まれます。次に、このバッファのフィールドが後続の各ドキュメントに追加されます。その結果、出力で2つのルールが得られます。スキーム1.YAMLドキュメントラベルを正しく割り当てて単純なルールを処理する ただし、最初のラベルを削除または忘れると、YAMLドキュメント2のすべてのフィールドがグローバルドキュメントに含まれます。その結果、出力に誤った検索識別子のセットを持つルールが1つだけ取得されます。したがって、このような複合ルールでYAMLドキュメントに適切にラベルを付けることが非常に重要です。



















スキーム2.前のルールの処理-YAMLドキュメントの最初のラベルを付けるのを忘れた場合



グローバルドキュメントは必ずしも最初に来るとは限らないことに注意してください。前の2つのスキームを見ると、必ずしもYAML DOCUMENT 1であるとは限りません。さらに、単数形である必要はありません。次の図は、これを明確に示しています。スキーム3.グローバルYAMLドキュメントを指定するためのさまざまなオプションを含むルールの処理 そこで、YAMLドキュメント内のタグの正しい配置に関連する問題を検討しました。また、グローバル値を持つaction属性を使用して、さまざまな方法でグローバルYAMLドキュメントを設定できることもわかりました。次に、アクション属性の残りの2つの値（リセットと繰り返し）を使用してルールを変換するためのスキームを見てみましょう。



















スキーム4.リセット値と繰り返し値を使用してアクション属性を含むルールを処理する

シグマプロジェクトについて他に何を言う必要がありますか

Sigmaは、このシリーズで取り上げたフォーマットされたルールのセットだけではありません。

私たちの出版物では、ルールの形式と構文の説明に焦点を当てました。ただし、ルールはプロジェクトの半分にすぎません。2つ目は、sigmacコンバーターが使用するバックエンドです。従来、これらのコンバーターは、ユニバーサル入力と特定の出力を備えた「アダプター」と考えることができます。普遍的な記述形式を非常に便利にするのは、そのような「アダプター」の存在です。この状況では、サポートされているシステムのどれを使用するかは関係ありません。Sigmaでは、アイデアと検出アルゴリズムを記述できます。一方、sigmacコンバーターのバックエンドは、ターゲットシステムの特定の構文とフィールドのマッピングを担当します。



ただし、ルールをダウンロードして必要なターゲットシステムの構文に変換することで、システムを専門知識で満たすことに関連するすべての問題を解決できるとは限りません。Sigmaが現時点ですぐに使用できるソリューションではない理由と、ルールの構文を理解する必要がある理由について簡単に説明します。

現在のシグマの課題

シグマは活発に開発されているプロジェクトであり、他の成長しているプロジェクトと同様に、シグマには独自の課題があります。個人的には、それらを開発のポイントおよび成長の領域として認識しています。これはオープンソースプロジェクトであるため、力を合わせることで、プロジェクトの特定の部分の開発に大きく貢献することができます。フレームワークの主な呼び出しについて、現時点で何を参照しているのかをリストします。

1. . .
2. , Windows- (. ). , .
3. Wiki , . .
4. experimental — , .
5. .
6. , .

私自身の経験から、シグマプロジェクトに精通してOSCDに参加したとき、リストの最初の項目が最も重要であることが判明したと言えます。MaxPatrol SIEMとSigmaの構文の違いは、キーワードのセマンティクスと相関ルールの設計だけにとどまらないことが判明しました。この段階ではイベント相関の可能性がないため、一部のアイデアはSigma構文の観点から説明できません。相関メカニズムを使用すると、イベントフィールドの一般的な値を検索し、そのようなイベントを相互に関連付けることができます。これは、イベント間の関係を正確に確立する場合に役立ちます。たとえば、1つのユーザーセッション内のイベントを追跡します。これを行うには、LogonIDフィールドまたはそれに相当する値でイベントをバインドする必要があります。



ポイント検出または直接関連しないイベントに基づく検出は、Sigmaを使用して非常にうまく記述されていることに注意してください。



これらの問題やその他の問題に対処するための1つの方法は、OSCDスプリントの1つに積極的に参加することです。そして、多くのタスクがあるので、誰もが彼にとって興味深いものを見つけることができます。

新しいスプリントが間もなく登場します。ぜひご参加ください。

最初のスプリントの主催者には、イベントの質と参加者に対する気配りのある態度に感謝の意を表します。手で記入され、各参加者に送られる唯一のパーソナライズされたポストカードは何ですか！私たちの側では、新しいスプリントに引き続き参加し、Sigmaリポジトリに実行可能な貢献をする予定です。



一連の記事を読み、ルールの形式を理解すると、情報セキュリティコミュニティ全体の利益のために専門知識を使用できるようになります。



必ず2回目のスプリントに参加してください。個別に参加してチームを編成し、一緒に世界をより安全にしましょう！



OSCDイニシアチブの連絡先：

• oscd.community
• twitter.com/oscd_initiative

著者：Anton Kutepov、専門家サービス部門およびポジティブテクノロジー開発のスペシャリスト（PTエキスパートセキュリティセンター）