Tenzir Udm

Google UDM

Google UDM (Unified Data Model) is the Google SecOps data model for normalized security telemetry. It represents events and entities as common records so logs from different products can describe actors, assets, resources, network activity, security outcomes, and product context with consistent field names and enum values.

Use this skill for two primary workflows: mapping logs into UDM event or entity objects for Google SecOps UDM API ingestion, and referencing UDM fields in YARA-L, Detect Engine, CBN, or other dotted field-path contexts. It also answers which event or entity type to choose, which fields to populate, and how Google expects values to be formatted.

Nomenclature

Google's UDM documentation is derived from protobuf terminology. Users may ask about UDM messages, sub-messages, oneofs, repeated fields, or objects. Treat those as equivalent to the data-centric terms used by this skill:

When a user uses Google UDM terminology, translate it to the skill term while preserving the original UDM meaning. For example, a question about the SecurityResult message should route to the SecurityResult record, and a question about a oneof should route to a union in the YAML.

Field Name Forms

Record YAML files use field keys as the dotted field-path form. When Google SecOps ingestion uses a different field name, the field record adds an ingestion_name value:

event_type: { ingestion_name: eventType, ... }

Use the YAML field key for field names in YARA-L, Detect Engine, CBN, and other dotted field-path contexts. Keep the root and prefix required by that context, for example $event.metadata.event_type. Use ingestion_name when mapping logs into UDM event or entity records for Google SecOps UDM API ingestion, for example metadata.eventType. If ingestion_name is absent, both contexts use the YAML field key.

Current irregular mappings:

• EntityRisk.DEPRECATED_risk_score / EntityRisk.DEPRECATEDRiskScore

Top-level Records

UDM uses two top-level data shapes: event records for telemetry and entity records for contextual objects such as users, assets, domains, files, URLs, and IP addresses.

The event ingestion path imports UDM events. Entity records are ingested as entity context through the entity ingestion path.

Event

Entity

Question routing

When a question asks for modeling guidance, read both layers. Event, entity, and record guidance explains how Google says to populate the data; record YAML leaves show the exact fields. If they differ, state both facts instead of silently reconciling them.

Domain knowledge

• UDM events center on metadata, participant nouns (principal, src, target, intermediary, observer, about), security_result / securityResult, network, and extensions.
• UDM entities center on metadata, an entity noun, relations, optional risk_score / riskScore, and optional metric data.
• metadata.event_type / metadata.eventType classifies the event. It is the first place to look when deciding how an event should be represented.
• metadata.entity_type / metadata.entityType classifies entity records and drives entity-specific requirements.
• Noun carries entity details such as users, assets, processes, files, resources, cloud context, and labels.