はじめに
こんにちわ、セキュリティチームのむろです。
今回はMicrosoft Defender for Endpoint（以下、MDE）カスタム検出ルールで生成されたアラートをSentinelと連携させて自動でクローズ＝解決済みに変更する仕組みを構築してみました。
本記事自体は限定的なユースケースではあるものの、Sentinelのデータコネクタ、分析ルール、オートメーションルールに触れるのでのSentinelの使い方を入門的に理解するのにも良いかもしれません。
はじめにまとめ
- MDEはカスタム検出ルール機能でカスタムアラートを作成できる
- MDEのアラートを継続的にメール通知させるためには新規スターテスのまま放置すると困る
- カスタム検出アラートはMDEの「アラートの調整（Alert Tuning）」機能で処理できない仕様なので、代わりにSentinelの分析ルールをトリガーにLogic Appsで自動クローズさせる
前提
- Sentinelのワークスペースは作成済みであること
- Sentinelを操作するユーザーはコネクタの接続、分析ルールの作成、Logic Appsを作成する権限を持っていること
アラートの自動クローズ処理の概要
- 今回は汎用的に自動クローズを構成したいため、アラート名に「autoclose」という文字列が含まれている「カスタム検出ルール」のアラートをSentinelの分析ルールでトリガーしてLogic Appsを実行させます
- 実行するLogic Appsで対象アラートのアラートIDを元にして「解決済み」へステータス変更します
ちょっと前置きが長いのでもしも先に具体的な設定手順を見たい場合は「自動クローズ対応の設定方法」までスキップしてください
ただし、Defender XDRとSentienlの連携設定がまだの場合は「事前準備」は設定ください
カスタム検出ルールのアラートって何？
Microsoft Defender for Endpoint（以下、MDE）P2ではAdvanced HuntingからMDEのセンサーモジュールで収集した端末上の様々な情報をクエリすることができます。
そして、Advanced Huntingで作成したクエリ結果をそのままアラートにするカスタム検出ルール機能があります。
これが便利でAdvanced Huntingでクエリできるスキーマの情報は細かなイベントが捉えられるので、クエリで条件を細かく設定した上でアラート化して通知させるような運用で利用することができます。
- 例）「mount」をというキーワードが含まれるコマンドラインが実行されたらアラート化させる
- 例）ASR（Attack Surface Reduction）のBlock イベントを検知したらアラート化させる
- 例）「Remove-EventLog」というPowerShellが実行されたらアラート化させる
なぜ自動クローズさせたいのか？
MDEではアラートに対してメール通知を設定することができ、アラートが生成された際にメール通知設定が可能です。
しかし、アラートのステータスが「新規」や「進行中」で残っている場合に同じアラートが発生した場合、条件によっては既存のアラートの更新扱いとなり、メール通知がされません。
つまり「解決済み」へステータス変更し忘れてしまうとメール通知がされない状態になる可能性があります。
アラートがあった際に通知されないのは困るものの、毎回クローズするのは面倒なので自動化したいところです。
もちろん、自動クローズで問題ないアラートに限ります！
Defender XDRの「アラートの調整（Alert Tuning）」の仕様
そもそも、通常のアラートであればアラートの調整（Alert Tuning）機能によって自動で解決済みステータスにすることができます。
アラートの内容を確認した上で「確認済み」へ変更することが通常の対応にはなりますが、ユースケースによっては「通知」させること自体が目的の場合もあります
- 特にカスタム検出ルールは自身で条件を決定している背景からこの傾向が強くなる場合があります
- ここで紹介しているアラートの調整（Alert Tuning）機能も運用に組み込むべきかどうかを十分に検討して利用してください
しかしながら、アラートの調整（Alert Tuning）機能はカスタム検出ルールで作成されたアラートは処理の対象外という仕様があります。
代わりにカスタム検出ルールで作成されたアラートをSentinelで自動クローズできるようにします。
Sentinelってお金が掛かるのでは？
はい、Sentinelには費用がかかります！
ただし、本記事で接続するMDEの「SecurityAlert」は無料ソースの対象となっています。
とは言ってもLogic Appsなどでも若干の費用がかかるので完全に無料は難しいですが、それほど大きな金額は掛からない想定となります。
心配な方は検証環境などで小さくはじめて費用試算をしていただけると安心です。
事前準備
SentinelへDefender XDRを接続する
- すでに接続済みの方は本作業は不要です。
- 簡単な接続手順を記載しますが、詳細は以下のドキュメントも参考ください。
- Sentinelのコンテンツハブから「Microsoft Defender XDR」をインストールします
- インストールが完了するとデータコネクタの「Microsoft Defender XDR」が表示されるようになるので、「コネクタページを開く」を選択します
- コネクタ画面で「これらの製品の Microsoft インシデント作成ルールをすべてオフにすることをお勧めします。」はチェックした状態であることを確認します
- コネクタページで「インシデントとアラートを接続する」を選択します
今回の対応では他のエンティティやイベントの接続は不要です
これらを接続すると前述の無料のデータソースの対象外の情報が接続されるので注意してください
Sentinelからカスタム検出ルールのアラートを手動で検索する方法
接続が完了したらMDEのアラートをSentinel上でクエリ検索することができるようになります
クエリ言語はSQLに似たKQL（Kusto Query Language）となります
試しにSentinelの「ログ」メニューから時間の範囲を設定して以下のクエリを実行してみてください
SecurityAlert
| where ProviderName == "MDATP"
| where AlertType == "CustomDetection"
- 上記のサンプルクエリはProviderNameで”MDATP”を指定、AlertTypeを”CustomDetection”で条件にすることで「MDEのカスタム検出ルールのアラート」という条件でフィルタしています
クエリ結果を展開すると様々な情報が得られることがわかります。
自動クローズ対応の設定方法
前置きが長くなりましたが、ここから具体的な設定方法にはいっていきます。
今回は汎用的に自動クローズを構成したいため、アラート名に「autoclose」という文字列が含まれている場合にLogic Appsをトリガーさせて対象アラートを自動で「解決済み」へ変更する構成にしています。
step1）カスタム検出ルールの「アラートのタイトル」調整
- MDEのカスタム検出ルール側も分析ルールの条件にあうようにアラート名に「autoclose」という文字列を追加します
step2）プレイブック（Logic Apps）の作成
- Sentinelの「オートメーション」メニューから「インシデントトリガーを使用したプレイブック」を選択します
- 紐付けするAzure サブスクリプション、リソースグループを選択して、「プレイブック名」を入力
- 接続画面へ進み、対象に「Microsoft Sentinel」となっていることを確認してプレイブックを作成します
- 次にAzure Portalに戻り「ロジックアプリ」から作成したLogic Appsを開きます
- Logic Apps内の「ロジックアプリデザイナー」を開きます
- 以下のように「アクションの追加」をしてLogic Appsを作成していきます
- コネクタ名で検索し、さらに表示から実行するアクションを探していきます
- 追加するアクションによってはLogic Appsとの接続のために認証操作が必要になる場合があります
- アクション内で取得したデータを次のアクションで利用するにはカミナリマークから選択することができます
- 上記の要領で実際に作成していきます
- 今回のLogic Appsの全体像は以下になります
- 最初のトリガーは事前に作成さているため、特に設定不要です
- 次に「Azure Monitor ログ」の「Run query and list results V2」アクションを追加します
- 環境によっては日本語の「クエリを実行して結果を一覧表示する V2」と表示されます
- クエリは以下の内容です
SecurityAlert
| where AlertName contains "autoclose"
| where Status != "Resolved"
| where ProviderName == "MDATP"
| where VendorName == "Microsoft"
| where IsIncident == false
| where Type == "SecurityAlert"
| where AlertType == "CustomDetection"
| order by TimeGenerated desc- 検索元であるSentinel（Log Analytics Workspace）をサブスクリプション、リソースグループ、リソース名から選択します
- 時間範囲は「Relative」で長めに「Last 12 hours」を選択します
- 次に「Control」の「For each」処理を追加します
- 「For each」は一つ前の「Run query and list results V2」で取得した結果が複数となる場合があるため、繰り返し処理を入れる目的で設定します
- Select An Output From Previous Stepに「Run query and list results V2」の「value」を設定します
- 次に「Microsoft Defender ATP」の「Alerts – Update Alert」処理を追加します
- 環境によっては日本語の「アラート – アラートの更新」と表示されます
- アラートのIDに「Run query and list results V2」の「VendorOriginalId」を設定します
- 「VendorOriginalId」にはMDE上のアラートIDが格納されています
- 更新後の状態として「Resolved」（解決済み）を設定します
- クローズ時のアラートの割り当て担当者、分類や決定は任意で設定してください
- 最後に運用時に自動クローズした通知を受け取るために「Slack」の「メッセージ投稿（V2）」を追加します
- 自動クローズそのものには不要な処理なので通知が不要であればこのSlackアクションは不要です
- チャネル名に通知先のチャンネルIDを指定します
- チャンネルIDは「チャンネルの詳細」やチャンネルのURLから確認できます
- メッセージテキストでお好みの内容を設定します
- 「AlertLink」はMDE上のアラートへの直リンクとなるので確認時に便利です
step3）分析ルールの作成
- Sentinelはクエリで指定した条件から「インシデント」を作成する「分析ルール」を作成できます
- 今回はNRTルールで作成します
- NRTルールとスケジュール済みクエリルールの違いは後ほど補足します
- 「ルール名」や「説明」、「重要度」を設定します
- 今回の分析ルールの位置付けから重要度は一番低い「情報提供」で設定しています
- 次の画面に進み「ルールのクエリ」に以下のクエリを設定します
SecurityAlert
| where AlertName contains "autoclose"
| where Status != "Resolved"
| where ProviderName == "MDATP"
| where VendorName == "Microsoft"
| where IsIncident == false
| where Type == "SecurityAlert"
| where AlertType == "CustomDetection"
- ここで設定したクエリが1件以上検出されると分析ルールからSentinelのインシデントが作成されることになります
- 「クエリ結果の表示」で結果を試しに確認することもできます
- インシデントの設定画面はデフォルトのまま、次へ進みます
- 自動応答の部分で新しくオートメーションルールを作成します
- オートメーションルールを予め作成して指定することも可能です
- 「プレイブックの実行」で事前に作成したプレイブックを選択します
- 「情報の変更」で「終了」を選択し、分類や理由を入力します
- プレイブックの実行後に分析ルールで作成したインシデント自身をクローズさせるために設定します
- 設定したら適用を選択します
- 最後に分析ルール自体の作成も完了させます
作成した分析ルールとプレイブックをテストする
意図的にアラートを発生させてみて実際にアラートをMDE側で発生させて自動で解決済みになるか確認してみてください
自動クローズまではアラートが発生してから大体10分〜15分ほど掛かります
- Logic Appsが実行されたかどうかはロジックアプリの「概要」ページで確認できます
- エラーがあった場合はここから原因を確認します
NRTルールとスケージュール済みルールの違い
- スケジュール済みルールは文字通り、設定した間隔で定期的に実行される分析ルールで、最短の実行間隔は5分となります
- NRTルールは1分に1回の間隔で実行され、NRTルールの方が使い勝手が良いように思えますが、50個までの制限があります。
詳細は以下のドキュメントを参照ください
さいごに
今回は限定的にユースケースではありますが、今回ご紹介した全体の流れ自体は他のいろいろな処理に応用できると思います。
カスタム検出ルールを自動クローズしたい方、Sentinelで分析ルールをこれから作成しようとしている方に参考になると嬉しいです！
