Summary:
The current Azure Log Analytics integration (cutom log) sends logs that are too sparse for real-world SIEM usage (Microsoft Sentinel, Splunk, etc.). We are requesting enrichment of the log schema and the Message field content.
Issues Identified:
1. No readable user identity The UserID field only contains a GUID. A workaround using Get-HubUser was suggested, but this requires a manual PowerShell join and is not viable at scale in a SIEM. The UserDisplayName / Username should be natively included in each log entry. (Note: We understand a dev ticket has been opened for this — thank you. We are adding it here for community visibility and prioritization.)
2. Message field is too vague The current content of the Message field does not allow an analyst to determine what action was performed (read, create, modify, delete, login, etc.), on which resource (vault, entry, group, policy), from which source IP or client, or with what result (success, failure, denied).
3. Missing structured/queryable columns For a SIEM like Sentinel or Splunk, a flat text blob is insufficient. Logs should expose distinct, typed columns. At minimum, the following fields are expected:
ActionType — e.g. EntryRead, VaultModified, UserLogin, PolicyChanged
ResourceName — name of the vault or entry affected
ResourceType — e.g. Vault, Entry, Group, Policy
SourceIPAddress — origin IP of the request
Result — e.g. Success, Failure, Denied
UserDisplayName — human-readable username
VaultName — name of the parent vault
4. No User Behavior Analytics (UBA) logs UBA is currently not a supported log type. We are formally requesting it as a feature. UBA is essential for detecting anomalous access patterns, privilege abuse, and insider threats in environments with PAM solutions.
5. Native Splunk HEC integration Azure Log Analytics works as an intermediate, but a direct Splunk HTTP Event Collector (HEC) output would be strongly preferred. Many enterprise security teams use Splunk as their primary SIEM, and routing through LAW adds latency and complexity.
Business Impact:
Without these improvements, the Azure Log Analytics integration cannot be used for security alerting and threat detection, privileged access reviews, or audit and compliance reporting. The logs as-is confirm that something happened, but provide no actionable context.
Expected behavior:
Each log entry sent to LAW should contain enough structured information to answer: Who did what, on what resource, from where, and with what result — without requiring any post-processing or external joins.
