安全误报的真相
引言
近年来,“假阳性”在我们的生活中出现了一些意想不到的体现。当然这里指的是新冠疫情,它需要进行大规模的核酸检测活动,来控制病毒的传播。根据记录,假阳性指的是检测结果是阳性,但检测者的实际情况却是阴性(未被感染)。通常,“误报”是该情况更为常见的说法。
在计算机安全方面,我们也经常面临着误报所带来的困扰。当提问到SIEM背后的安全团队“在工作上遇到的最大挑战是什么?”时,答案大概率会是“误报”。最近的一份报告估计,安全专业人员收到全部预警中,大约有20%都是误报,而这大大增加了安全人员的工作量。
然而,误报背后的故事并不像表面看起来的那样简单。本文中我们主张,在对一个分析工具进行评估时,适当的误报率往往意味着一个相对较好的结果。
我们到底在说什么?
在应用程序安全的静态分析中,我们主要关注的是通过分析源代码来捕获所有真实的漏洞。
下图是一个可视化结果,可以帮助我们更好地把握静态分析的两个基本概念之间的区别:查准率和查全率。放大镜内部区域中的点表示由检测工具识别或选择的样品。该图可以帮助我们更好地搞清楚如何评估系统统计程序的性能。
从工程学的角度来看,该图体现了以下几点内容:
减少误报,可以提高查准率(所有检测到的漏洞实际上都是真实确切的安全隐患)
减少误报,可以提高查全率(所有存在的漏洞都能被正确地检测到)
查全率100%时,检测工具不会错过任何一个漏洞。
查准率100%时,检测工具不会发出任何一个错误的预警
换句话讲,漏洞扫描仪的目标就是使放大镜中内部的区域尽可能地靠近左边的矩形区域(相关元素)。
然而,最佳方案往往是无法明确的,这就意味着必须要做出权衡。问题是:哪一方面更加重要呢?查准率的最大化,还是查全率的最大化?
哪种情况更糟糕呢?过多的误报,还是过多的漏报?
为了更好地了解其中的原因,我们把情况分为两个极端:假设一个检测工具只有在给定的代码片段存在漏洞的概率高于99.999%时,才会提醒用户。有了如此高的阈值,那么几乎可以肯定该预警确实是一个真实的漏洞。但是由于扫描仪的选择性,又会有多少安全问题被忽略呢?答案是:很多。
现在反过来考虑,如果检测工具被设置为:不错过任何一个漏洞(最大查全率)。那么又会发生什么呢?结果就是:该组织很快就会面临成百上千的误报。而这也同样是一件风险极高的事情。
正如伊索在他的寓言《狼来了》中警告世人的那样,任何一个反复发出虚假警报的人,其话语都不会被再次相信。在现实世界中,这种不再受信任的表现就体现在:安全人员会单纯地关闭安全预警,而不去理会它,或者说如果无法关闭的话,就直接忽略该预警。然而,其后果也同样会像寓言中的那样具有戏剧性,甚至更加严重。
实际上,“安全预警疲劳”大概是导致静态分析失败率较高的最大原因。可以说,误报背负了太多的“罪名”,以至于人们总会错误地认为:只要检测工具不再发出任何误报,那么一切问题就会迎刃而解了。
学会接受误报
想要学会接受误报,就必须要克制住那些促使我们过早下结论的本能。一个思维实验可以帮助说明这一点:假设要比较两个安全扫描仪A和B的性能。在基准测试上运行这两个工具后,结果如下:A扫描仪只检测到了有效的漏洞,而B扫描仪则同时检测到了有效漏洞和无效漏洞。仅根据这一点来判断,哪一台扫描仪会更容易得出表象结论呢?这要求安全人员必须足够地明智,并且在做出决策之前还需要参考更多的数据。根据这些数据,你很可能会发现:B结果报告中的一些有效内容,在A报告中却被忽略掉了。
现在,你大概就可以体会到本文的言外之意了:任何声称自己不会出现误报的检测工具、程序或安全公司,其本身都是可疑的。如果情况真是这样的话,那么也就意味着某些安全相关内容被忽略的可能性也非常高。
在查准率和查全率之间找到一个平衡点是一个很复杂的问题,需要大量的调整工作。(推荐去了解Gitguardian工程师是如何提高模型精度的)不仅如此,在寻找平衡点的过程中偶尔出现的失误,也是相当正常的。这就是为什么说,相比起存在少量误报,没有误报才是最该令人担心的。
同时,误报也暗示了一个有趣的事实:安全永远不是非黑即白的。一定存在着一个我们所不知道的领域。在该领域中,人工作业发挥着更大的左右。
由于现代软件的某些性质,组织总会得到一些误报。当误报出现时,开发者可以简单地将其标记。误报是测试用例的一部分,我们完全可以忽略这些困扰。
安全永远不是非黑即白的,总有一个我们所未知的领域,在那里人工审查和分类至关重要。换句话讲,重要的并不仅仅是原始数据,如何去利用它们也同样非常关键。从这个角度来看,误报也是具有一定价值的。它们有助于对检测工具和算法进行公司近,以便更好地理解和考虑安全上下文。然而,正如渐近线那样,绝对值0(0误报)是永远无法到达的。
还有一个必要的条件,就是要把那些看似是困难的东西转化为良性的循环。也就是说,你必须要确保这些误报是可以被标记的,并且能够尽可能简单地整合到检测算法中。实现这一目标最常见的方法之一就是单纯地从扫描的边缘排除文件、目录以及存储库。
专业从事机密检测的GitGuardian工作人员表示,他们推动了该想法,为的是能够在尽可能多的背景下获取更多的发现,从而加快反馈周期,并尽可能地减轻繁重的工作负载。
若开发人员利用客户端安装的ggshield作为预提交的hook,来提交机密,那么该提交便会被拦截,除非开发人员将其标记为要忽略的机密。从那时起,该机密就会被视为误报,并且该误报以后都不会被再次触发,但其适用范围也仅限于该开发人员的本地工作站。只有那些能够访问 GitGuardian决策面板的安全团队成员才能在整个团队范围中标记误报。
一旦出现了机密泄露,组织会提供工具来帮助安全团队进行迅速的处理。例如,自动修复机制会自动向泄密的开发人员发送邮件。根据机制的配置,开发人员可以独立做出决策,解决问题或忽略警报,这在一定程度上也减轻了安全团队的工作量。
上述的一些例子都启示着我们要学会绕过误报来调整检测和修复的过程,而不是痴迷于消除误报。在统计学中,有一个专有的名词来描述这种痴迷,即过拟合。这意味着组织的模型过于依赖特定的数据集,由于缺乏现实世界的输入,该模型在生产环境中已不再适用。
总结
误报通常会导致安全预警疲劳以及安全程序的损坏,以至于它被普遍地认为是百害而无一利。的确,当对某个检测工具进行评价时,组织往往会追求一个更高的查准率,毕竟误报过多的检测工具是弊大于利的。话虽如此,但也同样不要忽略查全率的重要性。
GitGuardian的安全团队设计了一种通用的检测过滤器,用来提高机密检测的查全率。从纯粹的统计学视角来看,较低误报率是一个相当好的迹象,这意味着存在的“漏网之鱼”极少。
在受控情况下,误报并没有多么地糟糕。它们甚至可以用来提升组织的某些优势。因为这些误报表明了该组织无论是在分析方面还是修补方面,都存在着可以改进的地方。
搞清楚为什么系统会发出误报,并找到一种有效的解决方案,才是提高应用程序安全性的关键。相信这是安全和开发团队在协作方面真正关键的领域之一。
总而言之,请记住:如果你的检测工具不存在任何的误报,那么就请赶快舍弃它,因为它很可能会给你带来更大的麻烦。
正如漏洞检测的查全率和查准率无法同时达到100%的理想状态一样,我们往往也无法通过有限的信息,来对安全检测工具的实际效率得出一个完全精准的评估。从本质上来讲,误报给安全团队带来的更多是负面影响,误报也的确是一种应被尽可能解决的问题。而本文则提供了一个外部视角,侧面地通过误报情况来获取更多有关检测工具或安全情况的潜在信息。也正如文中所讲,安全永远都不是非黑即白的。这是因为安全是由众多因素所共同影响的,我们永远也永远无法兼顾所有的方面。但是对于可把控的因素,从多个方面来充分挖掘其中的有效信息,从而提升整体的安全,却是可以做到的。
参考阅读
减少安全误报的五个技巧
数字经济时代的数据安全运营建设
人机合智:安全运营中的人工智能
AI驱动的XDR解决方案和安全运营服务