Alert から証拠へ：監査可能な AI SOC workflow
AI SOC workflowは、別のアナリストが元のsignalから最終アクションまでの判断を再現できて初めて信頼できます。設計方法を解説。
Alert から証拠へ：監査可能な AI SOC workflow
別のアナリストが元の signal から最終アクションまでの判断を再現できるとき、AI SOC workflow は信頼できます。
元の signal を保存
アラート、時刻、ソース、検知ルール、raw identifier を保持し、AI 要約で置き換えません。
結論を証拠に結び付ける
各 finding がイベント、クエリ、資産、ID、外部ソースを参照し、仮定を分けて表示します。
ループを閉じる
承認、対応、結果、フォローアップを記録し、検知と playbook を改善します。
モデルを組み込んだワークフローで「監査可能」とは何を指すか
NIST SP 800-53 Rev. 5 は、米国連邦政府機関である米国国立標準技術研究所（NIST）が公表している管理策のカタログです。タイの法的要件ではありませんが、物差しとして使えます。同書の管理策 AU-3 は、監査記録から、どの種類のイベントが、いつ、どこで、どのソースから、どんな結果で起き、誰（何）が関わったかが分かることを求めています。AU-3 自体に AI への言及はありません。
モデルが加わると、必要なことが3つ増えます。1つ目は、モデルの出力と、その背後にあるテンプレートまたはモデルのバージョンを保存することです。再実行しても同じ文章が返るとは限りません。2つ目は、その出力と人の判断を別の記録にすることです。モデルは提案できますが、承認できるのは承認権限のあるロールの人だけです。3つ目は、インシデントの証跡（1件のケースについて何が判断されたか）を、プラットフォームの監査ログとは別に持つことです。監査ログでは代わりになりません。以降の内容は、zcr の資料に記載があると明記した部分を除き、推奨パターンです。
証跡を1ステップずつ追う
| ステップ | 存在すべき記録 | フィールド（各行にタイムスタンプと実行主体） | 監査人が確認する理由 |
|---|
| 1. アラート受信 | 元のアラートと元のイベント（raw event）への参照（AI の要約とは別に保管） | 入力（アラート、ルール、イベント ID）、実行主体（ソースまたはルール） | 作業の起点を示す |
| 2. ケース作成 | 担当者、重大度、グルーピングしたアラートを持つケース | 出力（重大度、グルーピング） | 担当と開始時刻を確定する |
| 3. 調査 | 実行した全クエリ、元の質問、結果（または固定した参照）。修復作業の前に保全 | 入力（質問）、クエリ、出力（結果への参照） | 第三者が同じ検索を再現できる |
| 4. AI の出力 | AI の要約・推奨を原文のまま、引用イベントとともに保存。修正は新バージョンで保存 | 入力（コンテキスト）、テンプレートまたはモデルのバージョン、出力、実行主体（agent） | 再実行では結果が変わりうるため、保存した写しがアナリストの見たものを示す |
| 5. 人の判断 | 承認・却下・修正を、理由とともに、その提案に紐付けて記録 | 人の判断、実行主体（氏名とロール）、ステップ 4 への参照 | 責任と権限を示す |
| 6. 対応操作の実行 | 実行記録：playbook とバージョン、playbook のステップ、コネクタ、対象、ゲート設定（gating） | 対応操作、入力（パラメータ）、結果 | 実行内容が承認内容と一致することを示す |
| 7. ケースのクローズ | クローズ記録：分類、フォローアップの担当、同じ証拠から作ったレポート | 出力（分類）、人の判断（クローズ）、結果 | 結果とフォローアップで証跡を閉じる |
監査人が尋ねる5つの質問
どれか1つでも証跡から答えられなければ、そのステップは監査できないものとして扱います。質問 1・3・4 は AU-3 の要素に沿い、質問 2 はモデルが加わることで必要になる項目、質問 5 は AU-3 の時刻の要素と AU-9 が懸念する点を合わせたものです。
| 質問 | 答えられる記録 |
|---|
| 1. 何が発端で、チームは何を見ていたか | ステップ 1 と 3 |
| 2. AI は何に寄与し、どのバージョンが生成したか | ステップ 4 |
| 3. 誰が、どのロールで、どの提案を判断したか | ステップ 4 と 5 |
| 4. 何を、どの対象に実行し、結果はどうなったか | ステップ 6 |
| 5. 順序を再構成でき、記録の改変や欠落はないか | ステップ 2 と 7、すべてのタイムスタンプ、ストレージの保護 |
資料に記載があるもの、推奨パターン、お客様側で設定するもの
zcr の資料に記載がある機能
- zcrSOAR は、タイムスタンプ、ユーザー、操作、インシデント、playbook、コネクタ、入力、結果、実行ステータスを記録します。監査レポートを提供し、ダッシュボードからインシデント、playbook の実行、承認記録、証拠へドリルダウンできます。playbook の各ステップは Autonomous、Approval、Blocked のいずれかに設定でき、資料に記載のあるバージョン履歴は playbook が対象です。
- zcrCTEM はアタックサーフェスとエクスポージャーを扱う製品で、AI の回答と下書きをすべて自身の監査証跡に記録し、その背後にあるテンプレートとバージョンも残します。
- zcrSIEM は、ケースにメモ、証拠、ステータス履歴を残し、質問をアナリストが確認できるクエリに変換し、MFA、RBAC、監査証跡を備えます。承認キューと自動対応は zcrSOAR が担い、zcrSIEM は SOAR を含みません。
- zcrLog は、通信記録を完全性チェックと AES-128 暗号化とともに保持します。監査記録はサインイン、アクセス、システム変更が対象で、インシデントではなくプラットフォーム側のものです。
推奨パターン
すべての記録にケース ID、ステップ番号、UTC のタイムスタンプを付け、入力はコピーせず参照で示します。ただし、ケースより先に元データの保持期間が切れる証拠は、コピーをケースに固定します。記録の正本とするシステムを1つに決め、時計を揃えます。AI の出力はテンプレートとモデルのバージョンとともに原文のまま保存し（zcrSIEM ではアナリストのメモに記載）、修正は新バージョンとして残します。四半期に一度、再構成の演習（replay drill）を行い、SOC 以外の人に、クローズ済みのケース1件を記録だけで再構成してもらいます。
お客様側で設定が必要な項目
お客様側で、監査の遡及期間をカバーする保持期間、承認者のロールと承認ルート、ステップごとのゲート設定（本番の前に Draft、Test、Dry-run、Simulation Mode で検証）を設定し、実行記録にステップ 6 の項目が揃っているかも確認します。
証跡が途切れる場所と、エスカレーションの基準
証跡が揃っていても示せるのは手順が守られたことで、モデルの判断が正しかったことではありません。人が AI の出力を抜き取り、アナリストの最終所見と突き合わせてください。証跡が途切れうる箇所は次のとおりです。
- AI の出力が保存されていない、または上書きされている：ステップ 4 は事後に証明できません。その出力に頼るのをやめます。
- 承認が実行より後になっている：その playbook のステップが Autonomous なら設計どおりです。Approval や Blocked のステップなら統制の不備として扱い、なぜ実行できたのかを調べます。
- 保持期間が監査の対象期間より短い、または時計がずれている：監査の日には元のイベントが消えているか、順序を再構成できません。
- 管理者が削除できる監査データ、または個人データを含む監査データ：AU-9 は、許可のない改変や削除からの保護を求めています。AU-3 の解説は、記録した入力から個人データが露出しうると注意しています。推奨パターンは、管理者と監査担当の職務分離です。
再構成の演習が失敗した、承認のない操作が見つかった、AI の出力が見当たらない、記録が改変されていないことをストレージで示せない、のいずれかの場合は、コンプライアンス担当へエスカレーションし、該当する playbook のステップを Approval または Blocked に切り替えます。
よくある質問
AI の要約をインシデントの記録として使えますか？
それだけでは使えません。要約はモデルが他の情報から作った文章で、記録の実体は元のイベント、クエリ、判断の記録です。要約は、テンプレート、モデルのバージョン、引用したイベントとともに添付してください。
監査証跡は、書き込み後に変更できない（write-once）ストレージに置く必要がありますか？
準拠する基準や監査人が求める場合に限ります。NIST AU-9(1) は、単に書き込み保護されただけの媒体ではなく、ハードウェアで強制される write-once 媒体を求めています。write-once が必要な場合は、お使いのプラットフォームと導入形態が何を提供するかを確認し、要件を満たすストレージへコピーをエクスポートしてください。
AI の記録はどのくらい保管すべきですか？
推奨パターンは、少なくとも、それが説明するインシデント記録と同じ期間、かつ監査サイクルをカバーする期間です。zcrLog は 90 日から 2 年、zcrSIEM は履歴ログを少なくとも 90 日保持すると資料に記載があります。ただしこれらはログの保持期間です。ケースやチケットに残した AI の出力は、そこで設定した保持期間に従います。
出典
続き: ランサムウェア対応で AI Agent が最初に自動化すべきこと、Human-in-the-Loop SOC、AI SOC Agent ガイド、SOARにおけるAgentic Automationの仕組み
zcrSIEM を見る · 料金を見る · zcr に相談
自社の環境についてのご相談は、こちらへどうぞ。
