Microsoft Defender: エンドポイントのアタック サーフェス減少ルール

By Mirko Peters · 2026-03-06 · Updated 2026-03-24

アタック サーフェス減少ルールでエンドポイントを強化します。高度な KQL クエリを使用して ASR ルールの有効性を監査し、検出精度の向上と除外設定の調整に役立てます。

Automatically translated with AI from the original post. Read the English original

アタック サーフェス減少ルールの監査は、組織のセキュリティ態勢を維持するうえで重要な役割を果たします。高度な KQL を使えば、このプロセスを大幅に効率化できます。この強力なクエリ言語により、データをより効果的に分析でき、時間の節約と精度の向上につながります。高度な KQL を使うと、脆弱性を素早く特定し、セキュリティ ポリシーへの準拠を確認できます。このアプローチは監査能力を高めるだけでなく、セキュリティ戦略について情報に基づいた判断を下すうえでも役立ちます。

重要なポイント

• 監査スキルを高めるために、KQL クエリの基本的な構造を理解します。
• フィルター処理の手法を使い、特定の ASR ルールと関連データに焦点を絞ります。
• データ テーブルを結合して情報をまとめ、ASR 監査の全体像を把握します。
• count() や summarize などの関数を活用し、傾向やパターンを効果的に分析します。
• 定期的な監査スケジュールを設定し、コンプライアンスとセキュリティ態勢を維持します。
• 検出結果を十分に文書化し、進捗を追跡して時間の経過に伴う傾向を把握します。
• 結果を分析し、フィードバックを募ることで、監査プロセスを継続的に改善します。
• データのギャップに早めに対処し、監査データの信頼性を確保します。

1. ワークスペースをまたぐ結合は実用的で高速 — 高度な KQL は複数のワークスペースをまたぐ結合をサポートしており、大規模な ETL を行わなくても、ASR 監査でエンドポイント イベント、脅威シグナル、構成データを関連付けられます。
2. 近似関数で大規模クエリを高速化 — approx_count_distinct や percentile_approx などの関数を使うと、はるかに少ない計算リソースで大量の ASR テレメトリを集計でき、ほぼリアルタイムで応答が得られます。
3. 時系列演算子で微妙な傾向を把握 — make-series、series_fir、series_decompose などの演算子は、単純なフィルターでは見逃してしまう、ASR ルールの段階的なずれや、繰り返し発生するポリシー例外の検出に役立ちます。
4. エンティティのエンリッチメントが標準で組み込み — KQL を使うと、脅威インテリジェンス、デバイス インベントリ、ID 属性を ASR 監査データにその場で付加でき、個別のエンリッチメント パイプラインを使わずに、文脈を伴うアラートを生成できます。
5. レンダリングと可視化で誤検知を減らす — クエリ内で render timechart、barchart、heatmap を直接使うと、監査担当者は、調査が必要な異常な ASR ルールのヒットと、単なるノイズを素早く見分けられます。
6. クエリの上限とコスト管理を細かく制御 — KQL には take、limit、row_count_between などのクエリ時の制御機能や、クエリ診断機能が用意されており、監査担当者はリソース使用量を抑えつつ、実用的な ASR の知見を抽出できます。
7. 正規表現とシーケンスによる高度なパターン検出 — regex、mv-expand、sequence 演算子を組み合わせると、単純なイベント数では把握できない、ASR ログ内の複雑な多段階攻撃パターンを特定できます。

高度な KQL 環境のセットアップ

KQL の前提条件

高度な KQL に取り組む前に、いくつかの前提条件を満たす必要があります。まず、クエリに必要なデータを提供する Microsoft Defender へのアクセスを確保してください。プログラミングの基本的な概念を理解しておくと、KQL の理解も進みやすくなります。主な前提条件は次のとおりです。

• Microsoft Defender へのアクセス: セキュリティ データを収集するために欠かせないツールです。
• データ クエリの基礎知識: 簡単なクエリを読み書きできると、学習がスムーズに進みます。
• セキュリティの基本概念への理解: 脆弱性やコンプライアンスといった用語を理解しておくと、効果的な監査につながります。

KQL のツール

KQL を効率よく扱うには、適切なツールが必要です。以下は、始めるうえで役立つ推奨ツールです。

• Kusto Query Explorer: クエリをリアルタイムで作成・テストできる Web ベースのツールです。
• Azure Data Explorer: 大規模なデータセットに対して KQL クエリを実行するための堅牢な環境を提供するプラットフォームです。
• Microsoft Defender ポータル: このポータルを使用して、セキュリティデータとインサイトにアクセスします。これらは KQL を使って分析できます。

環境の構成

KQL のパフォーマンスを最適化するには、環境を正しく構成することが重要です。以下の手順に従って、環境を効果的にセットアップしてください。

1. 必要なツールのインストール: まず Kusto Query Explorer をインストールし、Microsoft Defender にアクセスできることを確認します。
2. データソースの設定: ツールを関連するデータソースに接続します。この接続により、クエリに必要なデータを取り込めるようになります。
3. クエリパフォーマンスの最適化: materialize 関数を使用して、中間結果をキャッシュし、クエリの速度を向上させます。KQL クエリ内の演算子の並べ方は、出力とパフォーマンスの両方に大きく影響します。そのため、最良の結果が得られるよう、クエリを慎重に組み立ててください。

これらの手順に従うことで、ASR 監査で高度な KQL を使用するための確かな基盤が整います。このセットアップは監査プロセスを効率化するだけでなく、検出結果の精度向上にも役立ちます。

ASR 監査のための KQL クエリ

基本的なクエリ構造

ASR 監査向けの KQL クエリを書き始める際には、基本構造を理解することが不可欠です。KQL クエリは通常、必要なデータを取得するために連携するいくつかのコンポーネントで構成されます。KQL クエリの主なコンポーネントは次のとおりです。

• テーブル名: クエリの対象となるデータソースを指定します。ASR 監査では、DeviceEvents や AlertEvidence などのテーブルを使用することがあります。
• 演算子: データに対して操作を実行するコマンドです。代表的な演算子には where、project、summarize があります。
• フィルター: フィルターを適用して結果を絞り込めます。たとえば、日付や特定の ASR ルールでフィルターできます。
• 関数: 関数を使うとデータを加工できます。出現回数のカウントや平均の計算に使用できます。

Microsoft Defender for Endpoint の Advanced Hunting 機能を使うと、カスタム KQL クエリで ASR ルールを詳細に分析できます。これらのクエリにより、ルールの検出状況、影響を受けたデバイス、アプリケーションへの影響についての洞察が得られます。

KQL クエリのコンポーネント

以下は、KQL クエリの構造を示すシンプルな例です。

DeviceEvents
| where ActionType == "ASRRuleTriggered"
| project DeviceName, Timestamp, ActionType

この例では、DeviceEvents テーブルに対してクエリを実行し、アクションの種類が "ASRRuleTriggered" のイベントをフィルターして、デバイス名、タイムスタンプ、アクションの種類のみを射影しています。

KQL の主な関数

KQL には、クエリ機能を拡張するためのさまざまな関数が含まれています。知っておくべき代表的な関数は次のとおりです。

• count(): 条件を満たすレコードの数を数えます。
• distinct(): 指定した列から一意の値を返します。
• summarize: 指定した条件でデータを集計し、時間の経過に伴う傾向を分析できるようにします。

高度なクエリテクニック

基本を理解したら、高度な KQL テクニックを探求して、ASR 監査データからより詳細な情報を抽出できます。これらのテクニックは、セキュリティ態勢についてより深い洞察を得るのに役立ちます。

ASR データのフィルタリング

ASR データの特定の側面に焦点を当てる場合、フィルタリングは非常に重要です。where 句で複数の条件を使用して結果を絞り込めます。例:

DeviceEvents
| where ActionType == "ASRRuleTriggered" and Timestamp > ago(30d)
| summarize Count = count() by DeviceName

このクエリは、過去 30 日間の ASR ルールのトリガーをフィルターし、デバイス名ごとのトリガー数を集計します。

データテーブルの結合

データテーブルを結合すると、異なるソースの情報を組み合わせて、ASR 監査をより包括的に把握できます。join 演算子を使用すると、共通のフィールドに基づいてテーブルをマージできます。以下は例です。

DeviceEvents
| join kind=inner (Alerts) on DeviceId
| where ActionType == "ASRRuleTriggered"
| project DeviceName, AlertSeverity, Timestamp

このクエリでは、DeviceId フィールドを基準に DeviceEvents テーブルと Alerts テーブルを結合しています。これにより、どのアラートが ASR ルールのトリガーに対応しているかを確認できます。

これらの基本的な技術と応用的な KQL の技術を習得することで、ASR 監査の機能を大幅に強化できます。意味のある洞察を引き出し、組織のセキュリティ対策について適切な判断を下せるようになります。

ASR 監査結果の解釈

出力形式の理解

KQL クエリを実行すると、照会するデータによって出力形式が異なります。これらの形式を理解すると、ASR 監査から実用的な洞察を引き出しやすくなります。検討すべき主な点は次のとおりです。

• Microsoft Defender ポータルでは、検出されたアクティビティの詳細なレポートを確認できます。これらのレポートから、攻撃対象领域の縮小ルールの有効性を追跡できます。
• ルールがトリガーされるとアラートが生成されるため、潜在的な脅威を即座に把握できます。
• Windows イベント ログを確認できます。具体的には、Microsoft-Windows-Windows Defender/Operational ログでイベント ID 1121 をフィルターすると、ASR ルールによってブロックされていたはずのアプリケーションを特定できます。

ASR 結果の分析

ASR 監査結果の分析は、セキュリティ対策の有効性を測るうえで欠かせません。次の手順で詳細な分析を行えます。

1. 監査モードを使用して、ASR ポリシーに関する洞察を収集します。
2. Microsoft Defender ポータルにアクセスし、「レポート」に移動します。
3. 「エンドポイント」で「攻撃対象の領域を減らすルール」を選択します。
4. ルールをフィルターしてメトリックを表示し、包括的なデータを得るために「すべて」を選択します。
5. 「監査された検出」を分析し、ブロックされていたはずの操作が必要かどうかを評価します。
6. デバイスが正しく設定されているかを確認するため、傾向と構成を定期的に見直します。
7. 「除外の追加」ページを使用して、特定の ASR ルールのヒットを管理します。

これらの手順に従うことで、監査結果を効果的に分析し、セキュリティ戦略を見直せます。

セキュリティ ギャップの特定

セキュリティ ギャップの特定は、ASR 監査プロセスの重要な部分です。KQL クエリで得た洞察を使うと、セキュリティ態勢の脆弱性を特定できます。ギャップの特定に役立つ主な方法は次のとおりです。

• データのパターンに注目します。たとえば、特定のデバイスが ASR ルールを頻繁にトリガーする場合は、追加のセキュリティ対策が必要かもしれません。
• ASR 監査の結果を時系列で比較します。この比較により、セキュリティ態勢が改善しているか、悪化しているかを把握できます。
• 高度な KQL クエリを使用して特定のインシデントを詳しく調べます。たとえば、DeviceEvents | where ActionType startswith 'Asr' のようなクエリを実行すると、ポリシーの改善に役立つ洞察を得られます。

セキュリティ ギャップを積極的に特定することで、先手を打って組織のセキュリティを強化し、潜在的な脅威のリスクを減らせます。

ASR 監査のベスト プラクティス

定期的な監査スケジュール

攻撃対象の領域を減らすルールの有効性を維持するには、定期的な監査スケジュールの設定が欠かせません。監査は少なくとも四半期ごとに実施する必要があります。この頻度により、セキュリティ環境の変化を常に把握できます。監査スケジュールを設定する際のヒントは次のとおりです。

• 具体的な日付を設定する: 四半期ごとに監査を実施する特定の日を選びます。日程を一定に保つことで、作業を忘れにくくなり、優先順位も付けやすくなります。
• チームを巻き込む: スケジュール設定の段階からセキュリティ チームを関与させます。作業負荷やその他の予定を考慮した最適な実施時期を、チームの意見から見極められます。
• 自動リマインダーを使用する: カレンダー ツールを活用して、今後の監査の通知を設定します。自動化により、監査の実施漏れを減らせます。

検出結果の文書化

監査中に検出結果を文書化することは、進捗の追跡と傾向の把握に欠かせません。文書化には構造化された形式を用意することをお勧めします。次の要素を含めることを検討してください。

• 監査日: 監査を実施した日付を記録します。
• 検出結果の概要: トリガーされた攻撃対象の領域を減らすルールを含め、主な検出結果を要約します。
• 推奨事項: 検出結果に基づき、実行可能な推奨事項を示します。この手順により、特定された問題に速やかに対処できます。
• フォローアップ アクション: 必要なフォローアップ作業を一覧化し、チームメンバーに担当を割り当てます。

詳細なドキュメントを残しておくことで、将来の監査に役立つ貴重なリソースになります。このリソースを使えば、時間の経過に伴う結果を比較し、セキュリティ戦略を見直すのに役立ちます。

継続的改善のための戦略

効果的な監査には、継続的な改善が欠かせません。監査プロセスを定期的に見直し、必要に応じて調整する必要があります。ASR の監査を強化するための戦略を以下に示します。

1. 傾向の分析: 監査結果のパターンを確認します。繰り返し発生する問題を特定すると、改善が必要な領域に焦点を当てやすくなります。
2. フィードバックの収集: チームメンバーに、監査プロセスに関するフィードバックを出すよう促しましょう。現場の知見が、価値のある改善につながることがあります。
3. 最新情報の把握: セキュリティと監査の手法に関する最新動向を追い続けましょう。ウェビナーに参加し、記事を読み、フォーラムに参加して、業界の他の人々から学びます。
4. 新しいアプローチの検証: 新しい監査の手法やツールを試すことをためらわないでください。さまざまな方法を検証すると、より効率的に監査を実施する方法が見つかることがあります。

これらのベストプラクティスを実践すれば、ASR の監査を強化し、組織全体のセキュリティ態勢を高めることができます。定期的な監査、詳細なドキュメント、そして継続的な改善への取り組みが、潜在的な脅威に先手を打つことに役立ちます。

KQL 監査でよくある課題

KQL クエリのトラブルシューティング

KQL を使用する際に、作業の妨げとなる問題に遭遇することがあります。効果的な監査のためには、これらのクエリのトラブルシューティングが欠かせません。よくある問題と解決策を以下に示します。

• 構文エラー: タイプミスや誤った構文がないか確認します。KQL は書式に敏感です。正しい演算子と関数を使用しているか確認してください。
• データ型の不一致: クエリ内のデータ型が、データベースで想定されている型と一致していることを確認します。たとえば、文字列と数値を比較するとエラーの原因になります。
• パフォーマンスの問題: クエリの実行が遅い場合は、最適化を検討してください。summarize 関数を使用すると、処理されるデータ量を減らせます。また、クエリの早い段階でデータをフィルターすることも有効です。

ヒント: クエリは必ず小さな単位に分けてテストしてください。この方法を使うと、問題を効率よく切り分けられます。

データ・ギャップへの対処

監査の実施中、データ・ギャップが大きな課題となることがあります。データの欠落や不完全さは、不正確な結論につながりかねません。これらのギャップに対処するための戦略を以下に示します。

1. 定期的なデータチェック: データソースの定期的なチェックをスケジュールします。関連するすべてのデータフィードが正しく機能していることを確認してください。
2. アラートの活用: 重要なデータポイントに対してアラートを設定します。この設定により、データが利用できなくなった場合にすばやく対応できます。
3. 相互検証: 監査データを他のソースと比較します。この方法により、不一致を特定し、欠落している情報を補完できます。

データ・ギャップに先手を打って対処することで、監査データの信頼性を高められます。この信頼性は、適切なセキュリティ上の判断を下すうえで欠かせません。

ASR のコンプライアンスの確保

組織のセキュリティ態勢を維持するには、ASR ルールへのコンプライアンスの確保が欠かせません。コンプライアンスを確保するために取るべき手順を以下に示します。

• 定期的な監査: ASR ルールが正しく適用されていることを確認するために、監査を頻繁に実施します。定期的なチェックにより、コンプライアンスからの逸脱を特定できます。
• ドキュメント作成: 監査の詳細な記録を残します。発見事項と実施した対応を文書化することで、説明責任が確保され、将来の監査の参照資料にもなります。
• トレーニング: ASR ルールと KQL の使い方について、チームにトレーニングを提供します。十分な知識を持つチームは、コンプライアンスを維持し、セキュリティの脅威に対応する能力が高まります。

これらの領域に注力することで、コンプライアンスへの取り組みを強化し、組織全体のセキュリティ戦略を高めることができます。

まとめると、ASR の監査に Advanced KQL を活用すると、セキュリティ監査のプロセスが大きく強化されます。分析を効率化し、脆弱性をより効果的に特定できます。ここでは重要なポイントをご紹介します。

これらの手法を継続的に実践し、監査プロセスを改善してください。セキュリティ対策の見直しを常に先回りして行いましょう。組織の安全がそこにかかっています！🔒

よくある質問

高度な KQL とは何ですか？

高度な KQL（Kusto Query Language）は、Microsoft Defender で大量のデータセットを分析するために使われる強力なクエリ言語です。セキュリティデータから効率的に洞察を抽出するのに役立ちます。

KQL の使用をどのように始めればよいですか？

まず Microsoft Defender にアクセスし、Kusto Query Explorer の操作に慣れてください。簡単なクエリを書いて練習し、言語の理解を深めましょう。

KQL クエリを自動化できますか？

はい、Azure Logic Apps や Power Automate を使って KQL クエリを自動化できます。これらのツールを使えば、クエリをスケジュール実行し、特定の条件に基づいてアラートを受け取れます。

KQL でよくあるエラーにはどのようなものがありますか？

よくあるエラーには、構文の誤り、データ型の不一致、パフォーマンスの問題があります。クエリの構造を必ず確認し、データ型が想定どおりであることを確かめてください。

ASR ルールの監査はどの程度の頻度で行うべきですか？

ASR の監査は少なくとも四半期ごとに実施してください。定期的な監査により、セキュリティの状態を把握し、ASR ルールへの準拠を確実にできます。

KQL をサポートする主なツールは何ですか？

KQL の主なツールには、Kusto Query Explorer、Azure Data Explorer、Microsoft Defender ポータルがあります。これらのツールは、クエリの作成とテストを行う環境を提供します。

KQL のスキルをどのように向上させればよいですか？

KQL のスキルを高めるには、定期的に練習し、トレーニングセッションに参加し、オンラインフォーラムに参加することが有効です。コミュニティと交流すると、貴重な洞察やヒントが得られます。

高度なハンティングと Defender：ASR 監査向けの高度な KQL の活用

「ASR 監査向けの高度な KQL」とは何ですか。また、高度なハンティングとどのように関係しますか？

「ASR 監査向けの高度な KQL」とは、攻撃対象領域の減少（ASR）ルールとその監査イベントに関する詳細な情報を明らかにするために作成された Kusto Query Language のクエリを指します。Defender の高度なハンティングや Microsoft 365 Defender の高度なハンティングでは、これらのクエリにより、脅威ハンティングチームやセキュリティ オペレーターが、監査モードのルールが設定されたデバイス、影響を受けるデバイスの一覧、Intune によるポリシーの展開状況、Microsoft Defender for Endpoint が検出した不審なアクティビティを特定できます。

ハンティングクエリを使って、ASR ルールが監査モードであることを確認するにはどうすればよいですか？

Defender の高度なハンティングクエリを使い、ルールのレポートや監査イベントを取得して、ルールが有効であることと、そのモード（監査またはブロック）を確認します。詳細な情報を明らかにする一般的な KQL では、ASR ルールのレポートをデバイスやイベントのテーブルと結合して監査モードのルールを確認し、過去 30 日間のルールイベントを表示できます。また、Intune ポリシーや Microsoft Defender XDR のテレメトリとの相互参照など、監査結果を検証するさまざまな方法も紹介しています。

Microsoft 365 Defender で ASR イベントのカスタム検出を作成できますか？

はい、Microsoft 365 Defender の高度なハンティングクエリを使って、カスタムの検出とルールを作成できます。攻撃ベクターやマルウェアのアクティビティに関する詳細な情報を明らかにする KQL を使えば、繰り返し発生するルールイベント、除外設定、Microsoft が監視を推奨する不審な監査イベントに対してアラートを出すカスタム検出を実装できます。さらに、それらの検出をルールのレポートや自動応答プレイブックに変換することもできます。

コンプライアンスのために ASR のアクティビティを報告し、ASR ルールのレポートを作成するにはどうすればよいですか？

検出ルールと Defender の高度なハンティングテーブルに対してクエリを実行し、過去 30 日間または任意の期間のイベントをエクスポートすることで、攻撃対象領域の減少ルールのレポートや ASR ルールのレポートを作成します。API や Microsoft 365 の組み込みのルールレポート機能を使うと、有効なルール、監査モードのルール、影響を受けるデバイス数、傾向を示すダッシュボードを作成できます。これは、ASR を最適化し、Intune およびオンプレミスのデバイス全体で ASR ルールの展開を管理する際に役立ちます。

クエリ結果に基づいて監査を検証し、ASR ルールを最適化する一般的な方法にはどのようなものがありますか？

ウォッチモードを検証する方法はいくつかあります。監査イベントの確認、デバイス間での監査ルールの比較、Intune ポリシーと展開状況の確認、そして高度なハンティング クエリによる脅威の探索です。これにより、監査モードで悪意のある動作が見過ごされていないかを確かめられます。検証結果をもとに監査とブロックのどちらにするかを判断し、必要に応じて除外を追加し、標準の保護ルールを調整するか追加の検出ルールを実装して ASR を最適化します。

Defender XDR と Microsoft Sentinel をまたいで、高度な KQL で脅威をハンティングするにはどうすればよいですか?

Defender for Endpoint、Microsoft Defender XDR のデータ、Microsoft Sentinel のログの間を行き来する高度なハンティング クエリを作成します。ASR の監査イベントを、エンドポイントのテレメトリ、マルウェア検出、ネットワークの指標と関連付けて、疑わしいパターンを見つけ出します。このアプローチにより脅威ハンティングが可能になり、監査イベントが正当なソフトウェアによるものか、除外が必要か、あるいは迅速な対処が必要な実際の攻撃の試みかを判断できます。

影響を受けたデバイスやルール固有の詳細を表示するクエリには、何を含めればよいですか?

KQL には DeviceId、DeviceName、Timestamp、ActionType、RuleId、RuleName、DetectionSource などのフィールドを含めます。ASR ルールのレポートまたはルールのイベントを、デバイスのインベントリと Intune 登録テーブルに結合し、影響を受けたデバイスの一覧、デバイスごとに有効なルール、ルールが監査モードかブロック モードかを表示します。このように詳細情報を示す KQL があると、修復の優先順位を決めやすくなり、ルールのレポートも更新しやすくなります。

高度なハンティング クエリはどのくらいの頻度で実行し、どこまで過去にさかのぼって検索すればよいですか (例: 30 日間)?

脅威モデルに合わせて、継続的に実行するか、スケジュールに従って実行してください。一般的な基準は、傾向や繰り返し発生するイベントを把握するために過去 30 日間を分析することです。Microsoft 365 Defender のスケジュール済みクエリまたは API を使用すると、ルールのレポート作成を自動化できます。インシデント対応のニーズに応じて検索期間を調整してください。ルールを監査モードでテストしている場合は、ブロック モードに切り替える前に十分なテレメトリが得られるよう調整してください。

除外とブロック モードは ASR の監査にどのように影響し、クエリではどの点を考慮する必要がありますか?

除外とブロック モードは ASR の動作を変えます。除外は既知の正当なアプリに対するアラートを抑制し、ブロック モードは防止を強制します。ハンティング クエリでは、除外されたプロセスをフィルタリングするかフラグを付けて除外を考慮し、ポリシーの取得元 (Intune、ローカル ポリシー) を示すフィールドを含める必要があります。これにより、監査イベントを正しく解釈でき、監査からブロックへの移行によって業務上重要なアプリケーションが予期せず停止することを防げます。

KQL の学習や、ASR 向けの効果的な高度なハンティング クエリの作成について、詳しい情報はどこで得られますか?

まず Microsoft Learn の Defender の高度なハンティングと、Microsoft 365 Defender の高度なハンティングに関するモジュールから始めてください。そのうえで、サンプル データセットと実際の ASR ルールのイベントを使い、詳細情報を示す KQL の作成を練習します。Microsoft Defender for Endpoint のドキュメント、Microsoft Defender の攻撃対象領域の削減に関するガイダンス、コミュニティが公開しているハンティング クエリを組み合わせると、脅威ハンティング、ルールのレポート作成、ASR ルールの効果的な管理に関するスキルを広げられます。

データにギャップが見つかった場合はどうすればよいですか?

データのギャップを見つけた場合は、データソースを定期的に確認してください。重要なデータポイントにアラートを設定しておくと、データが利用できなくなった際にすばやく対応できます。