Azure Activity Logs
Integration Guide for Azure Activity Logs with BluSapphire SIEM
1. Prerequisites
Item
Details
Azure subscription
Contributor or Owner access, or at minimum Microsoft.Insights/DiagnosticSettings/Write
Event Hub Namespace
Standard tier or higher (Basic tier does not support multiple consumer groups)
Event Hub
Dedicated Event Hub instance for Activity Logs (recommended: don't mix with other log types)
Shared Access Policy
A policy on the Event Hub with Listen permission for BluSapphire to consume
Consumer Group
Dedicated consumer group created for BluSapphire (avoid using $Default if other consumers exist)
2. Configuration Steps
Step 1 — Create an Event Hub Namespace and Event Hub
In the Azure Portal, go to Event Hubs → Create Namespace.
Choose Standard tier (minimum) to support multiple consumer groups and higher throughput.
Inside the namespace, create an Event Hub (e.g., activity-logs-eh).
Create a dedicated Consumer Group (e.g., blusapphire-cg) under this Event Hub.
Step 2 — Create a Shared Access Policy for BluSapphire
Navigate to the Event Hub → Shared Access Policies.
Create a new policy (e.g., blusapphire-listen) with Listen permission only (principle of least privilege).
Copy the Connection String – Primary Key; this will be used in BluSapphire's collector configuration.
Step 3 — Configure Diagnostic Settings on the Subscription (Activity Log)
Go to Monitor → Activity Log → Export Activity Logs (or Subscription → Diagnostic settings).
Click Add diagnostic setting.
Select the log categories to stream (see Section 6 — recommend enabling all categories for full SOC visibility, at minimum Administrative, Security, Policy, Alert).
Under Destination details, select Stream to an event hub.
Choose the Event Hub namespace and Event Hub created in Step 1.
Save the configuration.
Note: Diagnostic settings for Activity Log are configured per subscription. If you have multiple subscriptions in scope under one Azure tenant, repeat this for each one (or automate via ARM/Bicep/Terraform/Azure Policy for consistency at scale).
3. Azure Activity Log Categories — Description & SOC Importance
Log Category
What It Contains
SOC Importance
Why
Administrative
All create, update, delete, and action operations performed via Resource Manager (e.g., role assignments, resource creation/deletion, NSG changes, VM operations)
Critical
Primary source of control-plane activity. Almost all attacker actions post-compromise (privilege escalation, persistence, resource abuse, exfil infrastructure setup) show up here first. Essential for detecting unauthorized configuration changes.
Security
Alerts generated by Azure Security Center / Microsoft Defender for Cloud (e.g., suspicious process execution, malware detection, brute-force attempts)
Critical
Direct security detections from Microsoft's native threat detection engine. High-fidelity signal for active threats; should feed directly into SOC alerting/correlation rules.
Policy
Results of Azure Policy evaluations (audit, deny, effect actions) — records when a resource is evaluated against a policy definition
High
Tracks compliance posture and policy violations. Useful for detecting drift from security baselines and unauthorized attempts to bypass guardrails.
Alert
Activity generated by Azure Monitor Alerts (metric alerts, log alerts, activity log alerts firing/resolving)
High
Provides operational and security alert lifecycle visibility. Important for correlating downstream automated responses and verifying alert-to-incident workflows.
ServiceHealth
Microsoft-initiated notifications about Azure service incidents, planned maintenance, and health advisories affecting your resources
Medium
Not a security signal by itself, but helps the SOC distinguish platform outages from real incidents, reducing false-positive investigations.
ResourceHealth
Health status changes of individual resources (available, unavailable, degraded) as detected by Azure
Medium
Helps correlate resource downtime with potential DoS conditions, misconfigurations, or malicious resource manipulation.
Recommendation
Azure Advisor recommendations (cost, performance, reliability, security best practices)
Low
Primarily a hygiene/optimization signal, not a real-time threat indicator. Useful for periodic security posture review rather than active SOC alerting.
Autoscale
Events related to autoscale engine actions (scale-out/scale-in operations and the reasons behind them)
Low
Mostly operational telemetry. Minor security relevance (e.g., abnormal scale-out could indicate resource-abuse/cryptomining), but a secondary/contextual signal.
Priority Summary for SOC Onboarding
Must-have (Critical): Administrative, Security
Should-have (High): Policy, Alert
Good-to-have (Medium): ServiceHealth, ResourceHealth — mainly for noise reduction/context
Optional (Low): Recommendation, Autoscale — enable if log volume/licensing allows, useful for enrichment and anomaly baselining rather than direct alerting
Last updated