Microsoft Sentinelの UEBA 動作を使用して生のセキュリティ ログを行動分析情報に変換する

Microsoft Sentinelの User and Entity Behavior Analytics (UEBA) 動作レイヤーは、大量の生ログを集約して、明確でプレーンな言語のセキュリティ アクション パターンにまとめ、構造化された方法で "誰が誰に何をしたか" を説明します。

アラートや異常とは異なり、動作は必ずしもリスクを示すわけではありません。次のように強化することで、調査、ハンティング、検出のためにデータを最適化する抽象化レイヤーが作成されます。

• 効率: 関連するイベントをまとまりのあるストーリーにステッチすることで、調査時間を短縮します。
• Clarity: ノイズの多い低レベルのログをプレーンな言語の概要に変換します。
• コンテキスト: 即時のセキュリティ関連のために、MITRE ATT&CK マッピングとエンティティ ロールを追加します。
• 整合性: さまざまなログ ソース間で統一されたスキーマを提供します。

この抽象化レイヤーを使用すると、すべてのログ ソースについて深い知識を必要とせずに、セキュリティ操作全体で脅威の検出、調査、応答を迅速に行うことができます。

この記事では、UEBA 動作レイヤーのしくみ、動作レイヤーを有効にする方法、および動作を使用してセキュリティ操作を強化する方法について説明します。

UEBA 動作レイヤーの完全な概要とデモについては、UEBA 動作ウェビナーをご覧ください。

UEBA 動作レイヤーのしくみ

動作は、Microsoft Sentinelの User and Entity Behavior Analytics (UEBA) 機能の一部であり、異常検出とエンリッチ調査を補完する正規化されたコンテキスト化されたアクティビティの概要を提供します。

動作、異常、アラートを比較する

次の表は、動作と異常とアラートの違いを示しています。

動作の種類とレコード

UEBA 動作レイヤーを有効にすると、Microsoft Sentinelは、Sentinel ワークスペースに収集したサポートされているセキュリティ ログをほぼリアルタイムで処理し、次の 2 種類の動作パターンを要約します。

UEBA 動作レイヤーは、各動作のロジックに固有の調整された時間間隔で動作を要約し、パターンを識別したとき、またはタイム ウィンドウが閉じるとすぐに動作レコードを作成します。

各動作レコードには、次のものが含まれます。

• 簡単でコンテキストに基づく説明: セキュリティ関連の用語で何が起こったか (たとえば、誰が誰に何をしたか、なぜ重要なのか) の自然言語の説明。
• 統合スキーマと基になる生ログへの参照: すべての動作では、さまざまな製品とログの種類にわたって一貫性のあるデータ構造が使用されるため、アナリストは異なるログ形式を変換したり、大量のテーブルを結合したりする必要はありません。
• MITRE ATT&CK マッピング: すべての動作に関連する MITRE の戦術と手法がタグ付けされ、業界標準のコンテキストがひと目でわかります。 何が起こったのかだけでなく、攻撃フレームワークやタイムラインにどのように適合するかも確認できます。
• エンティティ関係マッピング: 各動作は、関連するエンティティ (ユーザー、ホスト、IP アドレス) とそのロール (アクター、ターゲット、またはその他) を識別します。

動作抽象化レイヤー

次の図は、UEBA 動作レイヤーが生ログを、セキュリティ操作を強化する構造化された動作レコードに変換する方法を示しています。

動作のストレージとテーブル

UEBA 動作レイヤーは、次の 2 種類のテーブルに動作レコードを格納します。

• 動作のタイトル、説明、MITRE マッピング、カテゴリ、および生ログへのリンクを含む動作情報テーブル。
• 動作に関連するエンティティ テーブル。このテーブルには、動作に関連するすべてのエンティティとそのロールが一覧表示されます。

これらのテーブルは、検出ルール、調査、インシデント分析のために既存のワークフローとシームレスに統合されます。 疑わしいイベントだけでなく、あらゆる種類のセキュリティ アクティビティを処理し、通常の動作パターンと異常な動作パターンの両方を包括的に可視化します。

動作テーブルの使用については、「動作のクエリを実行 するためのベスト プラクティスとトラブルシューティングのヒント」を参照してください。

ユース ケースと例

アナリスト、ハンター、検出エンジニアが、調査、ハンティング、アラートの作成中に動作を使用する方法を次に示します。

調査とインシデントエンリッチメント

動作により、SOC アナリストは、複数の生のログ テーブル間でピボットすることなく、アラートの周囲で何が起こったかをすぐに明確にできます。

• 動作のないワークフロー: アナリストは、多くの場合、イベント固有のテーブルに対してクエリを実行し、結果を一緒にステッチすることで、タイムラインを手動で再構築する必要があります。

  例: 不審な AWS アクティビティでアラートが発生します。 アナリストは、 AWSCloudTrail テーブルに対してクエリを実行し、ファイアウォール データにピボットして、ユーザーまたはホストが何を行ったかを理解します。 これには、各スキーマに関する知識が必要であり、トリアージが遅くなります。

• 動作を持つワークフロー: UEBA 動作レイヤーは、関連するイベントをインシデントにアタッチしたり、オンデマンドでクエリしたりできる動作エントリに自動的に集計します。

  例： アラートは、資格情報流出の可能性を示します。 BehaviorInfoテーブルでは、アナリストは、MITRE Technique T1552 (セキュリティで保護されていない資格情報) にマップされた AWS IAM by User123 による不審なマス シークレット アクセスの動作を確認します。 UEBA の動作レイヤーでは、20 個の AWS ログ エントリを集計することで、この動作が生成されました。 アナリストは、User123 が、20 個すべてのログ エントリを手動で確認することなく、インシデントをエスカレートするための重要なコンテキストである多くのシークレットにアクセスしたことをすぐに理解しています。

脅威の捜索

動作を使用すると、ハンターは複雑な結合を記述したり、生のログを自分で正規化したりするのではなく、TCP とアクティビティの概要を検索できます。

• 動作のないワークフロー: ハントには、複雑な KQL、テーブル結合、およびすべてのデータ ソース形式に関する知識が必要です。 重要なアクティビティは、組み込みのセキュリティ コンテキストがほとんどない大規模なデータセットに埋もれている可能性があります。

  例： 偵察の兆候を探す場合は、 AWSCloudTrail イベント と 特定のファイアウォール接続パターンを個別にスキャンする必要があります。 コンテキストは主にインシデントやアラートに存在し、プロアクティブハンティングが困難になります。

• 動作を持つワークフロー: 動作は正規化され、エンリッチされ、MITRE の戦術と手法にマップされます。 ハンターは、各ソースのスキーマに依存することなく、意味のあるパターンを検索できます。

  ハンターは、戦術 (Categories)、手法、タイトル、またはエンティティによって BehaviorInfo テーブルをフィルター処理できます。 例:

  BehaviorInfo 
  | where Categories has "Discovery" 
  | summarize count() by Title 
  

  ハンターは次のことができます。

  • Title フィールドでcount distinctを使用して、まれな動作を特定します。
  • 興味深い動作の種類を調べて、関連するエンティティを特定し、さらに調査します。
  • BehaviorId列とAdditionalFields列を使用して生ログにドリルダウンします。これは、多くの場合、基になる生ログを参照します。

  例：Title列で "資格情報の列挙" を使用して動作を検索する、ステルス資格情報アクセス クエリを検索するハンター。 結果は 、"ユーザー AdminJoe によるコンテナーからの資格情報ダンプの試行" ( CyberArk ログから派生) のいくつかのインスタンスを返します。 アラートは発生していませんが、この動作は AdminJoe では珍しく、詳細な Vault 監査ログで検出するのが困難な調査を促します。

  ハンターは次の方法で狩りをすることもできます。

  • MITRE 戦術:

    // Find behaviors by MITRE tactic
    BehaviorInfo
    | where Categories == "Lateral Movement"
    

  • 技術：

    // Find behaviors by MITRE technique
    BehaviorInfo
    | where AttackTechniques has "T1078" // Valid Accounts
    | extend AF = parse_json(AdditionalFields)
    | extend TableName = tostring(AF.TableName)
    | project TimeGenerated, Title, Description, TableName
    

  • 特定のユーザー:

    // Find all behaviors for a specific user over last 7 days
    BehaviorInfo
    | join kind=inner BehaviorEntities on BehaviorId
    | where TimeGenerated >= ago(7d)
    | where EntityType == "User" and AccountUpn == "user@domain.com"
    | project TimeGenerated, Title, Description, Categories
    | order by TimeGenerated desc
    

  • まれな動作 (潜在的な異常):

    // Find rare behaviors (potential anomalies)
    BehaviorInfo
    | where TimeGenerated >= ago(30d)
    | summarize Count=count() by Title
    | where Count < 5 // Behaviors seen less than 5 times
    | order by Count asc
    

アラートと自動化

動作は、組み込みのコンテキストで正規化された高品質の信号を提供することでルール ロジックを簡素化し、新しい相関関係の可能性を実現します。

• 動作のないワークフロー: ソース間の相関ルールは、各ログ形式が異なるため、複雑です。 多くの場合、ルールには次のものが必要です。

  • 正規化ロジック
  • スキーマ固有の条件
  • 複数の個別ルール
  • 生のアクティビティではなくアラートへの依存

  また、低レベルのイベントによって駆動される場合、自動化が頻繁にトリガーされる可能性もあります。

• 動作を持つワークフロー: 動作は既に関連するイベントを集計しており、MITRE マッピング、エンティティ ロール、一貫性のあるスキーマが含まれているため、検出エンジニアはより簡単で明確な検出ルールを作成できます。

  例：潜在的なキー侵害と特権エスカレーション シーケンスに関するアラートを生成するために、検出エンジニアは、"ユーザーが "新しい AWS アクセス キーの作成" 動作を持ち、その後に 1 時間以内に "AWS での特権の昇格" 動作が続く場合にアラートを生成する」 というロジックを使用して検出ルールを記述します。

  UEBA 動作レイヤーがないと、このルールでは、生の AWSCloudTrail イベントを一緒にステッチし、ルール ロジックでそれらを解釈する必要があります。 動作では、スキーマが統合されているため、スキーマの変更をログに記録するのは簡単で回復性があります。

  動作は、自動化のための信頼性の高いトリガーとしても機能します。 危険でないアクティビティに対するアラートを作成する代わりに、動作を使用して自動化をトリガーします (メールの送信や検証の開始など)。

サポートされているデータ ソースと動作

サポートされているデータ ソースと、これらのデータ ソースにログを送信するベンダーまたはサービスの一覧は進化しています。 UEBA 動作レイヤーは、収集したログに基づいて、サポートされているすべてのベンダーの分析情報を自動的に集計します。

現在、UEBA 動作レイヤーは、従来、Microsoft Sentinelで簡単な動作コンテキストが存在しない、Microsoft 以外のデータ ソースに焦点を当てています。

¹CommonSecurityLog には、多くのベンダーからのログを含めることができます。 UEBA の動作レイヤーでは、 サポートされているベンダーとログの種類に対してのみ動作が生成されます。 テーブルがサポートされていないベンダーからログを受信した場合、データ ソースが接続されていても動作は表示されません。

前提条件

UEBA 動作レイヤーを使用するには、次のものが必要です。

• Defender ポータルにオンボードされているMicrosoft Sentinel ワークスペース。
• サポートされている 1 つ以上の データ ソース を Analytics レベルに取り込みます。 データ層の詳細については、「Microsoft Sentinelでのデータ層と保持の管理」を参照してください。

必要なアクセス許可

UEBA 動作レイヤーを有効にして使用するには、次のアクセス許可が必要です。

Defender ポータルでの統合 RBAC の詳細については、「Microsoft Defender XDR統合ロールベースのアクセス制御 (RBAC)」を参照してください。

UEBA 動作レイヤーを有効にする

UEBA の動作の集計を開始するには、 少なくとも 1 つのサポートされているデータ ソースを接続してください。 UEBA の動作レイヤーは、サポートされているデータ ソースが接続され、アクティブに分析レベルにログを送信している場合の動作のみを集計します。

ワークスペースで UEBA 動作レイヤーを有効にするには:

1. Defender ポータルで、[システム >設定] > Microsoft Sentinel > SIEM ワークスペースを選択します。

2. UEBA 動作レイヤーを有効にするSentinel ワークスペースを選択します。

3. [ 動作分析を有効にする] > [UEBA > 新規を構成する] を選択します。動作レイヤー。

4. [動作の有効化] レイヤーをオンに切り替えます。

5. [ すべてのデータ ソースの接続 ] を選択するか、一覧から特定のデータ ソースを選択します。

   サポートされているデータ ソースを Sentinel ワークスペースにまだ接続していない場合は、[コンテンツ ハブに移動] を選択して、関連するコネクタを見つけて接続します。

   

6. [接続] を選択します。

価格モデル

UEBA 動作レイヤーを使用すると、次のコストが発生します。

• 追加のライセンス コストなし:動作は、Microsoft Sentinelの一部として含まれます。 別の SKU、UEBA アドオン、または追加のライセンスは必要ありません。 ワークスペースがSentinelに接続され、Defender ポータルにオンボードされている場合は、追加の機能コストなしで動作を使用できます。

• ログ データ インジェスト料金:動作レコードは、Sentinel ワークスペースの SentinelBehaviorInfo テーブルとSentinelBehaviorEntities テーブルに格納されます。 各動作はワークスペースのデータ インジェスト ボリュームに影響し、既存の Log Analytics/Sentinel インジェスト レートで課金されます。 動作は付加的です。既存の生ログは置き換えられません。

動作のクエリを実行するためのベスト プラクティスとトラブルシューティングのヒント

このセクションでは、Defender ポータルとSentinel ワークスペースの両方から動作を照会する方法について説明します。 スキーマは同じですが、データ スコープは異なります。

• Defender ポータルの動作テーブルには、接続された Defender サービスからの UEBA の動作と動作 (Microsoft Defender for Cloud AppsやクラウドのMicrosoft Defenderなど) が含まれます。
• Sentinel ワークスペースでは、動作テーブルには、その特定のワークスペースに取り込まれたログから生成された UEBA 動作のみが含まれます。

次の表は、各環境で使用する動作テーブルを示しています。

動作を使用するより実用的な例については、「 ユース ケースと例」を参照してください。

Kusto 照会言語 (KQL) の詳細については、「Kusto クエリ言語の概要」を参照してください。

• Defender ポータルで UEBA の動作をフィルター処理する

  BehaviorInfoテーブルとBehaviorEntities テーブルには、すべての UEBA 動作が含まれており、Microsoft Defender サービスからの動作も含まれる場合があります。

  Microsoft Sentinel UEBA 動作レイヤーから動作をフィルター処理するには、ServiceSource列を使用します。 例:

  BehaviorInfo
  | where ServiceSource == "Microsoft Sentinel"
  

  

• 動作から生ログへのドリルダウン

  SupportingEvidence フィールドの元のイベント ID への参照を含む、BehaviorInfoの [AdditionalFields] 列を使用します。

  

  SupportingEvidence フィールドの値に対してクエリを実行して、動作に影響を受けた生のログを見つけます。

  

• Join BehaviorInfo と BehaviorEntities

  BehaviorInfoをBehaviorEntitiesに結合するには、[BehaviorId] フィールドを使用します。

  例:

  BehaviorInfo
  | join kind=inner BehaviorEntities on BehaviorId
  | where TimeGenerated >= ago(1d)
  | project TimeGenerated, Title, Description, EntityType, EntityRole, AccountUpn
  

  これにより、各動作と、それに関連する各エンティティが提供されます。 エンティティの AccountUpn または識別情報は BehaviorEntitiesにありますが、 BehaviorInfo はテキスト内の "User" または "Host" を参照する場合があります。

• 動作データインジェストを監視する

  動作データ インジェストを監視するには、 Usage テーブルに対して、 SentinelBehaviorInfo と SentinelBehaviorEntitiesに関連するエントリを照会します。

• 動作に基づいて自動化、ブック、検出ルールを作成する

  • BehaviorInfo テーブルは、Defender ポータルの検出ルールまたはオートメーション プレイブックのデータ ソースとして使用します。 たとえば、特定の動作が表示されたときにトリガーされるスケジュールされたクエリ ルールを作成します。
  • Azure Monitor ブックと、Sentinel ワークスペースに直接構築された成果物については、Sentinel ワークスペース内のSentinelBehaviorInfoテーブルとSentinelBehaviorEntities テーブルに対してクエリを実行してください。

トラブルシューティング

• 動作が生成されていない場合: サポートされているデータ ソースがアクティブにログを Analytics レベルに送信していることを確認し、データ ソースのトグルがオンになっていることを確認し、有効にしてから 15 分から 30 分待ちます。
• 予想よりも少ない動作が表示されます。サポートされている動作の種類のカバレッジは部分的で増加しています。 詳細については、「 サポートされているデータ ソースと動作」を参照してください。 また、特定の動作の種類のインスタンスが非常に少ない場合、UEBA 動作レイヤーで動作パターンを検出できない場合もあります。
• 動作数: 1 つの動作が数十個または数百個の未加工イベントを表す場合があります。これは、ノイズを減らすために設計されています。

制限事項

現在、これらの制限は UEBA 動作レイヤーに適用されます。

• テナントごとに 1 つのSentinel ワークスペースで動作を有効にすることができます。
• UEBA 動作レイヤーは、 サポートされているデータ ソースとベンダーまたはサービスの限られたセットに対して動作を生成します。
• UEBA の動作レイヤーでは、現在、サポートされているソースであっても、可能なすべてのアクションまたは攻撃手法がキャプチャされるわけではありません。 一部のイベントでは、対応する動作が生成されない場合があります。 動作が存在しないということは、アクティビティが発生しなかったことを意味するとは考えないでください。 何かが見つからない可能性がある場合は、常に生のログを確認してください。
• 動作は、イベントの集計とシーケンスによってノイズを減らすことを目的としますが、動作レコードが多すぎる可能性があります。 カバレッジと関連性の向上に役立つ特定の行動の種類に関するフィードバックをお待ちしております。
• 動作はアラートや異常ではありません。 これらは中立的な観察であり、悪意のある、または良性として分類されません。 動作の存在は、"これは脅威です" ではなく "これが起こった" ことを意味します。 異常検出は UEBA で分離されたままです。 判断を使用するか、UEBA 異常データと動作を組み合わせて注目すべきパターンを特定します。