Metadata.Event_Type mappings.

Hi @Surendrasumith,

The following documentation will be of interest - 

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.