オピニオン
従来、セキュリティインシデントの記録には、ただ一つの重要な目的がありました。組織が何を観測し、何を判断し、何を実行したかを文書として残すことです。クローズ時のメモ、ルールの記述、誤検知（フォールスポジティブ）の処理結果、アラートを破棄した理由。セキュリティチームはこうした情報を、チケットキューに収まる記録として扱っています。組織が後から自らの判断を再構成し、とりわけその説明責任を果たすためには、これらの証跡をすべて保持しなければなりません。
もちろん、セキュリティの自動化そのものは目新しいものではありません。長年にわたり、SOARプラットフォームはプレイブックを実行し、アラートをクローズし、処理結果を記録してきました。ただし、そこで動くのは顧客自身が書いたルールです。変わったのは、その後の記録の行き先です。証跡の一部が、別の目的のために別の場所へ流れるようになりました。インシデント記録が、モデルの構築や検証を目的としたデータ取得の許可を持つセキュリティAIシステムに取り込まれると、その証跡はベンダーがモデルの開発や検証に使うデータになり得ます。
アーカイブに眠る豊富な情報
十分な量のプロンプトと関連記録が集まれば、多くのことが見えてきます。組織がどのシグナルを重要と見なしているか、どの検知を抑制しているか、アナリストが何を無害と判定しているか、そしてどこに見落としがあるかです。
一件のクローズは、比較的無害なメモにすぎません。しかし、それが連なると地図になります。同じ種類のアラートを抑制し続ければ、組織が懸念する範囲の境界線が浮かび上がります。クローズの根拠からは、PowerShellのノイズや失敗したログインについて、どの程度ならチケットを起票するかという許容水準が読み取れます。チューニングの判断には、チームがどのシグナルを、いつから信頼しなくなったかが刻まれています。このパターンを理解するのに、外部の第三者がチケットの中身へアクセスする必要はありません。そして、そのパターンこそが機微な部分です。
これはAIインシデントの再構成の話ではありません。それはログ取得の設計上の判断です。また、プロンプトインジェクションや、ベンダーによる学習に顧客のチャットログが使われるというおなじみのケースでもありません。問題は、ごく普通のセキュリティ記録が「第二の用途」を持ったときに何が起きるかです。
Copilotのオプション
Microsoft Security Copilotには、所有者がMicrosoftによるSecurity Copilotデータの取得と人手によるレビューを許可するオプションがあります。これは、Azure OpenAIの基盤モデルをベースに構築されたMicrosoftのセキュリティ特化モデルを改善・検証するためのものです。モデル改善のために取得されるデータには、製品の利用中にMicrosoftのプラグインやSecurity Copilotエージェントが扱ったあらゆる情報が含まれ得ます。ドキュメントには、このデータが基盤モデルの学習には使われず、OpenAIとも共有されないと記載されています。もう一つの設定は、製品パフォーマンスのレビューを目的としたデータ取得を制御するものです。
各設定の既定値は、ワークスペースのプロビジョニング方法によって異なります。Microsoft 365 E5およびE7の自動プロビジョニングを除き、データ共有は既定で有効です。設定を有効にした顧客は意図的に判断したことになりますが、設定ページを一度も見ていない顧客は、どの既定値が適用されているかを把握していない可能性があります。サービスを利用することと、モデルの開発や検証のためにベンダーがデータを取得するのを許可することは、別々の判断です。Microsoftはすでにこの二つを切り分けられるようにしています。
インシデントアーカイブの新たな務め
アーカイブの役目は一つでした。組織が自らの判断を再構成し、擁護できるようにすることです。ところが今では、同じ記録がモデルの開発や検証のためにベンダー側にも保持され得ます。これが新たなリスクを生みます。ベンダーが侵害されれば記録は顧客のネットワークの外に出てしまいますし、法的な開示要求があれば、顧客の関与なしに記録が公開されかねません。保持ルールやアクセス制御は、組織が管理するアーカイブを前提に作られており、別の場所にあるもう一つのコピーは想定していませんでした。
監査可能な記録は、最終的な判断だけを残せばよいわけではありません。組織が何を把握していたのか、アナリストが何を判断したのか、システムに何を与えたのか、システムが何を推奨したのかを区別して残す必要があります。そうしなければ、モデルの所見が事実上の判断にすり替わってしまいます。インシデント当時に組織が何を知っていたのかを問う弁護士は、これでは納得しません。検知ルールをなぜ緩めたのかを尋ねる監査人に対して、証跡の流れにも現れるクローズ理由で答えるべきではありません。
この点は調達契約に盛り込むべきです。ベンダーがサービス提供のために顧客のセキュリティ記録を使うことは、モデル改善への利用までは認めたことになりません。証跡の保持とモデル開発は別物であり、それぞれに個別の許可を求めるべきです。ルールの内容、クローズ時のメモ、チケットのテキストを、汎用的なAI条項でひとくくりにしてはいけません。ベンダーがモデル改善のためにデータを求めるのであれば、それは明示的で、撤回可能な選択であるべきです。
こうした用途が正式に切り分けられるまで、アーカイブは二つの機能を併せ持つことになります。一つは、これまでどおり組織が運用するものです。もう一つは、すべての証跡をベンダーの資源に変えてしまうものです。
著者について
ケンブリッジ大学 リサーチアフィリエイト
Gerald Makoは、欧州とアジアの政府に対し、人工知能、サイバーセキュリティ、テクノロジー戦略について10年以上助言してきました。専門は、AIガバナンス、サイバーレジリエンス、そして自律性を高めるシステムがもたらすセキュリティ上の課題です。
Cobham Satcom 最高情報セキュリティ責任者（CISO）
Lemuel Valdezは、プライベートエクイティ（PE）のポートフォリオ企業、政府機関、重要インフラ環境にわたり、サイバーセキュリティとセキュリティ変革を主導してきました。PEが出資する20社以上の企業に対し、サイバーリスク、デューデリジェンス、インシデント対応、セキュリティアーキテクチャ、規制コンプライアンスについて助言と支援を行ってきました。
翻訳元: https://www.darkreading.com/cyber-risk/ai-gave-your-incident-archive-second-job
