OSSIM开源安全信息管理系统（十四）

2021SC@SDUSC

从本周开始，进入一个全新的模块，开始对 OSSIM 的关联分析机制进行分析。首先对管理分析机制进行简介。

关联分析

在 OSSIM 中，关联分析这部分应该算是这个系统的较为关键的一部分，相比于其他功能相近的安全防护系统来说，OSSIM 的关联分析做的非常好，其后台关联规则较为完全，可以识别出大部分攻击事件，准确率也比较高。在本次课程的最后一段时间里，我的任务就是对 OSSIM 系统的关联分析部分进行功能分析、实现分析、源代码分析等。

下面首先简单讲述一下关于 OSSIM 中的关联分析的基本概念以及为什么要有这个关联分析、为什么这一部分如此重要、他会给安全维护人员带来哪些便利等等。

从海量安全事件中挖掘有用的威胁信息与情报是当今讨论的热门话题，同时这也是一个难点？怎么实现呢？OSSIM 用到一种技术叫做关联分析，他也是 SIEM（Security Information Event Management安全信息和事件管理）系统中最常见的事件检测手段，这并不是什么新鲜事物，很久之前就已经有人提出来了。通常基于时序来对相同数据源或来自不同数据源的安全事件，使用关联规则来进行综合的关联分析，下面介绍关联分析的具体功能。

通常来说，一次恶意攻击会在多个安全设备或应用程序(如网络防火墙，交换机，Web 应用日志，SQL 日志，审核日志等)中留下痕迹． 然而，所有这些信息都是孤立隔绝的，被保存在不同的设备日志中，如果利用了关联分析技术就可以快速定位故障。

关联分析为什么有如此神通广大呢？其实后台有很多复杂的关联规则最为基础的，这些检测规则可以识别 Attack 事件，实际上这些规则是人工在大量实践中总结出来生成对攻击事件的一种语言描述，并对其进行了精确分类，分类越细描述越准确，识别率就越高。

一、关联分析核心思想

关联分析技术的核心思想是通过对某一类事件进行训练建立行为基线，基线范围外的事件视为异常事件来进行分类。 该算法较适合于本文检测场景，通常 SIEM 系统中绝大多数的日志为正常事件，通过对正常事件训练建模，来检测异常或攻击事件，这就是理论上说的 One-Class SVM（单类支持向量机）。OSSIM系统中需要更多维度特征向量，才能准确判断攻击源，避免检测精度低或过拟合情况．。算法输入是经过 OSSIM 归一化后具备相同数据结构的安全事件，输出则为带有标记的安全事件，标记分为两类 :正常(Negative)与攻击(Positive)． 而OSSIM关联分析引擎的输出就是 One-Class SVM 分类算法输出的带标记的正常与攻击事件。

通过深入分析 SIEM 系统的关联规则，其中最常见的配置字段如: event_id，timestamp，plugin_id，plugin_sid，src_ip，src_port，des_ip，des_port，protocol 等。 为了使关联分析规则不依赖于传感器配置，从 OSSIM 的规则库中抽取了几个重要的字段 plugin_id_name，plu-gin_id_description，sid_name，并将所有字段拆分成关键词标签，然后针对每一条检测规则生成其关键词标签统计模型，利用规则统计模型来代替原始的规则来检测攻击。关联分析的核心通过一个或一组关联指令来完成。

二、OSSIM 的关联引擎

为了达到安全事件关联分析的目的，就要有好的事件处理机制，比如前面讲的日志收集的归一化处理，还得有好的关联方法，而且不止一种关联方法，将多种实时关联方法结合到一起效果更佳。大量标准化处理的事件被送入关联引擎处理后，它们会经历事件分类处理、聚合、交叉关联、后发式关联等多种关联方法，系统会根据数据库中的安全事件进行统计分类，找出经常导致安全事件的发源地和经常被攻击的端口，在这些阶段都会产生事件告警，参照其他资料自己画了一个安全事件关联过程模块，如下图所示。

聚合处理可以为后续关联提供高质量的安全事件，提高关联引擎效率。而分类处理可将已知可信度提高，受关注高的安全事件可直接提升为报警。而且分类通过对报警数据库、日志数据库、知识库综合进行分析统计，产生受控网段内最常被攻击的主机和端口分布，统计相同数据源和相同目标端口的安全事件的数量，这样就可以客观地反映网络异常情况。

在OSSIM 系统中关联分析功能同样是由关联引擎来实现，关联引擎策略文件定义位于 /etc/ossim/server/，分析的数据由探针来收集。

探针（Sensor) 每天要从网络上收集到成千上万的事件，如果对这些海量的事件信息不加任何处理就直接生成事件，这种做法是毫无意义的。而在报告之前通过关联分析可以将这些成千上万的事件进行浓缩（聚类)，并确认成数十个甚至数个事件显示在 Web 前端的 SIEM 中。简单理解就是 OSSIM 的网络安全事件关联分析能将不同功能的开源网络安全检测工具产生的报警信息进行去伪存真，从而挖掘出真正的网络攻击事件。

定义关联策略的配置文件位于 /etc/ossim/server/config.xml。

OSSIM使用了两种关联引擎进行安全行为的关联分析，分别是基于事件序列的关联方法和启发式的关联方法。

一个基本的交叉关联规则举例：如果 Snort 发现基于一个目标 IP 的攻击，则说明该目标 IP 主机有漏洞，其可靠性系数为10（即100%攻击成功)。如图4-19所示中REL 的值为10.

三、事件的交叉关联

攻击总是作用于特定的网络环境，环境条件不具备时，攻击不能取得成功。对于那些即使是由真实攻击产生，但不具备攻击成功条件的安全事件，其威胁度也可置为很低。

后面将会分析到，IDS 会产生大量误报的主要原因之一是，IDS 检测时基本不考虑现实网络的情况（如网络拓扑和主机信息等)，那么单独使用 Snort 已经变得没有意义，在 OSSM 平台中的做法是，通过 IDS 告警关联的数据模型，采用受监控信息系统的特性信息、漏洞信息、安全工具的信息以及安全事件四类信息进行交叉关联。交叉关联是确认告警非常有效的方法，当存在未知的漏洞以及漏洞扫描系统自身存在漏扫和误扫(误认为系统存在漏洞）时,交叉关联会出现漏报和误报。

四、规则树

关联引擎通过规则来实现对安全事件的关联分析，我们首先需要做的就是能够看懂 OSSIM 的规则，其中采用了特有的树形规则，在规则树中的每一个节点对应一条关联规则(rules)。在匹配时关联引擎将某段时间内收到的统一格式的报警，从根节点开始往叶子节点逐次匹配，系统根据匹配的结果可以进行事件聚合和再次提升报警级别。

这种基于事件序列的关联方法中的每条指令相当于一颗由规则组成的树，所以可以把它叫做基于树形指令（Directive）的关联方法，其基本思想是根据相关事件序列创建一系列的规则来表示攻击场景，在 OSSIM 系统中采用了 XML 来定义关联序列。

大概的模板如下

<directive id="" name="" priority="">

<rule type="" name="" reliability="" occurence="” from="" to="" port_from="" port_to="" plugin_id=""plugin_sid="">

<rules>

   <rules>

   ......

rule>

directive>

每个序列开头包括两个标签 directive_id 和 directive name，而每个序列，又包括很多规则，规则之中又可以嵌套规则，即递归方法。

其中 Rule 代表规则，规则后面代表一个可能发生的攻击场景，Event 代表在当前已发生的攻击场景下，一个攻击场景由若干条规则组成，这些规则可能是“与”和“或”的关系。这样表示的好处是，我们清楚的知道，如果一个攻击场景发生，那么只需要满足哪些规则即可。

通过计算每个Rule 里的Reliability 来确认这个攻击发生的可信度是多少。其中Scene 的id用directive_id来表示；Reliability 可以是0~10之间的数，直接给可靠性赋值，也可以使一个修改量，表示当这个规则满足时将前一步攻击场景的可靠性做修改，将结果存入New_Reliability中；规则部分的其它属性代表了将和它做匹配的Event 的属性值；而和数据库的具体交互是通过Action 来表示。

下面这段指令主要是用来检测公网服务器是否可用，其中包含了两个规则。

<directive id="500000" name="Public Web Server unavailable" priority="1">

     <rule type="detector" name="server unavailable" reliability="1" occurrence="1" from="192.168.11.100" to="ANY" port_from="ANY" port_to="ANY" plugin_id="1525" plugin_sid="1,7,9">
    
    <rules>
    
    <rule type="monitor" name="Ping Baidu Server  in order to check internet connection" reliability="10" from="www.baidu.com" to="www.baidu.com" plugin_id="2009" plugin_sid="1" condition="gt" value="0" interval="20" time_out="120" />
    
    rules>

directive>

关键参数解释：

● Detector: 探测器规则自动收集从代理发来的记录，包括Snort、Apache、Arpwatch等。

● Monitor：监控器负责查询Ntop服务发来的数据和会话。

● Name：事件数据库中的规则名称。

● Reliability:可靠性

● Plugin_id:插件ID

● Plugin_sid:插件子ID号，分配给每个插件事件的子ID，比如Snort这个插件ID号为1001,而1501就是它的子ID号，代表Apache事件的响应代码，当然可不止这一件。

● Condition:条件参数和下面6个逻辑有关系，必须符合的逻辑条件匹配规则如下:

Ø eq – 等于（Equal）

Ø ne – 不等于（Not equal）

Ø lt – 小于（Lesser than）

Ø gt – 大于（Greater than）

Ø le – 小于等于（Lesser or equal）

Ø ge – 大于等于（Greater or equal）

●Interval：间隔，这个值类似于time_out,用于监控类规则。

五、 完善规则
OSSIM 系统中的关联规则生成主要通过安全专家人工编写，这种方式效率低下，且人工成本难以承受． 对于新出现的攻击和漏洞无法及时作出响应，检测规则的编写往往出现滞后的情况， 考虑能否利用AI技术和数据融合技术进行智能化的数据挖掘，这些技术在实际应用中往往生成的关联规则检测精度较低，检测结果不理想，实际应用效果有限。利用人工神经网络来自动生成关联规则，是关联分析研究领域今后发展的方向。

接下来的文章将对 OSSIM 关联分析部分的源代码进行分析。

本篇文章部分内容参考或转载自下列文章及书籍。侵权即删。

参考书籍：

• 《开源安全运维平台OSSIM疑难解析（入门篇）》——李晨光著
• 《开源安全运维平台OSSIM疑难解析（提高篇）》——李晨光著
• 《开源安全运维平台:OSSIM最佳实践》——李晨光著

参考文章：

• https://blog.51cto.com/chenguang/2426473
• https://blog.csdn.net/lcgweb/article/details/101284949
• https://blog.51cto.com/chenguang/1665012
• https://www.cnblogs.com/lsdb/p/10000061.html
• https://blog.51cto.com/chenguang/1691090
• https://blog.51cto.com/chenguang/category10.html
• https://blog.51cto.com/topic/ossim.html
• https://blog.csdn.net/isinstance/article/details/53694361
• https://blog.51cto.com/chenguang/1332329
• https://www.cnblogs.com/airoot/p/8072727.html
• https://blog.51cto.com/chenguang/1738731
• https://blog.csdn.net/security_yj/article/details/120153992

上一篇：OSSIM开源安全信息管理系统（十三）
下一篇：