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 😅
Infrastructure as code is the only way
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.
Every dollar counts.
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.
—AF