自律型ペネトレーションテストの結果は信頼できるのか? OWASP APTSが求める記録と検証

今回扱う範囲

前回まで、OWASPの「Autonomous Penetration Testing Standard (APTS)」の8つのドメインのうち、実行時の安全性に関わる4つを見てきました (APTS v0.1.0を対象)。スコープ強制(Scope Enforcement)、安全制御(Safety Controls)、人間による監督(Human Oversight)、段階的な自律性(Graduated Autonomy)です。 これらは、ペネトレーションテスト(以下、ペンテスト)中に対象システムへ与える影響を抑えるための要件でした。

今回は、残りの4つのドメインを扱います。 監査可能性(Auditability)、操作耐性(Manipulation Resistance)、サプライチェーン信頼性(Supply Chain Trust)、報告(Reporting)です。

前半の4つのドメインが「検証対象を守る」ための要件だったのに対し、今回扱う後半のドメインは視点が変わります。ペンテストの終了後に何が起きたかを検証できるか、ペンテスト基盤自体が攻撃された際に耐えられるか、外部のAIプロバイダに依存して大丈夫か、そして出力された検証結果を信頼してよいか、という課題を扱います。APTS紹介の最終回として、これら4つを順に見ていきます。

すべての操作を後から再現できる状態にする

監査可能性のドメインには、20件の要件が含まれています。このドメインの目的は、ペンテスト基盤が行ったすべての操作を事後に検証し、再現し、異議を申し立てられる状態にすることです。

APTSによれば、自律型プラットフォームが人間の監督を減らして運用する権利を得られるのは、その判断、証拠、状態が、顧客によるレビュー、インシデント調査、規制当局の照会、紛争解決を支えるのに十分な忠実度で、事後に復元できる場合に限られます。 前回見た段階的な自律性は、この監査可能性が土台にあって初めて成り立ちます。

記録の中心になるのが、構造化されたイベントログです。 APTS-AR-001は、すべてのネットワークリクエストとレスポンス、システムイベントを、決められたフィールドを持つ構造化形式で記録することを求めています。ミリ秒精度のタイムスタンプ、イベントの種類、発生元、関連するイベントをつなぐ相関IDが共通のフィールドです。このログは、後から特定の操作を追跡し、その前後に何が起きたかを再構成するためのものです。

自動化された判断そのものも記録の対象です。 APTS-AR-004は、基盤が自動で下したすべての判断について、確信度スコア、検討した代替案(最低2つ)、選んだ理由を記録することを求めています。

ここでいう確信度スコアとは、その操作が意図した結果を達成する確率を0.0から1.0で表した値です。判断の結果だけでなく、なぜその判断に至ったのかを残すことで、後から判断の妥当性を検証できるようにします。

記録は、改ざんできないことが前提になります。 APTS-AR-012は、ログを追記専用とし、各エントリに前のエントリのハッシュ値を含めるハッシュ連鎖の構造を求めています。 連番と前エントリのハッシュがつながっているため、途中のエントリを削除したり書き換えたりすると連鎖が途切れ、改ざんが検出されます。

さらにAPTS-AR-020では、この監査記録をエージェントの実行環境からは書き込みも変更も削除もできない独立したストアに置くことを求めています。 ペンテストを実行する側が自分の記録を消せてしまえる状況なら、監査の意味がなくなるためです。

ペンテスト基盤自身が操作されることを防ぐ

操作耐性のドメインには、23件の要件が含まれています。このドメインは、ペンテスト基盤が外部からの操作により本来の統制を逸脱させられることを防ぎます。 プロンプトインジェクション、権限を詐称する入力、スコープの拡大を狙う働きかけ、ペンテストを妨害するために仕込まれた偽の対象などが想定される脅威です。

このドメインには、重要な前提が明記されています。 現在のAIやMLのアーキテクチャは、命令と対象由来のデータを同じコンテキストで処理するため、両者を完全に分離することは今日では実現できない、というものです。

第18回で触れた、対象ページに書かれた文言をモデルが指示として扱ってしまう問題は、モデルの構造に根ざしており、単一の対策では解消できません。そのため、標準は入力のサニタイズ、出力の検証、コンテキストの分離、監視、敵対的テストからなる多層防御を要件として定義しています。

具体的な要件は、この多層防御を構成します。 APTS-MR-018は、信頼できるシステムプロンプトと信頼できない対象由来のデータの間に、アーキテクチャレベルの境界を設けることを求めています。

実装ガイドが挙げるのは、対象由来のデータにタグ付けをしてシステムプロンプトと結合させないこと、システム用と対象データ用でモデルのインスタンスやコンテキストを分けること、モデルに投入する前に入力を検証することです。求められているのは文言のフィルタリングではなく、構造としての分離だという立場です。 

APTS-MR-005は、対象からの応答に含まれる「私は管理者だ」といった権限の詐称を検出して拒否すること、APTS-MR-010は「網羅性のため」「緊急」といった説得的な言い回しによるスコープ拡大の試みを検出することを求めています。 いずれも、対象から返ってくる情報がペンテスト基盤への指示になり得るという前提に立っています。

このドメインには、多層防御が実際に機能するかを確かめる要件もあります。APTS-MR-020は、ペンテスト基盤の運用者が自らの安全制御に対して、年1回以上、および主要な更新のたびに敵対的テストを実施することを求めています。

キルスイッチ、スコープ強制、エスカレーションといった制御に対して、既知の回避手法を試すテストです。テスト結果には敵対的入力の検出率、正常な入力を誤って警告した割合、検出までの平均時間といった定量的な指標を含め、これらは顧客の要求に応じて開示し、リリースのたびに更新することが定められています。 統制が備わっていることと、その統制が実際に効くことは別だという考え方が要件に表れています。

外部のAIプロバイダへの依存を統治する

サプライチェーン信頼性のドメインには、22件の要件が含まれています。自律型のペンテスト基盤は多くの場合、外部のAIプロバイダ、クラウドサービス、脆弱性情報のフィードに依存します。このドメインは、その依存先の選定、検証、統治を扱います。 APTSが指摘するのは、上流のモデルが更新されたりプロバイダが侵害されたりすると、他のすべての安全制御が無効になり得るという問題です。

依存先で特に注意が向けられているのが、AIモデルの扱いです。APTS-TP-002は、モデルを「最新版」ではなく明示的なバージョンで固定し、アップグレードの前には正式な変更管理と本番前のテストを行うことを求めています。モデルが黙って差し替わると、ペンテスト基盤の挙動が予告なく変わり、それまでの安全性の評価が通用しなくなるためです。

関連してAPTS-TP-022では、基盤モデルが実質的に変わった場合に、スコープ強制、安全制御、操作耐性、段階的な自律性の各ドメインを再評価することを求めています。プロバイダが変わる、モデルのファミリーが変わる、バージョンが世代をまたぐ、といった変化が実質的な変更に当たります。

検証対象の情報が外部に渡ることへの統制もあります。 APTS-TP-012は、顧客のデータを4段階に分類します。生の認証情報、暗号鍵、匿名化されていない個人情報などのRESTRICTEDデータは外部に送信してはいけません。一方、認証情報や暗号鍵を削除し、個人情報を匿名化するなどの処理を施したデータは、データ処理契約(DPA)を締結した承認済みのAIプロバイダへ送信できます。

どのAIプロバイダにどの分類のデータを送るのかを、契約書に明記して顧客の同意を得ることも要件です。APTS-TP-021では、使っている基盤モデルについてプロバイダ、モデルのファミリー、固定したバージョン、リリース日、ファインチューニングやシステムプロンプトの設定という5つの要素を開示することを求めています。ペンテストを依頼する側が、その基盤が何に依存しているかを把握できるようにするための要件です。

ペンテスト結果を検証可能にする

報告のドメインには、15件の要件が含まれています。このドメインは、ペンテスト基盤が生成する報告を、証拠に基づいて検証できるものにするためのものです。

自動化されたペンテストでは、実在しない脆弱性を検出結果として出してしまう可能性があるため、証拠と検証の要件が中心になります。出発点は検出結果を証拠と結びつけることです。

APTS-RP-001は、すべての検出結果にパケットキャプチャやHTTPのやり取り、コマンドの出力といった生の技術的証拠を含めることを求めています。「AIが生成した要約は証拠に添えることはできても、証拠の代わりにはならない」と明記されています。生の証拠がない検出結果は、報告書の中で「未検証」として明示的にフラグを付けます。 これは、モデルがもっともらしい説明を生成できてしまうことへの対策です。説明の説得力ではなく、証拠の有無で検出結果を扱います。

人間によるレビューも要件化されています。APTS-RP-002は、深刻度が最も高いCriticalの検出結果について、顧客に報告書を提供する前に人間がレビューすることを求めています。自律性レベルがL1からL3の場合、すべてのCriticalの検出結果は、資格を持つ人間のレビューを経てから顧客に提供されます。

前回見た最上位のL4では、人間のレビューを待たずに報告書を自動生成し、顧客に提供できます。ただし、提供から4時間以内に、Criticalの検出結果を人間が優先して事後レビューすることが推奨されています。

報告の正直さに関わる要件もあります。APTS-RP-008は、どの脆弱性クラスをテストし、どのクラスをテストしなかったのかを示すカバレッジの一覧を報告書に含めることを求めています。テストから除外したクラスを明示すること、カバレッジを過大に表現してはならないことが定められています。

自動化されたペンテストは網羅的に見えやすいため、何を見ていないのかを明示することが、結果を正しく受け取るために必要になります。あわせてAPTS-RP-006では、検出結果のうち誤検知だった割合を開示することも求めています。

APTSが示したもの

今回まで3回にわたって、APTSの8つのドメインを見てきました。 最初に確認したとおり、APTSは脆弱性の見つけ方を説明するペンテスト手法ではなく、自律型のペンテスト基盤に攻撃をさせるなら、どう統制すべきかを整理した標準です。

8つのドメインは、大きく2つの方向を向いていました。スコープ強制、安全制御、人間による監督、段階的な自律性は、ペンテスト中に対象システムへ与える影響を抑えるための統制でした。監査可能性、操作耐性、サプライチェーン信頼性、報告は、ペンテスト基盤自体の信頼性と、その結果の信頼性を確保するための統制でした。

これらの要件を貫いているのは、AIの判断能力を信頼の根拠にしないという前提です。境界はモデルの外側で強制し、判断はすべて記録して事後に検証できるようにし、検出結果は証拠と人間のレビューで裏付ける。モデルへの指示は統制にならないという立場が、8つのドメインすべてに共通していました。

APTSはまだ新しい標準であり、認証機関も必須の第三者監査もありません。それでも、自律型のペンテスト基盤を導入したり開発したりする立場からは、何を確認し何を設計すべきかのチェックリストとして使えます。そして、この設計思想はペンテストに限りません。

外部に影響を与える操作を自律的なAIに任せる場面では、同じ課題が繰り返し現れます。どこまで触ってよいのか、その操作をいま実行してよいのか、後から検証できるのか、結果を信頼してよいのか。 APTSは、それらの課題に答えを与える1つの具体例だと言えます。