丰富
丰富化功能使用以下方法为统一数据模型 (UDM) 指标或事件添加情境：
- 用于标识描述指标（通常是 UDM 字段）的别名实体。
- 使用已识别的别名或实体的其他详细信息填充 UDM 消息。
- 向 UDM 事件添加了全局丰富数据，例如 GeoIP 和 VirusTotal。
了解丰富逻辑模式
Google SecOps 会根据丰富类型对数据应用不同的逻辑模式。您可以使用下表了解这些模式，以便进行问题排查，并说明某些字段为何会填充、合并或覆盖。
| 逻辑模式 | 说明 | 适用的扩充项 |
|---|---|---|
| 首次匹配 | 遵循严格的优先级列表。流水线仅查询序列中找到的第一个可用值。 | 制品（文件哈希值） |
| 已合并 | 同时从多个字段收集和合并数据，以构建单个“黄金”实体记录。 | 资产、用户 |
| 有条件的后备 | 仅当缺少优先级更高的标识符时，才会使用特定字段进行丰富。 | 资产（ip 地址） |
| 映射和覆盖 | 使用唯一 ID (PSPI) 来解析实体。来自丰富来源的别名数据会替换现有的已解析数据。 |
流程 |
素材资源丰富化
对于资产丰富，流水线会通过评估多个 UDM 字段来识别唯一资产。与选择一个 ID 的制品丰富化不同，资产丰富化会合并来自多个 ID 的上下文，以构建完整的资产资料。
Google SecOps 会丰富归类为同一命名空间的资产事件。
对于资源，逻辑是累积的，而不是排他的，除非在特定的回退场景中。使用以下详细信息进行说明：
- 逻辑类型：合并或回退。除非满足回退条件（例如
asset_id检查），否则流水线会从所有可用字段收集数据，以创建单个“实体”视图。 - 字段映射：
- 主机名、MAC 和
asset_id：被视为主要 ID。来自所有这些字段的别名化结果会合并在一起，以生成最终的丰富型媒体资源个人资料。 - IP 地址：仅当
asset_id不可用时才包含在丰富查询中。
- 主机名、MAC 和
对于每个资产事件，流水线会从 principal、src 和 target 实体中提取以下 UDM 字段：
| UDM 字段 | 指示器类型 | 逻辑 / 优先顺序 |
|---|---|---|
hostname |
HOSTNAME | 合并：这些字段的别名结果会合并，以生成最终的丰富型素材资源记录。 |
asset_id |
PRODUCT_SPECIFIC_ID | 合并：用于整合资产上下文的主要标识符。 |
mac |
MAC | 合并：与其他标识符结合使用，以解析相应资产。 |
ip |
IP | 后备：仅当 asset_id 不可用时，才包含在丰富查询中。 |
用户丰富化
用户丰富功能通过查找特定标识符来解析身份数据。与制品丰富类似，此流水线使用偏好顺序来确定哪个标识符用作查找的主键。
对于每个用户事件，流水线会从 principal、src 和 target 中提取以下 UDM 字段：
| UDM 字段 | 指示器类型 | 逻辑或优先顺序 |
|---|---|---|
user.email_addresses |
电子邮件 | 最高优先级：管道首先尝试根据用户的主电子邮件地址或辅助电子邮件地址进行丰富。 |
user.windows_sid |
WINDOWS_SID | 第二优先级：如果没有电子邮件地址，流水线会使用 Windows 安全标识符 (SID)。 |
user.userid |
USER_ID | 第三优先级：仅在缺少电子邮件地址和 SID 时使用；通常映射到本地 ID 或应用专用 ID。 |
user.employee_id |
EMPLOYEE_ID | 最低优先级：用于解析用户身份的最终后备方案。 |
对于每个指标，流水线都会执行以下操作：
- 检索用户实体的列表。例如，
principal.email_address和principal.userid的实体可能相同，也可能不同。 - 使用以下优先级顺序从最高优先级的指示器类型中选择别名：
WINDOWS_SID、EMAIL、USERNAME、EMPLOYEE_ID和PRODUCT_OBJECT_ID。 - 使用有效性时间区间与事件时间相交的实体填充
noun.user。
流程丰富化
流程丰富化侧重于提供执行事件的可见性。 该流水线会提取进程详细信息，并通过交叉引用文件信誉和父子关系来丰富这些信息。
使用进程丰富功能将产品特定的进程 ID (product_specific_process_id)（即 PSPI）映射到实际进程，并检索有关父进程的详细信息。此流程依赖于 EDR 事件批处理类型。
| UDM 实体 | 字段来源 | 逻辑或优先级 |
|---|---|---|
| 主要实体 |
principal、src、target
|
提取：流水线从这些顶级实体中提取 PSPI，以启动查找。 |
| 父进程 |
principal.process.parent_process、src.process.parent_process、target.process.parent_process
|
映射：PSPI 通过进程别名检索有关父级进程的详细信息。 |
| 数据合并 |
noun.process（例如，principal.process）
|
覆盖规则：别名化字段具有绝对优先级。如果同一字段同时存在已解析的数据和别名数据，流水线会将已解析的数据替换为别名数据。 |
该流水线使用进程别名来识别 PSPI 中的实际进程，并检索有关父进程的信息。然后，将此数据合并到丰富消息中的相应 noun.process 字段中。
用于进程别名的 EDR 编入索引字段
当进程启动时，系统会收集元数据（例如，命令行、文件哈希和父进程详细信息）。在机器上运行的 EDR 软件会分配一个供应商专属的进程 UUID。
下表列出了在进程启动事件期间编入索引的字段：
| UDM 字段 | 指示器类型 |
|---|---|
| target.product_specific_process_id | PROCESS_ID |
| target.process | 整个流程；不仅仅是指标 |
除了标准化事件中的 target.process 字段之外，Google SecOps 还会收集父进程信息并将其编入索引。
制品丰富化
制品丰富化会添加来自 VirusTotal 的文件哈希元数据和 IP 地址的地理定位数据。对于文件哈希，流水线会在优先级列表中找到第一个值时停止；不过，对于 IP 地址，它会并行处理所有条目。对于每个 UDM 事件，流水线都会从 principal、src 和 target 实体中提取并查询以下制品指标的上下文数据，其中富集行为因指标类型而异：
| 指示器类型 | 提取逻辑 | 运算符优先级 / 运算顺序 |
|---|---|---|
| 文件哈希值 | 首次匹配 |
流水线会按以下顺序搜索哈希，并仅选择第一个可用于查询 VirusTotal 的哈希：
|
| IP 地址 | 并行（重复） | 每个公共 IP 地址或可路由的 IP 地址都被视为一个独立的条目。没有偏好顺序；每个 IP 都会获得自己的丰富化结果。 |
流水线使用 UNIX 纪元和事件小时来定义文件制品查询的时间范围。如果地理定位数据可用，流水线会根据地理定位数据的来源，覆盖 principal、src 和 target 实体的以下 UDM 字段：
artifact.ipartifact.locationartifact.network（仅当数据包含 IP 网络上下文时）location（仅当原始数据不包含此字段时）
如果流水线找到文件哈希元数据，则会将该元数据添加到文件或 process.file 字段中，具体取决于指示器的来源。流水线会保留与新数据不重叠的所有现有值。
IP 地理定位丰富化
地理位置别名可为外部 IP 地址提供地理定位数据。对于 UDM 事件的 principal、target 或 src 字段中的每个非别名化 IP 地址，系统都会创建一个 ip_geo_artifact 子协议缓冲区，其中包含关联的位置和 ASN 信息。
地理位置别名不使用回溯或缓存。由于事件数量众多，Google SecOps 会在内存中维护索引。
使用 VirusTotal 文件元数据丰富事件
Google SecOps 可将文件哈希丰富为 UDM 事件，并在调查期间提供更多背景信息。哈希别名通过合并所有类型的文件哈希来丰富 UDM 事件，并在搜索期间提供有关文件哈希的信息。
Google SecOps 集成了 VirusTotal 文件元数据和关系丰富功能，可用于识别恶意活动模式并跟踪恶意软件在网络中的移动。
原始日志提供的文件信息有限。VirusTotal 会使用文件元数据（包括有关恶意哈希和文件的详细信息）来丰富事件。元数据包括文件名、类型、导入的函数和标记等信息。您可以在 UDM 搜索和检测引擎中使用 YARA-L 来了解恶意文件事件，并在威胁搜寻期间使用这些信息。例如，您可以检测对原始文件的修改，这些修改使用文件元数据进行威胁检测。
记录中会存储以下信息。 如需查看所有 UDM 字段的列表，请参阅统一数据模型字段列表。
| 数据类型 | UDM 字段 |
|---|---|
| sha-256 | ( principal | target | src | observer ).file.sha256 |
| md5 | ( principal | target | src | observer ).file.md5 |
| sha-1 | ( principal | target | src | observer ).file.sha1 |
| 大小 | ( principal | target | src | observer ).file.size |
| ssdeep | ( principal | target | src | observer ).file.ssdeep |
| vhash | ( principal | target | src | observer ).file.vhash |
| authentihash | ( principal | target | src | observer ).file.authentihash |
| PE 文件元数据 Imphash | ( principal | target | src | observer ).file.pe_file.imphash |
| security_result.threat_verdict | ( principal | target | src | observer ).(process | file).security_result.threat_verdict |
| security_result.severity | ( principal | target | src | observer ).(process | file).security_result.severity |
| last_modification_time | ( principal | target | src | observer ).file.last_modification_time |
| first_seen_time | ( principal | target | src | observer ).file.first_seen_time |
| last_seen_time | ( principal | target | src | observer ).file.last_seen_time |
| last_analysis_time | ( principal | target | src | observer ).file.last_analysis_time |
| exif_info.original_file | ( principal | target | src | observer ).file.exif_info.original_file |
| exif_info.product | ( principal | target | src | observer ).file.exif_info.product |
| exif_info.company | ( principal | target | src | observer ).file.exif_info.company |
| exif_info.file_description | ( principal | target | src | observer ).file.exif_info.file_description |
| signature_info.codesign.id | ( principal | target | src | observer ).file.signature_info.codesign.id |
| signature_info.sigcheck.verfied | ( principal | target | src | observer ).file.signature_info.sigcheck.verified |
| signature_info.sigcheck.verification_message | ( principal | target | src | observer ).file.signature_info.sigcheck.verification_message |
| signature_info.sigcheck.signers.name | ( principal | target | src | observer ).file.signature_info.sigcheck.signers.name |
| signature_info.sigcheck.status | ( principal | target | src | observer ).file.signature_info.sigcheck.signers.status |
| signature_info.sigcheck.valid_usage | ( principal | target | src | observer ).file.signature_info.sigcheck.signers.valid_usage |
| signature_info.sigcheck.cert_issuer | ( principal | target | src | observer ).file.signature_info.sigcheck.signers.cert_issuer |
| file_type | ( principal | target | src | observer ).file.file_type |
排查丰富化问题
如果您发现某个 UDM 事件缺少预期的丰富数据，请使用以下建议来帮助解决问题。
一般丰富化
如果您的部分事件未得到任何扩充，很可能是因为 Google SecOps 优先考虑的是传送速度。在第一次传递期间，可能会有少量事件（不到 1%）跳过丰富化。如需解决此问题，请过几分钟后再来查看。系统会自动重新处理这些事件。如果一个小时后仍未看到富化数据，请验证日志源是否已正确解析为 UDM。
制品丰富化（首次匹配逻辑）
如果您的事件同时具有 MD5 和 SHA256 哈希，但您只能看到 SHA256 的 VirusTotal 元数据，这是首次匹配逻辑。流水线在找到优先级最高的哈希 (sha256) 后立即停止。如果存在 SHA256，则不会查询 VirusTotal 的 MD5。
如果您看到 principal.ip 的地理定位，但没有看到 target.ip 的地理定位，则并行逻辑会单独处理每个 IP。如果一个 IP 是内部或专用 IP（不可路由），而另一个是公共 IP，则只有公共 IP 会接收地理定位丰富信息。
素材资源扩充（合并和回退逻辑）
如果 IP 地址字段未显示资产的丰富数据，则表示它是条件回退逻辑。仅当缺少 asset_id (PSID) 时，IP 才会用于丰富查询。如果存在 asset_id，系统会依赖该 asset_id，并忽略相应特定查询的 IP，以防止出现冗余或冲突的数据。
用户丰富（偏好顺序）
如果 Department 字段显示 "IT"，而本地日志显示 "Security"，则表示用户丰富功能偏好于已解析的字段，而不是别名化的字段。如果您的原始日志已通过 "IT" 进行解析，则富集流水线不会使用身份源（例如 Okta 或 AD）中的 "Security" 值覆盖该值。
流程丰富化（映射和覆盖）
如果您在原始日志中看到某个进程名称，但在 UDM 搜索中，该名称被替换为其他名称，则表示存在覆盖逻辑。流程丰富化会优先处理别名化字段。如果 PSPI 查找从 EDR 上下文中返回了更准确的进程名称，则会完全替换原始解析值。
后续步骤
如需了解如何将丰富的数据与其他 Google SecOps 功能搭配使用，请参阅以下内容：
需要更多帮助？获得社区成员和 Google SecOps 专业人士的解答。