Microsoft Copilot for Securityでインシデント調査をしてみた

Microsoftソリューション推進チームの若居和直です。

Microsoft社の、生成AIを活用したオンラインセキュリティを強化するサービス、「Copilot for Security」が話題になっています。

専用のポータルなどからチャット形式で質問を投げかけると、専用のプラグイン経由でMicrosoftの様々なセキュリティサービスの情報を取得して、回答してくれるサービスです。

実際にどのように活用できるのか、専門家でなくともセキュリティ業務ができるようになるのは本当なのか、といったポイントが気になる方は多いのではないでしょうか。ラックは、サービスのリリースに先立って、EAP（Early Access Program）期間中からCopilot for Securityを利用したので、実際の使い勝手をレポートします。

今回は、Microsoft社のセキュリティ情報イベント管理サービス（Security Information and Event Management：SIEM）であるMicrosoft Sentinel（以下、Sentinel）を使い、インシデントの調査にCopilot for Securityを活用できるかを試しました。

インシデントとは

一般にインシデントとは、企業や組織にとって重大なマルウェアの感染や情報漏えいなどの、セキュリティ事故を示します。

また、Sentinelは「インシデント」を少し違う用途で使います。Sentinelは分析した脅威情報をアラートという形で通知し、一定の脅威があると判断すると、関連するアラート情報などをまとめて提示してくれます。その情報の塊を「インシデント」と呼びます。

この記事では、どちらの意味合いでの「インシデント」も登場しますのでご留意ください。

インシデントを調査するための各フェーズについて

インシデント（セキュリティ事故）を調査する場合、一般的にはいくつかのフェーズに分けられます。

今回は、JPCERT/CCの「インシデントハンドリングマニュアル」^※に習い、次の4段階で対応を検討することにしました。

※ JPCERT コーディネーションセンター CSIRTマテリアル

1. 検知/連絡受付
2. トリアージ
3. インシデントレスポンス
4. 報告/情報公開

「検知/連絡受付」について、今回はSentinelが担当するので、セキュリティ管理者は残りの2～4を行います。人間が行う部分をいかに楽にできるようになるか、自動化や省力化が可能かといった点が、Copilot for Securityを活用するために求められるポイントだと考えます。

従来は、十分な知識を持つ専門家でなければインシデントの対応は困難でした。しかし、必ずしも十分な知識を持っていない人が対応したとしても、Copilot for Securityが名前の通り副操縦士として補助できるようになれば、専門家はより困難な課題に取り組めるようになります。

Copilot for Securityを活用したインシデントの調査

3つの項目それぞれについて、実際にCopilot for Securityを使ってみてどうだったか説明します。

トリアージ

実際に発生するインシデントに対して、必ずしもすべてに対応する必要はありません。

トリアージの目的は、発生したインシデント対応の優先順位を決めて、対応方針を決定することです。インシデントの内容や周辺情報から「いつ」「どこで」「何が」「どのように」起こったかを調べ、対応する必要があるインシデントかどうかを判断します。原因究明は次以降のフェーズの役割なので、ここでは行いません。

Sentinelにおいても同様です。基本的には発生した「インシデント」に対して調査を行い、対応の必要があれば担当者を決めてアサインし、対応の必要がなければ「インシデント」をクローズします。

Copilot for Securityの活用

ここからは、Copilot for Securityをトリアージのために使った際の動きを説明します。Copilot for Securityが対象にしているのは、個別の「インシデント」だけではありません。例えば、「Sentinelで検知した、重要度が高のインシデントの最新10件」といった内容で、まとめて問い合わせできます。

個別の「インシデント」に対する調査も、一つ一つプロンプトを入力して問い合わせる他に、「プロンプトブック」と呼ばれる既定のパターン集が使えます。プロンプトブックを使えば、例えば「インシデント」に対する複数の定番調査を一度の操作で行なえます。

さらに、検知した内容を要約して、インシデントの発生時刻や内容、影響するエンティティ（IPアドレスやユーザーなどの関連情報）などの情報を一覧できます。また、「インシデント」に含まれるアラートに具体的なマルウェア名や脆弱性名などが含まれていれば、Microsoftの脅威情報を使ってより詳細な内容を得られます。これらの情報があれば、トリアージの判断材料として十分でしょう。

一方で、検証環境では他サービスとの連携が限られていたこともあり、Sentinelの画面上で得られる情報以上のものを求めようとすると、途端に良い回答を得るのが困難になりました。複雑なプロンプトになると、回答に時間もかかります。

Copilot for Securityの調査だけで完結するのではなく、普段のSentinelの「インシデント」への対応の補助として活用するのが良いと感じました。

インシデントレスポンス

インシデントレスポンスで行うべき内容は状況により様々ですが、大まかに以下のような行動にわけられます。

分析・特定	分析・特定	横展開などを含む被害範囲の調査や、発生原因を特定する。
封じ込め	被害を最小限にするために、まず対象を隔離し、再感染や横展開を防ぐための方策を実施する。
根絶	特定した侵入経路や被害範囲から、不正なツールや脆弱性などを取り除く。
復旧	被害を受けたシステムなどの復旧を行う。

逆に、封じ込めや根絶、復旧は、対象のシステムやサービス側での設定が主となるため、Sentinelの機能の範囲外^※です。

※ Sentinel単体ではなく、Microsoft Defender for EndpointやAzure Logic Appsといった他サービスと連携することで、インシデント対象の端末を自動隔離するなどのアクションが可能です。

Copilot for Securityの活用

さて、Copilot for Securityを分析・特定のために使ってみました。トリアージの際にも感じましたが、複雑な情報を得ようとするとプロンプトの組み立て方が難しくなり、複合した内容は問い合わせ時間も長くなります。

例えば、怪しいWebサイトへのリンクをクリックしてしまったユーザーがいたとします。そのユーザーが他にアクセスしたWebサイトや、同じリンクをクリックしてしまった他のユーザーが存在するか、存在するならば時刻やユーザー名の一覧を直接得るのは困難でした。

代わりに、Sentinelのログを検索するクエリ言語（KQL）を生成させることで、一定の情報を得やすくなりました。この場合も、Copilot for Securityの画面だけを利用すると、複数回試行して検索条件を詰めると問い合わせの時間がかかるため、実行はSentinel側で行い、適時修正するほうが有効でした。

また、現時点では画像を生成できないため、アラート間のエンティティの関連性や、実行プロセスのプロセスツリーといった視覚的な図が必要な場合は、SentinelなりDefender for Endpointの機能で見る必要があります。

このように、現状ではCopilot for Securityだけで完結するのではなく、Copilotの名前通り補助的な役割として使うのが適切でした。

報告/情報公開

報告をするために、まずは各フェーズで判明した内容について、技術的に適切な要約が必要です。Sentinelでは様々な情報を調査できますが、最終的に調査結果をまとめるのは人です。

Copilot for Securityの活用

さて、Copilot for Securityを報告のために使ってみたらどうだったでしょうか。Copilot for Securityで調査した内容は、Copilot for Securityのレポーティング用の機能で要約できます。

具体的には、プロンプトで質問/回答した内容から、報告したい内容を選び、要約します。また、Share機能を用いて、直接やりとりの内容を他の人と共有できます。

Copilot for Securityの中で完結した情報を要約するのは便利です。ただ、Sentinel側で画面を見ながら補助として利用している場合は、Copilot for Security側に履歴が残りません。その場合、要約は自分で行うか、別途メモしておいた内容と合わせてCopilot with Bingなどの他の生成AIを利用して要約してもらう必要があります。

Copilot for Securityをインシデント対応に活用してみよう

今回は、Microsoft Copilot for Securityを使ったインシデント調査を行ってみました。

セキュリティに詳しい人であれば、Sentinelの画面を見てすぐに判断できる事項ですが、あまり詳しい人でなくても「プロンプトブック」などで定形の調査方法を用意し、プロンプトベースで調査できる点が、インシデント調査の敷居を下げる効果があると考えます。

利点としては、間違いなく要約能力の強さでしょう。各種セキュリティ情報を情報源として要約することで、そのままでは少し足りない情報を補完しつつ調査できます。また、調査用のクエリ（KQL）を提案させることで、プロンプトだけでは表現しにくい情報も調査できます。

総じて、現時点では利用者側にも相応のノウハウが必要なサービスだと感じました。より良い問いを見つけられれば、違う側面からの調査ができ、より良いプロンプトを作れるなら、より良い答えを得られるでしょう。ノウハウを共有するために、ユーザーが個別に作成できるカスタムプロンプトブックに期待しています。

また、私たちが触れたのはEAP（Early Access Program）段階のサービスです。質問も英語で行う前提でした。実際には日本語でも受け付けてくれたので不自由はあまりありませんでしたが、応答時間に若干の間ができてしまいました。このあたりはいずれ解決されると考えています。

さいごに

Copilot for Securityは、セキュリティの専門家でなくてもインシデントに対応できるようになるため、セキュリティ人材の不足を解決する大きな一手となりえます。

今回試した範囲でも、トリアージまでであれば容易に有効活用できました。どんどんサービスは拡張されるでしょうし、関連するソリューションもでてくることでしょう。インシデントの把握の省力化や半自動化、一次対応の自動化や報告の補助など、より一層の躍進を期待しています。

以後も継続的にウオッチして、情報発信や、活用の幅を広げていきたいと思います。

※ 紹介している情報や感想は筆者が試行した時点でのものです。

※ これらはEAPによる評価環境での結果であり、リリース後のサービスでは異なる結果となる可能性があります。

※ 実際に試行する際には、最新の公式ドキュメントをご確認いただくことを強く推奨します。