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:
-
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.
-
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.
-
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.
LinkedIn
Twitter
