安全运营中的误报

误报/FP是false positive的缩写，假阳性，表示被检出有问题，但是实际上却没问题

误报（A false positive alert）是指错误地对非恶意事件进行了触发。

真阳性/告警（A true positive alert）是正确触发并捕获到恶意事件的告警。

漏报（A false negative alert）基本上就是未能检测到恶意事件。

最后一个不太重要的情况是真阴性（A true negative），即当没有发生任何恶意行为时不会产生告警。

我们理想状态下有真阳性（对恶意行动进行预警）和真阴性（当没有任何恶意行为发生时不进行预警）。所以乍看之下，误报和漏报都很糟糕。误报本质上就是一个错误，而漏报则表示我们未能及时提醒（又一个错误）。稍后我们将再次讨论漏报问题，但首先让我们来看看为什么误报如此令人头疼。首先，如果出现过多的误判可能会给分析团队带来巨大压力，在业界被称为“告警疲劳”。我的朋友Alex Levinson也从事大量的检测工程和安全思考，并进一步将这个问题归类为告警效率。Alex有一个简单公式用于计算告警分类（triage）效率：
(每日告警数量 * 分类时间) / 人员审查 = 告警分类总时间
(number_of_alerts (per day) * triage_time) / humans_reviewing = Total time for alert triage

如果你们程序里"告警分类总时间"超过了团队每天花在分类上面的小时数, 那么你们就会遇到无法处理完所有预期任务导致积压越来越多, 这种情况可以使人感到沮丧. 显然减少高价值、目标明确内容至关重要。我们还可以看出, 误报对于处理预期任务影响很大, 因为它既增加了待处理任务数量又延长了确认是否属于误报结果所需时间 (相比按规定操作流程确定是否属于阳性结果)。所以说误报结果同样也给SOC团队希望建立起更好机制去解决这个问题。这引出了一个问题: 我们究竟该怎么才能消除这些? 是否只需要编写特别具体规则去抓住特定威胁? 实际上你可以调整规则使其变得极其具体, 它经常能精确抓住威胁并且几乎不存在误报结果。然后你甚至可以直接使用近乎完美提示转化成自动阻止规则, 如此一来甚至都无需再设置告警功能，对于阻止特定威胁采用诸如软件哈希值等方式尽可能阻止运行已经成为最佳实践。

我们可以在HackerNews的这篇帖子中看到对此进行了很好的描绘，它讨论了减少误报和降低漏报之间的平衡。总结一下，我们实际上更关心漏报，也就是没有告警真正恶意活动，而不是过于关注误报。也就是说，我们想要编写足够广泛的告警以捕获新的恶意活动，但又不能过于广泛以至于需要花费大量时间来分类或使分析师疲劳。我们宁愿让分析师审查一些非恶意活动，也不愿错过所有恶意活动。

此外，误报往往来自完全合法的软件或良性技术，而这些软件或技术恰好也触发了这一标准。通常情况下，这种合法软件或技术在开发检测规则时并不在实验室或区域内，因此它是后来与规则发生冲突的未知因素。在这种情况下，重要的是要有人工审查员，以便他们能够了解这种特定情况，并更新规则以忽略这种例外情况。这是误报分类能够明显改善规则的一个例子。

处理误报的一种方法是在数据集中设置一组较弱规则（即更容易产生误报），而无需手工检查告警内容，并可选择性地进行狩猎。这在托管安全运营中非常流行，并且经常被称为拥有“狩猎池”。

所有这些说法，一个误报甚至是一个真正的阳性结果并不代表故事的结束。在我所见过的几乎所有情况中，无论是误报还是真实阳性告警都会由人工进行审核，然后确认是否发生了威胁事件，然后再进行上报。没错，这些误报甚至不是为了消费者而设定的，它们只是供分析师验证之用，在上报之前确认是否存在真正的误报（即关于威胁、感染或违规行为的上报）几乎永远不会传达给最终客户。广泛告警被设计成一种增加信号但同时引入额外噪音的方式供分析师使用。然而，优秀的分析师应该总能够将噪音或非真实攻击与事实区分开来，并在呈现给他人或升级到事件时予以说明。