一、简介
“从海量告警中找出能对企业安全造成风险的关键告警”是安全运营工作的核心，对于这一目标，运营人员往往如大海捞针般，没有行之有效的方法。因此企业安全运营的现状往往是依靠运营人员的长期积累的经验（包括对告警的认知程度、对企业资产的认知程度等），来逐步靠近这一目标。
实际上，实现这一目标需要大量的工作，严谨的流程。本文将逐步剖析告警分析中遇到的实际问题，并介绍一篇信息安全顶级期刊TDSC中《A Comprehensive Approach to Intrusion Detection Alert Correlation》[1]一文对这些问题的解决方法，分析文中方法的实用性，提出改进措施。
二、海量告警的产生原因
告警数据量过大，是产生告警分析问题的根本原因，而安全运营中心的主要压力也来自于海量告警数据，绝大多数告警数据都不会被分析，成为了垃圾数据。海量告警的产生原因是多方面的，主要有：
- 互联网环境复杂、流量激增。随着互联网上各种业务的增多、用户网络行为的多样化，安全设备有时无法准确区分正常业务与网络攻击，导致告警中产生误报，而由于正常业务流量巨大，误报数量上也很大。
- 攻击量大。这个量体现在两方面：一方面是攻击种类多，攻击种类越多，安全设备中的规则就会越多，那么告警的数量就会越多，另一方面是攻击流量大，不仅仅是恶意攻击，很多厂商、研究机构每天都会进行网络“攻击”，完成攻击验证、漏洞资产测绘等目的，如各种网络空间搜索引擎，这些行为在安全设备看来都是攻击，从而产生大量告警。
- 安全设备增多。随着网络安全问题日益严峻，各大公司对于安全问题的重视程度越来越来高，网络出口、核心资产等位置都会放置安全设备，安全设备的激增在一定程度上也导致了待分析告警的激增。
三、告警分析问题速览
一般来说，告警可以分为3种类型[2]：
- 高危告警（true positive）. 该部分告警的出现意味着企业资产的失陷，如：cobalt strike通信流量， 异常登录信息，内网扫描行为等等。
- 无关告警（not-relevant positive）。该部分告警为失败的攻击产生的告警，如：大部分僵木蠕触发的告警、网络空间搜索引擎触发的告警等等。
- 误报（false positive）。正常业务触发的告警。
实际上，除了以上告警，告警中还会存在第四类告警，笔者将之命名为“日志型告警”，如：SSH登录、Web登录、弱口令登录等等，这些告警虽然不是误报（即告警名称与行为直接无差异），但是日常运营过程中一般不会关注此类告警，运营人员还会将之认为是误报（不关心，但是仍会告警）。
在以上4种告警类型中筛选高危告警的过程中会遇到各种问题，笔者按照经验总结如下：
- 日志型告警处理。由于日志型告警与攻击没有强关联性，因此不好处理。一般来说要与攻击告警分开，采用异常检测的方法进行处理。该部分数据量大，目前没有较好处理方法。
- 误报识别。由于业务的复杂性，该部分告警不避免的会触发告警，且数量巨大，极大干扰了运营效率。一般来说需要运营人员逐渐熟悉业务后才能去除该部分误报。
- 无关告警识别。该部分告警是否需要关注有大量的主观因素，如：日常运营期间需要统计僵木蠕类告警，输出威胁情报，而网络演习期间则不关注。不过无论是否需要关注，将之与其他告警区分目前仍有难度。
- 告警验证问题。很多时候运营人员只关注“攻击成功的告警”，而原始告警无法直观展示该攻击是否成功，该问题也是目前安全运营中心的一大痛点问题。
四、告警分析方案介绍[1]
4.1 论文介绍
为了解决上一小节所述问题，并且基于告警生成更高层级的视角（如战术、攻击链等），论文[1]提出告警关联的方法，与常规的告警过滤不同，该方法会将多条告警进行聚合，生成新的告警，以此来减少告警量。整体框架如图1所示，共分10个步骤。
图1 告警分析流程图
步骤一：
规范化（Normalization）。该步骤把不同类型探针的回传数据按照统一格式进行处理，目前SIEM对于该步骤已经基本支持。该步骤无告警减少。
步骤二：
预处理（Pre-Processing）。虽然步骤一对告警进行了规范化，但是有些探针可能会缺失部分数据，如时间戳，预处理步骤需要将缺失的重要字段补齐。该步骤无告警减少。
需要补充的是，除了上述补充数据外，还有很多其他工作需要进行预处理，如告警名称的统一，不同安全设备对同一攻击的命名可能不同，甚至同一安全设备里会有类似的规则导致名称类似，因此存在不同类型告警表示相同行为的情况，同样需要处理。
步骤三：
告警融合（Alert Fusion）。对于同一攻击，可能同时有多个检测设备检测到，触发多个告警，需要将这些告警进行融合处理。论文中采用滑动窗口的方式，将时间间隔在2s内，由不同探针触发的相同告警进行融合。如图2所示，告警2、3被融合成元告警8.
图2 告警融合示例
该步骤在内部存在多个安全设备时十分有效，如网关处、重要网段出口处均部署了安全设备。在论文中的一个数据集上，告警融合可以将告警量降低28%。
步骤四：
告警验证（Alert Verification）。该步骤的目标是去除攻击失败的告警，主要方式是查看攻击遗留的痕迹，如主机上生成的文件、网络通信等，常见的方式有主动式和被动式两者。主动式验证需要在接收告警后实时对目标进行漏洞探测，判断漏洞是否存在，该方式会对当前网络产生较大影响，且效率较低；被动式验证需要提前准备先验知识，如网络拓扑、主机操作系统、运行的服务等，当告警到来时与这些数据进行比对便可判断攻击是否成功，但是该方式的准确性与信息收集的周期相关，同样有较高成本。
在实际环境中，可以采用被动主动结合的方式，如对于常见攻击采用被动式验证，可定义先验知识库，当相应符合预期则判定成功，对于重要攻击采用主动式验证，在IDS上配备漏扫，只对高危漏洞进行验证。
步骤五：
Thread重构（Thread Reconstruction）。该步骤将同一攻击者向同一受害者在一定时间内的相同告警进行聚合，这种方式能有效对某些行为做聚合，如：sql注入、口令猜测等。与步骤三攻击聚合不同的是，该步骤只对同一探针产生的告警做处理。
该步骤效果明显，不过需要注意时间窗口的设定，太大则会有较大误报，太小则压缩效果不明显，同时需要指出的是，该步骤也是目前国外处理告警问题的重要步骤[4]（Alert throttling）.
步骤六：
Session重构（Session Reconstruction）。该步骤的目标是将网络侧与主机侧的告警相关联，但是该过程存在较大难度，网络侧的告警一般是IP地址、端口等信息为主，主机侧的告警一般是进程、文件等信息，无法直接进行关联。文章使用一些先验知识来解决该问题，建立端口与进程名称、用户ID之间的映射关系进行关联。
步骤七：
攻击焦点识别（Attack Focus Recognition）。从拓扑上讲，网络攻击存在一对多（扫描器批量扫描）或多对一（DDoS攻击）的场景，将这些攻击产生的告警进行归并可进一步降低告警量，文章采用时间窗口机制对一定时间范围内的告警进行合并。
步骤八：
多步攻击关联（Multistep Correlation）。一般来讲，安全设备告警属于低层次告警，想要获取攻击的战术、战略层面信息则要进行告警关联。而高层次的模式则需要用到专家知识，文章用STATL系统[3]进行攻击建模，将攻击模式用状态和转移关系进行表示，从而进行告警关联，支持：recon-breakin-escalate(侦查-突破-逃逸) 和island-hopping（横向移动）两种场景下的告警关联。
步骤九：
影响分析（Impact Analysis）。该步骤确定攻击队目标网络的影响，进行该部分分析需要资产数据库做支撑，需要清楚企业内部资产、重要资产、资产提供的服务等信息，在此基础上便可对资产之间的关联关系进行建模，从而评估攻击的影响范围。
步骤十：
告警排序（Alert Prioritization）。该部分需要按照攻击对目标资产造成的影响进行排序，确定告警的优先级。该步骤同样需要考虑很多外部因素，如资产的重要性、资产在安全性（CIA）上的要求等，因此，对于一个攻击来说，并没有固定的优先级。如，端口扫描，该行为在互联网上已经司空见惯，一般不被重视，优先级较低，然而内网中的端口扫描、高保密性网站受到了端口扫描等场景又需要被高度重视。文章利用步骤九中的影响分析结合资产数据库完成该步骤。
4.2 小节
本小节中介绍的文章虽然发表于2004年，但其描述的问题（告警关联、压缩）至今仍未得到有效解决，在实践过程中，各种方法依然在文章描述的十个步骤范围内，该文章可让读者对告警分析的整体框架、流程有较清晰的认知。同时，需要注意的是，告警的重要程度不仅与攻击的破坏性、攻击是否成功有关，还与网络环境、资产等息息相关，引入这些外部知识后，告警压缩、排序会更加有效、实用。
五、总结
本文介绍了海量告警的主要形成因素，告警分析的主要问题，并通过一篇学术论文，介绍解决海量告警分析问题的主要流程。告警分析是一项复杂繁琐的工程，告警的重要性不仅与告警本身有关，也与网络状态、资产状态、甚至人的主观因素相关，同时需要很多外部知识库的输入。文中若有不当之处，请各位读者朋友批评指正。
参考文献
[1] Valeur, Fredrik, et al. “Comprehensive approach to intrusion detection alert correlation.” IEEE Transactions on dependable and secure computing 1.3 (2004): 146-169.
[2] Kruegel, Christopher, and William Robertson. “Alert verification determining the success of intrusion attempts.” Detection of intrusions and malware & vulnerability assessment, GI SIG SIDAR workshop, DIMVA 2004. Gesellschaft für Informatik eV, 2004.
[3] Eckmann S T, Vigna G, Kemmerer R A. STATL: An attack language for state-based intrusion detection[J]. Journal of computer security, 2002, 10(1-2): 71-103.
[4] van Ede, Thijs, et al. “DEEPCASE: Semi-Supervised Contextual Analysis of Security Events.” 2022 Proceedings of the IEEE Symposium on Security and Privacy (S&P). IEEE. 2022.
版权声明
本站“技术博客”所有内容的版权持有者为绿盟科技集团股份有限公司（“绿盟科技”）。作为分享技术资讯的平台，绿盟科技期待与广大用户互动交流，并欢迎在标明出处（绿盟科技-技术博客）及网址的情形下，全文转发。
上述情形之外的任何使用形式，均需提前向绿盟科技（010-68438880-5462）申请版权授权。如擅自使用，绿盟科技保留追责权利。同时，如因擅自使用博客内容引发法律纠纷，由使用者自行承担全部法律责任，与绿盟科技无关。