2026 年 9 月：事件回應挑戰

從日誌、工件與系統追蹤調查模擬的 AI 安全事件。重建攻擊時間軸、辨識根本原因，並撰寫事件報告。

2026 年 9 月：事件回應挑戰

調查三起模擬的 AI 安全事件。您將獲得日誌、系統工件與對話逐字稿。您的任務是重建事發經過、辨識所用攻擊技巧、判定影響，並撰寫專業事件報告。

挑戰概覽

為何需要 AI 事件回應

AI 安全事件在幾方面不同於傳統安全事件：

• 攻擊工件是自然語言。 攻擊載荷不是惡意軟體二進位檔或利用程式碼，而是一段提示詞。辨識惡意提示詞需理解提示詞注入技巧。
• 影響帶有機率性。 同一攻擊可能因模型取樣而成功或失敗。判斷攻擊是否成功需分析模型輸出，而不僅是輸入。
• 傳統偵測工具會漏掉 AI 特有攻擊。 WAF、IDS 與 SIEM 規則並非為偵測提示詞注入、越獄或模型操弄而設計。
• 證據是對話式的。 攻擊敘事會在多輪中展開。理解攻擊需在上下文中閱讀對話，而非只搜尋已知指標。

事件

事件 1：「熱心的內部人員」（30 分）

情境： 一個部署於內部人資查詢的企業聊天機器人，一直產生違反公司政策的回應。數名員工回報收到與既定薪酬、休假與晉升程序政策相矛盾的建議。不一致之處很細微 —— 聊天機器人給出聽起來合理但錯誤的指引。

提供證據：

• 72 小時的對話日誌（約 2,000 次對話）
• 系統提示詞版本歷史（期間共 3 個版本）
• RAG 知識庫變更日誌，顯示新增/修改 47 份文件
• 模型 API 呼叫日誌，含時間戳、token 計數與延遲指標
• 使用者回饋報告（12 件抱怨）

您的調查應判定：

• 異常行為何時開始？
• 根本原因為何？（選項：RAG 投毒、系統提示詞修改、模型退化、合法政策變更但未反映在抱怨中）
• 哪些對話受影響？
• 影響範圍（多少員工收到錯誤指引、關於什麼主題）？
• 是蓄意攻擊還是營運錯誤？

計分細項：

事件 2：「資料外洩」（35 分）

情境： 某 AI 驅動的客戶支援系統被懷疑資料外洩。安全團隊注意到支援系統向外部端點發出異常的對外 API 呼叫。該系統使用具 email、資料庫與網頁瀏覽能力的多工具代理架構。

提供證據：

• 48 小時的代理執行日誌，含工具呼叫追蹤（所有工具呼叫、參數與結果）
• 顯示代理服務對外 HTTP 請求的網路流量日誌
• 該期間 500 次客戶支援對話
• 代理系統提示詞與工具配置檔
• 資料庫查詢日誌
• Email 發送日誌

您的調查應判定：

• 哪些對話觸發了可疑的對外呼叫？
• 哪些資料被外洩、洩露到何處？
• 所用攻擊技巧為何（直接提示詞注入、透過客戶資料的間接注入、工具鏈利用，或其他）？
• 攻擊針對特定資料還是機會性的？
• 從初始存取到資料外洩的完整攻擊時間軸為何？

計分細項：

事件 3：「慢火」（35 分）

情境： 某內容審核 AI 系統似乎逐漸失去偵測有害內容的效能。審核準確率在三個月內從 97% 降至 82%，但下降得夠緩慢，以致最初被歸因於內容模式變化而非攻擊。安全團隊現在懷疑對抗性操弄。

提供證據：

• 90 天的審核準確率指標（日粒度）
• 微調作業日誌（模型每週以新的標註範例微調）
• 期間來自 15 位人類審核員的訓練資料貢獻
• 模型檢查點比較資料（每週版本間的權重差異統計）
• 時間軸上各點被誤分類的內容樣本
• 審核員績效指標與登入日誌

您的調查應判定：

• 準確率下降是由攻擊、自然漂移，還是內容模式變化造成？
• 若為攻擊，機制為何？（選項：透過被入侵審核員帳戶的訓練資料投毒、設計以造成模型退化的對抗性輸入、直接模型權重操弄、內容分布變化）
• 您能辨識攻擊何時開始嗎？
• 哪個審核員帳戶（若有）負責？
• 哪些特定訓練範例被投毒？

計分細項：

調查方法論

步驟 1：證據分類

在深入任何單一工件前，先概覽所有可用證據：

• 日誌涵蓋哪些時段？
• 可用的細節層級為何？
• 證據有缺口嗎？
• 哪些證據來源最可能包含入侵指標？

步驟 2：時間軸建構

從所有證據來源建構事件時間軸：

• 對齊不同日誌來源的時間戳（留意時區差異）
• 辨識第一個異常事件
• 描繪從初始入侵到觀察到影響的進展
• 標註證據缺失之處

步驟 3：假設測試

對每個事件發展競爭假設，並對照證據測試：

步驟 4：影響評估

量化影響：

• 多少使用者/對話/紀錄受影響？
• 哪些資料被暴露、修改或遺失？
• 潛在下游影響為何（監管、聲譽、營運）？
• 事件仍在進行中，還是已被遏制？

步驟 5：報告撰寫

為每個事件使用下方範本撰寫專業事件報告。

事件報告範本

# Incident Report: [Incident Name]
 
## Summary
- **Detection Date:** [when the issue was noticed]
- **Incident Window:** [start to end of malicious activity]
- **Severity:** Critical/High/Medium/Low
- **Status:** Contained/Active/Remediated
 
## Executive Summary
[2-3 sentences for non-technical stakeholders]
 
## Timeline
| Timestamp | Event | Source |
|---|---|---|
| [time] | [what happened] | [which log/artifact] |
 
## Root Cause Analysis
[Detailed technical explanation of what caused the incident]
 
## Attack Technique
[Classification using MITRE ATLAS or similar framework]
 
## Impact Assessment
- **Data affected:** [description and quantity]
- **Users affected:** [count and description]
- **Business impact:** [operational, financial, reputational]
 
## Evidence
[Key artifacts supporting the analysis, with references]
 
## Recommendations
### Immediate Actions
[Steps to contain and remediate]
 
### Long-Term Improvements
[Systemic changes to prevent recurrence]
 
## Lessons Learned
[What this incident reveals about gaps in detection, prevention, or response]

分析工具

您可使用任何工具分析所提供的證據。建議方法：

• 以 jq/Python 解析日誌。 JSON 結構化的日誌以腳本分析最有效率。
• 時間軸工具。 像 timesketch 或簡單試算表時間軸，有助於跨來源關聯事件。
• 統計分析。 對事件 3，對訓練資料貢獻進行統計分析可揭露異常模式。
• Diff 工具。 比較文件版本、模型配置與系統提示詞版本可揭露未授權變更。

計分標準

除了各事件計分之外，還有一般品質因子：

• 以證據為基礎的結論。 報告中每個論點都須引用具體證據。無證據的臆測不得分。
• 正確歸因。 歸因到錯誤原因比承認不確定性更糟。若不確定，請明說，並解釋哪些額外證據能解決曖昧。
• 可行的建議。 建議須具體且可實作，不可是通用的（「改進安全」）。
• 清晰寫作。 事件報告由高階主管、法務團隊與工程師閱讀。為所有受眾清晰撰寫。

關鍵概念

AI 特有入侵指標

傳統 IOC（IP 位址、檔案 hash、登錄檔鍵值）有 AI 特有的對應：

歸因挑戰

AI 安全事件常有曖昧的根本原因。模型準確率下降可能是：

• 一次攻擊（資料投毒、對抗性輸入）
• 一個營運問題（不良訓練資料、配置變更）
• 自然漂移（資料分布變化）

區分這些需對時機、模式與佐證仔細分析。此挑戰訓練這種判斷。

培養的技能

此挑戰培養可直接應用於專業 AI 安全事件回應的能力：

大規模日誌分析

真實 AI 安全事件產生巨量日誌。此挑戰中的證據集刻意大到手動檢閱不可行。您必須發展有效的過濾策略：

• 使用統計方法辨識異常對話模式（訊息頻率、token 數、回應時間）
• 於對話日誌中搜尋已知攻擊特徵（提示詞注入模式、編碼嘗試、指令覆寫短語）
• 透過時間戳跨日誌來源關聯事件以建構統一時間軸
• 區分攻擊工件與正常營運雜訊

根本原因分析紀律

事件回應最難的部分不是找出發生了什麼 —— 而是找出為何發生並對結論有信心。這需要：

• 以證據為基礎的推理。 每個論點必須由具體日誌條目、工件或資料點支持。間接證據有價值但須被如此標示。
• 替代假設測試。 對每個事件有多個合理解釋。您必須系統地排除替代方案，而非確認第一個猜測。
• 承認不確定性。 專業的事件報告清楚陳述什麼已知、什麼被推論、什麼仍未知。寫「我們基於證據 Y 相信 X，但無法排除 Z」比不加條件地寫「發生了 X」更有力。

壓力下的溝通

事件報告服務多個受眾：

• 高階領導 需要一頁摘要：發生了什麼、有多嚴重、我們在做什麼、是否結束。
• 法務與合規 需要細節：哪些資料受影響、適用哪些法規、有什麼通知義務。
• 工程團隊 需要技術細節：具體壞在哪、修復方式、如何防再次發生。

為這三個受眾在單一文件中撰寫，是此挑戰透過報告撰寫要求所培養的技能。

跨事件的模式辨識

此挑戰的三個事件獨立，但共享出現在真實 AI 安全事件中的常見模式：

• 漸進退化，最初被歸因於營運雜訊而非攻擊活動
• 原本被假設隔離之元件間的信任邊界違反
• 未早期發現時隨時間累積的資料完整性問題
• 使得技術性攻擊得以運作的人為因素（審查流程不足、過度依賴自動化）

跨事件辨識這些模式，發展出有經驗事件回應者用以快速評估新情況的直覺。

延伸閱讀

• AI 鑑識與事件回應 —— 本挑戰的基礎概念
• 案例研究與領域特定 —— 實際事件範例
• 2026 年 10 月挑戰 —— 下一個挑戰