Design Azure security logging with activity logs, diagnostics, Log Analytics, Microsoft Sentinel, detections, automation, retention, and investigation evidence.
From telemetry to action
Azure logging and Microsoft Sentinel are not complete when a diagnostic setting is enabled. The organization must know which events matter, whether the correct categories are collected, where data is routed, how long it is retained, who can access or delete it, what detections evaluate it, who owns the resulting incidents, and whether responders can contain the threat.
This guide covers Azure Activity Log, resource logs, platform metrics, Microsoft Entra activity logs, data collection rules, diagnostic settings, Log Analytics architecture, retention, data protection, Microsoft Sentinel data connectors, analytics, incidents, automation, hunting, cost control, and evidence.
Security visibility pipeline
Source inventory
| Source | Security value | Collection decision | Validation |
|---|---|---|---|
| Azure Activity Log | Subscription control-plane create, update, delete, action, policy, security, and service-health events | Azure retains the log for a default period; export with diagnostic settings for longer retention and analytics | Make a benign resource change and query the actor, operation, scope, status, time, and correlation ID |
| Microsoft Entra sign-ins | Interactive, non-interactive, service-principal, managed-identity, risk, device, authentication, and Conditional Access context | Route required categories through Entra diagnostic settings; account for licensing and retention | Perform representative sign-ins and verify applied policy and authentication details |
| Microsoft Entra audit | User, group, application, role, authentication-method, policy, consent, and directory changes | Collect the categories required for investigation and protected audit history | Create a controlled directory change and correlate actor, target, and result |
| Resource logs | Service-specific data-plane, administrative, request, firewall, audit, and security events | Enable per resource or at scale with supported policy or data collection features | Generate a service event and confirm the correct resource-specific table or destination |
| Platform metrics | Performance, capacity, availability, errors, throttling, and service behavior | Select metrics that support security and operational use cases; configure alerts | Test threshold or dynamic alert routing |
| Defender for Cloud | Recommendations, attack paths, alerts, workload signals, vulnerability findings | Confirm plan coverage, connector, integration, notification, and export behavior | Trace a test or historical alert into the incident workflow |
| Network telemetry | Firewall, WAF, gateway, Front Door, Application Gateway, DNS, flow, and connection events | Choose supported current sources and retention; monitor product transitions | Perform an allowed and denied connection and locate both records |
| Guest operating systems | Security events, processes, authentication, EDR, syslog, application logs | Use Azure Monitor Agent and data collection rules or approved endpoint tooling | Confirm agent health, source computer, event time, and required fields |
| Applications and APIs | User activity, authorization, transactions, errors, fraud, sensitive actions, trace context | Instrument securely; avoid secrets and unnecessary personal data | Run a known transaction and correlate application, identity, and Azure events |
| Backup and recovery | Policy changes, protection stop, deletion, restore, vault security, jobs, alerts | Route critical changes and job status to accountable owners and security monitoring | Perform a controlled test or review a restore record end to end |
Diagnostic settings
Azure Monitor diagnostic settings can send resource logs, metrics, and Activity Log categories to Log Analytics, a storage account, or an event hub. A separate setting is traditionally created for each resource; newer platform-log data collection rule capabilities may support selected resource types and should be evaluated against current Microsoft guidance.
Use resource-specific tables where supported and appropriate because they often provide clearer schemas than the legacy AzureDiagnostics table. Record the selected categories, destination resource ID, table mode, retention, owner, deployment method, and reason. Monitor deletion or modification of diagnostic settings.
At scale, use Azure Policy with deployIfNotExists or another governed deployment method to standardize collection. Test the managed identity, permissions, remediation tasks, existing-resource behavior, regional requirements, and cost. A policy marked compliant does not prove events are arriving; query a sample from every critical service family.
Workspace architecture
A centralized workspace can simplify cross-resource analytics and SOC operations. Multiple workspaces may be justified by tenant, region, data residency, access isolation, business ownership, retention, billing, or operational boundaries. Sentinel-enabled data has pricing implications, so do not combine security and high-volume operational data without analysis.
Use Azure RBAC and table or resource-context access where appropriate. Limit who can query sensitive identity, application, and security logs; who can change retention; who can purge data; and who can manage Sentinel rules and automation. Separate content authors, responders, platform administrators, and evidence custodians when risk justifies it.
Choose interactive retention according to investigation needs and table value. Use long-term retention, archive, search jobs, restoration, storage export, or event hub integration where justified. Azure Activity Log has a default retention period; export if longer history is required.
Use resource locks to reduce accidental workspace deletion or retention change, while recognizing that authorized administrators can remove a lock. For stronger tamper resistance, export selected audit data to immutable storage with separately governed access and retention.
Microsoft Sentinel operating loop
Data connectors and content
Inventory each connector, solution, content hub package, permission, prerequisite, data table, expected volume, health signal, owner, and update process. Confirm connectors for Microsoft Entra, Azure Activity, Defender products, Microsoft 365, network controls, endpoints, servers, and third-party systems according to the incident use cases. A connector can appear configured while permissions, licensing, agent health, API limits, or filters prevent useful data.
Review solution updates and content dependencies. Built-in analytics templates are starting points; enable them only after understanding data requirements, query logic, entity mapping, scheduling, thresholds, suppression, incident grouping, automation, and expected false positives. Preserve local changes and version custom rules.
Detection use cases
Detect unusual administrator sign-in, risky authentication, new credential or method, emergency-account use, Conditional Access change, named-location change, application consent, and security-setting modification.
Detect Owner, User Access Administrator, Global Administrator, or custom high-impact assignment; permanent role creation; unusual activation; approver change; and role-setting modification.
Detect public IP creation, broad NSG rule, management-port exposure, route change, firewall or WAF disablement, new peering, private endpoint change, DNS modification, and denied traffic spikes.
Detect Shared Key re-enable, unusual SAS or data access, Key Vault secret or key deletion, purge attempt, permission change, mass download, database anomaly, and diagnostic-setting removal.
Detect suspicious VM extension, run command, new automation credential, container deployment from an unknown registry, privileged pod, Defender alert, endpoint tampering, and vulnerable exposed asset.
Detect protection stop, backup deletion, immutability or soft-delete change, Resource Guard modification, vault role assignment, policy reduction, failed jobs, and unusual restore activity.
Analytics-rule engineering
| Field | Required decision | Quality check | Evidence |
|---|---|---|---|
| Threat scenario | Describe the attacker action, affected control, and business consequence | Rule is tied to a real response decision | Use-case document and control map |
| Data dependency | Tables, fields, connectors, permissions, latency, retention | Source health is monitored and fields are populated | Sample query and connector health |
| Query logic | Time window, joins, thresholds, allowlists, entity mapping, exclusions | Logic is readable, versioned, and peer reviewed | Rule export, repository, test cases |
| Incident behavior | Severity, grouping, suppression, alert details, tactics, techniques | One event does not create uncontrolled duplicate incidents | Test incident and tuning record |
| Response | Owner, SLA, triage questions, containment authority, escalation | Analyst can act without guessing | Runbook, assignment, case record |
| Automation | Enrichment, notification, ticketing, disablement, isolation, blocking | Permissions are least privilege and destructive action requires suitable approval | Playbook identity, role, run history, failure alert |
| Test and maintenance | Benign test, expected result, review date, owner, dependency change | Rule fires, creates the right incident, and receives response | Test record, screenshots without secrets, query result, ticket |
Automation
Automation rules can assign incidents, change status, add tags, and run playbooks. Logic Apps and other playbooks can enrich entities, notify teams, create tickets, revoke sessions, disable accounts, isolate devices, block indicators, or change cloud controls. Review the managed identity, connectors, API permissions, Azure RBAC, secret storage, network access, error handling, concurrency, retry behavior, data exposure, and change ownership.
Separate enrichment from destructive containment. Automated user disablement, network blocking, VM isolation, or key rotation can disrupt the business if the signal is wrong. Use approval, high-confidence conditions, limited scope, simulation, and rollback according to risk. Monitor playbook failures and expired connections.
Retain the incident timeline, rule version, playbook run, actor, decision, evidence, containment result, recovery action, and lessons learned. Do not put sensitive client data or secrets into notifications that leave the controlled environment.
Cost and signal quality
Measure daily ingestion by workspace, table, source, resource, and solution. Identify sudden changes, duplicate collection, verbose application logs, high-cardinality fields, low-value debug data, and tables with retention longer than their value. Use table plans, transformations, filtering at the source, data collection rules, commitment tiers, archive, and export only after understanding the security impact and current Microsoft pricing.
Do not use a daily cap as the primary security cost control; it can stop collection during an incident, exactly when volume rises. If a cap is used as an emergency guardrail, alert well before the threshold and document the risk. Preserve critical identity, Activity Log, security, firewall, Key Vault, and backup signals even when optimizing less valuable telemetry.
Metrics should include source coverage, connector health, ingestion delay, detection test success, mean time to acknowledge, mean time to contain, incident aging, false-positive rate, unassigned incidents, playbook failure, required-source gaps, retention compliance, and cost by use case.
Assessment and operations
OC Security Audit can assess log coverage, evidence quality, detection logic, response ownership, and risk. When findings require Azure monitoring and Log Analytics implementation, the IT Perfection Azure Monitor and Log Analytics guide can support the operational plan.
Generate a controlled source event, confirm ingestion, run the analytics logic, inspect the incident, assign it, execute the approved response path, verify the outcome, and retain the complete timeline.
Official guidance
Microsoft updates Azure capabilities, portal locations, licensing, defaults, feature status, and prerequisites. Confirm the current product documentation before a production change.
Practical questions
No. Activity Log is collected by the platform, but resource logs and many identity or workload sources require diagnostic settings, connectors, agents, data collection rules, or application instrumentation.
Microsoft currently documents a default retention period for Activity Log and recommends exporting it when longer retention or additional analysis is needed. Verify current documentation for exact behavior.
No. Sentinel provides SIEM and security operations capabilities, but the organization still needs use cases, data ownership, analysts, triage, authority, escalation, containment, evidence, and improvement.
Enable the rules that support defined, testable response use cases and available data. Rule count is less important than source health, signal quality, ownership, tuning, and response effectiveness.
Measure ingestion by source and table, remove duplicate or low-value data, filter carefully, choose suitable table plans and retention, archive selectively, monitor budget, and preserve critical security evidence.
About the author
Reviewed for practical Azure security, evidence, and remediation guidance by Ali Hassani, CISO, with 25+ years of IT and cybersecurity experience.
This material is for initial guidance only and does not replace a professional cybersecurity audit, compliance assessment, penetration test, or legal/compliance review. Validate configuration, licensing, service availability, architecture, and business impact before production changes.
This website uses essential cookies for security and operation. Optional analytics and advertising cookies help measure site use and outreach. Choose Allow or Deny. You can change your choice at any time.