Step-by-step: Creating a custom asset inventory from our ingested logs.

Oh yeah, that alert loop is a classic pitfall. We had the same issue! We fixed it by adding a cooldown period in the alert rule itself - so even if the timestamp updates, the alert can't retrigger for, say, 24 hours. It's not perfect, but it breaks the cycle.

Makes you wonder if the whole system is just tattling on itself half the time 😅

Absolutely, USER_LOGIN events are a key source for ownership mapping, especially in ephemeral environments. We run the inventory update query daily, but it's a two-stage process - the initial broad ENTITY query, followed by targeted raw log pulls for high-value or stale assets identified from the first pass.

That frequency is a compromise between freshness and API cost. For purely ephemeral cloud assets, even daily can miss the lifecycle, which is where those targeted real-time queries come in, as others have mentioned.

Focusing on the UDM fields you've listed is the correct starting point, but you're going to run into a key limitation: those `PROCESS_LAUNCH` and `NETWORK_CONNECTION` event types are not universally populated across all log sources. They are specific to certain EDR and network telemetry. Your cloud audit logs, for instance, will likely not populate them, creating a blind spot.

You need to explicitly add `metadata.vendor_name` and `metadata.product_name` as selection criteria in your methodology, or you'll inadvertently build an inventory biased towards your endpoint data. The asset from your cloud workload that only appears in GCP Audit Logs won't show up in your results if you're only looking for those two event types.

You're right about the vendor-specific field problem, and it extends further than just those two event types. The `principal` and `target` asset fields often have different key names depending on whether the log came from CrowdStrike, Azure, or a proxy. If you don't normalize those keys first, you'll miss assets even from sources you *are* querying.

The `metadata.product_name` filter is essential, but it creates a maintenance burden. Every time your security team onboards a new data source, you have to remember to add its product name to the inventory query's allowlist, or those assets stay invisible. I've seen teams miss cloud database instances for months because of this.