Hi @Surendrasumith,

The following documentation will be of interest - 

Thank you, @AymanC , 

I just mentioned windows as an example. Actually i have noticed this with some other data sources as well. My ask is in which condition the metadata.event_type will show the product_ event_types values under chronicle event types session.

Thanks,

Sumith.P

Broadly, think of metadata.event_type as being a vendor agnostic way of representing types of events. For instance network connection or network dns events could come from cisco, pan, microsoft and sysmon event but the product event type is specific to microsoft or sysmon.

That said the event_type is a field that can be excellent to narrow data sets down very quickly so if i am looking for windows login events i might use both event type = user login and product event type = 4624 to get good performance and vendor specific events.

You're raising a very important point about the nuances of event mapping in Chronicle, particularly concerning metadata.event_type and metadata.product_event_type. You are correct; there's not always a one-to-one correspondence, and understanding the mapping logic is crucial for writing accurate Yara-L rules.

metadata.event_type

• UDM Standard: This field is intended to represent a standardized event categorization according to the Unified Data Model (UDM).


• Enum Values: It uses predefined enum values that attempt to categorize events into broad security-relevant categories (e.g., PROCESS_LAUNCH, NETWORK_CONNECTION, USER_LOGIN, FILE_MODIFICATION).


• Normalization Goal: The aim is to provide a consistent way to refer to common event types across different data sources, facilitating rule writing and analysis.

metadata.product_event_type

• Source-Specific: This field captures the original, product-specific event type or identifier as provided by the data source.


• Heterogeneous Values: It can contain a wide range of values, including strings, integers (like EventIDs in Windows events), or even more complex structures depending on the source.


• Preservation of Context: It retains the original event categorization from the source, allowing for more granular analysis when needed.

Mapping Logic and Discrepancies

Chronicle's parsers attempt to map the product_event_type from the raw log to the closest corresponding event_type in the UDM standard. However, this mapping is not always straightforward or perfect due to several factors:

1. 
   

   Granularity: UDM event_type values are often more generic, while product_event_type values can be highly specific. For example, Windows has hundreds of EventIDs under the broad category of "PROCESS_LAUNCH," each with unique meanings.

   
   


2. 
   

   Ambiguity: Some source event types might not have a clear or direct UDM equivalent. This can lead to either a generic mapping (e.g., mapping many different Windows EventIDs to PROCESS_UNCATEGORIZED) or potential inaccuracies.

   
   


3. 
   

   Parser Limitations: Parser logic can influence how events are mapped. For instance, a parser might not yet handle a newly introduced product_event_type, leading to a generic or incorrect UDM event_type assignment.

   
   

When to Use product_event_type

You should consider using product_event_type in your Yara-L rules in the following circumstances:

• Source-Specific Logic: When you need to write rules that target very specific event types or identifiers from a particular data source (e.g., filtering for a precise Windows EventID).


• High Fidelity: If accuracy is paramount, and you want to avoid potential misinterpretations or generalizations introduced by the UDM mapping.


• Parser Incompleteness: When you suspect that the parser might not be correctly mapping a specific product_event_type to the intended UDM event_type.

Example: Windows EventIDs

As you observed, Windows EventIDs are often mapped under metadata.product_event_type. To target a specific EventID (e.g., 4688 for process creation), you would use:

$e.metadata.product_event_type = "4688"

Best Practices

• Consult UDM Documentation: Refer to Chronicle's UDM documentation to understand the available event_type values and their intended mappings.


• Verify Parser Behavior: Test your rules against real data to confirm that the parser is correctly mapping product_event_type to event_type as you expect.


• Use product_event_type When Necessary: Don't hesitate to use product_event_type for precise targeting or if you suspect mapping inaccuracies.

Key Takeaway:

While the UDM aims for standardization, the metadata.event_type might not always accurately reflect the original event type from the source. Be aware of the potential discrepancies and use metadata.product_event_type when necessary for precise matching or to work around parser limitations.

$e.metadata.product_event_type = "4688"

Thank you @raybrian @jstoner