Azure Log Analytics Integration – Log Content Enrichment & Structured Fields for SIEM
9 votes
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:
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.
Good morning @patrick_alphonso
Thanks for this suggestion. I will create an internal ticket and review this with our team regarding feasibility and priority. I will get back to you as soon as possible.
Regards
Any updates ? Stumbled upon a similar request.
Improvement Request – SIEM Integration and Log Management Enhancements
Good Afternoon @patrick_alphonso
! should be able to give you an update (positive/negative) by the end of this week.
Regards
Good Morning @patrick_alphonso
So, after reviewing with internal teams, we should be able to implement some of the changes requested here, but not all, and I will make sure to prioritize them in the smaller cases.
Here is what we had in mind:
It could be possible to add the "Denied" type logs. This represents a significant amount of work, but we believe it will be a valuable addition to the logs information. This will be prioritized in one of our upcoming major versions.
Provide clearer and translated messages for each logs.
ig: "Message_full" : "Entry 'Entry Sample' edited in vault 'Default vault' ",
Unfortunately, there are no plans to include UBA, Splunk options, or to export everything in a queryable format in our products.
We are open to feedback and suggestions, but this is where we stand for now.
Regards