Fix EmailEntity_PaloAlto join condition: DestinationUserID → DestinationUserName

[Copilot]

In PaloAlto CEF logs, DestinationUserID is a system-level account identifier (e.g. 1761761851203431902@playhop.com) — not a real email address — while DestinationUserName holds the actual user email. The join EmailSenderAddress == DestinationUserID could produce missed matches or false negatives when ID values don't correspond to real sender addresses.

Change(s):

• Replaced all DestinationUserID references with DestinationUserName in both rule variants:
  • Solutions/Threat Intelligence/Analytic Rules/EmailEntity_PaloAlto.yaml
  • Solutions/Threat Intelligence (NEW)/Analytic Rules/EmailEntity_PaloAlto.yaml
• Affected locations per file: isnotempty() filter, extend tolower(), where matches regex, join condition, summarize by, project, and entityMappings

// Before
CommonSecurityLog | where isnotempty(DestinationUserID)
| extend DestinationUserID = tolower(DestinationUserID)
| where DestinationUserID matches regex emailregex
...
on $left.EmailSenderAddress == $right.DestinationUserID

// After
CommonSecurityLog | where isnotempty(DestinationUserName)
| extend DestinationUserName = tolower(DestinationUserName)
| where DestinationUserName matches regex emailregex
...
on $left.EmailSenderAddress == $right.DestinationUserName

Reason for Change(s):

• DestinationUserName is the semantically correct CEF field for the user's email address in PaloAlto WildFire SMTP/POP3 logs; DestinationUserID is an opaque system identifier

Version Updated:

• Solutions/Threat Intelligence/Analytic Rules/EmailEntity_PaloAlto.yaml: 1.2.6 → 1.2.7
• Solutions/Threat Intelligence (NEW)/Analytic Rules/EmailEntity_PaloAlto.yaml: 1.2.9 → 1.2.10

Testing Completed:

• Yes — KQL and YAML validation checks passed; no remaining DestinationUserID references in either file

Checked that the validations are passing and have addressed any issues that are present:

• Yes