UseCase的威力在于两方面：

1. 采集日志的广度和深度，

2. UseCase检测思路。

怎么让UseCase发挥检测能力，需要尽可能多（广）和详尽（深）的日志，以及开阔性的检测思路，甚至要带一点“猥琐”。本文介绍了ArcSight Usecase的三种类型，并分别介绍了案例。

1. 什么是 ArcSight UseCase?

ArcSight 的 UseCase 是指通过 ArcSight 多种内外部资源的组合、配置来满足某一个或一类基于日志的分析场景需求，所以要实现某个 Use Case 的前提是有相应的基本日志源，其次要有对日志的分析基本手段和知识（即使没有 SIEM 工具，人工本身也要有基本的分析方法和解析能力）。

SIEM 的 UseCase 是基于日志的， SIEM 本身不会产生原始行为检测的判断性事件。所以各位要小心，有些 SIEM 销售吹嘘的所谓很牛的 UseCase 时大多会忽略说明有相应日志源的前提，容易误导用户把 SIEM 当成了一个类似 IDS 之类，可以产生检测日志的产品（当然有些早期从基于流量分析产品而演进来的 SIEM 产品的确有此功能）。

ArcSight UseCase 很多报警功能的确是基于内部资源 Rule 实现的，但 UseCase 不是只有这一种表现形式，除了规则还可能通过仪表板、报表的方式予以展现，所有展现出的内容后面也会有很多其它的内部资源予以支撑，有些会在日志采集的时候就事先做好预处理，所有这些满足某个检测场景的相关资源集合统称为一个 UseCase 。

类似于软件开发的某个功能点一样， UseCase 的简单与复杂程度和需求完全相关，所以简单的说有多少个 UseCase 其实无法真实体现真正的工作量。

2. ArcSight UseCase 利器 Rule 简介

2.1. Rule 类型

ArcSight 的强项是灵活的关联性规则定义资源 Rule ， Rule 有 3 种类型：

• Standard ：可以定义多种类型事件，在特定时间窗口符合某些关联情况下，触发多少次后在哪种情况下执行何种动作；
  

• Lightweight ：定义满足某种单一类型的单一事件时对列表（ List ）资源进行增加、删除操作，此类型规则执行的优先级高于 Standard 类型规则；

• Pre-persistence ：定义满足某种单一类型的单一事件时对原始事件内容本身进行丰富、修改，此类型规则执行的优先级高于 Standard 类型规则；

2.2. Rule 定义类型

2.2.1. 简单类型规则（ Simple Rule ）

这类规则指短时间内基于单一类型事件触发动作的规则，其实这也是很多常见的规则。

例如，需求是对 Windows Security Event Log 进行清除的行为监视。 UseCase 的编制过程如下：

1.需要监视的 Windows 版本信息，因为 Windows 2003 之前和之后的 Event Log ID 完全不同；

2.确定所有需要监视的 Windows 设备 Security Event Log 已经采集；

3.确定 Windows Security Event Log 清除的审计事件 ID ，确定此 ID 的方法很多，我常用的方法就是查阅 ArcSight SmartConnectorfor Windows EventLog 的说明文档，或者访问：

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx ；

4.基于上述方法确定， Security Event Log 清除后， Windows 2003 之前版本会产生 ID=517 的审计事件， Windows2003 之后版本会产生 ID=1102 的审计事件，分别找两个测试环境进行相应的操作进行验证，获取 ArcSight 中采集到的原始日志并确定各信息对应的字段；

5.定义相应的原始事件过滤资源（ Filter ），定义的内容如下（最佳实践是把事件的筛选条件使用 Filter 来定义，其它资源统一引用此 Filter ，这样便于统一维护、变更）：

6.定义实时报警规则，选择 Standard 类型；

7.规则适用的事件直接调用之前定义的 Filter ；

8.归并的条件是 2 分钟内发送 1 次；

9.定义在第 1 次满足条件时触发如下动作：

• 为了易读，设置报警名称；

• 为了未来做长期的报表（例如年报），将报警的概要信息记录有效期为 1 年的活动列表中；

• 调用报警邮件的脚本发送报警邮件（ ArcSight 本身具备邮件通知的功能，不过邮件显示内容不太易读，所以我们是通过一个自定义的脚本来发送报警邮件）；

10.上述规则定义完毕后，可以点击“ Test ”按钮对之前产生的清除 Event Log 测试日志进行校验，看规则是否如期望的执行，且各需要字段是否正常。

11.如果测试符合要求，将此规则加入实时运行规则组中，再次在测试 Windows 环境中清除 Event Log ，验证规则是否正常触发、列表信息是否更新、报警邮件是否正常发送。

12.如果一切如期望运行，再基于规则记录的列表定制 Event Log 清除事件报警的月报、年报（由于原始事件不会长期在线保存，如果每次的月报、年报都要从数百亿条原始事件中再次过滤汇总对 IO 的消耗过大，而且完全没有必要）。

13.规则相关的所有资源引用关系如下图所示；

2.2.2. 关联型规则（ Join Rules ）

这类规则指短时间内基于多种类型事件，这些事件之间存在相同要素的情况下触发动作的规则。

例如，需求是对触发了蜜罐的源地址成功登录了操作系统的行为监视。 UseCase 的编制过程如下：

1.获取蜜罐系统的报警日志并分析；

2.获取 Windows 及 Linux 系统的登录日志（我的环境就这两类操作系统，如果有其它操作系统，例如 AIX 也一样需要采集相应日志）；

3.定义实时报警规则，选择 Standard 类型；

4.规则适用的事件类型及关联关系定义类似如下；

5.后续其它的设置、测试、上线方法类似其它类型规则，这里就不再赘述了。

2.3. 链式规则（ Chain Rules ）

这类规则主要对于长时间判断的规则，由于 ArcSight Rule 是在内存内运行的，因此为确保效率、性能，前两种规则的时间窗口不建议大于 10 分钟，对于超过 10 分钟以上时间窗口的规则使用此类型规则，真实的场景下，此类规则是使用最多的。

例如，需求是对邮箱慢速密码破解的行为监视。 UseCase 的编制过程如下：

1.获取邮件系统的登录日志并分析，经过调研发现 IPS 已经设置了相关的 SMTP 暴力破解阻挡规则，但是邮件系统的登录失败日志中依旧可以发现很多用多个同网段地址，分别用不同的账号以 20-30 秒左右的频率来尝试登录，这种慢速攻击的行为 IPS 的现有规则还无法发现；

2.为更精准的发现 SMTP 的攻击行为，此 UseCase 要分几步做：

• 将所有 IPS 的相关 Use Case 报警中超过某个阈值（例如 1000 次）的源地址（除已知的合作伙伴地址外）放入可疑源地址列表中；

• 将所有的 SMTP 登录失败的源地址及账号记录入失败统计列表中并累加次数；

• 只要上一条规则累加的某个源地址及账号登录失败次数在 1 天内大于某个阈值（例如 100 次），将该源地址放入可疑地址列表中；

• 如果出现 SMTP 登录成功的源地址及账号在失败统计列表中，且累计次数大于某个阈值（例如 5 次），或者源地址出现在可疑地址列表中马上报警；

• 对于通过多个 IP 分布式的进行慢速攻击，通过报表按 C 段来统计，每天大于 1000 次以上的源地址及账号的登录失败汇总信息以报表方式发送进行人工判断。

3.对于 IPS 报警规则维护的可疑源地址列表，这里不详述，以下主要介绍一下 SMTP 慢速攻击相关的部分。

4.定义实时报警规则，选择 Lightweight 类型；

5.条件是 SMTP 登录失败的事件；

6.动作就是把相关的源地址及用户账号信息分别写入短时间（ 1 天）有效列表和长时间（ 1 年）有效列表，分别用来做累加次数和未来出汇总报表；

7.定义实时报警规则，选择 Lightweight 类型；

8.条件是上一规则累加发生次数超过 100 次的源地址及用户账号；

9.把源地址写入可疑源地址列表：

10.定义实时报警规则，选择 Standard 类型；

11.条件是 STMP 登录成功的事件，源地址及账号对在失败列表累计次数大于 5 ，或源地址在已知可疑源地址列表中；

12.发送报警通知邮件；

13.继续定义相关的报表，具体步骤不再详述，大致的摘要内容如下。

14.整个 Use Case 的 Rule 资源关联关系如下图所示。