完整流程

昨天做好了 Data Pack。今天走完剩下的路：

Data Pack → CVE/情報比對 → 脈絡組裝 → 生成初稿 → 送審

第一步：比對與擴充

Data Pack 組好之後，還要做幾次外部查詢。這些全部是確定性的程式呼叫，不經過模型：

• IOC 情報比對：IP、domain、hash 丟威脅情報源查信譽
• CVE 關聯：如果告警帶有漏洞利用特徵，查對應的 CVE 詳情與 CVSS
• 歷史案例查詢：這個客戶過去有沒有類似事件？用技術編號組合去查歷史報告庫
• 資產清單查詢：昨天講的業務脈絡

查到的結果回填進 Data Pack。查不到的填空值＋標記「已查詢無結果」。

歷史案例查詢這一項值得多說。如果查到這個客戶三個月前有過類似事件，報告裡就能寫「本事件與 IR-2026-0428-007 的行為模式相似」——這是客戶最有感的加值，也是通用模型絕對做不到的事，因為它沒看過那份歷史報告。

第二步：脈絡組裝（prompt 的實際結構）

送給模型的 prompt 分四塊，順序固定：

[SYSTEM]
你是資安監控中心的分析師，負責撰寫給客戶閱讀的資安事件報告初稿。

規則：
1. 只使用 <data_pack> 中提供的資訊，不得自行推測或補充未提供的事實。
2. 資訊不足時，於該段落標註「待補充」，不得填入推測內容。
3. 嚴重性等級必須使用 client_preferences 指定的分級。
4. 技術編號的信心程度為「推測」時，敘述須使用推測語氣。
5. 所有數字直接引用 data_pack，不得自行計算。
6. 依 <template> 的段落結構輸出，不得增減段落。

[TEMPLATE]
（這個客戶上一份報告的段落骨架，不含內容）

[REFERENCE]
（RAG 檢索到的技術說明、歷史相似案例摘要）

[DATA_PACK]
（昨天那包 JSON）

幾個刻意的設計：

規則 1 是防幻覺的主要防線。 明確把資訊邊界劃在 data_pack 裡。

規則 2 比規則 1 更重要。 只說「不要編造」，模型遇到缺資訊時可能會沉默地跳過那段。給它一個合法的出口（標註「待補充」），它才會誠實地留白。留白比編造好一百倍，而且留白會直接提示審核者去補。

規則 5 呼應 Day 15：數字不讓模型碰。

TEMPLATE 放的是骨架不是範例。 如果放完整的上一份報告，模型會抄內容。只放段落結構，它才會照結構寫新內容。

第三步：初稿長什麼樣

用昨天的 Data Pack，產出的初稿大致是（合成）：

# 資安事件報告（初稿）
報告編號：IR-2026-0731-014
事件偵測時間：2026-07-31 14:14 (UTC+8)
嚴重性：高

 

## 一、事件摘要
2026 年 7 月 31 日下午，監控系統於財務部使用之工作站
TW-FIN-WS-014 偵測到可疑的程式執行行為，並於 18 分鐘後
觀察到該端點對外部低信譽主機建立連線。本事件持續約 56
分鐘，目前狀態為調查中。

 

## 二、事件經過
14:14　偵測到經過編碼的 PowerShell 指令執行，其父程序為
　　　　電子郵件用戶端。此一組合常見於透過郵件附件進行的
　　　　初始入侵，惟本次未取得郵件本體，初始入侵途徑仍屬推測。
14:32　同一端點對外部主機 203.0.113.77 建立加密連線，
　　　　傳出資料量約 180 KB。該位址經威脅情報比對為低信譽。

 

## 三、影響範圍
受影響資產：TW-FIN-WS-014（使用者工作站，財務部）
資產重要性：中
目前未觀察到向其他端點的橫向移動跡象。

 

## 四、技術分析
本事件對應之攻擊技術如下：
- 初始存取：網路釣魚附件（推測）
- 執行：透過 PowerShell 執行編碼指令（已觀察）
- 命令與控制：使用 Web 協定對外通訊（已觀察）

 

## 五、建議處置
【立即】
1. 將 TW-FIN-WS-014 自網路隔離，保全記憶體與磁碟證據。
2. 於防火牆封鎖對 203.0.113.77 之連線，並檢視其他端點
   是否曾連線至該位址。
3. 重設該端點使用者之帳號密碼。

 

【中長期】
1. 檢視端點的 PowerShell 執行原則，評估限制編碼指令執行。
2. 加強郵件附件的沙箱檢測。

 

## 六、待補充
- 初始入侵途徑之確認（需取得對應郵件紀錄）
- 外傳資料內容之分析

看幾個做對的地方

「18 分鐘後」是程式算的，不是模型算的。時間差在 Data Pack 裡就有。

「初始入侵途徑仍屬推測」——這來自 Data Pack 裡 T1566.001 的 confidence: "推測"。模型忠實地把信心程度轉成了語氣。這一段是我認為整份初稿最有價值的地方。

「財務部使用之工作站」——業務脈絡起作用了。如果只有 hostname，這句話寫不出來。

「未觀察到橫向移動跡象」——注意用詞是「未觀察到」不是「沒有發生」。這個區分在 system prompt 的規則裡沒有明說，是 SFT 訓練資料教出來的語氣習慣。這就是微調的價值所在（Day 13 的「一致」）。

第六段「待補充」——規則 2 的產物。模型誠實地標出了它不知道的東西，而這一段對審核者的價值極高，它直接就是待辦清單。

這份初稿的問題

我不打算假裝它完美。實測下來常見的問題有三類：

一、建議處置有時過於制式。 因為訓練資料裡的建議段落格式化程度高，模型容易產出正確但沒有針對性的建議。這需要審核者補上場景特定的內容。

二、嚴重性偶爾會偏保守或偏激進。 因為 severity_basis 是規則產生的，遇到規則沒涵蓋的組合就會不準。

三、敘事的詳略偶爾失衡。 有時對技術細節著墨過多，對業務影響輕描淡寫。

這三類問題正好對應 Day 14 的「審核修改幅度」指標的三種分類。知道錯在哪，比錯得少更重要，因為前者可以改進。

送審

初稿產生後進入審核佇列，狀態標記為 Draft。審核者可以：核可、修改後核可、退回重產、或直接改寫。

每一種操作都要記錄，因為那是 Day 19 知識飛輪與 Day 24 狀態機的輸入。

明天換第二個任務：顧問問答。

💡 關於作者 我是 Fngi，專注在 AI 安全與雲端資安領域。如果這篇對你有幫助，歡迎追蹤 Instagram @aid3fend，我在那裡分享更多 AI 資安的實務筆記與趨勢觀察。