Question

本节通过使用 ArcSight 介绍 SOC 的规划和技术架构设计，在具体动手安装配置前，最重要的是做好整个平台的规划和架构设计。按以下九个步骤做好 SOC 平台的规划和架构设计，每个步骤推荐了实战中的一些最佳做法，供大家参考。

1）明确需求。

2）架构环境。

3）硬件规格。

4）日志管理策略。

5）应用的资产和架构信息。

6）外部信息集成策略。

7）开发方法及方式。

8）工作流规划。

9）成果度量。

21.3.1　明确需求

应明确以下问题：

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

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

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

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

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

21.3.2　架构环境

1.EISM 架构（整体架构）

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

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

·主备模式。

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

以下是适应大多数情况（不买 HA、Event Broker 模块）的 ESM 双机架构，如图 21-2 所示。

2.Connector 日志采集架构

（1）采集层

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

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

图 21-2　ESM 双机架构示意图

图 21-3　实践部署图

（2）处理层

笔者建议搭建两套 ESM Manager：

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

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

注意：

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

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

21.3.3　硬件规格

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

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

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

Minimum 规格估计可以支撑 2000EPS；Mid-Range 规格估计可以支撑 10 000EPS；High Performance 规格估计可以支撑 20 000EPS。

重要的是，不要使用 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 字节。

·归档时长，103 分钟。

·平均归档速率，6.2G/分钟。

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

21.3.4　日志管理策略

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

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

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

图 21-4 是某个实际场景中设置的日志存留期策略。

图 21-4　某个实际场景中设置的日志存留期策略

21.3.5　应用的资产和架构信息

关键业务的基础架构、灾备架构会确定如何及在哪里采集日志，同样也会影响 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》 ^[1] 。

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

21.3.6　外部信息集成策略

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

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

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

CEF 是 ArcSight 对日志格式进行定义的规范，ArcSight 与其他系统数据的交换可以采用此规范，以下是 CEF 的简单格式样例，详细描述请参见《CEF》 ^[1] 。

[1] CEF 地 址：https://community.softwaregrp.com/t5/ArcSight Connectors/ArcSight Common Event Format CEF Guide/ta p/1589306?attachment id=65537（打开较慢，耐心等待）。

21.3.7　开发方法及方式

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

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

所有新 Use Case 上线应该遵循必要的变更管理流程，并提供相应的文档及操作手册。我们在这方面吃过亏，教训极为深刻。

21.3.8　工作流规划

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

图 21-5　ArcSight 为某 500 强企业做的相关 SOC 流程规划示意图

21.3.9　成果度量

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

·实时关注的不同类型报警数量≤A 单/小时（一般来说对于每个一线值班人员，A＝6），否则一线值班人员无能力处理。

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

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