安全事件标准化
一般的日志系统,为了接收日志的效率，不去做日志的标准化工作，收集大量冗余日志在数据库，而庞大的数据库在检索时导致效率越来越低，更别提自动扫选出故障。当故障发生后很长时间，依然被动的在数据库中，人工查找可疑故障日志，效率低下。
然而，在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 归一化处理日志格式
| Date | Src_port |
| Sensor | Dst_ip |
| Interface | Dst_port |
| Plugin_id | username |
| Plugin_sid | password |
| Prority | filename |
| Protocol | Userdata1～Userdata5 |
| Src_ip | Userdata6～Userdata9 |
归一化处理，重要字段含义如下：
- 源和目标地址：在关联分析中属于很重要的内容。
- 源和目标端口：可以分析访问和试图访问的那些服务端口。
- 消息分类： 根据用户登录成功或失败或者尝试的消息分类。
- 时间戳： 这里包括日志消息在设备上产生的时间和系统接收消息的时间（因为有各种延迟存在，时间不同）。
- 优先级： 例如网络设备(交换机)的日志包含了优先级（设备供应商制定）。作为规范化的一部分也需要日志包含优先级。
- 接口： 通过那个网络接口接收到的日志消息。
原始日志是规范化过程的一个重要环节，OSSIM在归一化处理日志的同时也保留了原始日志，可用于日志归档，提供了一种从规范化事件中提取原始日志的手段。
经过归一化处理的日志，再通过TCP 3306端口存储到MySQL数据库中，接着就由关联引擎根据规则、优先级、可靠性等参数进行交叉关联分析，得出风险值并发出各种报警提示信息（详情在后续章节再分析）。
图5 日志存储
接下来，我们再看个实例，下面是一段Apache的原始日志，如图6所示。
图6原始日志
先经过OSSIM系统收集加工后，再通过Web前端展现给大家，方便阅读的格式如图7所示。归一化处理后的事件和原始日志的对比方法我们在后面还会讲解。
图7 归一化处理以后的Apache访问日志
在图7所示的例子当中，仅使用了Userdata1和Userdata2，并没有用到Userdata3～Userdata9这些是扩展位，主要是为了预留给其他设备或服务使用。