阅读： 15
一、告警筛选的现状
企业安全运营中告警数量过多，引起告警疲劳的问题已是老生常谈。为了解决告警疲劳问题，各种简单或复杂的、智能或非智能的告警筛选方法应运而生，并已经在一个又一个企业SOC落地生根，成为AISecOps体系不可或缺的一部分。
其中比较简单的，一般称作“高置信度规则”或“高风险规则”等，即根据预定义的若干场景优先筛选出特定类型的告警：
图1：通过高置信度规则集适配各种场景
稍微复杂一点的，可以将多数同类或相关的告警聚合呈现，例如一些告警平台可以根据告警上下文关联生成事件等：
图2：基于上下文关联的告警聚合
在相对比较复杂的智能方法中，告警分诊方法会给告警贴上界限分明的标签：
图3：告警分诊（三分类）
告警推荐方法则尽可能地将告警按重要程度排序：
图4：告警推荐
如此种种，不胜枚举。实际上，这些五花八门的告警筛选方法往往还会组合使用，更加变化万千。
二、性能指标的前提
然而，一套高质量的告警筛选方法从规划到落地，在技术层面和管理层面往往都有诸多难点，人力物力成本不菲。如果不能对告警筛选方法的性能和价值进行量化评估，多数企业可能都难以认可如此高昂的成本。
在设计性能评估指标之前需要先明确的是，告警筛选是一个与具体场景有关的、需要大量外部知识的、非常复杂的过程。现阶段可以认为，不存在任何已公开的、机械的筛选方法，在实战场景中对安全告警的筛选准确率能够超过经验丰富的人类专家。
综上，现阶段所有的性能指标总是需要人类参与，因此都无法做到完全客观。虽然专家对安全告警的研判也难免百密一疏，但归根结底，只有人类才能为安全运营过程中的操作负责。
三、常用性能指标介绍
- TopN精确率
即，选定某个待评估的时间范围，让人类专家研判该范围内的、所有被告警筛选方法认定为“关键”的告警，其中确实属于关键告警的占比即精确率指标。
由于有些告警筛选方法无法将关键告警的数量缩减到可以让人类专家全部研判的程度（尤其是告警推荐方法，它们通常只改变告警的顺序，而不缩减其数量），实际执行时可能需要按照某种策略进行采样。比较简单的方法是，参考实际场景中运营人员按顺序从前往后检查告警的方式，直接取告警筛选结果的前N个，交由人类专家进行研判。
图5：某告警筛选方法的Top10精确率评估
至于具体的N值，应当根据实际情况确定。例如，如果当前的SOC整体资源水平充足，或者以高强度攻防对抗为目标，就应该采用较大的N值；又例如在使用告警聚合方法时，单条聚合记录往往比单条原始告警复杂而研判难度大，这种情况就应该适当减小N值。
这种精确率指标的优势在于，它不仅简单明确，易于测量，还非常贴近于实际的安全运营场景。假定SOC整体资源在每个时间周期内能够完成N条告警的研判，那么TopN精确率就直接体现了运营过程中每个时间周期所能够发现的关键告警的数量。
但这种指标的劣势也很明显。首先，选取的时间范围内必须实际存在关键告警，否则不管多优秀的告警筛选方法也无法得到较好的指标；但如果为此将目标范围选得很大，又会增加人力、算力等成本。此外，一个只能识别出特定冷门攻击手法的告警筛选方法显然不是一个好的方法，就算它具备100%的精确率也不行。
- 反馈数据验证
大部分企业似乎都乐于让SOC流程闭环——要求运营人员对满足某些条件的告警进行全量检查，并反馈研判和处置的结果。这批反馈数据中的关键告警占比可以认为是衡量当前实际安全运营效率的指标之一。虽然告警筛选方法并非影响这项指标的唯一因素，但通过对比告警筛选方法应用前后的指标变化来评估告警筛选方法的性能也是非常合理的。
另一方面，SOC中带标注的反馈数据经常被用来训练或优化模型，并在此过程中适用常规数据分析中的验证方法。例如，如果告警筛选方法中主要使用监督模型，一般可以直接在反馈数据上运行k-fold交叉验证：
图6：从交叉验证结果看来，上图中告警筛选方案的泛化能力有待改善
但这种性能指标也存在弊端。SOC反馈数据都来自原本就被安全运营过程所关注的告警，它们虽然是原始告警的采样，但不一定能够反映原始告警数据的真实分布。这导致利用SOC反馈数据验证指标的“信息茧房”问题也很明显。
例如，如果某个时刻的SOC体系对于A类型攻击能够正确检出，而对于B类型攻击检出能力不足，那么SOC反馈数据中的正例样本就会缺少B类型攻击相关告警。如果持续面向这些反馈数据进行模型/参数/策略的优化，就会导致告警筛选方法越来越关注A类型攻击，而越来越忽略B类型攻击，并最终陷入只能检出A类型攻击的死循环之中。
- 召回率（覆盖率）曲线
即，运营人员完成前X条告警的核查后，最多能够发现Y%的关键告警，将其绘制在坐标系中形成的曲线。与前面两种只产生数值的性能指标不同，召回率曲线能够非常直观地反映告警筛选方法在不同阈值条件下的性能，以及对照传统安全运营方法的效率提升幅度：
图7：召回率曲线，蓝色来自某告警推荐方案，橙色为传统运营值守的对照数据
然而绝大部分情况下，想要在真实环境中找出所有的关键告警往往是不可能的。没有任何方法能够100%地保证检出真实环境中的所有关键攻击，不论人工的还是机械的。这使得关于告警筛选方法的召回率指标很难测算。
为此，一般需要手动构造并输入一些“关键告警”数据。实践中最常用的方法是举行内部红蓝对抗，然后通过攻击队记录的攻击步骤找出相关的全部告警。即使不考虑对告警筛选方法的评估，内部红蓝对抗也是暴露企业安全风险、提高整体安全建设水平的不二法门。
相比于被动地来自外部攻击的SOC反馈数据，内部红蓝对抗所产生的“关键告警”可能要全面得多，且较少出现SOC反馈数据的信息茧房问题。但举办内部红蓝对抗通常需要部署额外的人力和设备，并可能对业务运行造成一定程度的影响；之后还需要花费很多时间进行整理复盘，编制和验证数据分析代码；而红蓝对抗中攻防双方的人员和工具水平也极大影响评估效果。
与可以随时采样并集中研判的TopN精确率、以及日常运营过程中自然产生的SOC反馈数据不同，要绘制召回率曲线的成本相当之高。
四、后记
以上三种指标都是目前针对告警评估方法的有效评估指标。此外，一些常规运营指标（如MTTD），甚至用户问卷等方法也都可以加入对告警筛选方法的性能评估中。
但显然地，要全面评估一个告警筛选方法的性能，仅靠一个或几个单纯的性能指标显然是不够的。至于实际采用哪些指标来进行评估，应当根据企业自身智能安全运营的整体目标而定，而不应作为一项孤立的工作来开展。
更多前沿资讯，还请继续关注绿盟科技研究通讯。
如果您发现文中描述有不当之处，还请留言指出。在此致以真诚的感谢~
版权声明
本站“技术博客”所有内容的版权持有者为绿盟科技集团股份有限公司（“绿盟科技”）。作为分享技术资讯的平台，绿盟科技期待与广大用户互动交流，并欢迎在标明出处（绿盟科技-技术博客）及网址的情形下，全文转发。
上述情形之外的任何使用形式，均需提前向绿盟科技（010-68438880-5462）申请版权授权。如擅自使用，绿盟科技保留追责权利。同时，如因擅自使用博客内容引发法律纠纷，由使用者自行承担全部法律责任，与绿盟科技无关。