Security teams rarely receive telemetry in a consistent format. An endpoint platform may describe a process differently from a firewall, an identity provider may represent a login differently from a cloud platform, and each vendor can use its own field names, event types, timestamps, and terminology.
UDM, or Unified Data Model, is the normalization layer that gives Google SecOps a consistent way to represent security events. Instead of forcing analysts and detection rules to understand every vendor’s native log format, Google SecOps maps incoming telemetry into a common security-oriented structure.
This is more than simply renaming fields. UDM provides context about what happened, when it happened, which entities were involved, and what role each entity played in the event. That distinction is what makes UDM particularly important for investigation and detection engineering.
Why Google SecOps needs UDM
Imagine an organization receives authentication logs from several identity systems.
One source might call a username user, another might use account_name, while another uses principal. Their event names could also differ.
For an analyst, however, the underlying security question is much simpler:
Did a user authenticate, from where, against what system, and was the attempt successful?
UDM provides a common vocabulary for expressing that information.
This has several practical consequences:
- Analysts can investigate similar activity across different products using consistent field concepts.
- Detection rules can operate against normalized fields instead of being tightly coupled to a particular vendor’s terminology.
- Relationships between users, hosts, IP addresses, applications and other entities become easier to investigate.
- New data sources can fit into an existing analytical model rather than requiring every investigation workflow to understand another proprietary schema.
UDM is a schema, not a log source
A common misconception is that UDM is another security product or a separate telemetry source.
It isn’t.
UDM is the structure into which security telemetry is normalized.
A simplified data flow looks like this:
Security source → raw log → parser/normalization → UDM event → search/detection/investigation
For supported log types, a parser transforms the raw event into UDM. Organizations can also send data that has already been transformed into UDM.
This distinction matters when troubleshooting data.
If a log is visible in its original form but an expected UDM field is empty or incorrect, the problem may not be ingestion itself. It may instead be a normalization or field-mapping problem.
That is one of the most useful ways to think about UDM operationally: it creates a boundary between what the source said and how Google SecOps understands what the source said.
How a UDM event is organized
A UDM event is composed of sections rather than being one enormous flat collection of unrelated fields.
Common sections include:
metadataprincipaltargetsrcobserverintermediaryaboutnetworksecurity_resultextensions
Not every event needs every section. Google SecOps uses the portions relevant to the particular event, which allows the model to represent very different kinds of telemetry without requiring every record to contain the same populated fields.
This is an important design characteristic. An endpoint process event and a network communication event have very different information requirements, but both can live inside the same overarching model.
Metadata: the identity of the event
The metadata section provides the event’s fundamental context.
Among its important fields are:
metadata.event_timestamp— when the underlying event occurred.metadata.ingested_timestamp— when Google SecOps received the event.metadata.event_type— the normalized type of activity.metadata.vendor_name— the vendor associated with the source.metadata.product_name— the product that generated the event.metadata.product_event_type— the source product’s description of the event.
The distinction between event time and ingestion time is especially important during investigations. A security event can occur at one point in time and arrive in the platform later. Treating those timestamps as interchangeable can produce misleading investigation timelines.
The most important concept: event type
metadata.event_type is arguably the conceptual center of UDM.
Rather than asking which vendor generated a log, UDM asks what kind of security activity the event represents.
For example, an authentication event can be represented as USER_LOGIN, regardless of the terminology originally used by the underlying product.
The event type therefore gives detection logic a normalized description of the activity itself, rather than merely describing the syntax of the source log.
This leads to a useful detection-engineering principle:
Choosing the correct UDM event type is not just classification; it determines how the rest of the event should be interpreted.
Principal, source and target: understanding roles
Another powerful feature of UDM is that it describes entities according to their role in an event.
principal generally represents the entity originating the activity.
src represents a source entity involved in the activity, while target represents the entity being acted upon.
intermediary can represent systems through which the activity passes, such as a proxy or relay, while observer can represent a system that passively observes the activity.
This role-based approach is more useful than simply collecting IP addresses.
Consider a connection involving:
User → workstation → proxy → destination server
The same IP address can mean very different things depending on where it appears in an event. UDM attempts to preserve that contextual meaning.
That makes investigations more expressive because analysts can ask questions about relationships and roles, not merely matching strings.
Network and security-result information
The network section contains information associated with network activity, including communication and HTTP-related information.
The security_result section serves a different purpose. It represents a security product’s assessment or action associated with an event—for example, a detection, classification or response from an antivirus or another security control.
Keeping these concepts separate helps distinguish:
what happened on the system or network
from
what a security product concluded about what happened.
That distinction becomes particularly valuable when multiple security products observe the same underlying activity.
Extensions preserve information that does not fit neatly
Normalization inevitably creates a tension.
A common schema needs consistency, but security products continually introduce product-specific information.
UDM addresses this through areas such as extensions and additional vendor-specific data. The extensions structure can accommodate information that is not represented by the standard sections.
This is important because normalization does not mean throwing away everything unusual.
A well-designed normalized event can expose fields that matter across many products through standard UDM locations while retaining useful product-specific information where a universal field does not make sense.
How raw logs become UDM
Parsers perform much of the practical translation between a source log and UDM.
Suppose a source produces an authentication message containing a timestamp, username, source address and result. A parser has to determine where those values belong in the UDM representation.
Conceptually, the mapping might look like:
source username → UDM user field
source timestamp → metadata.event_timestamp
source activity → metadata.event_type
source result → security_result
The difficult part is not extracting strings. The difficult part is assigning the correct meaning and role to those strings.
A parser that extracts a username but puts it into the wrong entity context can produce an event that technically contains data but is analytically misleading.
This is why UDM quality should be evaluated semantically, not simply by asking whether fields are populated.
UDM and detection rules
UDM is closely connected to Google SecOps detection engineering.
Because detection logic can reference normalized UDM fields, a rule can describe a security behavior without reproducing every vendor’s original field names.
For example, conceptually, a detection might look for:
a user login + an unusual source + a particular authentication result
rather than separately implementing the same logic for every identity product.
This also explains why parser quality directly affects detection quality.
A detection rule cannot reliably identify a behavior if the underlying events have been normalized incorrectly or if important source information has been mapped to inappropriate UDM fields.
UDM is also an investigation model
UDM is sometimes explained primarily as a way to make searches easier. That is true, but incomplete.
Its larger value is that it creates a shared representation of security activity.
During an investigation, an analyst may move from:
- an IP address,
- to a host,
- to a user,
- to a process,
- to a network connection,
- to a security alert.
The usefulness of these pivots depends on the platform consistently representing the entities and relationships involved.
UDM provides the structure that makes those pivots possible.
This is one reason normalized data can be considerably more useful than simply having a huge collection of raw logs. Raw telemetry tells you what individual products recorded. A normalized model makes it easier to reason across those observations.
A practical way to think about UDM
A useful mental model is to treat UDM as a translation layer between vendor language and security language.
A firewall might speak in terms of connection records.
An endpoint product might speak in terms of processes.
An identity provider might speak in terms of authentication events.
A cloud service might speak in terms of API operations.
UDM attempts to express those observations through a common security vocabulary while preserving the source context.
The result is not necessarily that every event becomes identical. Instead, events that share meaningful concepts become comparable.
That distinction is critical.
UDM does not erase differences between security products. It makes those differences manageable.
What UDM means for security teams
For security engineers, UDM changes how data should be approached.
Instead of asking only:
“What field does this vendor use for the username?”
a better question is:
“What entity is the username describing, and what role does that entity have in this event?”
Instead of asking:
“What does this product call a login?”
ask:
“What UDM event type correctly represents the activity?”
And instead of assuming that a populated field means successful normalization, examine whether its location, role, timestamp and semantics are correct.
That mindset produces better parsers, more portable detections and more reliable investigations.
The deeper value of UDM
The most important benefit of UDM is not the size of its field library. It is the abstraction it provides.
Security operations deal with an enormous variety of technologies, but many investigations repeatedly revolve around a smaller set of questions:
Who acted? What acted? What happened? Where did it happen? What was affected? When did it happen? What security control observed or concluded about it?
UDM provides a structured vocabulary for answering those questions.
It therefore sits at the heart of the Google SecOps analytical workflow: raw telemetry supplies the evidence, normalization gives that evidence consistent meaning, and search and detection capabilities operate on the normalized representation.
The practical lesson is simple: when working with Google SecOps, UDM should not be viewed merely as a schema to memorize. It should be understood as the semantic layer that turns heterogeneous security telemetry into data that can be searched, correlated, detected on and investigated consistently.
That is ultimately what makes UDM valuable: it helps security teams spend less effort translating between products and more effort understanding the activity those products collectively observed.