实施规划和架构设计-ArcSight实战系列之二

上一篇介绍了ArcSight的整体情况、主要模块和一些特性。本篇介绍ArcSight实施前的规划和技术架构设计，在具体动手安装配置前，最重要的是做好整个平台的规划和架构设计。怎么做好ArcSight平台的规划和架构设计，按以下九个步骤进行基本就没有太大问题了，每个步骤基本都推荐了我们实战中的一些最佳做法，供大家参考。

1. 明确需求

2. 架构环境

3. 硬件规格

4. 日志管理策略

5. 应用的资产和架构信息

6. 外部信息集成策略

7. 开发方法及方式

8. 工作流规划
   

9. 成果度量

一、明确需求

确定SIEM平台需要解决哪些问题，不少情况下合规性要求是原始驱动力，例如等保、PCI等，实时关联需求是后续的需求，因此SIEM平台建设的各阶段的目标要明确。

1. 确定各日志源设备管理部门对SIEM平台的需求，哪些关键业务系统需求要优先完成，期望的合规性日、周、月报表有哪些，期望的实时关联需求有哪些，各业务系统以前对日志的处理方式及关注的重点有哪些。

2. 确定需求相关的日志源清单、采集方式、变更流程、变更窗口。

3. 确定相关报表、报警的发送对象及处理流程。

上述的需求务必在实施前落实到字面，否则一旦实施起来跨部门的协助、支持难度将会是巨大的。

二、架构环境

（一）ESM架构（整体架构）

首先要确定SIEM平台的运营方式（7x24、5x8），不同的运营方式决定了ArcSight的架构是单机系统还是双机系统，ArcSight的ESM可以：

• 开启HA功能（需单独付费）

• 或主备模式。

ArcSight的Logger也支持分布式存储、查询功能。SIEM平台如果与大数据平台有交互需求，架构中需要加入Event Broker。

以下是适应大多数情况（不买HA、Event Broker模块）的ESM双机架构示意图：

（二）Connector日志采集架构

1. 采集层

Connector根据日志源的特性分为接收型和获取型，对于接收型的Connector，例如Syslog，总体来说日志量是比较大的，尽管ArcSight也提供了名为Connector Load Balance的模块，但笔者的最佳实践按下图部署。

上述架构中LVS非必需，仅当Syslog日志量大于3000EPS，或Rsyslog本身性能模块提示有失败的情况下才需要搭建，当然任何其它的负载均衡软硬件均可使用。

2.处理层

最佳推荐：搭建2套ESM Manager：

• 1套为生产环境，其硬件配置需要满足规划设计

• 1套为备用/开发环境，其硬件配置无需和生产环境一样高，它主要用于在生产环境停止服务的时候可以接管日志继续运行关联分析规则，同时兼做Use Case的开发、测试环境。

注意：Connector 需要做相应的配置确定ESM发生主备切换时的日志发送目标，默认情况下ESM主节点停止服务时，Connector会将后续的所有日志发送至备节点，同时缓存这些日志数据，当主节点恢复服务时，Connector会将后续的所有日志发送至主节点，同时按7:3的比率逐步将之前缓存的日志数据发送给主节点。

上述是性价比较高的架构，也可以搭建2套完全相同配置的ESM Manager，Connector同时向两个ESM发送相同或不同的日志，也可以购买HA模块，由其自动准实时同步ESM Manager数据。

三、硬件规格

SIEM平台主要是日志的接收、存储、关联分析，ArcSight的ESM是基于Java编写的程序，因此决定性能的两大因素是硬盘、内存，其次才是CPU数量和存储容量。

首先需要估算大约的EPS、EPD规模，小规模的EPS（小于2000）可以考虑使用虚拟化环境部署，即便是大规模的EPS，也可以在小规模EPS的分支机构里考虑使用虚拟化环境部署，方便标准化、快速部署。

基于估算的EPS、EPD规模估算计算能力及存储容量，以下是ESM Manager部署所需的硬件建议：

Minimum规格估计可以支撑2000EPS；

Mid-Range规格估计可以支撑10000EPS；

High Performance规格估计可以支撑20000EPS；

重要的事情说三遍：

• 不要使用Raid 5

• 不要使用Raid 5

• 不要使用Raid 5

上述规格的实际性能需要在SIEM平台搭建后，初始化压力测试后才能得到相对准确的数据，实际情况下我们曾经使用Dell R730服务器（2x Intel E5-2690 V4 2.6GHZ 14核，256G，12x1.2T SAS 10KRPM RAID 10）持续40小时压测的结果如下：

• 平均EPS：约为218,879.4；

• 最大EPS：约为；263,246.5

• 平均EPD：约为18,813.2M

• 总事件量：约为32,358,786,964

抽样其中完整的24小时存储数据如下：

• 归档文件容量：639G

• 归档日志条数：19,455,972,366

• 日志平均尺寸：35.27 byte

• 归档时长：103分钟

• 平均归档速率：6.2G/分钟

以下是Logger部署所需的基础环境建议：

对于Connector所需的基础环境没有硬性需求，建议使用Linux操作系统，每个Connector的JVM需要至少256M（服务器中可以同时部署多个Connector），预留约512M-1G的给Linux操作系统后可以大致估算出所需的内存数量，CPU线程数量建议至少不小于4个。

四、日志管理策略

日志管理策略大多由需遵循的合规性要求确定，由于ESM Manager主要用于实时关联分析，因此默认情况下ArcSight Connector发送给ESM Manager的是、过滤、归并、规范后的日志信息，如果某些合规要求保留原始日志，就需要在Connector进行相应的设置，或将原始日志发送给Logger。

不同规范对日志的存留期有所不同（等保、PCI、SOX），ArcSight是可以设置多个日志存储池的不同存留期，没有必要保留过久的日志占用宝贵的存储资源。

ESM和Logger的存储引擎可以每日将前一天的日志归档至外部存储中，这样可以减少对内置存储的容量需求，归档出的日志文件可以保存在便宜的NAS或带库中。

以下是某个实际场景设置的日志存留期 策略：

存储组名称	在线存留期	说明
Default	180 天	没有设置策略的日志，默认在线存留存储组
LP3	400 天	满足等级保护三的日志存留存储组， 1 年
PCI	400 天	满足 PCI-DSS 的日志存留存储组， 1 年
SOX	2600 天	满足 SOX 的日志存留存储组， 7 年
10Year	3700 天	满足 10 年的日志存留存储组， 10 年

五、应用的资产和架构信息

关键业务的基础架构、灾备架构会确定如何及在哪采集日志，同样也会影响Use Case的定制策略，例如某个Web业务的前端由HAProxy/Nginx做Web应用代理，这时就应该取HAProxy/Nginx的Access Log，无需取后端的Web服务器Access Log。

关键业务资产信息的收集也会大大方便后续的事件分析及Use Case定制，ArcSight将每个IP视为一个资产（Asset），假设某个防火墙有多个接口，它就有多个资产属性。如果有CMDB工具最好，否则只能通过人肉收集后再通过工具导入ESM。

资产是ArcSight中的重要基础概念，也是个定制繁复的过程，但对精准定制Use Case的确有价值。

ArcSight的资产相关概念由Customer、Network、Zone、AssetGroup、AssetRange、Asset、AssetCategory、Location、Vulnerabilities组成，相互间有各种隶属、继承关系，详细的说明建议查看《ESM 101》。

ESM101地址：https://community.softwaregrp.com/t5/ESM-and-ESM-Express/ESM-101-ESM-6-11-0/ta-p/1585987?attachment-id=57488

（打开较慢，耐心等待）

资产主要资源关系简图：

六、外部信息集成策略

ArcSight的关联分析并不仅为日志，其它的资产信息、弱点扫描报告、黑白名单、威胁情报均可纳入关联分析规则中，但需要确定系统间的接口，接入方式（定时脚本、定时手工、实时自动）。

ArcSight提供专门的Connector（ArcSight Asset Model Import FlexConnector）实现自动资产的导入，也可通过手工用csv的方式导入。

弱点扫描报告可以通过特定Connector将相应的弱点导入ESM并关联。

CEF是ArcSight对日志格式定义的规范，ArcSight与其它系统数据的交换可以采用此文档定义的规范，以下是CEF的简单格式样例，详细描述请参见《CEF》：

CEF地址：https://community.softwaregrp.com/t5/ArcSight-Connectors/ArcSight-Common-Event-Format-CEF-Guide/ta-p/1589306?attachment-id=65537

（打开较慢，耐心等待）

CEF:Version|Device Vendor|Device Product|Device Version|Device EventClass ID|Name|Severity|[Extension]

七、开发方法及方式

SIEM的Use Case的开发需要遵循软件开发的模式，所以在资源允许的情况下建议有一套ESM开发、测试试运行环境，此环境需独立于生产环境，相关的日志信息由Connector配置后复制一份给开发环境。

如果资源实在有限，仅有一套ESM生产环境，所有上线需要实时/定时运行的Use Case均需有相应的测试、审批过程。

所有新Use Case上线也应该遵循必要的变更管理流程，并提供相应的文档及操作手册。我们在这方面吃过大亏，满满血泪史。

八、工作流规划

SIEM中的反映的问题很多在前期都需要进行优化、调整，否则误报率会很大，即使是准确的报警，很多情况下也需要设备管理部门来处理，因此定义合适的事件处理流程，形成闭环才能更好地发挥SIEM平台的作用。

以下是ArcSight为某500强做的相关SOC流程规划示意图：

九、成果度量

SIEM平台交付的各Use Case需要可验证并具备完整的设计、测试、维护文档，触发的有效性、精确性评估尽量量化，以下是实际情况中的一些度量评价指标：

• 实时关注的不同类型报警每小时≤A单（一般来说每个一线值班人员A≤6），否则一线值班人员无能力处理；

• 相同类型报警需具备归并、抑制、黑白名单功能，可以通过报表、仪表板展示明细，但实时报警24小时内不重复发送；

• 报警信息能显示相关的关联信息，以利于后续事件调研，报警的标题需包含事件严重度信息，方便快速检索；

• 其他……。

（未完待续）