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

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

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

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

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

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

UEBA ビヘイビアー レイヤーのしくみ

動作は、Microsoft Sentinel の ユーザーとエンティティの行動分析 (UEBA) 機能の一部であり、異常検出を補完し、調査を強化する、正規化されたコンテキスト化されたアクティビティの概要を提供します。 次の表は、動作と異常とアラートの違いを示しています。

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

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

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

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

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

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

ユースケースと事例

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

調査とインシデント情報の充実化

動作により、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
    

  • 特定のユーザー:

    // 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 以外のデータ ソースに焦点を当てています。

[前提条件]

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

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

権限が必要です

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

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

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 ワークスペースで動作を照会するためのベスト プラクティスとトラブルシューティングのヒントについて説明します。 動作を使用するより実用的な例については、「 ユース ケースと例」を参照してください。

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

• BehaviorInfo と BehaviorEntities のクエリを実行して Defender ポータルの動作データにアクセスする

  • BehaviorInfo テーブルには、"何が起こったか" を説明する動作インスタンスごとに 1 つのレコードが含まれています。 テーブル スキーマの詳細については、「 BehaviorInfo (プレビュー)」を参照してください。

  • BehaviorEntitiesテーブルには、各動作に関連するエンティティが一覧表示されます。 テーブル スキーマの詳細については、 BehaviorEntities (プレビュー) を参照してください。

  • 統合ビュー: BehaviorInfo テーブルと BehaviorEntities テーブルには、すべての UEBA 動作が含まれており、これらのサービスから動作を収集する場合は、Microsoft Defender for Cloud Apps と Microsoft Defender for Cloud の動作も含まれる場合があります。

    Microsoft Sentinel UEBA 動作レイヤーから動作をフィルタリングするには、ServiceSource 列を使用します。 例えば次が挙げられます。

    BehaviorInfo
    | where ServiceSource == "Microsoft Sentinel"
    

    

• 動作から生ログへのドリルダウン: AdditionalFieldsの BehaviorInfo 列を使用します。この列には、SupportingEvidence フィールドの元のイベント ID への参照が含まれています。

  

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

  

• Join BehaviorInfo と BehaviorEntities: BehaviorId フィールドを使用して、BehaviorInfoとBehaviorEntitiesを結合します。

  例えば次が挙げられます。

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

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

• Sentinel ワークスペースに動作データが格納されている場所:

  • Sentinel ワークスペースでは、動作データは SentinelBehaviorInfo テーブルと SentinelBehaviorEntities テーブルに格納されます。 テーブル スキーマの詳細については、「 SentinelBehaviorInfo 」および 「SentinelBehaviorEntities」を参照してください。
  • データの使用状況を監視するには、SentinelBehaviorInfo テーブルでSentinelBehaviorEntitiesテーブル名とUsageを探します。

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

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

トラブルシューティング

• 動作が生成されていない場合: サポートされているデータ ソースが Analytics レベルにログをアクティブに送信していることを確認し、データ ソースの切り替えがオンになっていることを確認し、有効にしてから 15 ~ 30 分待ちます。
• 予想よりも少ない動作が表示されます。サポートされている動作の種類の範囲が部分的に拡大しています。 特定の動作の種類のインスタンスが非常に少ない場合は、UEBA 動作レイヤーで動作パターンを検出できない場合もあります。
• 動作数: 1 つの動作が数十から数百の生イベントを表す可能性があります。これは、ノイズを減らすために設計されています。

パブリック プレビューの制限事項

これらの制限は、UEBA 動作レイヤーのパブリック プレビュー中に適用されます。

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