Azure Logging/Auditing Series (1) – Activity Logs

Logging and auditing plays a critical role in the security and compliance strategy of any serious organization. Collecting detailed information on events that happened and changes made to resources is the foundation of areas like security monitoring and digital forensics and the Azure platform is not different in this respect.

The Azure platform delivers multiple audit logs which enables us to track user, application and administration activity within our Azure environments. My purpose in this blog series is to cover the available audit logs, discuss the security insights that we can obtain from them and also to highlight existing blind spots that can save you a few headaches down the line. Here are SOME of the logs that will be discused:

• Activity Logs
• Resource Logs
• Azure AD (Tenant) Logs
• Network Logs (Including DNS)
• Application Logs

In this first blog in the series, I’ll answer the following key questions about the Azure Activity Log:

• What does it log?
• How do we enable it?
• What is the security value?
• What is the event latency?
• Where the logs stored and for how long?
• What are the long term retention options?
• Can attackers clean their tracks?

What does it log?

1. Administrative Events
   • It logs all write operations (PUT, POST, DELETE) for Azure management API endpoints
   • This will be like event log in Windows and /var/log on Linux but for the Azure platform
   • It logs the start of the operation and subsequent success or failure of the operation
   • It doesn’t include read operations (GET)
   • References
     • https://docs.microsoft.com/en-us/azure/azure-monitor/platform/activity-log-schema#administrative-category

2. Azure Service Health issues
   • Service Health is a monitoring service in Azure that reports platform issues 
     • If an incident/notification is detected by Service Health, an event is automatically logged in activity logs by the Azure infrastructure
     • Notifications/Incidents are published to activity logs only if our subscription has a resource that would be impacted by the event
   • References
     • https://docs.microsoft.com/en-us/azure/service-health/service-notifications
     • https://docs.microsoft.com/en-us/azure/azure-monitor/platform/activity-log-schema#service-health-category

3. Resource Health events
   • Resource health is a capability of the Azure platform that watches our Azure resources to check if they are running as expected
     • If an issue is detected and a service is not running as expected, a notification will be logged in activity logs
     • A resource is a specific instance of an Azure service, such as a virtual machine, web app, or SQL Database
     • An example of a Resource Health event is Virtual Machine health status changed to unavailable.
   • But what can checks does Resource Health perform?
     • It can check if a resource is available or unavailable
       • If a resource is not available, an “unavailable” status notification will be logged in activity logs
       • If Resource Health is unable to determine the health of the resource or if it hasn’t received information about the resource for more than 10 minutes, an “unknown” status notification will be logged in activity logs
     • It can check if a resource is experiencing performance degredation
       • If performance loss is detected for a resource even though it is still available for use, a “degraded” status notification will be logged in activity logs
   • Does Resource Health perform all checks for all resource types in Azure?
     • No. It currently performs checks for 49 resource types (out of over 180 resource types in Azure)
     • Some resources only supports availability checks while some supports both availability and performance degredation checks
     • The methods and signals used to monitor the health of resources also varies for different resource types
   • References
     • https://docs.microsoft.com/en-us/azure/service-health/resource-health-overview
     • https://docs.microsoft.com/en-us/azure/service-health/resource-health-checks-resource-types

4. Azure Monitor alerts events
   • If you have configured “Classic Azure Monitor alerts”, a notification will be logged in activity logs when an alert is triggered
   • References
     • https://docs.microsoft.com/en-us/azure/azure-monitor/platform/activity-log-schema#alert-category

5. Autoscaling events
   • The start and status of all autoscaling events are logged in Activity logs. This includes when the autoscaling event started and also its subsequent status of success or failure
   • References
     • https://docs.microsoft.com/en-us/azure/azure-monitor/platform/activity-log-schema#autoscale-category

6. Security events
   • Azure Security Center is a PAID Cloud Security Posture Management and Cloud Workload Protection service in Azure.
     • If an issue is detected by Security Center, a notification will be logged in activity logs
     • Is this for CWPP only or for CSMP also?
   • References
     • https://docs.microsoft.com/en-us/azure/azure-monitor/platform/activity-log-schema#security-category

7. Recommendation events
   • Azure Advisor is a FREE best practice recommendation service in Azure
     • It analyzes resource configuration and usage telemetry of Azure resources and provides recommendations on how to optimize cost effectiveness, performance, reliability and security
     • If an recommendation is identified by Azure Advisor, a notification will be logged in activity logs
     • High Availability, Performance, Security, and Cost Optimization
   • References
     • https://docs.microsoft.com/en-us/azure/azure-monitor/platform/activity-log-schema#recommendation-category

8. Policy events
   • Azure Policy is a FREE configuration assessment and enforcement service in Azure
     • It analyzes the configuration of existing resources and resources that are about to be deployed against assigned policy definitions
     • If the resource configuration matches the defined definition, the corresponding action is applied
     • The compliance status of resources are written to activity log
     • Non-compliant audit state is written with the “warning” level
     • Non-compliant deny state is written with the “error” level
   • References
     • https://docs.microsoft.com/en-us/azure/azure-monitor/platform/activity-log-schema#policy-category
     • https://docs.microsoft.com/en-us/azure/governance/policy/how-to/get-compliance-data

How do we enable it?

• It is enabled by default. We don’t need to do anything to enable it
• Some events may require other Azure Services to be configured
  • Policy events – Requires Azure Policy definitions or initiatives to be assigned
  • Security events – Requires Security Center to be enabled and configured
  • Recommendation events – Requires Azure Advisor
  • Autoscaling events – Requires autoscaling settings to be configured
  • Azure Monitor alert events – Requires alerts to be configured in Azure Monitor

What is the security value?

• Obtaining documented audit trails of administrative activities (reactive)
  • This is useful for forensic insights and to investigate breaches. For example, what did a bad actor do with a compromised credential?
  • Remember that GET administrative operations are not logged so there is a chance of missing insights like where an attacker has used a compromised credential to read other sensitive information.
• Proactive attack detection and prevention
  • Activity logs can be proactively exported to other services in Azure like Log analytics and Azure Sentinel OR to 3rd-party cloud security solutions like Prisma Cloud for proactive analysis and event correlation TO IDENTIFY THREATS AND ANOMALIES.
    • For example, a solution like Prisma Cloud could add extra context by analyzing the logs using built-in policies, machine learning algorithms that detects anamalies and correlating the log entries with different threat feeds.
  • Autoscaling events could be analyzed along with other logs to determine if there’s an EDoS (Economic Denial of Sustainability) or “denial of wallet” attack that is progress
• Compliance insights
  • Information on service usage can be obtained from Activity logs and this can be used to identify usage that violates compliance policies.
  • Since, Azure policy detections are logged in Activity logs, this can also be used to identify resources that have been configured in a non-compliant way.

What is the event latency? 

• This varies by event category
  • My “unofficial tests” showed that Administrative events could take about 2 minutes to appear in the UI after the event has occured so this is quick enough to be classified as “near real time”.

Where the logs stored and for how long?

• The logs are stored on the Azure platform for 90 days
  • This means that we can only view logs only for the last three months
  • https://docs.microsoft.com/en-us/azure/azure-monitor/platform/activity-log

But what if we want to retain longer?

• We have three options. We can either export the logs to an Azure Storage Account, Event Hub or to a Log Analytics workspace
  • These three export options have different use cases as I’ve highlighted in the diagram below

Can attackers delete or overwrite log entries?

• NO! Regardless of a user’s role, entries in the Activity log cannot be modified or deleted. They are automatically deleted from the platform after a 90 days ret remove themselves following 90 days.
  • This is great for forensics as both internal or external bad actors cannot delete or modify entries to cover their tracks
  • https://docs.microsoft.com/en-us/azure/azure-monitor/platform/activity-log

What can we do with it in Azure Monitor?

• Azure Monitor is the central unified monitoring service for the Azure platform. It has capabilities that ranges from collecting logs, to analyzing them, visualizing them and responding to them. Here are some of the capabilities that Azure monitor has for Activity logs:
  • View, Query and Filter using the Activity log menu
  • Configure alerts using an activity log alert rule
  • Configure activity log entries as a trigger for automated events
  • Export to a Log Analytics workspace for event correlation and further analysis