clarification on UDM enrichment

Question

I would like to clarify one point regarding context enrichment in Google SecOps.

Currently, our logs are already ingested and enriched with Azure AD context in UDM fields. As I understand, if we update Azure AD context, SecOps will ingest the updated data into the entity context, and future logs will use this updated information for enrichment.

However, I would like to confirm what happens to the previously ingested logs that were already enriched using the older context. Will those historical logs get updated automatically, or will they retain the past original enrichment values.

Example 1:

A user’s location was initially enriched as:

City = Chennai
Country = US

Later, the information was corrected to:

Country = India

In this scenario, if historical correlation is used, earlier events may continue to reflect the previously enriched country value (US), even after the correction has been made.

cmorris · Accepted Answer

Enrichment is point in time. If the context data is updated, future events will use the new data, but old events will not.

If new enrichment values updated historical records, we could have a scenario, where a user transfers from the IT Operations department to the Marketing department.

March 1st: While in IT Operations, the user logs into a restricted database to perform routine maintenance within the scope of their role.

March 15th: User transfers to Marketing. Their Azure AD context is updated, and their access to the database is revoked.

April 1st: A security analyst is doing a routine historical audit of database access.

In this scenario, if the historical log was updated to the new context:
The analyst looks at the March 1st log, which now reads: User | Department: Marketing | Action: Accessed Critical Database resulting in an incident for something that was previously in the scope of their former role.

Similar scenarios would be applicable for changing updating geolocation information related to an IP address as another example.

Mahesh1313 · Answer

Hi everyone,I am looking for some best-practice guidance on how to handle historical data quality corrections within Google SecOps (Chronicle), specifically regarding user entity context (like Department, Employee ID, and Country) used for downstream analytics and reporting.To illustrate the challenge, I have two distinct scenarios:Scenario 1: Legitimate Lifecycle Change (Working as Expected)A user works in the Service Desk in January 2026 and transitions to the Cybersecurity team in March 2026. Google SecOps handles this historical correlation perfectly. If I look at historical logs from January, the entity graph correctly shows "Service Desk." From March onwards, it shows "Cybersecurity." This is correct and intended.Scenario 2: Data Quality Error (The Problem)An admin mistakenly enters the wrong Department, Employee ID, or Country (e.g., entering "US" instead of "India") in Active Directory for a group of users. This incorrect data is ingested into SecOps for months. If we fix AD today, SecOps treats it like Scenario 1—it updates their status from today forward, but leaves the historical context for the past months corrupted with the wrong information.Because we rely heavily on this data for security analytics, compliance reporting, and dashboards, we need a way to correct that past timeline so our historical reports reflect the actual truth, not the data entry error.My questions for the community:What is the recommended method to fix bulk historical entity data for analytics purposes?Is it better to handle this at the analytics layer in BigQuery by creating a manual "Correction Map" table and merging it via a SQL View using COALESCE?Alternatively, is it safe/recommended to ingest a bulk JSON/CSV entity file via the Ingestion API while explicitly backdating the collected_timestamp or event_timestamp to overwrite the historical entity window? Are there lookback limits we should be aware of?Would love to hear from anyone who has tackled bulk identity data cleanups or from the Google product team on the preferred architecture for this.Thank you in advance for your insights!

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded