交付物	描述	權重
事件時間軸	分鐘等級的應變行動時間軸	15%
調查報告	含證據鏈的詳細調查發現	25%
圍堵行動	已記錄的圍堵決策與執行	15%
事後檢討報告	完整事後檢討,含根因、衝擊與改善	30%
溝通草稿	內部升級與客戶通知範本	15%

評分準則

分流速度 (15%) — 在演練前 15 分鐘內正確評估嚴重性,並採取適切的立即行動
調查徹底度 (25%) — 檢視所有可得證據,正確辨識根因
圍堵決策 (20%) — 圍堵行動合比例 (不因下線全部而反應過度,也不因讓系統繼續運作而反應不足)
事後檢討品質 (25%) — 根因分析準確、衝擊評估有資料支持,建議處理系統性議題 (非僅處理眼前 bug)
溝通 (15%) — 升級與通知草稿適合對應受眾 (技術團隊、法務、受影響客戶)

分階段做法

階段 1:偵測與分流 (1 小時)

評估嚴重性與範圍
依初期證據決定:洩漏了哪些資料?可能影響多少客戶?事件是否仍在進行?法規分類為何 (PII 外洩、HIPAA、GDPR)?指派初始嚴重性等級。
做出立即圍堵決策
決定:邊調查邊繼續運作、停用受影響函式 (get_account_details)、將聊天機器人完全下線,或實施部分緩解 (例如修改系統提示詞拒絕帳戶相關查詢)。記錄決策與理由。
適切升級通報
草擬對以下對象的內部升級通知:工程團隊 (技術細節)、管理階層 (商業衝擊)、法務團隊 (法規含義)、PR/公關 (客戶衝擊)。每份通知應依受眾調整。
開始保存證據
辨識並保存所有相關證據:對話日誌、應用程式日誌、函式呼叫紀錄、RAG 管道設定、系統提示詞版本,以及文件上傳歷史。確保日誌未在您能審視前自動輪替。

階段 2:調查 (3 小時)

重建攻擊時間軸
使用對話日誌與應用程式日誌,決定:資料外洩何時首次發生?影響多少對話?洩漏了哪些客戶資料給誰,其中是否有模式?這是鎖定目標的攻擊,還是系統故障?
辨識根因
追溯資料從來源到曝光的流動。另一客戶的資料如何進入聊天機器人回應?是透過函式呼叫系統、RAG 管道、對話歷程交叉汙染,還是其他原因?辨識具體失效點。
評估完整衝擊
確定完整範圍:多少客戶的資料被洩漏、洩漏給多少其他客戶、時間範圍為何,以及包含哪些資料類型。此資訊為法規通報所需。
判斷漏洞是否仍在活動中
驗證階段 1 的圍堵行動是否有效。資料是否仍透過其他管道曝光?管道中是否存在可能導致同一問題的其他類似漏洞?

階段 3:圍堵與修復 (2 小時)

實施確定性圍堵
依調查發現實施永久圍堵:從 RAG 索引移除受汙染文件、驗證函式呼叫系統回傳正確資料,並確認不存在殘留曝光路徑。
發展並測試修補
處理根因:對 RAG 接入管道實施內容驗證、對接入文件加入 PII 偵測、將客戶資料與知識庫內容分離,並為文件上傳流程加入存取控制。
驗證修復
測試修復後系統以確認:漏洞已解決、修補未引入新議題,以及系統對合法使用情境仍正常運作。

階段 4:事後檢討與報告 (3 小時)

撰寫事件時間軸
產出從初期偵測到修復的分鐘級時間軸,含所有決策、行動與發現的證據。
撰寫事後檢討報告
產出完整事後檢討,涵蓋:事件摘要、時間軸、根因分析 (5 Whys 或魚骨圖)、衝擊評估 (量化)、圍堵與修復行動、促成因素,以及系統性改善建議。
草擬客戶通知
撰寫給受影響個人的客戶通知:以淺白語言解釋發生了什麼、指明曝光的資料、描述您正在處理的措施,並提供問題聯絡資訊。送出前由法務審閱。
發展改善建議
辨識超越立即修補的系統性改善:內容驗證管道、PII 掃描、資料分離架構、資料曝光監控與告警,以及事件回應流程更新。這些應能預防一整類類似事件,而非僅此特定事件。

範例輸出

分流評估範例

## Initial Triage Assessment
**Time:** T+15 minutes
**Severity:** SEV-1 (Critical — PII data breach, ongoing)
**Scope:** Unknown, potentially all conversations in last 72 hours
 
### Assessment
- Confirmed PII exposure: customer name, email, partial account number
- Cross-customer data leakage via chatbot responses
- Incident is potentially ongoing (system still active)
- Regulatory implications: GDPR Article 33/34 notification may be required
  (72-hour window starts at awareness of breach)
 
### Immediate Actions
1. DISABLE get_account_details function via feature flag (T+18 min)
2. Add system prompt instruction: "Do not reference any customer data
   in responses until further notice" (T+22 min)
3. Preserve all conversation logs from past 7 days (T+25 min)
4. Escalate to engineering lead, legal, and CISO (T+30 min)
 
### Rationale for Not Taking System Offline
Taking the chatbot fully offline would impact 5,000 daily conversations
and create a visible outage. The function disable + prompt modification
should stop the data exposure while maintaining basic chatbot functionality
for non-account queries. Will re-evaluate if exposure continues.

根因 (5 Whys) 範例

## Root Cause Analysis: 5 Whys
 
1. **Why** did the chatbot expose Customer B's data to Customer A?
   → The LLM included customer record data from the RAG context in its response.
 
2. **Why** was Customer B's record in the RAG context for Customer A's query?
   → The vector similarity search retrieved a customer record document because
     it contained order-related keywords matching Customer A's query.
 
3. **Why** were customer records in the RAG document index?
   → A batch upload 3 days ago included a customer data export file mixed
     in with FAQ documents.
 
4. **Why** was customer data mixed with FAQ documents?
   → The upload process ingests all files from a shared drive folder without
     content validation or classification.
 
5. **Why** is there no content validation on the RAG ingestion pipeline?
   → The pipeline was built as a prototype and deployed to production without
     a security review. No data classification or PII detection was ever
     implemented.
 
**Root Cause:** The RAG ingestion pipeline lacks content validation, PII
detection, and data classification controls, allowing arbitrary content
including customer PII to be indexed and surfaced in chatbot responses.

提示

Knowledge Check

在此事件情境中,為何停用 get_account_details 函式優於將整個聊天機器人下線作為初期圍堵?

頂石專案:AI 事件回應演練

進階5 分鐘閱讀更新於 2026-03-15

透過分流、調查、圍堵、修復與事後檢討報告,回應一場模擬的 AI 安全事件。

capstone incident-response forensics post-mortem advanced

概觀

先備條件

AI 鑑識與事件回應 — AI 系統的 IR 方法論
提示詞注入 — 理解事件中使用的攻擊技術
代理式利用 — 代理與工具濫用概念
防禦與護欄 — 理解本應就位的防禦
執行與報告撰寫 — 報告撰寫

專案簡介

事件情境

您是值班的 AI 安全應變人員。以下是一開始所知資訊:

系統: CustomerAssist — LLM 驅動的客服聊天機器人,4 個月前部署。每天處理約 5,000 次對話,跨網頁與行動通道。

架構:

透過 Azure OpenAI 的 GPT-4,經自訂編排層存取
RAG 管道連接客戶知識庫與 FAQ 文件
函式呼叫用於帳戶查詢、訂單狀態與建立工單
對話歷程保存 30 天
基本輸入長度限制 (無其他安全控制)

初期證據:

客戶截圖顯示聊天機器人回應中包含另一客戶資料
回應似乎包含不屬於回報者的姓名、電子郵件與帳號末四碼
客戶表示僅詢問「我最近訂單的狀態為何?」

可用資源:

可存取對話日誌 (過去 30 天)
可存取應用程式日誌 (API 呼叫、函式呼叫、錯誤)
可存取編排層程式碼與系統提示詞
可存取 RAG 管道設定與文件索引
可修改系統提示詞、停用函式,或將系統下線
工程團隊、法務團隊與 PR 團隊的聯絡資訊

事件時間軸 (逐步揭露)

隨調查進展,您將發現更多證據。請依序完成各階段,若卡住可使用末尾的提示。

階段 1 證據 (立即可得):

客戶截圖
應用程式日誌顯示涉及對話
函式呼叫日誌顯示以另一客戶 ID 呼叫 get_account_details

階段 2 證據 (調查中發現):

過去 72 小時內另有 47 個對話中,帳戶資料出現在對無關客戶的回應裡
模式:所有受影響對話皆為詢問「orders」的使用者,回應包含字母相鄰客戶紀錄的資料
RAG 管道 3 天前以新文件批次更新,其中包含一份格式不當的客戶資料匯出檔

階段 3 證據 (深入調查中發現):

格式不當的文件包含原始客戶紀錄,與 FAQ 內容混雜
RAG 管道對接入文件無內容驗證或 PII 偵測
當使用者詢問「orders」時,向量相似度搜尋偶爾會檢索到客戶紀錄,因為紀錄含訂單相關關鍵字
文件批次在接入前無人審查 — 上傳由共享雲端硬碟自動化

交付物

主要交付物

交付物	描述	權重
事件時間軸	分鐘等級的應變行動時間軸	15%
調查報告	含證據鏈的詳細調查發現	25%
圍堵行動	已記錄的圍堵決策與執行	15%
事後檢討報告	完整事後檢討,含根因、衝擊與改善	30%
溝通草稿	內部升級與客戶通知範本	15%

評分準則

分流速度 (15%) — 在演練前 15 分鐘內正確評估嚴重性,並採取適切的立即行動
調查徹底度 (25%) — 檢視所有可得證據,正確辨識根因
圍堵決策 (20%) — 圍堵行動合比例 (不因下線全部而反應過度,也不因讓系統繼續運作而反應不足)
事後檢討品質 (25%) — 根因分析準確、衝擊評估有資料支持,建議處理系統性議題 (非僅處理眼前 bug)
溝通 (15%) — 升級與通知草稿適合對應受眾 (技術團隊、法務、受影響客戶)

分階段做法

階段 1:偵測與分流 (1 小時)

評估嚴重性與範圍
依初期證據決定:洩漏了哪些資料?可能影響多少客戶?事件是否仍在進行?法規分類為何 (PII 外洩、HIPAA、GDPR)?指派初始嚴重性等級。
做出立即圍堵決策
決定:邊調查邊繼續運作、停用受影響函式 (get_account_details)、將聊天機器人完全下線,或實施部分緩解 (例如修改系統提示詞拒絕帳戶相關查詢)。記錄決策與理由。
適切升級通報
草擬對以下對象的內部升級通知:工程團隊 (技術細節)、管理階層 (商業衝擊)、法務團隊 (法規含義)、PR/公關 (客戶衝擊)。每份通知應依受眾調整。
開始保存證據
辨識並保存所有相關證據:對話日誌、應用程式日誌、函式呼叫紀錄、RAG 管道設定、系統提示詞版本,以及文件上傳歷史。確保日誌未在您能審視前自動輪替。

階段 2:調查 (3 小時)

重建攻擊時間軸
使用對話日誌與應用程式日誌,決定:資料外洩何時首次發生?影響多少對話?洩漏了哪些客戶資料給誰,其中是否有模式?這是鎖定目標的攻擊,還是系統故障?
辨識根因
追溯資料從來源到曝光的流動。另一客戶的資料如何進入聊天機器人回應?是透過函式呼叫系統、RAG 管道、對話歷程交叉汙染,還是其他原因?辨識具體失效點。
評估完整衝擊
確定完整範圍:多少客戶的資料被洩漏、洩漏給多少其他客戶、時間範圍為何,以及包含哪些資料類型。此資訊為法規通報所需。
判斷漏洞是否仍在活動中
驗證階段 1 的圍堵行動是否有效。資料是否仍透過其他管道曝光?管道中是否存在可能導致同一問題的其他類似漏洞?

階段 3:圍堵與修復 (2 小時)

實施確定性圍堵
依調查發現實施永久圍堵:從 RAG 索引移除受汙染文件、驗證函式呼叫系統回傳正確資料,並確認不存在殘留曝光路徑。
發展並測試修補
處理根因:對 RAG 接入管道實施內容驗證、對接入文件加入 PII 偵測、將客戶資料與知識庫內容分離,並為文件上傳流程加入存取控制。
驗證修復
測試修復後系統以確認:漏洞已解決、修補未引入新議題,以及系統對合法使用情境仍正常運作。

階段 4:事後檢討與報告 (3 小時)

撰寫事件時間軸
產出從初期偵測到修復的分鐘級時間軸,含所有決策、行動與發現的證據。
撰寫事後檢討報告
產出完整事後檢討,涵蓋:事件摘要、時間軸、根因分析 (5 Whys 或魚骨圖)、衝擊評估 (量化)、圍堵與修復行動、促成因素,以及系統性改善建議。
草擬客戶通知
撰寫給受影響個人的客戶通知:以淺白語言解釋發生了什麼、指明曝光的資料、描述您正在處理的措施,並提供問題聯絡資訊。送出前由法務審閱。
發展改善建議
辨識超越立即修補的系統性改善:內容驗證管道、PII 掃描、資料分離架構、資料曝光監控與告警,以及事件回應流程更新。這些應能預防一整類類似事件,而非僅此特定事件。

範例輸出

分流評估範例

## Initial Triage Assessment
**Time:** T+15 minutes
**Severity:** SEV-1 (Critical — PII data breach, ongoing)
**Scope:** Unknown, potentially all conversations in last 72 hours
 
### Assessment
- Confirmed PII exposure: customer name, email, partial account number
- Cross-customer data leakage via chatbot responses
- Incident is potentially ongoing (system still active)
- Regulatory implications: GDPR Article 33/34 notification may be required
  (72-hour window starts at awareness of breach)
 
### Immediate Actions
1. DISABLE get_account_details function via feature flag (T+18 min)
2. Add system prompt instruction: "Do not reference any customer data
   in responses until further notice" (T+22 min)
3. Preserve all conversation logs from past 7 days (T+25 min)
4. Escalate to engineering lead, legal, and CISO (T+30 min)
 
### Rationale for Not Taking System Offline
Taking the chatbot fully offline would impact 5,000 daily conversations
and create a visible outage. The function disable + prompt modification
should stop the data exposure while maintaining basic chatbot functionality
for non-account queries. Will re-evaluate if exposure continues.

根因 (5 Whys) 範例

## Root Cause Analysis: 5 Whys
 
1. **Why** did the chatbot expose Customer B's data to Customer A?
   → The LLM included customer record data from the RAG context in its response.
 
2. **Why** was Customer B's record in the RAG context for Customer A's query?
   → The vector similarity search retrieved a customer record document because
     it contained order-related keywords matching Customer A's query.
 
3. **Why** were customer records in the RAG document index?
   → A batch upload 3 days ago included a customer data export file mixed
     in with FAQ documents.
 
4. **Why** was customer data mixed with FAQ documents?
   → The upload process ingests all files from a shared drive folder without
     content validation or classification.
 
5. **Why** is there no content validation on the RAG ingestion pipeline?
   → The pipeline was built as a prototype and deployed to production without
     a security review. No data classification or PII detection was ever
     implemented.
 
**Root Cause:** The RAG ingestion pipeline lacks content validation, PII
detection, and data classification controls, allowing arbitrary content
including customer PII to be indexed and surfaced in chatbot responses.

提示

Knowledge Check

在此事件情境中,為何停用 get_account_details 函式優於將整個聊天機器人下線作為初期圍堵?

頂石專案:AI 事件回應演練

評估嚴重性與範圍

做出立即圍堵決策

適切升級通報

開始保存證據

重建攻擊時間軸

辨識根因

評估完整衝擊

判斷漏洞是否仍在活動中

實施確定性圍堵

發展並測試修補

驗證修復

撰寫事件時間軸

撰寫事後檢討報告

草擬客戶通知

發展改善建議

相關文章

頂石專案:AI 事件回應演練

評估嚴重性與範圍

做出立即圍堵決策

適切升級通報

開始保存證據

重建攻擊時間軸

辨識根因

評估完整衝擊

判斷漏洞是否仍在活動中

實施確定性圍堵

發展並測試修補

驗證修復

撰寫事件時間軸

撰寫事後檢討報告

草擬客戶通知

發展改善建議

相關文章