Azure Security Telemetry: Start with the Control Plane

Tue, 22 Sep 2026 00:00:00 +1000

Security telemetry programs often begin with tools, dashboards, and alert rules. That is understandable, but it can push teams into collecting data before they know what the data is supposed to prove. In Azure, the better starting point is the control plane: who changed what, where, when, and through which path.

If you cannot explain control-plane activity, you do not yet have a defensible Azure security telemetry model.

This first post in the Azure Security Telemetry series sets the foundation. We are not trying to collect every possible log. We are defining the minimum trustworthy signal set that helps platform, security, and operations teams reason about Azure change.

The Mental Model

Think of Azure security telemetry as three connected layers. The first layer is intent: management operations, policy changes, role assignments, deployments, and configuration updates. The second layer is resource behavior: logs and metrics emitted by the workloads and services affected by those changes. The third layer is detection context: the alerts, incidents, investigations, and response actions that turn raw events into security decisions.

The control plane sits in the intent layer. Azure Activity Log records subscription-level events such as administrative operations, service health events, and resource health changes. That makes it the audit backbone for questions like: who changed a network security group, who modified a key vault access model, who assigned a privileged role, or who deleted a diagnostic setting?

The mistake is treating Activity Log as just another table. It is not simply “more logs.” It is the record of management authority being exercised. A denied data exfiltration attempt matters, but so does the control-plane change that opened the path for it. A risky deployment matters, but so does the identity and pipeline that submitted it.

For senior cloud and security leaders, the mental model should be accountability before analytics. Start by mapping the decisions you must defend: privileged access, policy exceptions, logging coverage, network exposure, data protection posture, and incident response authority. Then collect the control-plane signals that let you prove those decisions are operating as intended.

How It Really Works

Azure gives you some control-plane visibility by default, but durable security telemetry still requires deliberate routing. Platform metrics and activity logs exist automatically, while diagnostic settings are used to send activity logs, resource logs, and metrics to destinations such as Log Analytics workspaces, Event Hubs, or storage accounts. For security operations, the common pattern is to send security-relevant control-plane logs into a central Log Analytics workspace that is connected to Microsoft Sentinel.

flowchart LR A[Azure Subscription] --> B[Activity Log] A --> C[Resource Diagnostic Settings] B --> D[Central Log Analytics Workspace] C --> D D --> E[Microsoft Sentinel] D --> F[Security Dashboards] E --> G[Analytics Rules and Incidents]

The important implementation detail is scope. Activity Log helps at the subscription level, but many useful resource logs require diagnostic settings on the individual resource, resource group, or supported platform service. That means your logging design must account for scale. If diagnostic settings are configured by hand, they will drift. If they are configured through policy, infrastructure as code, and landing zone standards, they can become part of the platform contract.

You also need to separate collection from interpretation. The collection design answers: what should be sent, where should it go, how long should it be retained, and which teams can read it? The interpretation design answers: which events matter, how should they be enriched, when should they alert, and which response path owns them?

The control-plane baseline should include administrative operations, policy and initiative changes, role assignment changes, diagnostic setting changes, network control updates, key vault configuration changes, security control changes, and major resource lifecycle events. The exact list varies by environment, but the principle does not: if a change can materially alter security posture, it should leave a searchable trail.

Real-World Impact

The practical value of control-plane telemetry is speed and confidence during incidents. When something looks wrong, teams should not spend the first hour arguing whether the platform changed. They should be able to reconstruct the management timeline quickly.

A common example is storage exposure. A storage account suddenly allows broader network access, public access is changed, or diagnostic coverage disappears. Without control-plane telemetry, the investigation starts with speculation. With it, the team can see the resource update, caller identity, caller IP, operation name, status, correlation ID, and timestamp. That does not solve the incident by itself, but it gives the response team a defensible timeline.

Another example is privileged access. If a high-impact role assignment appears, the important question is not only whether the role exists. It is who assigned it, through which mechanism, whether it matched an approved change, whether Privileged Identity Management was involved, and whether related resources changed afterwards. Activity Log and identity telemetry together make that analysis possible.

This also changes executive reporting. Instead of saying “we collect Azure logs,” the platform team can say “we can reconstruct privileged and security-relevant management changes across production subscriptions.” That is a stronger assurance statement because it is tied to decision quality, not data volume.

Control-plane telemetry is also valuable for engineering discipline. When deployment pipelines, policy assignments, and manual portal actions are visible in the same workspace, teams can identify where change is automated, where exceptions happen, and where operational habits are creating risk. The telemetry becomes a feedback loop for platform maturity.

Gotchas and Edge Cases

The control plane looks simple until you operate it across many subscriptions, tenants, regions, and teams. The hard parts are not usually about whether Azure can emit logs. They are about consistency, ownership, cost, and retention.

The first gotcha is assuming that default visibility is the same as a security telemetry design. Azure provides useful default signals, but default availability does not guarantee central retention, Sentinel integration, least-privilege access, or detection coverage. A log that exists somewhere but cannot be queried by the incident team is not operationally useful.

The second gotcha is inconsistent diagnostic settings. Many Azure services require explicit diagnostic settings to export resource logs. If these are created manually, some resources will be covered and others will not. If your detection rules depend on a log category that only exists on half the resources, the rule creates false confidence.

The third gotcha is treating every operation as equal. A noisy stream of benign write operations can bury the few events that matter. Control-plane telemetry needs classification. Privileged access changes, policy changes, network exposure changes, logging changes, and security tooling changes deserve a different review path from routine tag updates.

Retention is another edge case. Security investigations often need to look beyond a short operational window, especially when a compromise is discovered late. Retention choices should be deliberate and risk-based. Sending everything to a premium workspace forever is rarely the answer, but neither is keeping only a few days of high-value administrative history.

Finally, watch for cross-tenant and centralized operations. Enterprises often centralize logging, security operations, or event streaming. That is powerful, but it introduces permission, routing, and accountability questions. The target workspace or event hub must be protected as a security asset.

Best Practices

Begin with a written signal contract. Define the control-plane events that are security relevant for your organization, the subscriptions in scope, the destination workspace, the retention class, and the owning team. Make the contract understandable enough that cloud platform engineers and security analysts can both challenge it.

Use Azure Policy or infrastructure as code to deploy diagnostic settings at scale wherever possible. Manual setup is acceptable for early discovery, but it should not become the operating model for production. Policy also helps detect drift when teams create new resources without the expected telemetry path.

Design the workspace access model intentionally. Security analysts need enough access to investigate, but broad workspace access can expose sensitive operational data. Use role-based access control, table-level patterns where appropriate, and a clear distinction between readers, detection engineers, platform operators, and workspace administrators.

Classify events before alerting. Not every write operation is an incident. Build analytic logic around high-impact operations, unexpected actors, unusual locations, after-hours changes, failed administrative attempts, and changes to logging, identity, network, and security controls. Use allow lists carefully and review them regularly.

Correlate control-plane activity with identity and resource telemetry. An administrative operation becomes more meaningful when you can connect it to sign-in behavior, workload behavior, Defender findings, or Sentinel incidents. The goal is not a bigger query. It is a more reliable story.

Practical control-plane reconstruction query

Use this as a starting point in Azure Monitor Logs or Sentinel when Azure Activity Log has been routed into the AzureActivity table. It focuses on security-relevant management operations and returns the actor, correlation, operation, target, result, and time fields needed for a defensible change timeline.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


let lookback = 14d;
let securityRelevantOperations = dynamic([
 "Microsoft.Authorization/roleAssignments/write",
 "Microsoft.Authorization/roleAssignments/delete",
 "Microsoft.Authorization/policyAssignments/write",
 "Microsoft.Authorization/policyExemptions/write",
 "Microsoft.Insights/diagnosticSettings/write",
 "Microsoft.Insights/diagnosticSettings/delete",
 "Microsoft.Network/networkSecurityGroups/securityRules/write",
 "Microsoft.KeyVault/vaults/write",
 "Microsoft.Storage/storageAccounts/write",
 "Microsoft.Security/pricings/write"
]);
AzureActivity
| where TimeGenerated >= ago(lookback)
| where CategoryValue in ("Administrative", "Policy", "Security")
| where OperationNameValue in~ (securityRelevantOperations)
 or OperationNameValue has_any ("diagnosticSettings", "roleAssignments", "policyAssignments", "networkSecurityGroups", "keyVault", "storageAccounts")
| extend AuthorizationAction = tostring(Authorization_d.action),
 AuthorizationScope = tostring(Authorization_d.scope),
 RequestMethod = tostring(HTTPRequest.method),
 ClientRequestId = tostring(HTTPRequest.clientRequestId),
 ClaimsAppId = tostring(Claims_d.appid),
 ClaimsUpn = tostring(Claims_d.upn)
| project TimeGenerated, Caller, ClaimsUpn, ClaimsAppId, CallerIpAddress, CorrelationId, OperationId, OperationNameValue, ActivityStatusValue, ActivitySubstatusValue, SubscriptionId, ResourceGroup, ResourceProviderValue, ResourceId, AuthorizationAction, AuthorizationScope, RequestMethod, ClientRequestId
| order by TimeGenerated desc

The assumption is that AzureActivity contains subscription-level or management group level events routed to the workspace. Microsoft documents CorrelationId as the field that groups events belonging to the same broader action, while OperationNameValue, ResourceId, Caller, CallerIpAddress, ActivityStatusValue, and TimeGenerated provide the core reconstruction frame. Validate provider-specific operations in your tenant before turning this into an alert.

🍺

Brewed Insight: The first real win I look for in an Azure security telemetry program isn’t the number of logs collected. It’s whether the team can explain a security-relevant change without relying on memory, screenshots, or tribal knowledge.

Microsoft Sentinel on Brewed in the Cloud by Chris Hailes