Skip to main content

Hi all,

I'm looking for some clarity around the use and interpretation of the metadata.log_type and metadata.base_labels.log_types fields in Google SecOps / Chronicle UDM, particularly in relation to the log ingestion method and parser behaviour.
 

The Standard Flow:

When data (e.g., Windows Event Logs) is ingested via agents like BindPlane, Chronicle automatically detects the log source (e.g., WINEVTLOG) and uses the appropriate parser – in this case, Windows Event Parser. The parsed UDM ends up with fields such as:

"metadata": {
"logType": "WINEVTLOG",
...
"baseLabels": {
"logTypes": ""WINEVTLOG"]
}
}

This makes sense – the original raw event (XML) is parsed and normalized, and the parser used is reflected here.
 

My Question:

When I take a pre-parsed UDM log (in the same format as above), and upload it manually via the Events Import API, the fields instead show:

"metadata": {
"logType": "UDM",
...
"baseLabels": {
"logTypes": p"UDM"]
}
}

This behavior is expected, I suppose, since the import endpoint is for UDM-format data – but it leads to some questions:
 

Core Questions:

  1. Is metadata.log_type simply an indicator of the ingestion parser used (e.g., WINEVTLOG, UDM, etc.), or is it meant to semantically represent the original log source type?

  2. If the field only reflects how the log was ingested (e.g., RAW → parsed by SecOps vs. UDM → imported), does that mean it should not be used in detection logic to identify log types?

  3. Is there a way to preserve or explicitly declare the original source (e.g., WINEVTLOG) when uploading via the UDM import API, or is this strictly inferred by the system based on ingestion path?

It feels like once a raw log is parsed into UDM, it is technically no longer a WINEVTLOG – yet Chronicle still preserves that original log type in the metadata. However, when I manually upload UDM, I'm unable to specify the original type, and the logType defaults to UDM.

This raises concerns about the reliability of logType for detection logic – especially when mixing logs ingested both through automatic pipelines and via manual upload.

Would appreciate any insights or confirmation from others who've worked through this nuance!

That’s interesting, and I’d love to know the answer too! I’m not using the Event Import API (yet) but I heavily rely on the metadata.log_type field, and have advised my team to use it in all rules because (I assumed) it should be a highly efficient way to help the detection engine narrow search results (given this is a native option in the Legacy Search interface).
 


@MichaelCain , For question #1, metadata.log_type is added by the SecOps backend based on the parser used during ingestion. Bindplane can provide either automatic or manually defined log_type mapping (https://bindplane.com/docs/resources/destinations/secops) .

For question #2, ​​​using a log_type filter can be a good way to control the efficacy of your detection logic by limiting it to expected UDM mapping. SecOps Curated Detection content sometimes leverages this approach. However, as you and ​@mogriffs noted, that could lead to missed detections.

For question #3, when importing UDM content into SecOps, one solution would be to insert a metadata.ingestion_label value for the original log source type. You could then adjust your custom rules to match either the metadata.log_type or the ingestion_label.


Thanks ​@Niles,

That clears things up.

So pre-parsing the data and adding a metadata.ingestion_label seems like a good compromise. It’s a shame that this would mean that the data may be excluded from some community/curated detections without modification. In future I wonder if the UDM parser could honour the metadata.log_type if it is set and is not UDM.


Reply