方法论：评估SIEM有效性

SIEM是一个提供广泛且灵活威胁检测能力的复杂系统。由于其复杂性，其有效性很大程度上取决于配置方式以及连接的数据源。仅靠实施阶段的一次性设置是不够的：组织的架构和攻击者的技术都会随时间演变。要有效运行，SIEM系统必须反映当前实际情况。

我们为客户提供SIEM有效性评估服务，帮助发现问题并提供系统优化选项。本文中，我们将探讨典型的SIEM操作陷阱以及解决方法。针对每种情况，我们也包含独立验证的方法。

本材料基于对卡巴斯基SIEM有效性的评估；因此，所有具体示例、命令和字段名称均取自该解决方案。然而，评估方法、我们发现的问题以及提升系统有效性的方法，都可以轻松推广到任何其他SIEM。

有效性评估方法论

有效性评估报告的主要受众是组织内的SIEM支持和运营团队。主要目标是分析SIEM的使用情况与其目标的一致程度。因此，检查范围可能因既定目标而异。标准评估涵盖以下领域：

• 已连接数据源的构成和范围
• 数据源的覆盖率
• 现有源的数据流
• 数据规范化的正确性
• 检测逻辑的可操作性
• 检测逻辑的准确性
• 检测逻辑的覆盖率
• 上下文数据的使用
• SIEM与SOC流程的技术集成
• SOC分析师对SIEM中警报的处理
• 将警报、安全事件数据和事件信息转发至其他系统
• 部署架构和文档

同时，这些领域不仅被单独检查，还会评估它们之间潜在的相互影响。以下是几个说明这种相互依赖性的例子：

1. 由于数据规范化错误导致的检测逻辑问题。一条条件为 deviceCustomString1 not contains <string> 的关联规则触发了大量警报。检测逻辑本身是正确的：特定事件及其目标字段不应产生大量匹配该条件的数据。我们的审查发现，问题出在SIEM摄取的数据上，错误的编码导致规则目标字符串被转换成了另一个字符串。因此，所有事件都匹配了条件并生成了警报。
2. 在分析特定源类型的覆盖率时，我们发现SIEM只监控了基础设施中部署的此类源总数的5%。然而，扩大覆盖率会增加系统负载和存储需求。因此，除了连接额外的源，还需要为特定模块（存储、收集器或关联器）扩展资源。

有效性评估包含几个阶段：

1. 收集并分析文档（如果可用）。这有助于评估SIEM目标、实施设置（理想情况下是评估时的部署设置）、相关流程等。
2. 访谈系统工程师、分析师和管理员。这有助于评估当前任务和最紧迫的问题，并确定SIEM的具体操作方式。访谈通常分为两个阶段：项目开始时的介绍性访谈，用于收集一般信息；以及项目中期进行的后续访谈，用于讨论分析先前收集数据时产生的问题。
3. 在SIEM内收集信息并进行分析。这是评估中最广泛的部分，在此期间，卡巴斯基专家被授予系统的只读访问权限（或部分权限），以收集有关其配置、检测逻辑、数据流等方面的事实数据。

评估会产生一份建议列表。其中一些可以几乎立即实施，而另一些则需要更全面的变革，由流程优化或转向更结构化的系统使用方法来驱动。

SIEM运营中出现的问题

我们在SIEM有效性评估中发现的问题可分为三组：

1. 性能问题，即系统各组件的操作错误。这些问题通常由技术支持解决，但为了防止它们，值得定期检查系统健康状态。
2. 效率问题——系统运行正常但似乎价值不大或未充分发挥潜力。这通常是由于客户以有限、错误或非开发者预期的方式使用系统功能。
3. 检测问题——当SIEM可运行并根据既定流程和方法持续演进，但警报大多是误报，并且系统漏报事件时。这些问题大部分与制定检测逻辑时采用的方法有关。

评估中的关键观察

事件源清单

在为SIEM构建事件源清单时，我们遵循分层监控原则：系统应拥有所有可检测攻击阶段的信息。这一原则使得即使个别恶意行为未被察觉，也能检测到攻击，并允许追溯性地从攻击者入口点开始重建完整的攻击链。

问题：在有效性评估中，我们经常发现，当基础设施发生变化时，连接的源类型清单没有更新。在某些情况下，自SIEM初始部署以来就未曾更新，这限制了事件检测能力。因此，某些类型的源对系统完全不可见。

我们也遇到过非标准的不完整源清单案例。例如，基础设施中同时存在运行Windows和Linux的主机，但只为一个操作系统家族配置了监控。

如何检测：要识别上述问题，需要确定连接到SIEM的源类型列表，并与基础设施中实际存在的源进行比较。识别基础设施中特定系统的存在需要进行审计。然而，这项任务对于许多网络安全领域都是至关重要的，我们建议定期运行。

我们编制了一份常见于大多数组织的系统类型参考表。根据组织类型、基础设施和威胁模型，我们可能会重新安排优先级。然而，一个好的起点如下：

• 高优先级——与以下相关的源：
  • 远程访问提供
  • 可从互联网访问的外部服务
  • 外部边界
  • 终端操作系统
  • 信息安全工具
• 中优先级——与以下相关的源：
  • 边界内的远程访问管理
  • 内部网络通信
  • 基础设施可用性
  • 虚拟化和云解决方案
• 低优先级——与以下相关的源：
  • 业务应用程序
  • 内部IT服务
  • 各专业团队（人力资源、开发、公关、IT等）使用的应用程序

监控来自源的数据流

无论检测逻辑有多好，没有来自数据源的遥测数据，它都无法工作。

问题：SIEM核心没有收到来自特定源或收集器的事件。根据所有已进行的评估，已配置源但未传输事件的收集器平均比例为38%。可能存在针对这些源的关联规则，但它们当然永远不会触发。同样重要的是要记住，单个收集器可以为数百个源（如工作站）提供服务，因此即使一个收集器丢失数据流，也可能意味着失去对大部分基础设施的监控可见性。

如何检测：定位未传输数据的源的过程可分为两个部分。

1. 检查收集器健康状态。查找收集器的状态（参见支持网站了解在卡巴斯基SIEM中执行此操作的步骤），并识别状态为离线、已停止、已禁用等的收集器。
2. 检查事件流。在卡巴斯基SIEM中，可以使用以下查询收集统计数据来完成（计算特定时间段内从每个收集器收到的事件数量）：

   1	SELECT count(ID), CollectorID, CollectorName FROM `events` GROUP BY CollectorID, CollectorName ORDER BY count(ID)

   指定收集这些统计数据的最佳时间范围至关重要。范围太大会增加SIEM负载，而范围太小则可能为一次性检查提供不准确的信息——尤其是对于那些遥测传输相对不频繁（例如，每周一次）的源。因此，建议选择一个较小的时间窗口，例如2-4天，但针对过去的不同时间段运行多个查询。 此外，为了更全面的方法，建议使用内置功能或通过关联规则和列表实现的自定义逻辑来监控事件流。这将有助于自动化检测源问题的过程。

事件源覆盖率

问题：系统未接收基础设施中存在的特定类型所有源的事件。例如，公司使用运行Windows的工作站和服务器。在SIEM部署期间，工作站被立即连接进行监控，而服务器部分则因某种原因被推迟。结果，SIEM接收来自Windows系统的事件，数据流被规范化，关联规则工作，但未监控服务器部分中的事件会被漏报。

如何检测：以下是可用于搜索未连接源的查询变体。

1
2

SELECT count(distinct, DeviceAddress), DeviceVendor, DeviceProduct FROM events GROUP BY DeviceVendor, DeviceProduct ORDER BY count(ID)
SELECT count(distinct, DeviceHostName), DeviceVendor, DeviceProduct FROM events GROUP BY DeviceVendor, DeviceProduct ORDER BY count(ID)

我们将查询拆分为两个变体，因为根据源和DNS集成设置，某些事件可能包含DeviceAddress或DeviceHostName字段。

这些查询将有助于确定发送特定类型日志的唯一数据源数量。此计数必须与从系统所有者处获得的该类型源的实际数量进行比较。

保留原始数据

原始数据对于开发自定义规范化器或存储未用于关联但可能在事件调查中需要的事件很有用。然而，不小心使用此设置可能会带来比好处大得多的危害。

问题：启用保留原始事件选项实际上会使数据库中的事件大小加倍，因为它存储两个副本：原始副本和规范化副本。这对于接收来自NetFlow、DNS、防火墙等高流量源事件的收集器尤其关键。值得注意的是，此选项通常用于测试规范化器，但在配置完成后经常被遗忘并保持启用状态。

如何检测：此选项在规范化器级别应用。因此，有必要审查所有活动的规范化器，并确定是否需要为其操作保留原始数据。

规范化

与缺少源事件一样，规范化问题会导致检测逻辑失效，因为该逻辑依赖于在特定事件字段中查找特定信息。

问题：可以识别几个与规范化相关的问题：

• 事件流完全未规范化。
• 事件仅被部分规范化——这对于自定义、非开箱即用的规范化器尤其重要。
• 使用的规范化器仅解析头部，例如syslog_headers，将整个事件正文放入单个字段，该字段最常见的是Message。
• 使用了过时的默认规范化器。

如何检测：由于遥测数据量大且解析器种类繁多，识别规范化问题比发现源问题更具挑战性。以下是缩小搜索范围的几种方法：

1. 首先，检查组织使用了SIEM提供的哪些规范化器以及它们的版本是否是最新的。在我们的评估中，我们经常遇到使用过时的规范化器（对于卡巴斯基SIEM是Linux audit and iptables syslog v2）来规范化auditd事件的情况。新的规范化器完全重构并优化了来自此源事件的规范化模式。
2. 执行查询：

   1	SELECT count(ID), DeviceProduct, DeviceVendor, CollectorName FROM `events` GROUP BY DeviceProduct, DeviceVendor, CollectorName ORDER BY count(ID)

   此查询收集来自每个收集器的事件统计信息，按DeviceVendor和DeviceProduct字段细分。虽然这些字段不是强制性的，但它们几乎存在于任何规范化模式中。因此，它们的完全缺失或空值可能表明存在规范化问题。我们建议在开发自定义规范化器时包含这些字段。
3. 为了简化开发自定义规范化器时识别规范化问题，可以实现以下机制。对于每个成功规范化的事件，添加一个Name字段，从常量或事件本身填充。对于一个处理所有未解析事件的最终全能规范化器，设置常量值：Name = unparsed event。这将允许您以后通过简单搜索此字段来识别未规范化的事件。

检测逻辑覆盖率

在大多数情况下，仅收集的事件仅对调查已识别的事件有用。要使SIEM充分发挥其潜力，需要开发检测逻辑以发现可能的安全事件。

问题：根据我们所有评估确定的源的平均关联规则覆盖率为43%。虽然这个数字只是一个大致估计——因为不同的源类型提供不同的信息——但为了计算它，我们将“覆盖率”定义为至少存在一条针对源的关联规则。这意味着对于超过一半的已连接源，SIEM没有主动进行检测。同时，为连接、维护和配置这些源付出了努力并消耗了SIEM资源。在某些情况下，这在形式上是合理的，例如，如果日志仅出于法规遵从性需要。然而，这是例外而非规则。

我们不建议通过简单地不将源连接到SIEM来解决此问题。相反，应该连接源，但这应与相应检测逻辑的开发同时进行。否则，它可能被遗忘或无限期推迟，而源则无谓地消耗系统资源。

如何检测：这又将我们带回了审计过程，创建和维护已开发检测逻辑的注册表可以极大地帮助这个过程。鉴于并非每条检测逻辑规则都明确说明它期望遥测数据的源类型，应在开发阶段将其描述添加到此注册表中。

如果没有关联规则的描述，可以参考以下内容：

• 检测逻辑的名称。通过标准化的关联规则命名方法，名称可以指示关联的源或至少提供其检测内容的简要描述。
• 规则内部字段的使用，例如DeviceVendor、DeviceProduct（另一个在规范化器中包含这些字段的理由）、Name、DeviceAction、DeviceEventCategory、DeviceEventClassID等。这些可以帮助识别实际的源。

检测逻辑生成过多警报

关联规则有效性的一个标准是低误报率。

问题：检测逻辑生成了异常多的警报，无论SOC团队规模如何，实际上都无法处理。

如何检测：首先，检测逻辑应在开发期间进行测试并加以完善，以达到可接受的误报率。然而，即使调整良好的关联规则也可能由于事件流或连接基础设施的变化而开始产生过多的警报。为了识别这些规则，我们建议定期运行以下查询：

1

SELECT count(ID), Name FROM `events` WHERE Type = 3 GROUP BY Name ORDER BY count(ID)

在卡巴斯基SIEM中，Type字段值为3表示关联事件。

随后，针对每个识别出的具有异常警报数量的规则，验证其使用的逻辑正确性以及触发它的事件流的完整性。

根据识别的问题，解决方案可能涉及修改检测逻辑、添加例外（例如，通常99%的垃圾邮件仅来自1-5个特定对象，如IP地址、命令参数或URL），或者调整事件收集和规范化。

缺乏与入侵指标的集成

SIEM与其他系统的集成通常是事件处理和警报丰富化的关键部分。至少在一种特定情况下，它们的存在直接影响检测性能：与技术威胁情报数据或IoC的集成。

SIEM允许方便地根据各种信誉数据库或阻止列表检查对象。此外，有大量现成的数据源可以原生集成到SIEM中或只需最少的努力即可整合。

问题：没有与TI数据集成。

如何检测：通常，IoC在部署或后续优化期间在系统配置级别集成到SIEM中。在SIEM内使用TI可以在不同级别实现：

1. 在数据源级别。一些源，如NGFW，将此信息添加到涉及相关对象的事件中。
2. 在SIEM原生功能级别。例如，卡巴斯基SIEM与CyberTrace指标集成，这些指标在处理来自源的事件时添加对象信誉信息。
3. 在检测逻辑级别。有关IoC的信息存储在各种活动列表中，关联规则将对象与之匹配以丰富事件。

此外，TI数据不会凭空出现在SIEM中。它要么由外部供应商提供（商业或开放格式），要么是所用安全工具内置功能的一部分。例如，各种NGFW系统可以额外检查用户正在访问的外部IP地址或域的信誉。因此，第一步是确定您是否正在接收关于入侵指标的信息以及以何种形式（是否集成了外部供应商的订阅源和/或部署的安全工具是否具有此功能）。值得注意的是，仅接收安全工具级别的TI数据并不总是能覆盖所有类型的IoC。

如果以某种形式接收数据，下一步是验证SIEM是否正在利用它。对于来自安全工具的TI相关事件，SIEM需要开发关联规则来生成警报。因此，在这种情况下检查集成涉及确定安全工具的功能、在SIEM中搜索相应事件以及识别是否存在与这些事件相关的检测逻辑。如果缺少来自安全工具的事件，应评估源审计配置，看相关遥测类型是否已转发到SIEM。如果是规范化问题，应评估解析准确性并重新配置规范化器。

如果TI数据来自外部供应商，则确定其在组织内的处理方式。是否存在用于聚合和管理威胁数据的集中式系统（如CyberTrace），或者信息是否存储在例如CSV文件中？

• 在前者情况下（存在威胁数据聚合和管理系统）您必须检查它是否与SIEM集成。对于卡巴斯基SIEM和CyberTrace，此集成通过SIEM界面处理。随后，SIEM事件流被定向到威胁数据聚合和管理系统，在那里识别匹配项并生成警报，然后两者都被发送回SIEM。因此，检查集成涉及确保所有接收可能包含IoC的事件的收集器都将这些事件转发给威胁数据聚合和管理系统。我们还建议检查SIEM是否存在基于检测到的对象与IoC匹配生成警报的关联规则。
• 在后者情况下（威胁信息存储在文件中）您必须确认SIEM已配置收集器和规范化器以将此数据作为事件加载到系统中。同时，验证是否已配置用于在SIEM内存储此数据以用于关联的逻辑。这通常借助包含所获IoC的列表来完成。最后，检查是否存在将事件流与这些IoC列表进行比较的关联规则。

如示例所示，标准场景中与TI的集成最终归结为开发一个最终的关联规则，该规则在检测到与已知IoC匹配时触发警报。鉴于集成方法的多样性，创建和提供通用的开箱即用规则是困难的。因此，在大多数情况下，要确保IoC连接到SIEM，您需要确定公司是否开发了该规则（规则的存在）以及是否正确配置。如果系统中不存在关联规则，我们建议根据您基础设施中实施的TI集成方法创建一个。如果规则确实存在，则必须验证其功能：如果没有来自它的警报，则根据SIEM中可见的事件数据分析其触发条件并进行相应调整。

SIEM未保持更新

要使SIEM有效运行，它必须包含关于其监控的基础设施以及它旨在检测的威胁的最新数据。这两个要素都会随时间变化：新的系统和软件、用户、安全策略和流程被引入基础设施，而攻击者则开发新的技术和工具。可以安全地假设，一个完美配置和部署的SIEM系统，在运行五年且没有额外配置后，将无法完全看到已改变的基础设施或新的威胁。因此，几乎所有组件——事件收集、检测、用于上下文信息的额外集成以及排除项——都必须维护并保持最新。

此外，必须承认不可能覆盖100%的所有威胁。持续研究攻击、开发检测方法以及配置相应规则是必要的。SOC本身也在演变。随着它达到一定的成熟度水平，为团队开辟了新的增长机会，这需要利用新的能力。

问题：自初始部署以来，SIEM没有演进。

如何检测：将原始工作说明书或其他部署文档与系统的当前状态进行比较。如果没有变化或只有最小变化，那么您的SIEM很可能存在需要增长和优化的领域。任何基础设施都是动态的，需要持续适应。

SIEM实施和运营中的其他问题

在本文中，我们概述了SIEM有效性评估中发现的主要问题，但此列表并非详尽无遗。我们也经常遇到：

• 许可证容量与实际SIEM负载不匹配。问题几乎总是源事件的缺失，而不是对组织需求初始评估不正确。
• 系统内缺乏用户权限管理（例如，每个用户都被分配了管理员角色）。
• 可定制SIEM资源组织不善（规则、规范化器、过滤器等）。例如：混乱的命名约定、非最佳分组，以及过时的或测试内容与活动内容混合在一起。我们遇到过令人困惑的资源名称，如[dev] test_Add user to admin group_final2。
• 使用未适应组织基础设施的开箱即用资源。要最大化SIEM的价值，至少必须填充例外列表并指定基础设施参数：管理员、关键服务和主机的列表。
• 禁用了与外部系统的原生集成，如LDAP、DNS和GeoIP。

通常，大多数SIEM有效性问题源于系统内已实施流程的自然退化（错误积累）。因此，在大多数情况下，保持有效性涉及结构化这些流程，监控所有阶段（源接入、关联规则开发、规范化等）的SIEM参与质量，并定期审查所有系统组件和资源。

结论

SIEM是一个用于监控和检测威胁的强大工具，能够识别组织基础设施中几乎任何点、各个阶段的攻击。然而，如果配置和操作不当，它可能会变得无效甚至无用，同时仍消耗大量资源。因此，定期审计SIEM的组件、设置、检测规则和数据源至关重要。

如果SOC团队负担过重或因其他原因无法独立识别其SIEM的操作问题，我们为卡巴斯基SIEM平台用户提供评估其运行状况的服务。评估后，我们提供一份建议列表以解决我们发现的问题。尽管如此，需要明确的是，这些不是严格的、规定性的指令，而是强调值得关注和分析的领域，以改善产品性能、提高威胁检测准确性并实现更高效的SIEM利用。