归档日志存在arch_日志关联分析的前提条件：安全事件标准化

日志关联分析的前提条件：安全事件标准化

一般的日志系统,为了接收日志的效率，不去做日志的标准化工作，收集大量冗余日志在数据库，而庞大的数据库在检索时导致效率越来越低，更别提自动扫选出故障。当故障发生后很长时间，依然被动的在数据库中，人工查找可疑故障日志，效率低下。

然而，在OSSIM系统中不仅需要统一格式，而且要专门的属性，这为系统中的关联分析引擎的数据源奠定了良好的基础，我们先看几个典型字段及说明：

• Alarm 报警名称
• Event id 安全事件编号
• Sensor id: 发出事件的传感器编号
• Source IP :src_ip 安全事件源IP地址
• Source Port :src_port 安全事件源端口
• Type 类型分为两类一类是detector，另一类是monitor
• Signature 触发安全事件的特征值
• Reliability 安全事件的可信度（描述了一个检测到的攻击是否真的成功可能性，侧面反映了安全事件的严重性质）

为了更好的学习第2章介绍的SIEM控制台，下面先看几个统一格式安全事件的实例，

在Redis服务器中处理大量的非结构化数据，但最终经过一系列规则检测发出的报警，再经过聚合后产生的聚合报警具有统一格式，并集中存储在MySQL数据库中。下面给出典型的记录格式。

1）Raw Log典型记录格式如图1所示。

图1 Raw Log记录格式

2） SIEM事件归一化记录格式如图2、图3所示。

图2 事件归一化处理格式

图3 SIEM记录格式

在OSSIM中的事件是如何实现存储呢？传感器从各种网络设备和服务器上通过Rsyslog收集原始日志，存储在Sensor所在服务器的硬盘等待处理，当收到日志后，安装在探针服务器上的代理开始工作，利用事先设定好的安全插件开始对日志进行预处理（也就是进行归一化处理），流程如图4所示。

图4 传感器日志采集流程

Agent将插件收到的日志送往Server再进行深度加工，将字段按照类别重新组合，成下面的格式（这样就从RAW
Log变成了归一化处理的日志，归一化处理格式如表1所示。

表1 归一化处理日志格式

归一化处理，重要字段含义如下：

• 源和目标地址：在关联分析中属于很重要的内容。
• 源和目标端口：可以分析访问和试图访问的那些服务端口。
• 消息分类： 根据用户登录成功或失败或者尝试的消息分类。
• 时间戳： 这里包括日志消息在设备上产生的时间和系统接收消息的时间（因为有各种延迟存在，时间不同）。
• 优先级： 例如网络设备(交换机)的日志包含了优先级（设备供应商制定）。作为规范化的一部分也需要日志包含优先级。
• 接口： 通过那个网络接口接收到的日志消息。

原始日志是规范化过程的一个重要环节，OSSIM在归一化处理日志的同时也保留了原始日志，可用于日志归档，提供了一种从规范化事件中提取原始日志的手段。

经过归一化处理的日志，再通过TCP
3306端口存储到MySQL数据库中，接着就由关联引擎根据规则、优先级、可靠性等参数进行交叉关联分析，得出风险值并发出各种报警提示信息（详情在后续章节再分析）。

图5 日志存储

接下来，我们再看个实例，下面是一段Apache的原始日志，如图6所示。

图6 原始日志

先经过OSSIM系统收集加工后，再通过Web前端展现给大家，方便阅读的格式如图7所示。归一化处理后的事件和原始日志的对比方法我们在后面还会讲解。

图7 归一化处理以后的Apache访问日志

在图7所示的例子当中，仅使用了Userdata1和Userdata2，并没有用到Userdata3～Userdata9这些是扩展位，主要是为了预留给其他设备或服务使用。

图8 SIEM控制台下的主机标识形式

经过归一化处理之后，目标地址会标记成Host-IP地址的形式，例如：Host-192-168-0-1。实际上归一化处理这种操作发生在系统采集和存储事件之后，关联和数据分析之前，在SIEM工具中把采集过程中把数据转换成易读懂的格式，如同图7显示的那样，采用格式化的数据我们能更容易理解。如果您希望继续学习有关安全事件标准化的技术请参考《开源安全运维平台-OSSIM最佳实践》、《开源安全运维平台OSSIM疑难解析：提高篇》。