Which Log Source Completes principal.user.userid Matching?
You use Google Security Operations (SecOps) curated detections and YARA-L rules to detect suspicious activity on Windows endpoints. Your source telemetry uses EDR and Windows Events logs. Your rules match on the principal.user.userid UDM field. You need to ingest an additional log source for this field to match all possible log entries from your EDR and Windows Event logs. What should you do?
Community Insight
The question tests identity context completeness for UDM field matching; the trap is picking another Windows behavioral telemetry source (Sysmon, PowerShell, Procmon) that adds events but never resolves the user identity behind them.
Google Security Operations detections written in YARA-L that filter on principal.user.userid need identity-complete telemetry from every source they evaluate. Ingesting Microsoft Entra ID (Azure AD) logs supplies the user identity context that EDR and Windows Event logs alone cannot provide, so the field matches across all possible log entries.
Learners most often choose A, C, or D because Sysmon, PowerShell, and Procmon are familiar Windows telemetry sources. These add behavioral event volume but produce no identity records, so principal.user.userid still fails to match every entry.
Community Discussion (3 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Microsoft Entra ID (Azure AD) is the authoritative cloud identity provider for Windows endpoints, and its audit/sign-in logs carry the user identifiers that SecOps normalizes into principal.user.userid. Ingesting this source lets curated detections and YARA-L rules resolve the same user across EDR telemetry and Windows Event logs, which frequently record short names, domain-qualified names, or SID-based representations. As Hamza_hmz123 linked, the Chronicle parser documentation for Azure AD audit ingestion is the intended path. This satisfies the requirement to match "all possible log entries" rather than merely adding more behavioral events.Why the Other Options Are Wrong
Windows Sysmon (A) and Windows Procmon (D) are process and registry telemetry utilities that generate behavioral event records keyed to processes, not to resolved identity entities, so they cannot fill an identity gap on principal.user.userid. Windows PowerShell (C) captures script and command-line activity, which is valuable for detection but likewise supplies no canonical user identity mapping. As b925054 put it, these are "Event log sources, not Entity (identity context) sources" — they increase behavioral coverage while leaving the identity matching problem unsolved. None of A, C, or D can make the UDM field match entries that currently lack a normalized user identifier.Community Comment Notes
All three substantive comments converge on B, with Hamza_hmz123 citing the Azure AD audit default-parser documentation and TitanZauron explaining that consistent detection coverage requires "User Identity Aliasing and Enrichment" through the Entity Graph. b925054 explicitly separates event telemetry from entity context, arguing that A, C, and D "will provide more behavioral telemetry but will not solve the identity mapping problem." The vote pattern and the reasoning both support the verdict that identity ingestion, not additional endpoint event sources, is what the question is really asking for.Official Reference
Exam Strategy
Read the UDM field named in the stem before scanning the options: if the field is an entity field (principal.*, principal.user.userid), the fix is an identity/context data source, not another behavioral event source. On SecOps questions, treat identity, asset, and alert sources as distinct categories from endpoint event telemetry.
Frequently Asked Questions
Why don't Sysmon, PowerShell, or Procmon logs fix principal.user.userid matching?
They are behavioral event sources, so they add process and script telemetry but never supply the canonical user identity records needed to normalize principal.user.userid across sources.
Why is Microsoft Entra ID the right identity log for Windows endpoints?
Entra ID is the authoritative identity provider for those endpoints, and its audit and sign-in logs carry the user identifiers SecOps maps into principal.user.userid for YARA-L matches.
sAMAccountName,DOMAIN\username, User Principal Name[email protected], or Security Identifiers / SIDs)[1][3]. If YARA-L rules or Curated Detections strictly evaluateprincipal.user.userid, logs presenting an unmapped format or SID will fail to trigger detections[2][4]. 2. User Entity Context & Automatic UDM Enrichment: Ingesting identity logs from Microsoft Entra ID (formerly Azure AD) feeds User Entity data into the Entity Graph[5][6]. Google SecOps uses this identity context to perform automatic user aliasing and enrichment[2]. It maps all valid aliases, email addresses, and SIDs of a account to the standardizedprincipal.user.useridUDM field across all incoming EDR and Windows Event streams[2][3]. 3. Rule Fidelity: Once Entra ID context is ingested, any YARA-L rule or Curated Detection checking$event.principal.user.useridwill match successfully regardless of which endpoint log format captured the activity