A client of mine asked a while ago is there a possibility to audit admin activities in the Azure Log Analytics (audit queries). When the question was raised up I wasn’t aware of such a possibility but later on this year (Sep 2020) Microsoft published the capability to audit queries in the Log Analytics workspace.
According to Microsoft: “This includes information such as when a query was run, who ran it, what tool was used, the query text, and performance statistics describing the query’s execution“. In some scenarios, I have worked with, it has been extremely important to monitor the admin activities. This capability offers a technical possibility to adjust that need.
Azure Log Analytics queries auditing can be enabled with the Azure diagnostics settings. Available destinations for the audit data are:
- Azure Log Analytics workspace
- Storage Account
- Retention only affect the storage account
- Event Hub
Log entry is created every time when a query is run in the Log Analytics workspace where auditing is enabled.
For testing purposes I ran the following simple KQL queries in my Azure Sentinel dedicated Log Analytics workspace.
Queries ran in the Log Analytics are flowing to another workspace extremely fast, almost immediately in my environment. The Log Analytics schema is found from the second pic.
In my storage account called “centralauditsa” I can see the json file created almost immediately after I ran the first queries in the Log Analytics workspace.
From the json file, the actual query is seen.
Azure Sentinel offers threat hunting queries out-of-the-box for the “watching the watchers” scenario. These queries can also be found from Azure Sentinel GitHub. Detailed explanation for each scenario can be found from MS TechCommunity blog.
|Cross workspace query anomalies||This hunting query looks for increases in the number of workspaces queried by a user.|
|User running multiple queries that fail||This hunting query looks for users who have multiple failed queries in a short space of time.|
|User returning more data than the daily average||This hunting query looks for users whose total returned data for a day is significantly above their monthly average.|
|Query looking for secrets||This hunting query looks for queries that appear to be looking for secrets or passwords in tables.|
|Query data volume anomalies||This hunting query looks for anomalously large LA queries by users.|
|New users running queries||This hunting query looks for users who have run queries that have not previously been seen running queries.|
|New ServicePrincipal running queries||This hunting query looks for new Service Principals running queries that have not previously been seen running queries.|
|New client running queries||This hunting query looks for clients running queries that have not previously been seen running queries.|
|Multiple large queries made by user||This hunting query looks for users who are running multiple queries that return either a very large amount of data or the maximum amount allowed by the query method.|
Considerations (partly from docs.microsoft.com)
- Log Analytics architecture design is an important factor if you need to audit the LA admin activities
- Might be beneficial to send audit data to a dedicated subscription where a separate LA workspace is located
- Queries are only logged when executed in a user context
- No Service-to-Service within Azure will be logged
- Performance statistics are not available for queries coming from the Azure Data Explorer proxy. All other data for these queries will still be populated.
- The h hint on strings that obfuscates string literals will not have an effect on the query audit logs. The queries will be captured exactly as submitted without the string being obfuscated. You should ensure that only users who have compliance rights to see this data are able to do so using the various Kubernetes RBAC or Azure RBAC modes available in Log Analytics workspaces.
- For queries that include data from multiple workspaces, the query will only be captured in those workspaces to which the user has access.