AI 紅隊證據蒐集

中級3 分鐘閱讀更新於 2026-03-21

AI 紅隊演練的系統化證據蒐集方法論,包含成品保存、發現文件化與保管鏈程序。

ai-forensics-ir red-team evidence-collection engagement-methodology

概觀

AI 紅隊演練中的證據蒐集與事件回應中的證據蒐集目的根本不同。事件回應中,你在重建發生了什麼。紅隊演練中,你在建立你做了什麼、你發現了什麼,以及這對組織安全態勢意味著什麼的紀錄。證據必須足夠詳細以重現發現、足夠可信以推動修補決策、結構足夠完整以能跨多次演練在時間軸上分析。

AI 紅隊演練引入了傳統滲透測試中不存在的證據類型。當你成功越獄 LLM 時,「證據」是一段對話——讓模型在預期邊界之外行為的一串自然語言訊息。當你發現 RAG 系統的提示詞注入漏洞時,證據包含被注入的文件、檢索上下文,以及模型的被妥協輸出。當你發現模型洩漏訓練資料時,證據則是一組與私有資料在統計顯著性上相符的生成輸出。

這些成品很脆弱。對話預設是暫態的。模型行為是隨機的——成功的攻擊下次嘗試時可能不會相同地重現。雲端託管模型可能隨時被更新,無預警地改變攻擊面。穩健的證據蒐集方法論必須納入所有這些挑戰。

本文涵蓋 AI 紅隊演練證據蒐集系統的設計,從規劃要捕捉什麼、以密碼學完整性保存成品,到產出推動修補的報告。

證據蒐集框架

定義證據分類

AI 紅隊證據分為數類,各需要不同的蒐集與保存方法。

import json, hashlib, uuid
from datetime import datetime, timezone
from dataclasses import dataclass, field
from enum import Enum
 
class EvidenceType(Enum):
    CONVERSATION = "conversation"
    PROMPT_PAYLOAD = "prompt_payload"
    MODEL_RESPONSE = "model_response"
    SCREENSHOT = "screenshot"
    CONFIGURATION = "configuration"
    NETWORK_CAPTURE = "network_capture"
    BEHAVIORAL_OBSERVATION = "behavioral_observation"
    RETRIEVAL_CONTEXT = "retrieval_context"
    TOOL_OUTPUT = "tool_output"
    METRIC_DATA = "metric_data"
 
class SeverityLevel(Enum):
    INFORMATIONAL = "informational"
    LOW = "low"
    MEDIUM = "medium"
    HIGH = "high"
    CRITICAL = "critical"

EvidenceItem 資料類別代表單一證據項目,欄位涵蓋:evidence_id、evidence_type、timestamp、title、description、content(字串/字典/位元組)、engagement_id、finding_id、severity、tags、metadata、integrity_hash、collector。其 compute_hash() 方法將內容序列化後以 SHA-256 雜湊,作為完整性指紋。

Finding 資料類別代表紅隊發現,欄位含 finding_id、title、description、severity、attack_category、attack_vector、impact、remediation、evidence_ids、reproducibility(always/usually/sometimes/once)、cvss_score、cwe_id、timestamp、engagement_id。

RedTeamEvidenceCollector 類別提供系統化證據蒐集介面,核心方法包括:

collect_conversation(messages, title, description, model_id, severity, tags):將一段對話記錄為 CONVERSATION 證據,內容為含 messages、message_count、model_id 的字典;計算完整性雜湊並呼叫 _store_evidence 存檔。
collect_prompt_payload(payload, title, attack_technique, target_model, effectiveness, response_summary, severity):記錄特定攻擊載荷。內容含 payload、攻擊技術、目標模型、效果(success/partial/failure)、回應摘要。標籤自動加入攻擊技術名稱與效果。
collect_behavioral_observation(observation, title, category, severity, supporting_evidence_ids):記錄對 AI 系統的行為觀察,例如安全繞過、資料洩漏等類別,可鏈結到支撐證據 ID。
create_finding(title, description, severity, attack_category, attack_vector, impact, remediation, evidence_ids, reproducibility, cvss_score, cwe_id):建立由證據支撐的發現;會驗證所有 evidence_ids 均已存在,並反向更新對應證據的 finding_id。
_store_evidence(evidence):將證據寫入 output_dir/evidence/.json,並附加到 evidence_log(僅能追加的稽核軌跡)。
_save_finding(finding):將發現寫入 output_dir/findings/.json。
_save_evidence_log():寫入整個蒐集日誌。

測試期間的自動化證據捕捉

包裝 API 呼叫以自動捕捉

在主動紅隊測試期間,手動記錄每次 API 呼叫並不實際。應包裝 API 客戶端以自動將所有互動捕捉為證據。

EvidenceCapturingClient 包裝 LLM API 客戶端,自動將所有互動作為鑑識證據捕捉。建構時傳入實際 API 客戶端、RedTeamEvidenceCollector、目標模型與是否自動標記的旗標。

send_message(messages, attack_technique, notes, **kwargs) 會:(1) 呼叫底層 API、(2) 計算延遲毫秒數、(3) 從回應抽取文字並組裝完整訊息串,(4) 呼叫 collector 的 collect_conversation 自動存證,標題含互動序號與攻擊技術,描述含延遲與紅隊註記,標籤含攻擊技術與「auto_captured」。

_extract_response_text(response) 支援多種 API 回應格式:OpenAI 格式從 choices[0].message.content 擷取、Anthropic 格式從 content[0].text 擷取,並能處理字串與其他形式。

可重現性測試

無法重現的發現價值有限。識別潛在漏洞後,系統化地測試其可重現性。

test_reproducibility(client, attack_messages, success_criteria, num_trials, attack_technique) 多次執行攻擊並檢查成功標準:

執行 num_trials 次重現(預設 10),每次以不同 trial 序號標記
success_criteria 是接受回應文字並回傳 True/False 的函式
成功率分級:≥0.9 → always、≥0.6 → usually、≥0.2 → sometimes、否則 → rarely
回傳字典含總試次、成功數、成功率、可重現性等級與每次結果詳情

報告產出

產製演練報告

紅隊演練結束時,應產出結構化報告,呈現含支撐證據的發現。報告應同時適合技術與高層讀者。

EngagementReportGenerator.generate_report(collector, engagement_name, scope_description, executive_summary) 產出完整演練報告:

將發現依嚴重性降序排列
輸出固定格式的標頭(演練名稱、ID、時間戳)
SCOPE 區塊列出範圍描述
EXECUTIVE SUMMARY 使用提供的摘要,否則由 _auto_executive_summary 自動生成
FINDINGS SUMMARY 依嚴重性分組計數(critical/high/medium/low/informational),並列出總發現數與證據項目數
DETAILED FINDINGS 對每個發現輸出編號、ID、嚴重性、CVSS、CWE、可重現性、描述、攻擊向量、衝擊、修補建議,以及支撐證據清單

_auto_executive_summary 會:點出關鍵與高嚴重性發現的數量與標題,建議關鍵發現需立即修補、高嚴重性發現應在下個衝刺週期處理。

_severity_order 提供嚴重性排序:INFORMATIONAL(0) → CRITICAL(4)。

為證據蒐集規劃演練

演練前的證據需求

在任何測試開始前,定義將蒐集什麼證據與蒐集方式。與演練利害關係人(通常是 AI 產品團隊與安全團隊)合作建立證據需求。典型包括:每項發現的最低文件化標準、每個證據項目的必需元資料、證據分類等級與處理程序、最終報告的格式與結構。

定義證據保留政策:演練結束後證據將保留多久?對大多組織而言,紅隊演練證據應至少保留一年以支援跨多次演練的趨勢分析。對受監管產業,保留需求可能更長。

在測試開始前建立工具與基礎設施。以演練 ID 設定證據蒐集系統、建立輸出目錄、設定 API 客戶端包裝器以自動捕捉,並透過測試互動驗證證據正確儲存。演練途中才發現工具問題會浪費測試時間且可能導致證據流失。

演練規則與證據邊界

AI 紅隊演練需要清楚的演練規則,定義哪些系統可被測試、哪些攻擊技術獲準、哪些資料可被蒐集。這些規則直接影響證據蒐集。

若演練規則禁止針對生產使用者資料測試,請確保你的證據蒐集系統不會捕捉真實使用者對話或 PII。若某些攻擊技術超出範圍(例如對開發團隊的社交工程),請確保任何潛在社交工程漏洞的附帶證據被記錄但不被積極追逐。

演練規則也應指定若紅隊在測試期間發現活躍的非模擬資安事件會如何處理。此情境罕見但非未曾出現:調查 AI 系統防禦的紅隊員可能發現實際惡意活動的證據。定義升級程序:停止測試、保留證據,並透過既定溝通管道通知事件回應團隊。

與藍隊合作

最有效的 AI 紅隊演練產出藍隊(防禦者)可直接採取行動的證據。設計證據蒐集以支援此目標。每個發現不僅應包含攻擊技術與其衝擊,還應包含具體偵測機會:哪些日誌項目、指標或行為訊號能揭露此攻擊?藍隊可部署什麼監控以於未來偵測類似攻擊?

從雙重視角記錄攻擊:紅隊觀點(他們做了什麼以及為何有效)與藍隊觀點(有哪些訊號可用以及為何被錯過或未被監控)。此雙重視角讓證據包成為完整的學習資源,而非僅是漏洞報告。

保管鏈考量

維持證據完整性

整個 AI 紅隊演練期間,維持所有證據的保管鏈。每個證據項目應在蒐集時計算 SHA-256 雜湊、含蒐集者識別與時間戳。證據日誌提供僅能追加的稽核軌跡,記錄蒐集了什麼與何時蒐集。

對可能有法律意涵的演練(例如受監管產業測試或蒐集第三方 AI 濫用證據),考慮額外控制:證據檔案的 write-once 儲存、對關鍵發現進行雙人完整性驗證,以及使用 GPG 或類似工具對證據清單簽章。

特定 AI 攻擊類型的證據蒐集

越獄證據

記錄成功越獄時,捕捉從第一則訊息到越獄成功的完整對話,包含中間任何失敗嘗試。失敗嘗試具鑑識價值,因為它們記錄了模型的防禦邊界並顯示攻擊技術的進展。記錄精確模型版本、溫度設定與其他參數,因為越獄成功率對這些設定敏感。在多個溫度值測試可重現性並記錄越獄成功的範圍。

也包含負面證據:記錄越獄成功前模型正確拒絕了什麼。這建立基準安全行為並讓越獄發現更可信。若越獄只在特定系統提示詞組態下有效,同時記錄易受攻擊的組態與越獄失敗的組態。

RAG 投毒證據

RAG 投毒發現應捕捉被投毒的文件、其嵌入、被檢索時的相似度分數、觸發檢索的查詢、模型使用被投毒上下文的輸出,以及對相同查詢使用乾淨上下文的輸出。投毒與乾淨輸出的比較是證明衝擊的核心證據。

記錄注入路徑:被投毒文件如何進入知識庫、通過了哪些驗證或過濾、投毒能否被既有內容審核偵測。若投毒利用嵌入模型的特定特性(例如對抗性製作的文字嵌入接近目標查詢),記錄嵌入相似度分析。

訓練資料萃取證據

當模型洩漏訓練資料時,證據必須證明生成輸出與實際訓練資料相符,而非巧合生成。這需要將模型輸出與已知訓練資料來源比較。使用多種提示策略誘發相同資料並記錄成功率。透過衡量輸出在模型下的困惑度對比參考分佈下的困惑度,計算生成為巧合的統計可能性。

捕捉觸發萃取的完整提示詞、模型的完整輸出、相符的訓練資料來源(含出處),以及顯示相符具統計顯著性的相似度分析。若萃取揭露個人可辨識資訊或受著作權保護材料,分別以適當處理標記標註。

處理敏感證據

AI 紅隊證據常含敏感材料:成功的越獄載荷、含有害內容的模型輸出、洩漏的訓練資料,或暴露的系統提示詞。適當分類證據並套用存取控制。將敏感載荷與主證據庫分開儲存,加上額外存取限制。在分發給更廣受眾的報告中將敏感內容編修,同時在安全證據庫中保留未編修的完整證據供技術審查。

證據品質指標

衡量證據完整性

每次演練結束時,評估所蒐集證據的品質與完整性。可追蹤指標:每個發現的證據數比(每個發現應至少 2-3 個支撐證據)、可重現性測試涵蓋率(多少比例的發現經過可重現性測試)、元資料完整性(多少比例的證據項目填齊所有標準元資料欄位),以及雜湊驗證率(多少比例的證據項目計算並驗證完整性雜湊)。

跨演練追蹤這些指標以識別趨勢。若證據品質下降,調查測試方法是否變得匆促、工具是否需要改善,或演練範圍是否已擴展到超出團隊能徹底記錄的能力。證據品質直接影響發現的可信度與修補被優先處理的可能性。

證據歸檔與跨演練分析

每次演練後,將完整證據包歸檔至可長期供未來參考的儲存系統。隨時間累積,歸檔能實現跨演練分析:相同漏洞模式是否跨多次演練出現?修補建議是否被實作且有效?哪些 AI 模型或架構最常出現漏洞?

建立跨歸檔演練的可搜尋索引,允許依攻擊技術、AI 模型、漏洞類型與嚴重性查詢。此索引成為知識庫,為未來演練規劃提供資訊,並幫助紅隊依歷史觀察的漏洞模式優先排序測試。

參考資料

MITRE ATLAS (Adversarial Threat Landscape for AI Systems). "ATLAS Matrix." https://atlas.mitre.org/
NIST AI 100-2 E2023 (2024). "Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations." https://csrc.nist.gov/pubs/ai/100/2/e2023/final
Microsoft (2024). "AI Red Team Playbook." https://learn.microsoft.com/en-us/security/ai-red-team/

AI 紅隊證據蒐集

中級3 分鐘閱讀更新於 2026-03-21

AI 紅隊演練的系統化證據蒐集方法論,包含成品保存、發現文件化與保管鏈程序。

ai-forensics-ir red-team evidence-collection engagement-methodology

概觀

本文涵蓋 AI 紅隊演練證據蒐集系統的設計,從規劃要捕捉什麼、以密碼學完整性保存成品,到產出推動修補的報告。

證據蒐集框架

定義證據分類

AI 紅隊證據分為數類,各需要不同的蒐集與保存方法。

import json, hashlib, uuid
from datetime import datetime, timezone
from dataclasses import dataclass, field
from enum import Enum
 
class EvidenceType(Enum):
    CONVERSATION = "conversation"
    PROMPT_PAYLOAD = "prompt_payload"
    MODEL_RESPONSE = "model_response"
    SCREENSHOT = "screenshot"
    CONFIGURATION = "configuration"
    NETWORK_CAPTURE = "network_capture"
    BEHAVIORAL_OBSERVATION = "behavioral_observation"
    RETRIEVAL_CONTEXT = "retrieval_context"
    TOOL_OUTPUT = "tool_output"
    METRIC_DATA = "metric_data"
 
class SeverityLevel(Enum):
    INFORMATIONAL = "informational"
    LOW = "low"
    MEDIUM = "medium"
    HIGH = "high"
    CRITICAL = "critical"

RedTeamEvidenceCollector 類別提供系統化證據蒐集介面,核心方法包括:

collect_conversation(messages, title, description, model_id, severity, tags):將一段對話記錄為 CONVERSATION 證據,內容為含 messages、message_count、model_id 的字典;計算完整性雜湊並呼叫 _store_evidence 存檔。
collect_prompt_payload(payload, title, attack_technique, target_model, effectiveness, response_summary, severity):記錄特定攻擊載荷。內容含 payload、攻擊技術、目標模型、效果(success/partial/failure)、回應摘要。標籤自動加入攻擊技術名稱與效果。
collect_behavioral_observation(observation, title, category, severity, supporting_evidence_ids):記錄對 AI 系統的行為觀察,例如安全繞過、資料洩漏等類別,可鏈結到支撐證據 ID。
create_finding(title, description, severity, attack_category, attack_vector, impact, remediation, evidence_ids, reproducibility, cvss_score, cwe_id):建立由證據支撐的發現;會驗證所有 evidence_ids 均已存在,並反向更新對應證據的 finding_id。
_store_evidence(evidence):將證據寫入 output_dir/evidence/.json,並附加到 evidence_log(僅能追加的稽核軌跡)。
_save_finding(finding):將發現寫入 output_dir/findings/.json。
_save_evidence_log():寫入整個蒐集日誌。

執行 num_trials 次重現(預設 10),每次以不同 trial 序號標記
success_criteria 是接受回應文字並回傳 True/False 的函式
成功率分級:≥0.9 → always、≥0.6 → usually、≥0.2 → sometimes、否則 → rarely
回傳字典含總試次、成功數、成功率、可重現性等級與每次結果詳情

報告產出

產製演練報告

紅隊演練結束時,應產出結構化報告,呈現含支撐證據的發現。報告應同時適合技術與高層讀者。

EngagementReportGenerator.generate_report(collector, engagement_name, scope_description, executive_summary) 產出完整演練報告:

將發現依嚴重性降序排列
輸出固定格式的標頭(演練名稱、ID、時間戳)
SCOPE 區塊列出範圍描述
EXECUTIVE SUMMARY 使用提供的摘要,否則由 _auto_executive_summary 自動生成
FINDINGS SUMMARY 依嚴重性分組計數(critical/high/medium/low/informational),並列出總發現數與證據項目數
DETAILED FINDINGS 對每個發現輸出編號、ID、嚴重性、CVSS、CWE、可重現性、描述、攻擊向量、衝擊、修補建議,以及支撐證據清單

_auto_executive_summary 會:點出關鍵與高嚴重性發現的數量與標題,建議關鍵發現需立即修補、高嚴重性發現應在下個衝刺週期處理。

_severity_order 提供嚴重性排序:INFORMATIONAL(0) → CRITICAL(4)。

MITRE ATLAS (Adversarial Threat Landscape for AI Systems). "ATLAS Matrix." https://atlas.mitre.org/
NIST AI 100-2 E2023 (2024). "Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations." https://csrc.nist.gov/pubs/ai/100/2/e2023/final
Microsoft (2024). "AI Red Team Playbook." https://learn.microsoft.com/en-us/security/ai-red-team/

AI 紅隊證據蒐集

相關文章

AI 紅隊證據蒐集

相關文章