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

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

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

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

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

このセクションでは、UEBAビヘイビアレイヤーの仕組み、ビヘイビアレイヤーの有効化方法、そしてビヘイビアを使ってセキュリティ運用を強化する方法について説明します。

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

UEBA 動作レイヤーのしくみ

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

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

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

Microsoft Sentinelは、最初に見られた活動、異常な行動量、異常な値、脅威インテリジェンスマッチなど、異常なインサイトを行動記録に直接追加することもできます。 詳細は「 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 
  

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

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

  例: ステルス性の高い資格情報アクセスを探しているハンターは、Title 列で「資格情報の列挙」を含む挙動を検索します。 結果には、「ユーザー AdminJoe による Vault からの資格情報のダンプの試行」（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
    

  • 特定のユーザー — 行動レコードとエンティティデータを結合し、過去7日間の特定のユーザーの行動を一覧にし、各行動のタイムスタンプ、タイトル、説明、カテゴリを示します。

    // 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ティアにログを接続し、積極的に送信してください。 UEBAの挙動レイヤーは、サポートされたデータソースが接続され、ログを積極的に送信している場合にのみ振る舞いを生成します。 データ層の詳細については、「Microsoft Sentinelでのデータ層と保持の管理」を参照してください。

必要なアクセス許可

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

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

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

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

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

1. Defender ポータルで、[設定] > Microsoft Sentinel > UEBA を選択します。

2. 新規! 動作レイヤー を選択します。

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

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

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

   

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

価格モデル

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"
  

  

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

  AdditionalFields フィールド内の元のイベント ID への参照を含む、BehaviorInfo の SupportingEvidence 列を使用してください。

  

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

  

• BehaviorInfo と BehaviorEntities を結合

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

  以下のクエリは BehaviorInfo と BehaviorEntities を組み合わせ、前日の行動記録に関連するエンティティの詳細を豊かにし、調査中に関与したユーザー、ホスト、IPアドレスとともに各行動を確認できます。

  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 テーブルに対してクエリを実行してください。

トラブルシューティング

UEBA の動作に関する一般的な問題をトラブルシューティングするには、次のヒントを使用します。

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

制限事項

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

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