闲谈：

最近和朋友在讨论SIEM的告警优化，大家交流过后，给我个人的感觉：分析师总会执着于对某条规则的某条具体告警进行过滤、加白、调整阈值、时间窗口，诚然以上都是规则优化的基本操作。但是如果你过度执着于以上行为，那么你是否会忽略了规则优化的本质？会不会忽略了其他重要的工作呢？或者忽略规则本身的问题呢？

所以笔者结合工作经验，写了这篇文章，希望读完本文能打开你的思维。

以下仅为个人观点，仅供参考。

0.理解规则优化的本质

从技术本质上看，SIEM规则优化是一个系统性的安全检测能力重构过程。这一过程本质上超越了简单的规则微调，需要安全专业人员深入理解规则的内在机制、攻击者行为模式和技术演进路径。根据Gartner安全研究报告，有效的规则优化应当基于MITRE ATT&CK框架，针对攻击生命周期的不同阶段构建多层次、高精度的检测逻辑，从根本上缩短攻击者停留在系统中的时间（Mean Time to Detect, MTTD）。

SIEM规则优化是一个动态、多维度的网络安全治理过程，其核心目标是通过系统性方法持续提升组织的安全检测与响应能力。这一过程不仅仅是技术层面的技术调整，更是一种面向企业安全建设未来的战略性重构。它需要安全团队整合威胁情报、机器学习算法和上下文关联分析，构建一个具有前瞻性和适应性的安全防御生态系统。

对规则调整，其实就像医生做手术。如果分析师要对规则“动刀”前，你应该想好的是，你的规则病因出在哪？而不是简单的“割两刀，缝几针”，你需要：做好症状诊断、精确定位病因，手术治疗，术后监控，预防管理。

1.现状评估与问题识别

既然要进行“症状诊断”开展医学会诊，结合经验，我将其归纳为五个症状。

• 规则库分析（全面体检）
• 告警质量评估（症状严重程度评估）
• 误报率统计与分析（病理指标检测）
• 规则覆盖度的评估（免疫系统评估）
• 性能瓶颈识别（器官功能极限测试）

每一个"症状"背后，都隐藏着潜在的系统性风险。就像医生通过CT、核磁共振和血液检查建立全面的诊断图谱，安全分析师需要通过多维度的技术分析方法，精准地"扫描"SIEM规则的每一个"器官"和"组织"。我们的目标不仅仅是"治愈"当前的安全"疾病"，更是构建一个具有高度免疫力和自我修复能力的安全防御生态系统。

通过这种系统性的诊断方法，我们将有效缩短攻击者的潜伏期（MTTD），提升组织的网络安全"免疫力"，使安全防御从被动应对转变为主动免疫。

规则库分析

规则库笔者将其分类为一下几种：

• 内置规则
• 自定义规则
• 第三方规则

内置规则

针对内置规则（即开箱规则），我习惯将其分为无效规则、有效规则。

• 有效规则
• 无效规则

针对无法生效的规则，首先分析该规则是否可以改造。针对无法改造的规则，即环境中没有满足的数据源/字段的规则，且规则无法替换数据源/字段进行关闭。针对可改造的规则，使用数据源/字段进行平替。

针对可以生效的规则，抑制重复的无效告警，对规则的误报进行优化。后面会详细介绍优化方法，此处不进行展开。

自定义规则

一般分为以下几类：

• 针对特定业务场景新增的临时规则
  • 针对某些业务临时进行检测防护增加的规则
• 情报IOC的规则
  • 监管单位推下来/开源情报提供的IOC
• 根据实际环境新增的非临时规则

第三方规则：

• 开源规则
• 上级单位推下来的规则
  • 顾名思义，不多赘述。

开源规则，即国外开源的规则库，Splunk、Sentinel等，国内的某些产品经常会“参考”这些规则，纳入开箱规则，这其实并没有什么不好。但是我希望分析师能理解某些规则的过滤逻辑是否合理，这些规则是否适合你的环境，总之，多思考。

也许你整体分析规则库过后就会发现：

• a%的规则过去6个月并未触发

• b%的规则存在重复检测逻辑
• c%的规则基于过时的威胁情报
• d%的规则并未即使针对业务系统更新而更新
• ……

总之，首先分析师要对规则有一个总体的认识及详细思考。

• 如果某些规则一直未触发告警，那么这些规则是否检测逻辑存在问题？这些规则的过滤条件是否短期内无法满足？这些规则是否真正可以触发？
• 存在重复检测逻辑的规则，分析师应当对规则进行优化合并。
• 过期的威胁情报规则，应当及时更新情报或关闭规则。
• 针对临时防护规则及时更新业务系统的信息。
• ……

告警质量评估

告警质量的评估，笔者认为这个并不是简单的仅评估告警的准确性，其实还要考虑告警的及时性、完整性，这和准确性同样重要。

• 告警是否准确
  • 一个精准的SIEM告警应具备高相关性、低误报率，并提供清晰的上下文信息，如事件时间、来源、目标、严重程度和潜在影响等。
• 告警是否及时
  • 如果规则过于复杂，例如规则使用多种消耗性能的算子，且进行时序关联，且在数据量庞大的情况下，可能会消耗引擎的大量性能，有可能导致告警延迟。
• 告警是否完整
  • 缺少关键上下文、缺少资产信息、告警描述不清晰等。

如何评估没什么好说的，主要就是进行大量的分析工作。

误报率统计与分析

误报率统计：

误报率统计不详细展开，往上有很多参考的知识。准确率、召回率、误报率、漏报率等，主要是进行数据分析的工作。

分析误报原因：

SIEM规则告警误报的原因包括规则设计问题、数据源质量问题、环境变化、威胁情报过期、规则过滤逻辑缺陷、用户行为多样性、以及测试与验证不足等等。

针对不同误报原因制定优化策略，优先处理高误报规则。

规则覆盖度的评估

SIEM规则覆盖度评估是衡量SIEM系统检测能力的重要环节，旨在确保规则能够有效覆盖组织的威胁场景和安全需求。

规则覆盖度的评估指标，主要归纳为以下几类：

威胁场景覆盖率：

主要分析规则是否覆盖组织面临的主要威胁场景（如恶意软件、数据泄露、内部威胁等）。将规则与威胁模型（如MITRE ATT&CK框架）进行比对，检查是否覆盖关键战术和技术。

日志源覆盖率：

分析规则是否覆盖所有关键日志源（如防火墙、终端、身份认证系统等）。列出所有日志源，检查是否有相关规则对其日志进行分析。可结合D3FEND框架进行对比。

攻击生命周期覆盖率：

衡量规则是否覆盖攻击生命周期的各个阶段（如初始访问、持久化、横向移动、数据泄露等）。  
可使用ATT&CK框架或其他攻击模型，检查规则是否覆盖各个阶段。

资产覆盖率：

衡量规则是否覆盖所有关键资产（如服务器、数据库、网络设备等）。列出关键资产清单，检查是否有规则保护这些资产。

威胁情报覆盖率：

衡量规则是否充分利用威胁情报（如IoC、TTPs）来检测威胁。检查规则是否包含威胁情报驱动的检测逻辑。

评估方法总结：

• 使用威胁建模框架（如MITRE ATT&CK）对组织的威胁场景进行建模。  将现有规则映射到威胁模型，识别覆盖缺口。
• 检查SIEM系统是否收集并分析所有关键日志源。  识别未被规则覆盖的日志源，并补充相关规则。
• 将威胁情报与SIEM规则结合，确保规则能够检测最新的威胁。  检查规则是否充分利用IoC（如恶意IP、域名、文件哈希）和TTPs。
• 根据资产的重要性和风险级别，评估规则的覆盖情况。  确保高价值资产和高风险场景有足够的规则覆盖。
• 检查规则是否覆盖正常和异常用户行为。  确保规则能够检测内部威胁和账户滥用。
• 通过BAS测试SIEM规则的检测能力。  记录规则未能检测到的攻击，分析覆盖缺口。
• 定期审查现有规则库，确保其覆盖最新的威胁和攻击技术。

SIEM规则覆盖度评估需要从威胁场景、日志源、攻击生命周期、资产、威胁情报等多个维度进行。通过威胁建模、红蓝演练、日志源分析等方法，识别覆盖规则缺口并持续优化规则，确保SIEM系统能够全面检测和响应威胁。

规则性能瓶颈识别

识别SIEM性能瓶颈是优化SIEM系统运行效率的关键步骤。性能瓶颈可能导致告警延迟、日志处理积压甚至系统崩溃。分析师对规则优化往往会忽略这个重要的指标。

SIEM性能瓶颈的常见表现

• 告警延迟：告警生成时间明显滞后于事件发生时间。  
• 日志积压：日志处理速度跟不上日志生成速度，导致积压。  
• 高CPU/内存使用率：SIEM系统资源占用过高，影响其他服务。  
• 规则执行超时：复杂规则执行时间过长，导致超时或失败。  
• 查询响应缓慢：在SIEM界面中执行查询时响应时间过长。

常见SIEM性能瓶颈原因

• 规则设计问题：复杂规则、高触发频率、多事件关联。  
• 日志处理问题：日志量过大、日志格式复杂。  
• 资源不足：CPU、内存、磁盘空间不足。  
• 配置问题：索引策略不当、存储配置不合理。  
• 系统架构问题：单点故障、分布式性能不足。

识别性能瓶颈方法：

• 监控系统资源，如CPU使用率、内存使用率、磁盘I/O、网络带宽等。
  • 检查资源使用是否达到瓶颈。  确定资源高占用是否与特定规则相关。
• 分析规则执行时间
  • 使用SIEM系统的规则性能分析功能。分析每条规则的执行时间、触发频率。
    • 识别执行时间过长或触发频率过高的规则。  检查规则逻辑是否过于复杂。
• 检查日志处理延迟
  • 使用SIEM系统的日志处理监控功能，检查日志处理是否延迟。
    • 确定延迟是否与特定规则相关。调优相关规则进行解决。
• 评估查询性能
  • 使用SIEM系统的查询性能分析功能。
    • 识别响应时间过长的查询。  优化查询逻辑和索引策略。
    • 通常SIEM都有此类功能。例如Splunk的Search Job Inspector、Qradar的Ariel Query Performance、Sentinel的Query Performance Insights等。
• 分析规则触发频率
  • 使用SIEM系统的规则统计功能。分析每条规则的触发次数、触发频率。
    • 识别触发频率过高或触发次数异常的规则。  调整规则条件以减少误报。
• 检查日志源
  • 使用SIEM系统的日志源监控功能。
    • 检查是否有日志源生成过多日志。优化日志收集和过滤策略。

性能优化建议

• 优化规则设计：简化复杂规则，调整触发条件。  
• 优化日志处理：过滤无关日志，优化解析逻辑。  
• 扩容硬件资源：增加CPU、内存、磁盘等资源。  
• 优化配置：调整索引和存储策略。  
• 优化系统架构：采用分布式部署，避免单点故障。  
• 定期性能调优：持续监控和优化系统性能。

由于想写的内容比较多，整体分为几篇进行撰写。这篇主要介绍了关于SIEM规则优化的现状评估与问题识别。可能读者有疑问，这篇并没有介绍如何优化规则？笔者认为，对于现状评估和识别是优化规则的前置动作，是一项必须得工作。

因为无论是所谓的SIEM/SOC系统，它都是一个整体，是一个工程。就像一个正方体，它是由点、线、面构成的。在你没有理解透这个物体时，不要随意对某一点进行动工，SIEM的规则对应SIEM“这个正方体”来说就是一个点，牵一发而动全身。对于安全而言，要如履薄冰，谨慎每一步的操作。

感谢你的阅读，希望对你有一些帮助。