拒絕黑盒子——為什麼每個判定都附上完整的推理依據
有一個時刻,是每個資安團隊都熟悉的。某個工具將一封郵件標記為惡意。分析師看著這個警示,拋出那個唯一有用的問題——為什麼?——但工具給出的答案只有一個分數。於是分析師只能從頭、親手重新調查這封郵件,只為了判斷是否該相信這個原本應該替他省下工夫的判定。
我們很早就決定,WhiteMail 不會這樣做。這個決定塑造了整個產品。
為什麼黑盒子始終存在
大多數偵測系統只輸出結論,而不附上依據。「這是惡意的」、一個數字,頂多再加上一個分類名稱。理由要嘛不以可讀的形式存在,要嘛被當成無關緊要的實作細節。
業界給出的答案是可解釋 AI(xAI):揭露主要特徵(feature),展示哪些訊號對分數有所貢獻。這總比什麼都沒有好。但一份加了權重的特徵清單並不是調查。它只會告訴你模型看到了什麼,而不會告訴你這封郵件裡實際發生了什麼。分析師沒辦法把這份清單,當作「發生了什麼事」的說明,交給同事或高階主管。
我們打造的替代方案
由於 WhiteHat 是「專家群 + 協調者」的結構,依據並非事後重建出來的,而是決策本身。對於每一項判定,你都能看到以下內容。
- 郵件是如何被分析的 — 每個代理人的分數,以及它提出的具體訊號(Reply-To 不一致、SPF 失敗、相似網域、緊急匯款請求)。
- 考量了哪些脈絡 — 發信者的歷史紀錄,以及這封郵件所依附的關係。
- 得出結論的路徑 — 以韓文與英文雙語寫成、讀起來像是分析師案件記錄而非除錯日誌的平實敘述。
敘述之所以是雙語的,並非為了打勾式的在地化。一項判定必須同時獲得 SOC 分析師、收到這封郵件的財務人員,以及最終核准應對措施的高階主管的信任。在我們鎖定的團隊裡,這些人並非都使用同一種語言工作。因此,說明在每一種語言中都必須是同等一級(first-class)的存在。
背後的原則
核心的轉變是從*「相信這套系統」轉移到「看看系統是如何判斷的」*。當依據隨判定一同附上時,三件事會隨之而來:信任提升;誤判在幾秒內就能被解決,而不必重新調查;因為所有人讀的是同一份記錄,應對也因此保持一致。
無法被看穿的判定,終究會被重新來過。因此,我們把調查本身做成了產品。判定只是它的標題。
到分析主控台打開任何一份結果,閱讀其背後每一個代理人的完整依據。