拒绝黑盒子——为什么每个判定都附上完整的推理依据
有一个时刻,是每个安全团队都熟悉的。某个工具将一封邮件标记为恶意。分析师看着这个警示,抛出那个唯一有用的问题——为什么?——但工具给出的答案只有一个分数。于是分析师只能从头、亲手重新调查这封邮件,只为了判断是否该相信这个原本应该替他省下工夫的判定。
我们很早就决定,WhiteMail 不会这样做。这个决定塑造了整个产品。
为什么黑盒子始终存在
大多数检测系统只输出结论,而不附上依据。“这是恶意的”、一个数字,顶多再加上一个分类名称。理由要么不以可读的形式存在,要么被当成无关紧要的实现细节。
业界给出的答案是可解释 AI(xAI):揭露关键特征(feature),展示哪些信号对分数有所贡献。这总比什么都没有好。但一份加了权重的特征清单并不是调查。它只会告诉你模型看到了什么,而不会告诉你这封邮件里实际发生了什么。分析师没办法把这份清单,当作“发生了什么事”的说明,交给同事或高层管理者。
我们打造的替代方案
由于 WhiteHat 是“专家群 + 协调者”的结构,依据并非事后重建出来的,而是决策本身。对于每一项判定,你都能看到以下内容。
- 邮件是如何被分析的 — 每个代理的分数,以及它提出的具体信号(Reply-To 不一致、SPF 失败、相似域名、紧急汇款请求)。
- 考虑了哪些上下文 — 发件人的历史记录,以及这封邮件所依附的关系。
- 得出结论的路径 — 以韩文与英文双语写成、读起来像是分析师案件记录而非调试日志的平实叙述。
叙述之所以是双语的,并非为了打勾式的本地化。一项判定必须同时获得 SOC 分析师、收到这封邮件的财务人员,以及最终批准应对措施的高层管理者的信任。在我们瞄准的团队里,这些人并非都使用同一种语言工作。因此,解释在每一种语言中都必须是同等一级(first-class)的存在。
背后的原则
核心的转变是从*“相信这套系统”转移到“看看系统是如何判断的”*。当依据随判定一同附上时,三件事会随之而来:信任提升;误报在几秒内就能被解决,而不必重新调查;因为所有人读的是同一份记录,应对也因此保持一致。
无法被看穿的判定,终究会被重新来过。因此,我们把调查本身做成了产品。判定只是它的标题。
到分析控制台打开任何一份结果,阅读其背后每一个代理的完整依据。