Sumo Logic アップデート情報 – Cloud SIEM Enterprise の UEBA とエンティティのタイムラインについて

Sumo Logic のアップデート情報をご紹介します！今回は、UEBA 関連のルールとエンティティのタイムライン機能についてご説明します。

#Sumo Logic

佐久間昇吾

2023.05.08

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

最初に

Sumo Logic では、下記のプラットフォームを使用できます。今回は、CSE の新機能 UEBA と、エンティティのタイムラインについてご紹介させていただきます。

Continuous Intelligence Platform（CIP）

ログの一元管理、強力な機械学習分析 / 予測、ふるまい検知、ダッシュボード化など

Cloud SIEM Enterprise（CSE）

膨大なログの自動相関分析、ドリルダウン、トリアージなど

Cloud SOAR

複数製品のオーケストレーション、インシデント対応の自動化 / 半自動化、エスカレーションなど

そもそも UEBA とは？

UEBA（User and Entity Behavior Analytics）とは、ユーザやデバイス、アプリケーション、システムなどを含むエンティティの行動を分析して異常を検知するソリューションや技術のことを言います。主に NW トラフィックのパターンや API Call のログを使用して「不審な行動」や「悪意のある侵入行為」などを把握するために使用されています。

なぜ UEBA が必要とされるのでしょうか？

すでに多くの企業様が、エンドポイントセキュリティ製品やアクセス制御、侵入検知システムを持っていらっしゃるかと思います。その中でも、不審な行動を検知するために従来の白か黒かのようなルールベースの方法だけでは誤検知や過検知が多く、複雑な振る舞いや攻撃を正確に検知することに苦労してきました。こうした背景を経て、多様な製品のデータソースを収集してふるまいを検知し、分析した結果をモデル化したり、１つのプラットフォームで統合的な可視化につなげることで横断的かつ迅速な異常検知を提供するソリューションが求められ、UEBA が誕生しました。

また、昨今 IPA が公開している情報セキュリティ10大脅威 2023にも記載があります通り、ランサムウェアやサプライチェーンの脆弱性を狙った巧妙かつ進化し続ける攻撃とその量が増加しています。こうした攻撃では、最終的に組織内にアクセスするためのバックドアとして、その宿主にされることもあります。攻撃を未然に防ぐ、もしくは有事の際にすぐに対処できるように能動的なアプローチをしてくれる AI セキュリティ製品は不可欠と言えます。

昨今、EDR、XDR などのエンドポイントセキュリティ製品にも UEBA 機能が追加されつつある中、今回ご紹介する SIEM 製品の Sumo Logic にも UEBA 関連のアップデートがありましたので、ご紹介させていただきます。

CSE の新機能をご紹介

まず、CSE とは何か簡単にご紹介します。

CSE ってどんなもの？

CIP に収集されたログをフォワードして CSE プラットフォームでエンティティ（IP やユーザ名など）をベースに自動相関分析してくれるものです。CSE の特徴としては、膨大なログの１つ１つを機械学習の篩にかけて、自動相関分析したあと、ごく少数の本当に重要なログのみに絞り込んでくれます。さらにユーザは、それら関連性のあるログを GUI ベースでトリルダウンして調査が可能になっております。これにより、エンジニアは時間を大幅に削減して本当に必要なタスクに時間を使えます。

実際の様子については、弊社ブログ「Sumo Logicの自動相関分析サービス　Cloud SIEM Enterprise (CSE)を使ってみた」でも紹介しておりますので参考にしていただければ幸いです。

CSE の新ルール First Seen Rule について

今回、UEBA 関連で 2つの機能が追加されました。

First Seen Rule

UEBA に強いルールです。ふるまい検知として、普段とは逸脱するアクティビティを検知します。

エンティティのタイムライン

先ほど、CSE はエンティティをベースに自動相関分析をするとお伝えしましたが、このエンティティのアクティビティを時系列で調査することが出来るようになりました。実際に使ってみましたので、下記を読み進めていただきご確認ください。

First Seen Rule

UEBA の検知ルールとして、エンティティ（ユーザ、デバイス、IP など）がこれまでにない動作の検知に特化したルールです。主に下記のようなイベントを検知します。

普段と異なるロケーションでのログイン
新しいアカウントの作成や追加
エンドポイント製品等が初めて検知したアラート
初めて認識したデバイス

実際の CSE の画面では、Content > Rules と進んでいただき、FILTERS に「first」などと入力いただくと各種サービスごとに組み込みのルールが出力されます。現在 36 個です。

これらのルールは、ベースラインに基づいて動作します。ベースラインというのは、一定期間に収集されるログの変動値を合算した結果の平均を示しております。これにより、ベースラインと比較して異常な行動を検知できるようになります。もちろんルールさえ Enable にしてしまえば自動で学習してくれます。また、これらのルールはユーザがカスタマイズすることも可能です。

AWS の API CALL イベントに関するルールを見てみます。

Rule Type は、First Seen となっております。同じ名前のルールタイプが今回ご紹介している First Seen Rule というものになります。ここで、もしルールに引っかかるような普段と逸脱する行動が検出されれば、Last Signal の部分に表示されますし、右のカレンダーにも Signal として色が点灯します。最後に Data Collected in Model の部分ですが、こちらがベースラインを形成するためにインジェストされたデータを学習する期間になります。30日で設定すると、n of 30 days の様に表記されます。（n は実際にデータが入った日数です）

First Seen Rule を作成してみましょう！ せっかくなので、新しくルールを作成してみてどのような要件なのか確認してみます。ルールの作成には、Content > Rules > 右上の CREATE > First Seen を選択します。

すると、ルール作成画面が表示されます。順番に見ていきます。

① When a Record matching the expression

どのレコードを使用してベースラインを形成させるかを定義します。レコードにマッピング出来るスキーマ属性 CSE Schema Attributes、レコードにマッピングできないスキーマ属性 Attributes You Can Map to Records を参考に式を作成します。

下記の様に AND で繋いで作成してください。

metadata_vendor = 'Amazon AWS'
AND metadata_product = 'CloudTrail'
AND user_username_role != "cloudhealthreadonly"
AND NOT isEmpty(user_username)
AND fields["userIdentity.type"] = "IAMUser"

② has a new value for the field(s)

最初のベースライン期間後に新しい値が検出されたときにシグナルが作成されます。ここにはそのスキーマ属性を指定します。

③ baseline

グローバル単位、またはエンティティ単位で設定します。global は、ルール作成時にすべてのエンティティのベースラインを作成しますが、per entity は、エンティティ単位でベースラインを作成します。

④ for the following

デフォルトでは、最初のベースラインを30日間収集（Learning）して、ルールが異常を探し始めます。その後、90日間のローリングウィンドウ（Retention）で動作します。

⑤ On Entity

First Seen ルールがトリガーされたときに作成されたシグナルに表示される情報です。名前、説明、どのスキーマ属性を使用したか、重要度指数はいくつか、タグを設定します。

あとは、すぐにこのルールを運用したい場合は Submit を、下書きとして保存したい場合は、プロトタイプとして保存にチェックを入れて Submit してください。

ここまででルールを作成できましたので、次は実際にシグナルを見てみましょう！

エンティティのタイムライン

２つ目の機能であるエンティティのタイムライン機能をご紹介します。その名の通り、エンティティごとにレコードの時系列を調査できる機能です。UEBA との親和性も高く、非常に見やすいためすぐに状況を把握できます。

尚、執筆時点（2023/05/08）では、エンティティタイプが Username である必要があります。

今回は、電子メールのフィッシングリンクをクリックして、その後「ファイルハッシュが脅威情報と一致しました。（= 危険なファイル）」というタイムラインを見てみます。

Entity > Username > ユーザ名を選択すると、早速下記のような画面になります。まずは UI の説明をします。

① こちらは、選択したユーザ名が表示されています。このユーザがエンティティとなっているレコードが右側のタイムラインに表示されます。

② RECORD TYPE でどのスキーマ属性かを選択できます。先ほどルール作成の時にご紹介した検知のトリガーとなる値になります。

③ EVENT TIME では、降順と昇順を切り替えられます。デフォルト降順なので、最新状況はすぐにつかめます。

④ LAST N DAYS は、対象とする期間の絞り込みに使用します。デフォルトは3日です。

では、タイムラインの中身を見てみます。UI も一緒にご説明します。

赤枠部分：左から順に、各レコードの作成時間、関連するレコードの総数、レコードの種類、関連する異常の項目が表示されています。

黄枠部分：各レコードの下には、関連するインサイトとシグナルがネストされています。赤いマーカーはネストしたインサイトを、オレンジのマーカーはネストしたシグナルを示しています。インサイトやシグナルのタイトルを選択すると、新しいタブでその詳細ビューが表示されます。

今回の例だと、電子メールのフィッシングリンクをクリックした痕跡を Proofpoint Targeted Attack Protection が検出して、その後 CrowdStrike Falcon がファイルハッシュが脅威情報と一致したことを検知した。というシナリオになります。

詳細ビューを見てみます。

怪しいファイルは、YQICQ6N4_SETUP.zip で、保存先は、\Device\HarddiskVolume2\users\vagrant\AppData\Roaming であることが分かりました。

ここまで、GUI だけで簡単に他製品のログも含めて一挙に調査して、迅速に問題を発見できました。というところでご紹介は以上になります。

まとめ

いかがでしたでしょうか。今回ご紹介した Sumo Logic の CSE で実現できる UEBA としての First Seen Rule で普段とは異なるふるまいや、新たな脅威のあるログの検知が可能になり、さらにエンティティのタイムラインによって時系列での簡単な調査が可能になり、非常に効率的に複数ソリューションにおける相関性のあるログを調査できるのではないかと思います。すでに Sumo Logic をご導入されている企業様はもちろん。新たに導入をご検討されている企業様にも本記事で紹介させていただいた機能を知っていただけましたら幸いです。