Part2:Sentinelによるログからのインシデント検知まで
はじめに
Part1ではSentinelにおけるデータ収集、さらに簡単なログ検索まで解説しました。
今回は、収集したデータを活用した脅威検知機能について詳しく説明します。
SOCおよびSentinelで実現できる主な機能は以下の通りです:
- 大規模なデータの収集
- 脅威を検出する
- 脅威の調査
- インシデントへの対応
Part2では「大規模なデータの収集」を模擬的に実装しましたので、今回は「脅威を検出する」機能にフォーカスします。
脅威検出と分析ルール
脅威検出の基本概念
Sentinelにおける脅威検出は、収集したログデータから怪しい動作を自動的に識別し、インシデントとして管理する仕組みです。
「怪しい動作」とは一言で表現するのは難しいですが、Sentinelではコンテンツハブから提供される分析ルールセットを活用することで、セキュリティ専門家が定義したベストプラクティスに基づいた検知を実現できます。
主要な分析ルールセット
Microsoft Entra ID
Microsoft Entra IDに関する分析ルールセットには、以下のようなカテゴリの脅威検知ルールが含まれています:
- アカウント侵害検知
- 特権昇格検知
- 異常なサインイン検知
- 多要素認証関連の脅威検知
代表的なルール例:
-
Bulk Changes to Privileged Account Permissions
- 特権アカウントの権限に対する大量変更を検知
- 管理者権限の不正な付与や変更を監視
-
MFA Spamming followed by Successful login
- MFA認証のスパム攻撃後の成功ログインを検知
- 多要素認証疲労攻撃(MFA fatigue attack)の検知
-
User Assigned New Privileged Role
- ユーザーへの新しい特権ロール割り当てを検知
- 不正な管理者権限付与の監視
Microsoft 365
Microsoft 365に関する分析ルールセットには、以下のようなカテゴリの脅威検知ルールが含まれています:
- データ漏洩検知
- メール関連の脅威検知
- SharePoint/OneDrive異常活動検知
- Teams関連のセキュリティ脅威検知
代表的なルール例:
-
Office365 Sharepoint File transfer above threshold
- SharePointからの大量ファイル転送を検知
- データ漏洩の可能性がある異常なファイルアクセスを監視
-
Multiple users email forwarded to same destination
- 複数ユーザーのメールが同一宛先に転送される異常を検知
- メール転送ルールを悪用した情報漏洩の検知
構築:Microsoft Entra ID および Microsoft 365 分析ルールインストール(コンテンツハブより)
前提条件の確認
- Microsoft Entra ID: Part1でログがSentinelに送られるよう構成済み
- Microsoft 365: これから構成が必要
Microsoft Entra ID および Microsoft 365 のインストール
- Sentinelの管理画面で「コンテンツ管理」->「コンテンツハブ」を選択
- 「Microsoft Entra ID」「Microsoft 365」を検索し、それぞれインストール
Microsoft 365データコネクタの有効化
- Sentinelの管理画面で「構成」->「データコネクタ」を選択
- 「Microsoft 365 (formerly, Office 365)」を検索し、コネクタを選択
- 「コネクタページを開く」をクリック
- 必要なサービス(Exchange、SharePoint、Teams等)を有効化
- 接続状態を確認※ここは時間がかかることがあるので後ほど確認でもOK
分析ルールの導入
「Bulk Changes to Privileged Account Permissions」ルールの設定
このルールは、特権アカウントの権限に対する大量変更を検知するものです。
設定手順
-
分析ルール作成
-
分析ルール ウィザード
- 全般 を確認(ここはいじらなくてよいかと)
- ルールのロジックを設定 の調整
- ルールのクエリ は "where dcount_TargetUserPrincipalName > 9"
というところがありますが、ここを変えると「大量」とはいくつかを定義できます。 - クエリのスケジュール設定 の調整
クエリの実行間隔 と 次の時間分の過去のデータを参照します の部分も自分で調整します。
なおこの二つの数字がずれているとログを確認しない時間が出たり、
無駄に確認する時間ができるので注意。
- ルールのクエリ は "where dcount_TargetUserPrincipalName > 9"
- インシデントの設定 の調整
ここは「この分析ルールによってトリガーされるアラートからインシデントを作成する」
が有効になっているのを確認するのみでデフォルトで。 - 自動応答 の設定
ここは次回設定します。今回はスキップ。 - 確認と有効化
最後にこれまでの設定チェックして保存します。
検知の確認
検知テストの実行
実際に検知ルールが機能することを確認するため、意図的に検知対象の動作を実行します。
テストシナリオ
-
特権変更の実行
-
検知結果の確認
- 設定した実行頻度に応じて検知が発動します。今回の設定なら2時間待ちましょう...
インシデントの確認
検知が正常に機能した場合、インシデントが生成されています。
今回はそもそもなぜインシデントが生成されているかはわかっていますが、
あえて調査してみましょう。
-
Sentinel Overview(概要) から新しいインシデントの確認
-
インシデント詳細の確認
- 検知されたインシデントの詳細を確認。
「Bulk Changes to Privileged Account Permissions」
というインシデントができていますので選択するとなにやら("エンティティ")
大量にロールが付与されているようです。詳細を見てみます。
- 検知されたインシデントの追跡
インシデント詳細画面よりイベントをクリックすると、実際どのような監査ログ記録がインシデント生成させたのか一覧が出ます。
そのうち一つの監査ログを追うとあるユーザー(testuser110)にユーザー管理者が与えられていました。
このようなイベントがほかにも11件記録されたのでインシデント生成に至ったのがわかります。
- 今回はあえて発生させたインシデントということで調査はここでおわりですが、
実際にはさらに与えられたユーザーや与えたユーザーがどのようなユーザーなのか、
他にどういった操作をしていたのか調査していくことになります。
- 検知されたインシデントの詳細を確認。
まとめ
Part3では、Sentinelにおける脅威検知機能について実装、検出テスト、調査テストしてみました。
主なポイントは以下の通りです:
- コンテンツハブから提供される分析ルールセットの活用
- Microsoft Entra IDおよびMicrosoft 365に特化した検知ルールの一部紹介、および設定
- 実際の検知テストによる動作確認、および調査デモ
次のPart3では、検知されたインシデントの対応自動化(といってもメール通知ぐらいですが)
について解説していこうと思います。