重要
カスタム検出は、SIEM Microsoft Defender XDR全体で新しいルールMicrosoft Sentinel作成するための最良の方法になりました。 カスタム検出を使用すると、インジェスト コストを削減し、無制限のリアルタイム検出を取得し、自動エンティティ マッピングを使用してDefender XDRデータ、関数、修復アクションとシームレスに統合できます。 詳細については、 このブログを参照してください。
この記事では、Microsoft Sentinelのスケジュールされた分析ルールの実行で発生する可能性がある特定の問題に対処する方法について説明します。
問題: クエリ結果にイベントが表示されない
イベントのグループ化がイベントごとにアラートをトリガーするように設定されている場合、後で表示されるクエリ結果が見つからないか、予想とは異なる場合があります。 たとえば、関連するインシデントを調査するときに後でクエリの結果を表示し、その調査の一環として、このクエリの以前の結果に戻ることにします。
結果はアラートと共に自動的に保存されます。 ただし、結果が大きすぎる場合、結果は保存されません。また、クエリ結果を再度表示するときにデータは表示されません。
インジェストの遅延がある場合、または集計によってクエリが決定的でない場合、アラートの結果が、クエリを手動で実行して表示される結果とは異なる場合があります。
この問題を解決するために、ルールにこのイベント グループ設定がある場合、Microsoft Sentinelは、クエリの結果に OriginalQuery フィールドを追加します。 既存の [クエリ] フィールドと新しいフィールドの比較を次に示します。
| フィールド名 | Contains | このフィールドでのクエリの実行 結果は.... |
|---|---|---|
| Query | アラートのこのインスタンスを生成したイベントの圧縮レコード。 | アラートのこのインスタンスを生成したイベント。 10 キロバイトに制限されます。 |
| OriginalQuery | 分析ルールで記述された元のクエリ。 | クエリが実行される期間の最新のイベント。クエリによって定義されたパラメーターに適合します。 |
つまり、 OriginalQuery フィールドは、既定のイベント グループ設定で クエリ フィールドが動作するように動作します。
問題: スケジュールされたルールの実行に失敗したか、名前に AUTO DISABLED が追加された状態で表示される
スケジュールされたクエリ ルールの実行に失敗することはまれですが、発生する可能性があります。 Microsoft Sentinelは、障害の特定の種類とその原因となった状況に基づいて、障害を一時的または永続的に分類します。
一時的なエラー
一時的な障害が発生するのは、一時的な状況が原因で発生し、すぐに通常の状態に戻り、その時点でルールの実行が成功します。 一時的なものとして分類Microsoft Sentinelエラーの例を次に示します。
- ルール クエリの実行に時間がかかり、タイムアウトします。
- データ ソースと Log Analytics 間、または Log Analytics と Microsoft Sentinel間の接続の問題。
- その他の新しい不明なエラーは、一時的なものと見なされます。
一時的な障害が発生した場合、Microsoft Sentinelは、事前に設定された間隔と増加し続ける間隔の後、1 ポイントまでルールを再実行し続けます。 その後、ルールは次回スケジュールされた時刻にのみ再実行されます。 一時的な障害が原因で、ルールが自動ディスタブルになることはありません。
永続的なエラー - ルールの自動ディスタブル
永続的なエラーは、ルールの実行を許可する条件の変更が原因で発生します。これは、人間の介入なしでは以前の状態に戻ることはできません。 永続的に分類されるエラーの例を次に示します。
- (ルール クエリが操作された) ターゲット ワークスペースが削除されました。
- (ルール クエリが操作された) ターゲット テーブルが削除されました。
- ターゲット ワークスペースからMicrosoft Sentinelが削除されました。
- ルール クエリで使用される関数は無効です。変更または削除されました。
- ルール クエリのいずれかのデータ ソースに対するアクセス許可が変更されました (例を参照)。
- ルール クエリのデータ ソースの 1 つが削除されました。
同じ種類と同じルールに対して、一定の数の連続する永続的なエラーが発生した場合、Microsoft Sentinelはルールの実行を停止し、次の手順も実行します。
- ルールを無効にします。
- ルールの名前の先頭に "AUTO DISABLED" という単語を追加します。
- エラーの理由 (および無効化) をルールの説明に追加します。
規則リストを名前で並べ替えることで、自動ディスタブルルールの存在を簡単に判断できます。 自動無効ルールは、リストの上部またはその近くに存在します。
SOC マネージャーは、自動的に無効なルールが存在するために規則一覧を定期的にチェックする必要があります。
リソース ドレインによる永続的なエラー
別の種類の永続的なエラーは、 不適切に構築されたクエリ により、ルールが 過剰なコンピューティング リソースを 消費し、システムのパフォーマンス低下のリスクがあるために発生します。 Microsoft Sentinelがこのようなルールを識別する場合、他の種類の永続的なエラーに関して説明したのと同じ 3 つの手順を実行します。ルールを無効にし、ルール名に "AUTO DISABLED" を付加し、エラーの理由を説明に追加します。
ルールを再度有効にするには、クエリでリソースが多すぎる原因となる問題に対処する必要があります。 詳細については、以下を参照してください:
サブスクリプション/テナント間でアクセスが失われたための永続的なエラー
データ ソースのアクセス許可の変更 (一覧を参照) によって永続的なエラーが発生する可能性がある特定の例の 1 つは、Microsoft セキュリティ ソリューション プロバイダー (MSSP) の場合、または分析ルールがサブスクリプションまたはテナント間でクエリを実行するその他のシナリオに関係します。
分析ルールを作成すると、アクセス許可トークンがルールに適用され、一緒に保存されます。 このトークンにより、ルールのクエリによって参照されるテーブルを含むワークスペースにルールがアクセスでき、ルールの作成者がそのワークスペースへのアクセスを失った場合でも、このアクセスが維持されます。
ただし、MSSP の場合に何が起こるかなど、他のサブスクリプションまたはテナントのワークスペースにアクセスするルールが作成された場合、Microsoft Sentinelは、顧客データへの不正アクセスを防ぐために追加のセキュリティ対策を講じます。 これらの種類のルールには、独立したアクセス トークンではなく、ルールを作成したユーザーの資格情報が適用されます。 ユーザーが他のテナントにアクセスできなくなった場合、ルールは動作を停止します。
サブスクリプション間またはテナント間のシナリオでMicrosoft Sentinelを操作し、アナリストまたはエンジニアのいずれかが特定のワークスペースへのアクセスを失った場合、そのユーザーによって作成されたすべてのルールは動作を停止します。 "リソースへのアクセスが不十分" に関する正常性監視メッセージが表示され、ルールは 前に説明した手順に従って自動的に無効になります。
次の手順
詳細については、以下を参照してください。