Skip to main content

Helo folks,

I’m observing behavior in Google SecOps that seems to deviate from what I expected based on the documentation. I want to see if others have seen it or have insight into what’s happening internally. Below is the scenario, observations, and things I’ve already verified. I’d appreciate thoughts, explanations, or pointers to relevant internal logic.

I ingest a single IOC Entity (e.g. an IP or hash) via a parser, with its metadata and interval.start_time (and without interval.end_time).

Right after ingestion, in Raw Log Search, I see exactly one entity record corresponding to that IOC, as expected.
 



However, when I search using UDM Search over a larger time window (e.g. 1-2 Month), I see many entries (15+), each with different interval.start_time / interval.end_time, as if one entry per day.


You could see on the below attached image, when i clicked on the any entry all of them are getting highlighted which means that all of them refer to the same single entity.
 



This seems inconsistent with the documented 5-day lookback / implicit TTL for entity context in Chronicle.

If anyone has deep knowledge of the entity context graph internals, or has observed similar behavior, I’d be grateful for your insight.

Major Questions :
1. Why is a new entity created each day, even though I ingested the entity only once?
2. How long does an IOC entity remain “live” in Google SecOps?
3. Why do I see inconsistencies (e.g., one entity shows 16 entries while another shows 31 entries)?

Thank you in advance!

If an Entity within the Entity Context Graph (ECG) includes a metadata.threat key, then the +/- 5 day lookback/lookforward is not used, and rather it is the interval.start_time and interval.end_time that are the deciding factor

 

» I ingest a single IOC Entity (e.g. an IP or hash) via a parser, with its metadata and interval.start_time (and without interval.end_time).

 

In effect this IOC will persist forever, and the end time will be set to the year 9999:

 

metadata.interval.start_time = "1970-01-01T00:00:01Z"
metadata.interval.end_time = "9999-12-31T23:59:59Z"

 

There is a slight curve ball in that searching via UDM Search shows the interval and start time of each day (i.e., its calculating is it active on a given 24 hour interval, and showing that), and as you did in your screenshot.  You actually have to use the legacy Raw Log Search to find the original record with the start and end time in the UDM event; however, I do see in your screenshot that the UDM Entity tab did not show, which is annoying (as that means you can’t see it there), but that is the nearest to a source of truth you can get via the UX.

 

The UDM Search and Native Dashboards try to show you what is currently active, and as a result show the interval start and end date as calculated on the fly, but not the actual underlying values which afaict you can only see in the legacy raw log search.

 

I had a quick look and couldn’t see that the ExtraHop RevealX parser outputs IOCs so am curious if this was custom?  (else I could have missed the parser code that generated an IOC)

 

 


@cmmartin_google
Thank you for the insightful clarification.

Upon reviewing the behavior and considering the details shared, it appears that the observed multiple entries for a single IOC entity in UDM Search are expected and align with the platform's design. Specifically, when an entity includes a metadata.threat field, the standard ±5-day lookback/lookforward logic does not apply. Instead, the entity's interval is effectively open-ended, with:

metadata.interval.start_time = "1970-01-01T00:00:01Z"
metadata.interval.end_time = "9999-12-31T23:59:59Z"

Consequently, the entity persists indefinitely in the Entity Context Graph. UDM Search calculates daily active intervals dynamically for visualization, leading to multiple entries even though it's logically a single entity. This behavior is consistent with the platform's handling of Indicator of Compromise (IOC) entities, which are designed to persist beyond the standard lookback window to ensure comprehensive threat detection.

Thank you again for the detailed insight!