はじめに
ご無沙汰しております。@hkomachi です。
なんか、この時期にしか記事書かない感じになっていますが、1年分の思いをここにぶつけていきたいと思います。
最近Sentinelを活用して頂いているお客様が増えており、誠にありがとうございます。
分析ルールやSOARを活用して、Sentinelが皆さまの日々の業務を効率化するお手伝いができたらいいな と思っているのですが、そんな中で最近よく聞くキーワードがあります。
「UEBA」
正しく書くと「User and Entity Behavior Analytics」となって、読んで字のごとく、ユーザーとエンティティの行動分析なのですが、これが昨今のAIブームの影響で独り歩きしている感じがします。
UEBAは何でもできる魔法の機能！ みたいな理解が暴走している感じがするので、今日はこのUEBAを正しくご理解いただこうと思います。
UEBA（User and Entity Behavior Analytics）とは？
UEBA ですが、「User and Entity Behavior Analytics」つまり、ユーザーやその他のエンティティ(ホスト、IP アドレス、アプリケーション等)に対するふるまい検知 というのが一般的な解釈だと思います。
そして、そこに対する期待値としては、
・UEBA機能を使うと通常の分析機能で見つける事ができなかった不審なふるまいが見つけられる！
・今、人間がログをみて手動で不審だと判断している部分を自動化できる！
・いっそもう分析ルールなんか書かないでUEBAで検出されたアラートを拾えばいいじゃないか！
と言ったところではないでしょうか？
この理解ですが、少なくともSentinel のUEBA機能についていうのであれば、半分は正しく、半分は間違いです。
以下、Sentinel のUEBA機能の概要の公開情報です。
ここにも記載がありますが、
「時間とピア グループの期間全体にわたる組織のエンティティ (ユーザー、ホスト、IP アドレス、アプリケーションなど) のベースライン行動プロファイルを構築します。 さまざまな手法や機械学習機能を使用して、Microsoft Sentinel で異常なアクティビティを特定でき、資産が侵害されているかどうかを判定するのに役立ちます。
となっており、確かに不審なふるまいを検知する事は可能です。
ただし、それ自体がアラートが上がるわけではなく
「侵害されているかどうかを判定するのに役立つ」
つまり補足情報として判断に利用できる というのがSentinelのUEBA機能のコンセプトとなります。
では、もう少しSentinel のUEBA機能を紐解いていきましょう。
UEBA 分析アーキテクチャ
以下がUEBAの分析アーキテクチャ図になりますが、個人的にはこれが誤解の原因だと思っています。
Sentinelは確かに様々なログを自身に取り込んで分析する事が可能です。しかし、現時点でUEBAエンジンがその分析対象として利用可能なデータソースは、以下の公開情報にもある通り4種類のみとなります。
・Microsoft Entra ID サインイン ログ
・Microsoft Entra ID 監査ログ
・Azure のアクティビティ ログ
・Windows セキュリティ イベント
UEBAはこのデータソースおよびEntra IDのユーザー情報（所属セキュリティグループ、地理的な場所、デバイス等）を利用して、ユーザーのベースライン プロファイルを作成し、そこから外れたアクションを異常（Anomaly）として判断します。
つまり、各アプリケーションからのログやネットワーク機器からのログ等については、UEBAエンジンはその判断基準として利用しておらず、Sentinelにそれらのログをどんな取り込んでも、UEBAによるふるまい検知には影響しません。
じゃあ何のためのUEBAなの？
皆さまから激しく聞こえてきそうな言葉がまさにこの
「何のためのUEBA？ 意味なくね？」
です。
いや、ほんとその通りだと思います。自分も最初そう思いました。
でも、これにはきちんと意味があるのです。
Sentinelでは、様々な分析ルールによってアラートやインシデントが検出されますが、その中でもやはり擬陽性（False Positive）の判断は常に発生します。日々の運用において、その真偽を判断するためにかなりの稼働が必要になりますが、その判断ポイントとしてUEBAのふるまい検知の結果は十分に有用です。
多数のログを改めてかき集めて真偽を判断せずとも、アラートと同時にUEBAのふるまい検知において疑わしいものが確認されていれば、そのアラートは真である と判断しやすくなる訳です。
また、それ以外にもエンティティの動作ページやUEBA ブックを利用して「インシデント/アラートの多いユーザー」と「異常（Anomaly）」と判断されたふるまい の相関を分析して、特定ユーザーに対する監視を強化する事も可能です。
この辺は公開情報にもシナリオ別でまとめてありますので、ぜひ合わせてご覧ください。
UEBA ブック
せっかくなので、UEBA ブックについてもちょっと触れていきたいと思います。（きちんと説明するとかなり長くなりそうなので、ここではご紹介程度ですが）
UEBAブックでは、組織の全ユーザーから「異常（Anomaly）」の数の一覧や、その「異常（Anomaly）」の詳細を確認する事が可能です。
このように全体を出力し、「異常（Anomaly）」の数でソートします。
ソートした結果から、「異常（Anomaly）」の詳細を知りたいユーザーをクリックすると最下部に詳細情報一覧が出てきます。
「異常（Anomaly）」詳細から、「Evidence」をクリックすると、右部分に詳細情報が表示されます。
この中からTrueの表示がある項目が、「異常（Anomaly）」として判断された理由になります。
判断された理由の一覧はこちらにまとまっています。
エンティティの動作ページ
エンティティの動作ページでは、エンティティを直接検索して、エンティティ毎の詳細を確認する事が可能です。（検索以外にもアラート毎のTOP5が確認できますが、UEBAとの連携では利用しないので割愛しています）
検索結果からそのエンティティを選択すると、そのエンティティについての基本的な事実、このエンティティに関連した注目すべきイベントのタイムライン、そのエンティティの行動に関する分析情報を確認する事が可能です。
特にUEBAにおける調査としては、右側の分析情報から同じセキュリティグループに所属している他のユーザーのアクションや、同じロケーション、同僚と比較した場合の結果が出力され、UEBAにおける「異常（Anomaly）」と判断された項目が他のユーザーではどうなのか？に比較調査がしやすくなります。
まとめ
このようにSentinelにおけるUEBAはデータソースおよびEntra IDのユーザー情報を利用して、ユーザーのベースライン プロファイルを作成し、そこから外れたアクションを異常（Anomaly）として判断します。
そして、その結果をInformation として出力します。
しかしながらご覧いただきました通り、それらはアラートやインシデントとしてSentinel に表示されるわけではなく、あくまでも各エンティティの付帯情報として、アラートやインシデントの調査の1つの追加情報として利用されるものとなっております。
※厳密にはこれらを利用して分析ルールを作成しアラートあげる事も可能ですが、それは応用です。
そのため、「なんだ、使えない」みたいな感想をもたれがちですが、今回ご紹介させていただきました通り、そもそもの使い方のコンセプトが異なるだけであり、正しい使い方をすれば十分有用な機能です。
ぜひ皆様もUEBA機能をOnにしていただき、自社におけるSentinelの分析において有効に活用していただければ幸いです。
※今回の記事を書きながら、ほんとはもっと詳細に書きたい部分が多数あり、時間ができたらもう少し詳細編についても執筆してみようと思います。（期待しないでお待ちいただければ幸いです。）