Azure Log Analytics Integration – Log Content Enrichment & Structured Fields for SIEM

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

From a governance, risk, and compliance perspective—particularly in alignment with Québec Law 25, privacy-by-design principles, and broader regulatory expectations—the enhancement of logging capabilities is both justified and advisable.

Absence of Readable User Identity in Logs
The current logging structure records the UserID solely as a GUID, which limits traceability and accountability. While a workaround using Get-HubUser has been suggested, it requires manual PowerShell correlation and is not scalable for SIEM ingestion or real-time analysis.

For effective auditability and compliance with Law 25 accountability and transparency requirements, each log entry should natively include a human-readable identifier (e.g., UserDisplayName / Username).

Insufficiently Descriptive Message Field
The current Message field lacks the necessary level of detail to support incident investigation, audit review, or regulatory reporting. Specifically, it does not clearly indicate:

• The action performed (e.g., read, create, modify, delete, login)
• The target resource (vault, entry, group, policy)
• The origin context (source IP, client)
• The outcome (success, failure, denied)

This level of ambiguity limits the organization’s ability to demonstrate traceability, decision reconstruction, and breach analysis, which are core expectations under Law 25 and other privacy frameworks (e.g., PIPEDA, GDPR principles).

Lack of Structured and Queryable Log Fields
For enterprise SIEM platforms such as Microsoft Sentinel or Splunk, relying on unstructured text significantly reduces detection capabilities and increases operational overhead.
To align with industry best practices and compliance requirements for monitoring and incident response, logs should expose clearly defined, structured fields. At minimum:

• ActionType (e.g., EntryRead, VaultModified, UserLogin, PolicyChanged)
• ResourceName
• ResourceType (Vault, Entry, Group, Policy)
• SourceIPAddress
• Result (Success, Failure, Denied)
• UserDisplayName
• VaultName

This structure supports effective audit trails, timely detection of anomalous activity, and defensible reporting, all of which are key elements of compliance with privacy legislation and cybersecurity frameworks (e.g., NIST CSF logging and monitoring principles).

Absence of User Behavior Analytics (UBA) Logs

• UBA capabilities are currently not supported, which limits the organization’s ability to detect anomalous access patterns, privilege misuse, or insider threats.
• From a compliance standpoint, particularly under Law 25’s emphasis on safeguarding personal information and proactive risk mitigation, the availability of UBA telemetry is increasingly considered a baseline expectation for environments handling sensitive or privileged data.

We formally recommend the introduction of UBA logs as a strategic enhancement to strengthen both security posture and regulatory defensibility.
Need for Native Splunk HEC Integration

While Azure Log Analytics provides functional ingestion capabilities, routing logs through it introduces additional latency, complexity, and potential points of failure.
A native Splunk HTTP Event Collector (HEC) integration would:

• Simplify architecture
• Improve timeliness of detections
• Reduce operational overhead

This is particularly relevant for organizations where Splunk serves as the primary SIEM of record, and where real-time monitoring is essential to meet incident response expectations under privacy regulations, including mandatory breach notification timelines under Law 25.

Good Morning @patrick_patenaude

First of all, I apologize for the delay in my response. It seems that I did not see your reply message, and for that I apologize. Let me take some time next week to discuss internally the concerns expressed in this message, and I will get back to you as soon as possible. This does not mean that anything will change, but I acknowledge your concerns.

Thank you for your complete and detailed feedback. I will contact you soon.