How can I drop logs using Parser Extensions and UDM fields?

You can drop logs in Google Chronicle by using Parser Extensions to manipulate UDM fields. The key is to set conditions in your parser extension so that unwanted logs either map to null values or are excluded entirely before they reach the Unified Data Model (UDM). 
- Parser Extension parser Extensions let you override or extend the default parser behavior for specific log sources.  
- By customizing UDM field mappings, you can remove, nullify, or redirect values so that logs you don’t want are effectively dropped.  

Thanks, ​@cmmartin_google !

I wasn't aware of this new function. I had a read through the docs and tried to configure the Bindplane integration without success. I will discuss it further with Bindplane Support. Thanks for pointing me to this resource.

​@cmmartin_google Do you have any examples with filter processors based on UDM fields?

Quite hard to figure out from these examples.

During the preview the recommended approach is to use the BindPlane OP UX, either the on-prem or the SaaS instance (of which your Google SecOps license entitles you access).

As to the pipeline, you would apply a match against the raw log data, e.g., use the json extract processor with a transform and drop a specific key, or you can write a regex match.

​@cmmartin_google 

I’m in the process of confirming whether or not we have access to this feature in Bindplane, as I read some previous posts where it was stated that only Ent+ customers can use this.

So even in this integration, I can’t work directly with the UDM data and apply the filter after normalization. I must only work with the raw events. Is my understanding correct?

The Google Edition license of BindPlane would be available to all SecOps customers - https://docs.cloud.google.com/chronicle/docs/ingestion/use-bindplane-agent#bindplane_google_edition - this gives you access to the BindPlane OP. 

The Data Pipeline feature mentioned if, I think, for Enterprise and Enterprise+ SecOps users.

You *can’t* filter on UDM values as this feature runs ahead of normalization, but in your example the original log source is JSON and has a clean and reliable key name you can use for filtering confidently.

Understood. The Chrome events do not have a field for the product name, and from what I’ve seen in the parser, it deduces the product based on the event names. But that’s fine; I just wanted to know how this works. Thanks for your help!