情境感知分析概览
借助 Google Security Operations,您可以将遥测、实体情境、关系和漏洞作为 Google Security Operations 账号中的单个检测来查看。它提供了实体情境化,以便您能够了解遥测中的行为模式以及这些模式中受影响实体的情境。
示例:
- 显示尝试以暴力破解的方式登录的账号的权限。
- 由资产托管的数据的重要性,该资产也是出站网络活动的来源。
客户可以使用此情境化来进行检测过滤、启发式提醒优先级排序、分类和调查。
安全分析师和检测工程师通常会根据事件遥测(出站网络连接)的基本模式进行检测,从而创建大量检测结果,以便分析师进行分类。分析师会尝试将触发提醒的原因与威胁的严重性结合起来考虑。
情境感知分析在检测编写和执行工作流中整合了高级的增强功能,使您能够提供以下附加功能:
- 在检测执行时(而不是在人工分类阶段)提供相关情境,以对检测进行启发式情境风险评分
- 减少从不同的 IT 安全系统(EDR 控制台、防火墙/代理日志、CMDB 和 IAM 上下文、漏洞扫描结果)中分类和手动拼接信息的时间
- 使分析师和检测工程师能够过滤出全部的威胁集群,这些威胁可能会对企业构成极小风险或无风险(例如,沙盒环境中的恶意软件测试、没有敏感数据或访问的开发网络中的漏洞和异常活动,等等)
编写用于情境感知分析的规则
您可以使用检测引擎规则在您的 Google Security Operations 账号中搜索实体上下文数据。
如需搜索实体情境数据,请完成以下操作:
使用 udm 或实体指定来源。
$eventname.[<source>].field1.field2
对于实体情境,<source> 为“graph”。对于 UDM 事件,<source> 为“udm”。如果省略该项,则 <source> 默认为 udm。指定实体数据:
$e1.graph.entity.hostname = "my-hostname"
$e1.graph.entity.relations.relationship = "OWNS"
指定 UDM 事件数据。以下语句是等效的。
$e1.udm.principal.asset_id = "my_asset_id"
$e1.principal.asset_id = "my_asset_id"
您可以为实体情境创建许多与 UDM 事件相同类型的规则,其中包括:
多事件规则
将实体情境与其他实体情境进行比较
将实体情境与 UDM 事件进行比较
实体情境中的重复字段
滑动窗口
计算检测的风险评分
与 UDM 事件不同,实体情境没有特定的时间戳。每个实体情境记录都有一个时间间隔(entity.metadata.interval),实体情境在此时间间隔内有效。此时间间隔不必是一天的边界,可以是任意时段。
只有当 UDM 事件的时间戳在实体情境记录的时间间隔内时,UDM 事件才会与实体情境记录相关联。如果不满足此条件,系统将不会评估 UDM 和实体 检测。Detection Engine 会隐式强制执行此操作,您无需在规则中将其指定为条件。
- 利用窗口化将 UDM 事件与实体情境进行比较时,实体情境代表指定窗口内的常量值。
- 如果存在相邻日期的存储桶并且其中的实体情境会更改其值,则 Google 安全运营团队会尝试匹配所有实体情境值,并返回找到的所有匹配项。
示例规则
搜索具有管理员情境的实体
以下规则会搜索与管理员权限相关联的实体。它会查找有管理员权限的用户尝试登录或退出系统的时间。
rule LoginLogout {
meta:
events:
($log_inout.metadata.event_type = "USER_LOGIN" or $log_inout.metadata.event_type = "USER_LOGOUT")
$log_inout.principal.user.user_display_name = $user
$context.graph.entity.user.user_display_name = $user
$context.graph.entity.resource.attribute.roles.type = "ADMINISTRATOR"
match:
$user over 2m
condition:
$log_inout and $context
}
滑动窗口示例
以下滑动窗口示例有效。
rule Detection {
meta:
events:
$e1.graph.entity.hostname = $host
$e2.udm.principal.hostname = $host
match:
// Using e2 (a UDM event) as a pivot.
$host over 3h after $e2
condition:
$e1 and $e2
}
无效滑动窗口示例
以下滑动窗口示例无效。实体情境不能用作滑动窗口的数据透视表。
rule Detection {
meta:
events:
$e1.graph.entity.hostname = $host
$e2.udm.principal.hostname = $host
match:
// Attempting to use $e1 (an entity context) as a pivot. Invalid.
$host over 3h after $e1
condition:
$e1 and $e2
}
使用结果部分的登录示例
以下示例使用 outcome
部分计算检测的风险评分。
rule Detection {
meta:
events:
$auth.metadata.event_type = "USER_LOGIN"
$auth.metadata.vendor_name = "Acme"
$auth.metadata.product_name = "Acme SSO"
$auth.target.user.userid = $user
$auth.target.user.termination_date.seconds > 0
$auth.metadata.event_timestamp.seconds >
$context.graph.entity.user.termination_date.seconds
$context.graph.metadata.vendor_name = "Microsoft"
$context.graph.metadata.product_name = "Azure Active Directory"
$context.graph.metadata.entity_type = "USER"
$context.graph.entity.user.userid = $user
$context.graph.entity.user.termination_date.seconds > 0
match:
$user over 15m
outcome:
$risk_score = max(
if ( $auth.metadata.event_type = "USER_LOGIN", 50) +
if (
$context.graph.entity.user.title = "Remote" nocase or
$context.graph.entity.user.title = "Temp" nocase or
$context.graph.entity.user.title = "Vendor" nocase, 40) +
if ( $context.graph.entity.user.title = "Legal" nocase, 10)
)
condition:
$auth and $context
}
可疑进程启动示例
以下示例根据存储为实体情境的 IOC 情境数据评估 UDM 事件进程数据。
rule ProcessLaunch {
meta:
events:
$ioc.graph.metadata.vendor_name = "ACME"
$ioc.graph.metadata.product_name = "IOCs"
$ioc.graph.metadata.entity_type = "FILE"
$ioc.graph.entity.file.sha256 = $hash
$process.metadata.event_type = "PROCESS_LAUNCH"
$process.principal.hostname = $hostname
(
not $process.target.process.file.sha256 = "" and
$process.target.process.file.sha256 = $hash
)
match:
$hash over 15m
condition:
$ioc and $process
}
实体情境的其他限定符
如需创建使用实体情境的事件变量,必须在事件名称后提供 <source>
。<source>
必须是 graph
。
以下模式会引用实体情境:
$e.graph.entity.hostname
请注意,您可以通过两种等效的方法来引用 UDM 事件:
$u.udm.principal.asset_id
$u.principal.asset_id
您可以在规则文本中混搭使用所有这些限定符。您也可以对同一事件使用不同的限定符。
结果部分
Detection Engine 支持 outcome
部分,可让您从规则中获取更多信息。系统会针对每个检测对 outcome
部分中定义的逻辑求值。如果规则生成了 N 个检测,则这 N 个检测中的每个检测都可能会导致不同的结果集。
您可以在此处找到使用 outcome
部分的示例规则。
有关 outcome
部分的详细用法和语法,请参阅本部分。
结果部分和检测重复信息删除 / 检测分组
对于具有匹配部分的规则,回想一下可以发现,检测结果按匹配变量进行分组。这会删除重复的检测信息,以便仅匹配一行 返回的值。
执行重复信息删除时,结果变量会被忽略。因此,如果两个不同的检测发现匹配变量和时间窗口具有相同的值,但结果变量的值不同,那么这两个检测将被执行重复信息删除,您将只能看到一个检测。例如,如果因数据延迟到达而创建了检测,可能会发生这种情况。以下示例说明了这种情况。
rule ExampleOutcomeRule {
...
match:
$hostname over <some window>
outcome:
$risk_score = <some logic here>
...
}
此规则会产生以下匹配:
检测 1: 主机名:test-hostname 时间窗口:[t1, t2] risk_score:10
检测 2: 主机名:test-hostname 时间窗口:[t1, t2] risk_score:73
由于检测 1 和检测 2 的匹配变量和时间窗口相同,将会被执行重复信息删除,并且即使结果变量 risk_score 不同,您也只会看到一个检测。
后续步骤
如需了解 Google Security Operations 如何提取情境数据并丰富实体,请参阅 Google Security Operations 如何丰富事件和实体数据