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 .
