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

製品の作成と専門知識の開発において、私たちは主に企業のセキュリティを改善したいという願望に導かれています。ただし、私たちの研究は、カスタマーケア以上のものによって推進されています。長い間、私たちはボランティアで情報セキュリティコミュニティの調査を行うことを望んでいましたが、現在積極的にこれを行っています。Twitterで注目のネットワーク攻撃の検出を公​​開し、トラフィック分析ルールをANY.RUNサービスに提供し、ETOpenルールを追加します。プルリクエストを送信できるオープンソースプロジェクトはたくさんありますが、最近まで、ホスト検出はまだ手に届きませんでした。



そして、愛好家のグループが2週間のスプリントを手配することを決めたことを知りましたSIEMシステムのルールを記述するための統一されたフォーマットを開発するために作成され、140人以上の参加者によってサポートされているSigmaプロジェクトのルールの記述について。私たちは、SIEMベンダーとしてコミュニティの発展を注意深くフォローしているため、イベントに関するニュースに興味を持っていました。



主催者から連絡があり、PT Expert Security Centerチームにスプリントへの参加を招待したときの驚きを想像してみてください。イベントの参加者は、Open Security Collaborative Development（OSCD）を形成しました。これは、知識の普及とコンピュータセキュリティ全般の改善を目的とした情報セキュリティスペシャリストによる国際的な取り組みです。私たちは、共通の安全のために私たちの経験を応用するために参加することに喜んで同意しました。

この記事が生まれた経緯

ルールを書き始めたとき、特にロシア語では、シグマルールの構文の包括的な説明がないことに気づきました。知識の主な情報源は、GitHubと個人的な経験です。いくつかの優れた記事（ロシア語と英語）がありますが、それらの焦点は、ルールの構文からシグマルールの適用範囲の分析または特定のルールの作成に移っています。私たちは、初心者がSigmaプロジェクトに慣れ、私たち自身の経験を共有し、その使用の構文と機能に関する情報を1か所に収集しやすくすることにしました。そしてもちろん、これがOSCDイニシアチブを拡大し、将来的に大きなコミュニティを作成するのに役立つことを願っています。



大量の資料があったため、3つのシリーズの記事で説明を公開することにしました。

1. , ( ).
2. . , .
3. (, , , , ) .

Sigma

シグマは、ログのデータに基づいて検出ルールを記述するための統一された形式です。ルールは個別のYAMLファイルに保存されます。Sigmaでは、統一された構文を使用してルールを1回記述し、次に特別なコンバーターを使用して、サポートされているSIEMシステムの構文でルールを取得できます。さまざまなSIEMシステムのクエリの構文に加えて、次のタイプのクエリの作成がサポートされています。

• Elasticsearch Query、
• 必要なパラメータを含むgrepユーティリティ起動ライン
• Windows監査ログPowerShell文字列。

最後の2つのタイプは、ログを分析するための追加のソフトウェアを必要としないという事実で注目に値します。grepユーティリティとPowerShellインタープリターは、それぞれLinuxとWindowsでそのまま使用できます。



ログに基づいて検出を記述するための統一された形式の存在により、知識の共有、オープンソースセキュリティの開発が容易になり、情報セキュリティコミュニティが新たな脅威と戦うのに役立ちます。

一般的な構文

まず第一に、ルールの必須部分とオプション部分があるということです。これはGitHub の公式wikiに記載されています。ルールの概要（ソース：公式Wiki）を以下に示します。







ほとんどすべてのルールは、大きく3つの部分に分けることができます。

1. ルールを説明する属性（メタ情報）;
2. データソースを説明する属性。
3. ルールをトリガーするための条件を説明する属性。

各部分は、タイトル（タイトルに加えて、最後のグループには他のオプションの高レベル属性が含まれます）、ログソース、および検出の必須の高レベル属性に対応しています。



話す価値のあるルール構造のもう1つの機能があります。ルールはYAMLマークアップ言語で記述されているため、YAML形式では複数のYAMLドキュメントを1つのファイルに配置できるため、Sigmaの開発者はこれをいくつかの用途に使用しています。そしてSigmaの場合-1つのファイルに組み合わせるいくつかのルール、つまり「ルールコレクション」を作成します。このアプローチは、攻撃を検出する方法がいくつかあり、説明部分を複製したくない場合に便利です（対応するセクションで説明するように、ルールの説明部分だけでなく複製することもできます）。



この場合、ルールは通常2つの部分に分けられます。

• コレクションアイテムの一般的な属性を持つパーツ（通常、ログソースと検出セクションを除くすべてのフィールド）、
• 検出を説明する1つまたはいくつかの部分（セクションログソースと検出）。

ファイルに単一のルールが含まれている場合、1つのルールから縮退したコレクションを取得しているため、このステートメントも当てはまります。ルールのコレクションについては、このシリーズの第3部で詳しく説明します。



次に、架空のルールの例を見てみましょう。このフォームのコメントは通常、ルールでは使用されないことに注意してください。ここでは、フィールドを説明するためだけのものです。

典型的なルールの説明

シグマルールの作成例

構文の詳細を説明し、シグマルールの機能について説明する前に、実際にこれらまたはそれらの属性値がどこから来るのかを明確にするために、そのようなルールを作成する小さな例を考えてみましょう。このトピックについての良い記事は英語です。独自のルールを作成して、YAMLファイルの属性で指定する必要のあるデータがわかっている場合は、イベントソースセクションの詳細な説明を含む次のセクションに進むことができます（このセクションをログソースとも呼びます）。



SettingSyncHost.exeの使用をLiving Off The Land Binary（LOLBin）として検出するルールを作成する方法を説明しましょう。ルールの作成には通常、3つの段階があります。

1. 攻撃を実行し、必要なログを収集し、
2. 原則として検出の説明、
3. 作成したルールを確認します。

攻撃を行う

ルールのアイデアは、ヘキサコーンのブログに詳しく記載されています。注意深く読んだ後、記事に記載されている結果を繰り返すために必要な手順が明らかになります。

1. 実行するプログラムを書き込み可能なディレクトリにコピーします。記事では％TEMP％を選択することを推奨していますが、任意のパスを選択できます。手順4で指定した名前のサブディレクトリがこのディレクトリに作成されることを検討する価値があります。
2. , , , (wevtutil.exe, makecab.exe, reg.exe, ipconfig.exe, settingsynchost.exe, tracelog.exe). , findstr.exe. , SettingSyncHost.exe Binary Search Order Hijacking (MITRE ATT&CK ID: T1574.008).
3. , ( settingsynchost.exe cmd PowerShell, cd < >).
4. : c:\windows\system32\SettingSyncHost.exe -LoadAndRunDiagScript <___>
5. SettingSyncHost.exe.

Sysmonは、sysmon-modularプロジェクトの構成ファイルと共にシステムに インストールされます。したがって、ログの収集は自動的に実行されました。ルールの作成中に、検出の作成に役立つログの種類が表示されます。

シグマルールの形式での検出の説明

このステップでは、2つのアプローチが可能です。検出ロジックで最も近い既存のルールを見つけてニーズに合わせて変更するか、ルールを最初から作成します。初期段階では、最初のアプローチに固執することをお勧めします。明確にするために、2番目のアプローチを使用してルールを記述します。



新しいファイルを作成し、その本質を名前で簡潔かつ簡潔に説明します。ここでは、既存のルールのスタイルを遵守する必要があります。この例では、win_using_settingsynchost_to_run_hijacked_binary.ymlという名前を選択しました。次に、コンテンツを入力し始めます。ルールの始めにメタ情報を入力することから始めましょう。これに必要なすべてのデータがすでにあります。

ルールがフィールドで検出する攻撃の種類について簡単に説明しますtitle、より詳細な説明-説明フィールドでは、新しいルールの場合、ステータスを設定するのが慣例です：試験的。一意の識別子はさまざまな方法で生成できます。Windowsでは、PowerShellインタープリターで次のコードを実行するのが最も簡単な方法です。

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

残りのフィールドは自明ですが、攻撃の理解に役立つソースへのリンクを提供することをお勧めします。これは、このルールをさらに理解する人々に役立ちます。また、攻撃を説明するために元の研究の著者が行った努力への賛辞でもあります。



この段階でのルールは次のとおりです。







次に、ログのソースを説明する必要があります。上記のように、Sysmonログに依存しますが、一般的なカテゴリの登場により、process_creationカテゴリを使用してプロセスを作成するのが慣習となっています。一般化されたカテゴリについては、以下で詳しく説明します。 Sysmon構成機能など、定義フィールドでのソースの構成に関するコメントとアドバイスを書くのが慣例であることに注意してください。







次に、検出ロジックを説明する必要があります。これは最も時間がかかる部分です。この攻撃は多くの基準で検出できます。この例では、可能なすべての検出方法を網羅しているわけではないため、可能なオプションの1つについて説明します。



発生したイベントを見ると、次のチェーンを構築できます。

まず、プロセス（PID：4712）を開始行c：\ windows \ system32 \ SettingSyncHost.exe -LoadAndRunDiagScript join_oscdで開始しました。プロセス







の現在の作業ディレクトリはユーザーのTEMPディレクトリであることに注意してください。



次に、実行中のプロセスがバッチファイルを作成し、その実行を開始します。











：命令のバッチファイルを実行するプロセスには、固有のシステムファイルとメタが含まれていませんPlusの一時ファイルとフォルダにある打ち上げIPCONFIG.EXEファイル、参照イベントの識別子7076.さらなる分析を受けた







ことは、攻撃の起動プロセスの兆候と考えることが提案され、嘘をしない実行ファイルをシステムディレクトリ（C：\ Windows \ System32）にあります。また、親プロセスのスタートアップ行にサブストリング「cmd.exe / c」、「RoamDiag.cmd」、および「-outputpath」が含まれている場合も同様です。これをシグマ構文で記述して、最終的な規則を取得しましょう（検出ロジックを記述するために使用できる構造の詳細な分析は、シグマに関する一連の記事の次のパートで説明されます）。

ルールが機能することを確認する

コンバーターをPowerShellクエリに起動します。







この場合、除外フィルターは親プロセスの実行可能ファイルイメージへのパスも検出するため、このクエリでは目的の結果が得られません。したがって、単にImageという単語の前に文字tがあってはならないことを示すだけです。つまり、単語の終わりです。親：







イベントが見つかりました。ルールは機能します。



これが実際にSigmaルールが作成される方法です。次に、検出を担当するフィールド、つまりログソースの説明について詳しく説明します。

説明を検出

ルールの主要な部分は検出の説明です。これは、攻撃の兆候を探す場所と方法に関する情報が含まれる場所だからです。この情報は、ログソース（場所）および検出（方法）属性のフィールドに含まれています。この記事では、ログソースセクションを詳しく見ていき、シリーズの次のパートで検出セクションについて説明します。

イベントソースセクションの説明（logsource属性）

イベントソースの説明は、logsourceフィールドの値に含まれています。このセクションでは、検出セクションのイベントが配信されるデータソースについて説明します（検出属性については次のセクションで説明します）。このセクションでは、検出に必要なソース自体、プラットフォーム、およびアプリケーションについて説明します。コンバーターによって自動的に処理される3つの属性と、任意の数のオプション要素を含めることができます。基本的なフィールド：

• カテゴリ -製品のクラスを説明します。このフィールドの値の例：ファイアウォール、ウェブ、ウイルス対策。また、フィールドには、以下で説明する一般化されたカテゴリを含めることができます。
• 製品は、ログを作成するソフトウェア製品またはオペレーティングシステムです。
• サービス -ログを特定のサービスのサブセットに制限します。たとえば、Linuxの場合は「sshd」、Windowsの場合は「セキュリティ」です。
• 定義 -ソースの機能を説明するための追加フィールド。たとえば、監査をセットアップするための要件（まれに使用されます。このフィールドのルールの例はGitHubにあります）。ソースに詳細がある場合は、この属性を使用することをお勧めします。

 

GitHub の公式wiki は、ルールがクロスプロダクトになるために使用する必要がある一連のフィールドを定義しています。これらのフィールドを以下の表にまとめます。





次に、使用されたイベントフィールドを示すログのいくつかのソースをより詳細に説明し、これらのフィールドが使用されるルールの例を示します。

プロキシカテゴリのイベントフィールド

ファイアウォールイベントフィールド

Webサーバーカテゴリのイベントフィールド

一般化されたカテゴリ

シグマはログベースの検出ルールを記述するための一般的な形式であるため、そのようなルールの構文は、さまざまなシステムの検出ロジックを記述できるはずです。一部のシステムでは、イベントではなく集計データを含むテーブルを使用し、さまざまなソースからのデータが同じ状況を説明するために入力される場合があります。構文を統一し、同様の問題を解決するために、一般的なログソースメカニズムが導入されました。現在、そのようなカテゴリの1つが作成されています-process_creation。詳細については、patzke.orgブログをご覧ください。このカテゴリのフィールドのリストは、分類のページにあります（このページでは、サポートされている他のカテゴリについても説明しています）。

一般化されたカテゴリイベントフィールドprocess_creation

更新

この記事の準備として、新しい一般的なカテゴリが追加されました。

• network_connection（例sysmon_powershell_network_connection）
• dns_query（例sysmon_regsvr32_network_activity）
• registry_event（sysmon_rdp_settings_hijackの例）
• file_creation
• process_access（sysmon_lsass_memdumpの例）
• image_load（例sysmon_mimikatz_inmemory_detection）
• process_terminated

これらはすべて、WindowsログイベントとSysmonログイベントの重複した情報に関係しています。ルールを作成するときは、既存の一般化されたカテゴリを使用することをお勧めします。プロジェクトは活発に開発されているため、新しいカテゴリの出現に追従し、さらなる革新に従ってルールを更新することをお勧めします。

既存のルールのイベントソース使用統計

以下の表は、ログソースを記述するための最も一般的な構成を示しています。ほとんどの場合、あなたはそれらの中であなたのルールに合ったものを見つけるでしょう。



最も一般的なソースのいくつかについての説明フィールドの組み合わせの使用に関する統計（ダッシュはこのフィールドがないことを意味します）：

ルールを書くためのヒント

新しいルールを作成する場合、次の状況が考えられます。

1. 正しいイベントソースは、既存のルールで既に使用されています。
2. このイベントソースを使用する単一のルールがリポジトリにありません。

最初のケースに直面した場合は、既存のルールの1つをテンプレートとして使用します。おそらく、必要なログソースが他のルールですでに使用されている可能性があります。これは、さまざまなSIEMシステムのプラグイン（バックエンドコンバーター）の作成者が、おそらくマッピングでそれを考慮に入れており、ルールがすぐに正しく処理されることを意味します。



2番目の状況では、既存のルールの例を使用して、カテゴリー、製品、およびサービスIDを正しく使用する方法を理解する必要があります。独自のログソースを作成する場合、既存のバックエンドのすべてのマッピングに追加することをお勧めします。他の貢献者や開発者でさえこれを行うことができますが、主なことはそのような必要性について知らせることです。



既存のルールのログソースの説明フィールドの組み合わせの視覚化を作成しました。

ログソースの配布

ログソース属性サブフィールドの組み合わせに統計を使用する

この記事では、単純なルールを作成する例を示し、イベントソースの説明について説明しました。これで、得られた知識を適用し、Sigmaリポジトリのルールを確認して、特定のルールで使用されているソースを特定できます。私たちの出版物に従ってください。次の部分では、シグマルールの最も難しい部分、つまり検出ロジックを説明するセクションを見ていきます。



著者：Anton Kutepov、エキスパートサービス部門とポジティブテクノロジー開発のスペシャリスト（PT Expert Security Center）