复合检测概览
本文档介绍了复合检测，以及复合检测如何通过关联多条规则的输出结果来增强威胁检测工作流。
复合检测由规则生成，这些规则使用其他规则的检测结果作为输入，并结合事件、指标或实体风险信号。然后，这些规则会与事件、指标或实体风险信号相结合，以检测单个规则可能遗漏的复杂多阶段威胁。
复合检测有助于通过定义的规则互动和触发器分析事件。通过关联来自不同来源和攻击阶段的数据，可以提高准确性、减少假正例，并提供安全威胁的全面视图。
以下概念定义了复合规则的组成部分，并阐明了它们在检测工作流中的运作方式：
复合规则：使用检测结果或提醒（或两者）作为输入。（可选）使用事件、指标和实体图中的各种情境数据（例如普及率数据、威胁情报或实体风险评分）来丰富这些数据。这些规则必须始终具有匹配部分，并且可以引用输入规则中的元字段、
match变量和outcome变量。检测：满足规则条件时生成的输出。
仅检测规则：仅使用检测或提醒作为输入的复合规则。
何时使用复合检测
复合检测有助于实现以下目标：
关联两个或更多规则的结果（例如，将“已下载恶意软件”检测结果与来自同一主机的后续 C2 信标提醒相关联）。
利用相关事件数据丰富提醒。
仅在多次发生嘈杂、低置信度检测或与其他可疑活动结合发生时触发最终提醒，从而减少提醒疲劳。
针对复杂的、多阶段的攻击构建提醒，其中每个阶段都已通过其自己的规则进行识别。
复合检测的优势
复合检测具有以下优势：
揭露多阶段攻击：网络攻击通常是多方面的，并且相互关联。复合检测通过关联看似孤立的安全性事件，揭示更广泛的攻击叙事。例如，复合检测可以识别攻击的完整序列，例如初始入侵，然后是提权和数据渗漏。
缓解警报疲劳：复合规则可整合并过滤嘈杂的警报，从而实现更集中的响应。这种方法有助于优先处理影响重大的突发事件，并减少整体警报疲劳。
提高检测准确性：结合统一数据模型 (UDM) 事件、规则检测、实体上下文、用户和实体行为分析 (UEBA) 发现结果以及数据表中的数据洞见，构建更准确的检测逻辑。
简化复杂逻辑：将复杂的检测场景分解为可管理、互连且可重复使用的规则，以简化开发和维护。
在信息中心内使用：将复合检测无缝集成为 Google SecOps 信息中心的数据源。您可以使用它们创建可视化图表，总结多阶段攻击模式，从而更轻松地了解复杂的风险。
常见使用场景
本部分列出了复合检测的一些常见用例。
利用原始事件中的上下文丰富检测结果
此用例涉及将一个系统中的高级别提醒与另一个系统中的事件日志相关联。
目标：确定导致高级别提醒的具体本地操作。
示例：
由于工作负载对恶意网域进行了 DNS 调用，因此 Google Cloud Event Threat Detection 中触发了提醒。这就是检测。
此检测会触发复合规则。
然后，该规则会在一分钟的时间范围内，从同一工作负载中搜索原始端点检测和响应 (EDR) 日志（事件），查找包含相同恶意网域的命令行操作。
最终提醒提供了丰富的上下文：它显示了联系的恶意网域以及使用的特定
ssh命令。这些信息使结果比原始检测更具实用性。
跟踪登录后的用户活动
主要用例侧重于将用户的登录事件与后续可疑活动相关联。虽然标准多事件规则可以跟踪短序列，但复合检测更适合构建用户整个会话的全面风险分析。
目标：将单个事件（例如高风险登录）与较长时间段（例如一整天）内的一系列后续“弱信号”活动相关联。
示例：创建多条规则，以生成较低级别的检测结果。 然后，使用具有较长匹配窗口（例如 24 小时）的复合规则，在初始可疑登录时触发，并将其与来自同一用户的以下任何检测相关联：
用户清除其命令行历史记录。
创建新的本地管理员账号。
向个人 Cloud Storage 网站上传大量数据。
与 UEBA 指标结合使用
此用例利用现有 UEBA 指标作为复合检测的起点，以发现更复杂的长期行为。
目标：将 UEBA 指标的峰值与另一项异常活动相关联。
示例：
UEBA 规则检测到某位用户登录失败次数过多。
另一条 UEBA 规则检测到来自同一用户的大量出站流量字节。
复合检测会将这两个独立的 UEBA 发现结果关联起来，以识别潜在的账号入侵以及随后的数据窃取。
检测数据渗漏企图
这涉及关联多个不同的用户操作，这些操作组合在一起可能表示有人试图渗漏数据。
目标：构建单个用户在多个设备和操作中处理风险数据的个人资料。
关联的操作：
从多台设备（例如家用设备和工作设备）登录。
访问的数据源比平时多。
同时下载、打印和通过电子邮件发送数据。
统计用户在一段时间内接触的机密文档数量。
已提交辞职信。
检测多阶段恶意软件
此用例涉及识别长期缓慢运行的恶意软件，这些恶意软件很难通过匹配窗口较短的单一规则捕获。
目标：将初始感染途径与后续恶意操作关联起来，即使这些操作相隔数小时或数天。
示例：
用户访问恶意网站（初始网络事件）。
下载并执行“dropper 文件”（第一个进程事件）。
很久之后，Dropper 文件下载并运行另一个可执行文件（第二个进程事件）。
这需要一个较长的
match窗口来连接父进程和子进程，而复合检测可以提供该窗口。
减少提醒干扰
此应用场景涉及管理过于“嘈杂”或自身产生过多假正例的检测。
目标：优化嘈杂的规则，而无需将其关闭或创建复杂的排除项。
示例：
将嘈杂的精选检测设置为“仅检测”，使其不再生成提醒。
创建一个复合检测，将该精选规则的输出作为其第一个条件。
添加第二个条件以提供额外的限定条件，例如“仅当同一用户在一小时内发生 5 次此检测时才发出提醒”或“如果此检测与来自其他规则的检测相结合”。
复合检测的工作原理
当规则满足预定义条件时，会生成检测结果。这些检测可以选择包含结果变量，用于捕获特定数据或事件状态。
复合规则会将其他规则的这些检测结果作为其输入的一部分。 评估可以基于原始规则的元部分、结果变量和匹配变量中的信息。
根据此评估，您可以使用复合规则创建新的检测，以用作调查的中间表示，并使用后续规则发出提醒。这有助于关联来自不同检测结果的多个因素，以识别复杂的威胁。
制定策略
在开始创建复合规则之前，请先规划策略，确保新规则有效、高效且能解决正确的问题。
评估当前检测策略。检查现有规则，找出那些过于嘈杂、产生大量假正例或过于复杂且难以管理的规则。
确定复合规则可以发挥价值的具体场景。 这包括检测多阶段攻击、将多个低置信度提醒关联到单个高置信度提醒，或使用来自其他数据源的其他上下文丰富检测结果。
根据评估结果，制定实施计划。确定需要优化哪些干扰规则、需要简化哪些复杂规则，以及需要优先处理哪些新的多阶段检测。
此明确计划为创建有针对性且有效的复合规则提供了路线图。请考虑以下高级策略，以便在管理技术限制的同时，充分利用复合检测。
选择合适的方法
在构建复合检测之前，请考虑是否可以通过其他替代方案实现所需的结果。分析您是否可以使用现有 UEBA 检测来识别复杂模式。检测过于复杂可能会增加维护开销并消耗规则配额。
在以下情况下使用复合检测：您的目标是关联两个或更多个不同的预先存在的规则的最终结果。这会将攻击的概念上不同的阶段连接起来。
示例：将“已下载恶意软件”规则的检测结果与“检测到 C2 信标”规则的后续检测结果相关联。
在以下情况下使用现有 UEBA 检测：您希望发现用户或设备何时打破其正常活动模式。
示例：自动检测到某位用户今天下载了 100 GB 的数据，而其通常只会下载 1 GB。
管理规则配额和风险评分
如需管理组织的资源，请了解不同规则类型如何影响规则配额。
精选规则不计入自定义规则配额。
复合规则和自定义多事件规则会计入您的配额。
您可以将精选检测设置为“仅检测”模式。这样，精选规则就可以执行初始广泛检测，而不会生成提醒。 然后，您可以使用复合规则对这些发现结果应用特定逻辑，从而在战略性管理配额的同时提供更多价值。
了解风险和情境之间的区别
在设计检测逻辑时，请区分评估风险的规则和提供上下文的规则。
风险是指对一组活动的危险程度的评估。针对风险设计的规则通常会汇总多个情境事件或检测结果，以便做出判断。例如，虽然单次登录失败提供了上下文，但大量登录失败则表明存在暴力破解攻击的风险。
背景信息是指与事件相关的真实细节。为上下文设计的规则会使用另一个事件的详细信息来丰富一个事件。例如，虽然规则可以检测到成功的用户登录，但情境规则会提供关键情境，即此登录来自一个新的异常国家/地区。
示例：初始检测可以提醒您注意潜在风险，例如对恶意网域的 DNS 调用。然后，复合规则会将该提醒与 Google SecOps 中的事件日志相关联，以找出启动该调用的特定命令行进程。这为高级别风险提醒提供了关键、可操作的背景信息。
巧妙利用长匹配时间范围
配置了长匹配窗口（例如 14 天）的复合规则执行频率较低。它们的高延迟可能使其不适合用于时效性提醒。考虑使用这些长持续时间窗口来检测长时间内缓慢、持续的对抗活动。
使用检测结果进行可视化
管理干扰规则的一种策略是将其输出转换为信息中心上的可视化图表。此方法不消耗规则配额，并且可以将大量低保真度数据转化为有价值的数据洞见。
通过将规则设置为仅检测，然后在信息中心微件中绘制其检测结果，您可以跟踪趋势、识别离群值，并获得活动的高级审核视图，而不会被单个提醒所淹没。
示例：跟踪个人身份信息数据处理
一条规则会跟踪用户每次处理敏感 PII 数据的行为。
它不会每次都发出提醒，而是设置为仅检测。然后，信息中心微件会显示哪些用户即将达到每日出站流量限额（例如 10,000 字节）。这样可以快速查看风险行为，而不会持续生成提醒。
示例：监控特定的数据泄露防护风险：
微件会汇总来自非常具体的数据泄露防护规则子集的风险评分。这样，特定团队（例如数据泄露防护 [DLP] 管理员）就可以仅监控相关风险，过滤掉来自其他安全网域的干扰。
构建复合检测
以下工作流概述了创建复合规则的典型历程。如需详细了解语法和示例，请参阅复合检测规则和示例。
定义威胁场景：定义您要检测的具体威胁。
创建或识别输入规则：针对威胁场景的每个阶段，创建或识别用于检测特定活动的输入规则。
定义联接条件：确定用于关联输入规则检测结果的共同信息，例如规则标签、变量或检测字段。
构建复合规则：编写规则，以提取输入规则中的检测结果。
定义
events部分，通过名称、ID 或共享元标签引用输入规则。定义
match部分，以指定联接键和匹配的时间范围。定义
condition部分，以设置触发最终提醒必须满足的条件。
测试和部署规则链：我们建议您为序列中的每个规则手动运行追溯搜寻。
对复合规则使用测试规则功能时，该功能仅针对符合规则输入条件的预先存在的检测运行。它不会自动执行底层规则来为测试生成新的输入，这意味着您无法通过单个操作验证整个规则链。
如需针对规则序列运行追溯搜索，请执行以下操作：
从序列中的第一条规则手动启动 Retrohunt。
等待该流水线完成。
继续执行下一条规则。
示例：以下规则提供了一个基本的规则关联模板：
rule Basic_Rule_Correlation_Template {
meta:
description = "Triggers when a user triggers two different rules within X days"
events:
// 1. Identify the first sub-rule detection
$d1.metadata.event_type = "DETECTION" $d1.metadata.rule_name = "INSERT_RULE_NAME_A_HERE" $user = [REDACTED_GENERIC_ID]
// 2. Identify the second sub-rule detection
$d2.metadata.event_type = "DETECTION"
$d2.metadata.rule_name = "INSERT_RULE_NAME_B_HERE"
$user = [REDACTED_GENERIC_ID]
match:
// 3. Connect the rules by the same user over the specified window
$user over 14d
condition:
// 4. Fire when both conditions have occurred
$d1 and $d2
}
示例：以下规则使用事件检测规则和事件图表检查精选检测，并使用了一些高级 YARA-L 函数和变量定义：
rule CheckCuratedDetection_with_EDR_and_EG {
meta:
author = "noone@cymbal.com"
events:
$d.detection.detection.rule_name = /SCC: Custom Modules: Configurable Bad Domain/
$d.detection.collection_elements.references.event.network.dns.questions.name = $domain
$d.detection.collection_elements.references.event.principal.asset.hostname = $hostname
$e.metadata.log_type = "LIMACHARLIE_EDR"
$e.metadata.product_event_type = "NETWORK_CONNECTIONS"
$domain = re.capture($e.principal.process.command_line, "\\s([a-zA-Z0-9.-]+\\.[a-zA-Z0-9.-]+)$")
$hostname = re.capture($e.principal.hostname, "([^.]*)")
$prevalence.graph.metadata.entity_type = "DOMAIN_NAME"
$prevalence.graph.metadata.source_type = "DERIVED_CONTEXT"
$prevalence.graph.entity.hostname = $domain
$prevalence.graph.entity.domain.prevalence.day_count = 10
$prevalence.graph.entity.domain.prevalence.rolling_max <= 5
$prevalence.graph.entity.domain.prevalence.rolling_max > 0
match:
$hostname over 1h
outcome:
$risk_score = 80
$CL_target = array($domain)
condition:
$e and $d and $prevalence
}
查看复合检测发现结果
您可以在检测页面中查看复合检测结果。如果输入列将检测显示为来源，并且检测类型列显示提醒标签且旁边有一个数字（例如 Alert (3)），则该提醒为复合检测。
注意：如果您同时拥有 SIEM 和 SOAR，还可以在案例标签页中查看结果。
优化复合检测
我们建议您在构建复合规则时遵循以下做法。
针对延迟时间进行优化
为了最大限度地缩短检测流水线中的延迟时间，请尽可能使用单事件规则，例如用于初始触发器。复合规则可以使用其检测结果与其他事件、实体或检测结果执行更复杂的相关性分析，这有助于缩短总体延迟时间。
使用高效的方法联接检测结果
我们建议使用结果变量、元标签和匹配变量来联接检测结果。与使用事件样本相比，这些方法可提供更确定、更可靠的结果。元标签特别灵活，因为它们可让您对规则进行分类，以便复合规则可以定位具有该标签的任何检测。
例如，如果多个规则共享相同的元标签 tactic: exfiltration，则您可以创建一个复合规则，该规则以策略标签值为 exfiltration 的任何检测结果为目标。
在复合检测中将 nocase 与联接变量搭配使用时，您可能会收到以下语义分析错误：
semantic analysis: match variable <variable_name> is not assigned to an event field.
在复合检测中，第一个变量赋值（例如 $username = $fact1...）定义变量的属性，包括使用 nocase 时不区分大小写。如果将 nocase 应用于同一联接变量（例如 $username = $fact2...）的后续变量赋值，编译器会将其解释为冲突的重新定义或冗余约束，从而导致语义错误。
使用函数库增强检测
您可以在复合规则中的关键位置使用 YARA-L 函数库，以增强信号并添加更复杂的逻辑。
管理规则更新
当您更新一条或多条复合规则中使用的规则时，系统会自动创建该规则的新版本。复合规则会自动使用新版本。我们建议您测试整个更新后的规则序列，以验证预期行为。
限制
在设计和实现复合检测时，请考虑以下限制：
排除项：请勿将规则排除项直接应用于复合规则。您必须将排除规则应用于构成复合规则的基础底层规则。这是因为系统会根据 UDM 字段（例如
principal.user.userid）评估规则排除项，而复合规则会根据其他检测结果（而非 UDM 字段）触发。如果您直接将规则排除项应用于复合规则，则排除项将无法匹配，并且事件不会被排除。SOAR 案例数据可用性：复合检测无法访问所有 SOAR 案例数据。不支持尝试根据状态（例如
$edetection.feedback_summary.status != "CLOSED"）过滤或排除案例的规则逻辑。复合规则：Google SecOps 支持复合规则的最大深度为 10。深度是指从基本规则到最终复合规则的规则数量。
仅检测规则：匹配窗口期上限为 14 天，每条规则的每日检测上限为 10,000 次。
结果变量：每条规则最多只能包含 20 个结果变量。此外，每个重复的结果变量最多只能有 25 个值。
事件示例：规则中的每个事件变量仅存储 10 个事件示例，例如
$e1存储 10 个，$e2存储 10 个。
如需详细了解检测限制，请参阅检测限制。