Azure Security Logging – part 2: security-logging capabilities of Azure resources

In this second blog post in a series about Azure Security Logging, we will focus on some of the key services that are used in most Azure deployments. We go into detail how logging can be enabled, what logging options are available and what relevant data is generated.

Log sources in Azure

At the moment of writing, Azure lists more than 600 services. In this blog series we only cover the key Azure services where logging must be enabled from a security perspective.  If you use additional services, enabling logging should be similar and should be enabled especially if they store or process sensitive data.

Activity Logs

As discussed in the first post in this series, Azure Activity Logs contains all write operations (PUT, POST, DELETE) against the Azure API. But unfortunately, they do not contain all read operation (GET) what would be valuable when doing threat hunting. Security Center alerts are also written to the Activity Log.

The Activity Log can be viewed in the Azure Portal, but they are only accessible here for 60 days. The data is stored in JSON format. The Activity Log for multiple subscriptions and regions can be exported to a Storage Account for archiving and sent to an Event Hub.

From within a Log Analytics workspace, it is possible to connect the Activity Log from multiple subscriptions to send the data to the workspace.

Activity Log:

  • Username
  • Name
  • On premise SID
  • IP address
  • Action
  • Result
  • Timestamp
  • Resource Type
  • Resource ID

Azure Active Directory

Azure Active Directory (AAD) is the Identity and Access management platform for your Azure infrastructure where user authentication takes place. This is one of the most critical services for protecting your Azure infrastructure so logging should definitely be enabled.

The export options are standard, and you have the options of enabling audit and sign-in logs. Sign-in logs are only available if you have an Azure AD Premium P1 or P2 license which is highly recommended for security logging. According to the Azure AD documentation, audit logs may have a latency of up to one hour.

Audit logs:

  • Device registration
  • Directory management
  • User management
  • Group management
  • Password management
  • App registration
  • Service principal management

logs:

  • Identity
  • Failed/success login
  • IP address
  • Location
  • OS version
  • Browser version
  • Conditional access policies
  • Accessed resource

NSG Flow Logs

Network Security Group (NSG) flow logs are a feature of Network Watcher that allows you to view information about inbound and outbound traffic through an NSG. Flow logs are very valuable for DFIR and at a minimum should enabled on all public facing NSG’s.

Network Watcher must be enabled per region and NSG Flow logs can be enabled per NSG and exported to a Storage Account and is stored in JSON format.

Enabling Traffic Analytics send the NSG Flow log data to a Log Analytics workspace and automatically visualizes it in dashboards created by Microsoft.

NSG Flow logs:

  • Mac address
  • Protocol
  • Allowed/denied
  • Inbound/outbound
  • Source/destination IP
  • Source/destination port
  • Number of source/destination packets
  • Number of source/destination bytes

Storage Accounts

Diagnostics logs for a Storage Account are called Storage Analytics and differs from other Azure services. Storage Analytics logs are stored in the Storage Account itself in a hidden $logs blob container that can be accessed through AZcopy, Storage Explorer, PowerShell or via the Azure API. Data is not stored in JSON format but in a semicolon delimited text file.

Storage Analytics is enabled by storage type and you have the option to collect metrics and access logs. Metrics can be interesting for threat hunting but at least access logs should be enabled for DFIR.

Storage Accounts logs cannot be exported out of the box but using Azure Automation Runbooks a work-around can be implemented.1

Storage Analytics log types:

  • Successful authenticated requests
  • Successful anonymous requests
  • Failed authenticated requests, including timeout, throttling, network, authorization, and other errors.
  • Failed anonymous GET requests with error code 304
  • Requests using a Shared Access Signature (SAS), including failed and successful requests.

Storage Analytics log data:

  • API endpoint
  • Authentication type
  • Data accessed
  • IP address
  • OS version
  • Browser version

Key Vault

Azure Key Vault is a service for securely storing keys, secrets and certificates used by your application running in Azure. It is best practice to store your secrets in a Key Vault instead of storing them hard coded in your source code, configuration files or environment variables.

As a Key Vault contains the keys to your kingdom, diagnostic logging should be enabled. The export options are archiving to a Storage Account, streaming to an Event Hub and sending logs to a Log Analytics workspace. You have the option to log audit events and metrics. Audit events should be enabled to have a complete audit trail of all your keys, secrets and certificates.

Key Vault audit logs:

  • Caller IP address
  • Identity
  • Client Info
  • Action
  • Result
  • Azure Resource ID
  • Azure Subnet ID
  • HTTP Status Code
  • Duration

In this blog post we have covered the security-logging capabilities of some of the key services used in Azure infrastructure. In upcoming blog posts in this series, we will discuss some more Azure services. Stay tuned!


2 thoughts on “Azure Security Logging – part 2: security-logging capabilities of Azure resources

Leave a Reply