Windowsの高度な監査ポリシーに対するデータドリブンのアプローチ：有効にすべきポリシーとその理由

デジタルフォレンジック、検出エンジニアリング、脅威ハンティングの経験がある程度あれば、悪質なアクティビティを検出するうえでWindowsイベントログがいかに重要であるかをご存じでしょう。Windowsのデフォルトのログは長年にわたって改善されてきましたが、それでも、高度な脅威を検出するために必要なレベルの可視性を得るにはまだ十分とは言えません。そこで役に立つのが、Windowsの高度な監査ポリシーです。これらのポリシーを使えば、検出やハンティングに欠かせない、価値の高いイベントを追加で収集できます。しかし残念ながら、Windowsの複雑さゆえ、どのサブカテゴリを有効にすべきかを正確に判断するのは容易ではありません。ログの量やイベントの重大度、負荷が増えてもそのサブカテゴリを有効にする価値があるかどうかなど、さまざまな要素を考慮する必要があります。

このブログ記事では、どのサブカテゴリが最も広く脅威をカバーできるかをデータに基づいて検証することで、複雑さを軽減していきます。特に重要なイベントがどれかを探り、監査ポリシーの適切な設定方法と、大量のログに圧倒されることなく可視性を最大限に高める方法について、参考になる情報を提供します。

Windows監査ポリシー：入門編

Windowsの管理やセキュリティの業務に携わったことがあれば、Windows監査ポリシーのことはすでによくご存じだと思います。ここで簡単におさらいして要点を確認できます。まだご存じでない方は、この機会に基本を押さえておきましょう。

Windows監査ポリシーは、システム内で発生したセキュリティイベントログを制御するための内蔵のメカニズムです。管理者は、監査ポリシーを設定して、ログに記録するイベントを調整できます。これにより、デフォルトでは記録されないログを収集して、ユーザーログオン、ファイルアクセス、プロセス作成、リクエスト処理など、重大なアクティビティの発生を把握できます。こうしたイベントは特に、セキュリティチームが悪質なアクティビティを検出したり、インシデントの発生後に調査を行ったりするために役立ちます。

監査ポリシーは、次の図に示す2つの場所から設定できます。

• ローカルポリシー(従来の広範なアプローチ)：これらのポリシーでは、ログオンイベントやアカウント管理など、対象の広い監査カテゴリを有効または無効にできます。細かい設定はできず、カテゴリ内のすべての項目をログに記録するか、一切記録しないかを選択します。
• 高度な監査ポリシー(詳細なアプローチ)：これらのポリシーでは、対象の広いカテゴリが細かいサブカテゴリに分けられており、ログに記録する項目をより柔軟に選択できます。たとえば、ログオンイベントのすべての項目を有効にする代わりに、ログオンの成功やログオンの失敗など、組織にとって重要な、より具体的なサブカテゴリを選択できます。

詳しくは、Microsoft社のドキュメントで「高度な監査ポリシー」に関する説明を参照してください。

高度な監査ポリシーのカテゴリとサブカテゴリ

Windowsの高度な監査ポリシーは9つの主要カテゴリで構成され、各カテゴリには、ログに記録する項目をより細かく設定するための一連のサブカテゴリが含まれます。Microsoft社のこちらのドキュメントでは、各カテゴリとサブカテゴリの詳細を確認できます。ぜひご覧ください。

サブカテゴリではそれぞれ、設定した監査ポリシー(成功か失敗か)に基づく固有のイベントが生成されます。これらのカテゴリでカバーされるイベントIDは400以上あり、どのカテゴリでどのイベントが生成されるかを追跡するのは容易ではありません。

そこで、Splunk脅威調査チームは、各イベントIDを対応するカテゴリとサブカテゴリにマッピングした包括的なスプレッドシートを作成しました。このブログ記事では、Windowsの監査ポリシーを効果的に設定できるようにするために、このスプレッドシートを参照します。

Windowsの高度な監査ポリシーの概要は以上です。次に、監査ポリシーを設定するうえでの課題を見ていきます。ログに記録するイベントを細かく設定できることは便利である反面、複雑さを伴います。ログの量を考慮して、システムやSIEMに過度な負担がかからないようにしながら、適切なイベントを記録できるように、有効にする項目を慎重に選択する必要があります。では、監査ポリシーを効果的に設定するうえで直面しがちな主な課題を詳しく見ていきましょう。

課題：ログの量、妥当性、カバー範囲の調整

単純にすべての監査カテゴリとサブカテゴリを有効にしてしまえばよさそうなものですが、そうはいきません。すべてを有効にすると、膨大な量のイベントが生成され、しかも、その多くが組織のセキュリティ目標とは無関係ということもありえます。また、ログが大量になると、SIEM (Splunk Enterprise Securityなど)に過度な負荷がかかり、アナリストの負担が増え、ストレージコストが必要以上にかさみます。

そこで、有効にするカテゴリを選択しようとすると、以下のような重要な疑問に直面します。

• サブカテゴリでは、ログに記録するイベントをより詳細に管理できますが、その中の特定のイベントだけを選択する機能は(デフォルトでは)ありません。どのサブカテゴリなら、ログの量と妥当性のバランスを適切に取ることができるでしょうか？
• どのイベントなら、最新の攻撃や手口を検出するために最適な範囲をカバーできるでしょうか？

これらの疑問に答えるために、Splunk脅威調査チームが取り入れている調査アプローチをご紹介しましょう。

Splunk脅威調査チームの調査アプローチ

私たちは、この調査プロジェクトにデータドリブンのアプローチを取り入れたいと考え、できるだけ正確な情報を集めることを目指しました。そこで、以下の要素に焦点を当てました。

監査ポリシーの推奨事項

監査ポリシーに関する全体的な推奨事項を探るために、私たちは、Microsoft社による公式な推奨事項と、各種の業界や信頼できるサードパーティが公開しているガイドラインを幅広く調査しました。対象には以下の資料が含まれます。

• Microsoft社：監査ポリシーの推奨事項と各サブカテゴリに関する推奨事項(資格情報の確認の監査など)
• 米国国家安全保障局(NSA)：Windowsイベントログの監視による攻撃の検出
• CISベンチマーク
• ADSecurity：ドメインコントローラーの保護によるActive Directoryのセキュリティ向上
• Malware Archaeology社：ログ収集チートシート

私たちは、これらの推奨事項の違いに着目し、どの監査ポリシーがすべての資料で有効に設定され、重要度が高いか、どのポリシーが資料によって異なるか、さらに潜在的なギャップがどこにありそうかを調べました。これにより、効果的な検出とセキュリティ監視を行うために有効にすべき項目がより明確になりました。

イベント量に関するデータ

イベント量のデータについては、Microsoft社の公式ドキュメントと、信頼できるサードパーティが公開している情報を参考にしました。対象には以下の資料が含まれます。

• Microsoft社：サブカテゴリに関するドキュメントと個々のイベントの情報(ある場合)
• The Joint SIGINT Cyber Unit (JSCU)：ログの基本
• ADSecurity：ドメインコントローラーの保護によるActive Directoryのセキュリティ向上
• オーストラリア通信電子局(ASD)：Windowsイベントのログと転送

イベント量に関するデータは比較的少ないうえに、システムアクセス制御リスト(SACL)の設定や、インストールされているロールと機能によってイベントの生成量は異なります。しかし、手に入る資料を活用して全体的な分析に組み込むことにより、特定の監査ポリシーを有効にしたときの影響をより正確に把握できました。

設定と有効化の複雑さ

監査ポリシーの設定時に直面しがちな問題の1つは、特定のサブカテゴリで有意義なイベントを生成するために追加の設定が必要になることです。サブカテゴリを有効にしただけでは効果を得られず、追加のポリシー調整、レジストリ変更、さらにはシステムの再起動が必要になることがあります。その例をいくつかご紹介します。

• イベントID 4688：コマンドライン引数を取得するために、グループポリシーまたはレジストリ値の追加設定が必要です。
• 「レジストリの監査」、「ファイルシステムの監査」などのサブカテゴリ：関連イベントのログ収集を開始する前に、特定のオブジェクトについてシステムアクセス制御リスト(SACL)の設定が必要です。
• サブカテゴリ「リムーバブル記憶域の監査」：レジストリキーを変更し、それを有効にするためにシステムを再起動する必要があります。

イベントとMITRE ATT&CK技法のマッピング

この調査プロジェクトの主な目標の1つは、監査ポリシーに関する推奨事項にATT&CKデータを組み込むことです。サイバーセキュリティ、特に検出の領域で広く活用されているATT&CKは、攻撃のTTP (戦術、技法、手順)とWindowsイベントログを体系的にマッピングするために最適なフレームワークです。イベントIDをATT&CK技法と関連付けることにより、特定のイベントまたはサブカテゴリの重要度をニーズに応じて判断できます。

そのために、私たちは、ATT&CKに基づく複数のデータソースを参照しました。対象には以下の資料が含まれます。

• ATT&CKデータソース
• Open Threat Research Forge (OTRF)プロジェクト：OSSEM検出モデル
• Malware Archaeology社：ATT&CKチートシート

また、ATT&CKフレームワークは脅威調査レポートでも標準のマッピング方法として広く利用されているため、これらのレポートをもとに、攻撃者がよく悪用する技法を特定できます。幸い、SURGeの同僚が、Macro-ATT&CK調査でこの重労働の大半を引き受けてくれました。この調査グループは、オープンソースのレポート(Red Canary、CISA、Mandiant社のM-Trends、Center for Threat Informed Defense (CTID)のSightings Ecosystemプロジェクト)を5年分調査して、マクロレベルのサイバーインシデントデータをまとめました。

ATT&CKのマッピングと実際の頻度データを組み合わせることで、より確かな根拠に基づいて、優先すべきイベントやサブカテゴリを判断できます。

オープンソースの検出で使われているイベントと公開されている推奨事項

私たちが収集したかったもう1つの重要なデータポイントは、オープンソースの検出ルールで実際に使われている、各種の監査ポリシーのサブカテゴリに含まれるWindowsイベントログです。これを調べるために、私たちは3つの主要なオープンソースの検出プロジェクトを分析しました。

• SigmaHQルール：コミュニティ主導で開発され幅広く利用されている検出ルールです。
• Elastic検出ルール：Elastic Securityプラットフォーム用に開発されたオープンソースの脅威検出ルールです。
• Splunk Analytics：Splunk脅威調査チームが開発および改良した、Splunk独自の検出コンテンツです。

ここでの目標は、現場で実際に収集されているWindowsイベントを特定することです。これらのルールセットで多く参照されているイベントIDを洗い出すことで、監査ポリシーで有効にすべき重要なイベントを判断するための追加のデータポイントとして活用できます。

重要なポイント

当然ですが、高度な監査ポリシーを設定するための万能のアプローチはありません。最適なアプローチは、最終的には、組織のセキュリティニーズ、インフラ、優先課題によって異なります。それでも、前のセクションでの調査内容から、監査ポリシーに関する判断に役立ついくつかの重要ポイントが見つかりました。

最高賞：イベントID 4688 (「詳細追跡」より)

予想していた方は多いと思いますが、上記の調査でほぼすべてのメトリクスを分析した中で、「詳細追跡」サブカテゴリに含まれるイベントID 4688が費用対効果において圧倒的に優れていることがわかりました。

まず、監査ポリシーの設定の点で見ると、調査した資料のすべてで「プロセス作成」カテゴリの監査を有効にすることが推奨されています。

ログの量の点では、イベントID 4688では、システムのアクティビティに応じて中程度から大量のログが生成されます。かなり多いと感じるかもしれませんが、そのセキュリティ上のメリットは、ストレージコストがかかるデメリットをはるかに上回ります。その理由は以下のとおりです。

• MITRE ATT&CKのカバレッジ：イベントID 4688は、約280のMITRE ATT&CK技法とサブ技法に完全にまたは部分的に対応します。そのため、脅威検出において幅広く活用できます。

• 検出エンジニアリング：オープンソースの検出ルールを使用している場合、その多くで、プロセス作成イベントが頻繁に参照されています。

  • Splunkのセキュリティコンテンツには、このイベントに基づいて作られた分析が 400以上 含まれます。
  • SigmaHQには、イベントID 4688を含む「process_creation」ログソースを使った検出ルールが 1,000以上 含まれます。

• 公開されている脅威レポート：SURGeの調査から、過去数年間に報告された多くの技法とサブ技法は、イベントID 4688を通じて部分的に、場合によっては完全に検出できることがわかっています。

有効にすべき最重要イベントを知るためにこのブログ記事をお読みになっているなら、答えはズバリ「イベントID 4688」です。このイベントは、無数のセキュリティ検出の基盤となり、システムのアクティビティをより明確に可視化して、実際に使われる攻撃技法を特定するために極めて効果的です。

ATT&CKカバレッジとその補完

前のセクションで取り上げた各種のソースで使われているATT&CKデータに基づいて、監査ポリシーのサブカテゴリごとに、概ねまたは理論的にカバーできる技法とサブ技法の数を下の表にまとめました。

注意していただきたいのは、ATT&CKは、考え得るすべての攻撃と攻撃経路を網羅しているわけではない点です。また、技法の実装方法はさまざまであり、取得できる情報の量もデータソースによって異なるため、各サブカテゴリで検出できる技法の数は必ずしも正確なわけではない点にも注意してください。それでも、以下のデータは許容可能な近似値であり、推奨事項に基づいて検出ルールを開発するための初期のベースラインとして役立ちます。

一見すると、上の表を参考にMITRE ATT&CKカバレッジが高いサブカテゴリを有効にするだけで、最適な監査ポリシーの設定が完了するように思えるかもしれませんが、残念ながら話はそれほど単純ではありません。

ATT&CKのカバレッジは出発点として役立ちますが、それですべてが解決するわけではありません。カバーされる技法の数が多いからと言って、必ずしも検出率が上がるとは限りません。それどころか、表に挙げたすべてのカテゴリを闇雲に有効にすれば、複雑さが増し、大量のノイズが生じて、処理の負荷が増大する可能性もあります。

効果的な監査ポリシーを設定するには、考慮すべき要素がほかにもあります。

設定の複雑さ

調査アプローチのセクションで述べたように、設定のしやすさは監査サブカテゴリによってさまざまです。有効にするだけで済むものもありますが、対応するイベントを収集するために追加の設定(レジストリの変更、SACLの設定、ロールのインストール、システムの再起動など)が必要になるものもあります。

その一部を次の表に示します。

ファイルシステムやレジストリの監査など、特に強力なサブカテゴリの一部では、セキュリティに役立つ情報を得るために追加の設定が必要になります。その設定を行わないと、有効にしても有意義なログは収集できません。

ログの量に関する考慮事項

イベントの量が多いことは必ずしも悪いことではありません。重要なのは、S/N比や、イベントを調整、フィルタリング、調査できるかどうかです。たとえば、先ほど説明したように、プロセス作成のイベントID 4688は、量に関係なく非常に有用です。一方、ファイルシステムの監査では、範囲を慎重に調整しないと、役に立たないものも含めた大量のログがSIEMに押し寄せる可能性があります。

オープンソースの検出ルールでの使用頻度

独自の検出ルールを作成する際や、カバー範囲を拡大する際に、オープンソースの検出ルールを利用することがあるでしょう。そのため、SigmaHQ、Elastic検出ルール、Splunkセキュリティコンテンツなど、オープンソースの検出ルールを調べれば、頻繁に使用される監査サブカテゴリがわかります。逆に、オープンソースの検出ルールでめったに使われないサブカテゴリは、実用性に乏しい、ノイズが多すぎて効果が低い、または単に、ユーザーが有効にするのではなくEDRなどのツールで取り込むことを想定しているなどの理由で、検出エンジニアリングの観点からは直接役に立つものではありません。これらのサブカテゴリがコミュニティ主導またはオープンソースの検出ルールでどの程度使用されているかを下の表に示します。

この表で「該当なし」でも、そのカテゴリで生成されるテレメトリが必ずしも存在しない、あるいは該当するプラットフォームで収集されないというわけではありません。この表では、特定のカテゴリで生成される特定のイベントを使用するルールを取り上げています。そのカテゴリに含まれるイベントがいずれか1つでも使用されていれば、チェックマークを付けています。

Eventlog Compendiumのご紹介

私たちは、このブログ記事で紹介した調査結果を実用化するための「Eventlog Compendium」というStreamlitアプリを開発しました。このアプリは、スプレッドシートや長いドキュメントを隅々まで調べなくても、Windowsの高度な監査ポリシーをそれぞれの環境に合わせて簡単に設定できるように設計されています(その他の設定にも対応します)。

その目的は、MITREカバレッジ、ログの量、設定の複雑さ、検出ルールでの使用頻度など、この記事で説明したすべての要素を実務に反映できるようにすることです。

仕組み

このアプリでは、この記事で説明したすべての要素をユーザー入力として設定できます。

• システムのタイプ、ロール/機能の選択 最初に、システムのタイプ(サーバー、クライアントなど)を選択します。次に、その環境に関連付けられた特定のWindowsロールまたは機能(ドメインコントローラー、証明書サービスなど)を選択します。これにより、システムに実際に導入されている機能に合わせた推奨事項を適用できます。
• 検出フレームワークの選択 オプションで、1つまたは複数のオープンソース検出フレームワーク(SigmaHQ、Elastic検出ルール、Splunkセキュリティコンテンツなど)を選択して、そのフレームワークに合わせてポリシーを調整できます。これにより、生成された設定で、そのフレームワークで使われている可能性の高い検出ルールがサポートされます。
• 複雑度の選択 必要となる設定の技術的な複雑度を選択できます。[Low]を選択すると、SACLやレジストリの変更が必要な推奨カテゴリは除外されます。[Medium]または[High]を選択すると、より高度な設定が必要なカテゴリが含まれ、可視性が向上します。
• 望ましいログ量の選択 望ましいログ量を設定して、生成される監査データの量を制御できます。これにより、SIEMなどのログシステムで処理できるデータの量や、ノイズの低減と包括的な可視化のどちらを優先するかの基準に基づいて、ログの量を調整できます。
• MITRE ATT&CKの統合 最後に、MITREの技法と戦術のどちらに基づいてカバー範囲を設定し、該当するサブカテゴリを有効にするかを選択します。

EDRソリューションを使用していてもこのアプリを使用すべきか？

答えは「YES」です。ただし、使用している製品や達成したい目標によって、設定すべき監査ポリシーは多少異なることがあります。一般的なシナリオをいくつかご紹介します。

EDRソリューションの補完

ほとんどのEDR製品では、カーネルレベルのドライバーまたはETW (Event Tracing for Windows)プロバイダーを介してデータが収集されます。それでも、すべての監査項目をカバーできるとは限りません。一部のソリューションでは、その不足を補うために特定の監査ポリシーが有効になるか、有効にすることが推奨されます。

その例をご紹介します。

• Palo Alto社のCortex XDRでは、XTHアドオンを通じて、セキュリティチャネルからのイベントログを含む追加のイベントログを収集できます。

• Cisco Secure Endpointでは、エンドポイントポリシーの設定を通じて、特定のWindows監査ポリシーを有効にできます。たとえば、以下のポリシーを有効にできます。

  • ユーザーアカウント管理の監査/成功
  • ログオンの監査/成功
  • ログオンの監査/失敗
  • セキュリティシステムの拡張の監査/成功
  • その他のオブジェクトアクセスイベントの監査/成功

詳しくは、ベンダーが提供する製品ドキュメントをご覧ください。EDRソリューションで生成されるテレメトリとその生成方法の概要については、EDR Telemetry Projectを参照してください。

デジタルフォレンジックやインシデント対応での利用

この場合、必要なテレメトリが収集されていないという状況はよくあります。原因としては、EDRエージェントが正しく設定されていないか、無効になっているか、対象のシステムに導入されていないことが考えられます。その場合は、Windows監査ポリシーを適切に設定するか、Sysmonエージェントを使ってローカルのイベントをすべて収集しておくことで、状況がかなり改善されます。

ログを日常的に使用していない場合でも、必要なときにすぐに入手できれば、特に重要度の高いシステムで、情報収集の時間を節約し、調査上の重要な要素を特定することができます。

EDRが提供する情報だけでは、起きている状況を仮定することしかできません。監査ポリシー(とイベントログ全般)を活用すれば、特に障害が発生したときに、その仮定を検証、補完、裏付けできます。

まとめ

Windows監査ポリシーの設定は、リストにチェックマークを入れるだけの作業ではありません。目標を明確にし、適切なログを選択して、適切なレベルで有効にする必要があります。今回の調査を通じて、私たちは、MITREカバレッジ、イベントの量、検出ルールでの使用頻度、設定の複雑さを考慮に入れたデータドリブンのアプローチが、より賢明で効果的なポリシー、そして何よりも、わかりやすいポリシーを構築するために大きな役割を果たすことを証明しました。

検出ルールの開発、インシデント対応、既存のEDRの補完のいずれの目的でも、監査ポリシーを適切に設定すれば、可視性を向上させ、基盤を強化できます。Eventlog Compendiumアプリを使えば、その作業がより簡単になります。このアプリを活用し、目的に合わせて調整しながら、次のステップへと進んでください。

フィードバック

ご意見やご要望がございましたら、GitHubから遠慮なくお寄せください。Slackチャネル「#security-research」にご参加いただくこともできます。SlackのSplunkユーザーグループへの招待が必要な場合は、こちらの手順に従ってください。

寄稿者

この記事の執筆にあたってご協力いただいた以下の方々に感謝を申し上げます。Nasreddine Bencherchaliと、Splunk脅威調査チームのMichael Haag、Jose Hernandez、Lou Stella、Bhavin Patel、Rod Soto、Eric McGinnis、Patrick Bareiss、Teoderick Contreras(敬称略)