Skip to content
    November 15, 2022

    A Guide To Microsoft Azure Security Logging

    Azure is an attractive option for organizations that use Microsoft 365 and other related Microsoft products, due to the various integrations with Azure and Azure Active Directory (AD). 

    However, many organizations quickly migrate to the cloud without considering the security ramifications, under the assumption that cloud security is automatic or inherent. Rather, the very nature of public cloud can leave these services open and ripe for exploitation when configured improperly. 

    Fortunately, Azure can generate security logs that provide comprehensive visibility into your environment. But which logs are most valuable and how should you collect them? We’ll delve into the best practices of Azure security logging.

    What is Azure?

    Azure is Microsoft’s public cloud offering. Microsoft hosts a variety of services and resources for organizations, which are usually charged based on time or utilization. This can be a subscription cost model or organizations can use reservations to reduce the cost.

    There are many Azure services available, including Azure virtual machines, SQL, and Kubernetes.

    Types of Azure Log Sources 

    Before you begin with a log management strategy, it’s important to first break down each of these log types and services and detail what logs you can expect, why they are useful, and what you can use them for.

    Azure Platform Logs

    These logs are generated by Azure itself and can be split into three sub-categories: resource logs, activity logs, and Azure AD logs.  

    You can integrate resource and activity logs with Azure Monitor via the Diagnostic Settings blade or you can deploy them via Azure Command-Line Interface (CLI) for automated configurations and setups, along with support for Azure Policies. 

    Since Azure AD is not part of Azure Monitor or your Azure subscriptions, configuration for those logs is slightly different. You can configure Azure AD logs within the portal.

    Resource Logs

    These logs are generated by the resources themselves where supported. They can include audit logs on actions performed within and by the resources such as read and write operations on storage accounts, network security flow logs, DDoS protection logs on virtual networks, and even metrics for certain resources. 

    Some resources do not generate resource logs such as certain compute-based resources or Managed Disks. Instead, actions taken on these resources are logged under activity logs.

    Metric logs can be noisy but depending on your particular needs, they can be useful for monitoring usage behavior. Audit log categories within these resources are the most important for security-related logging and monitoring.

    Activity Logs

    Activity logs are tied to each individual Azure subscription an organization has, and are generated each time someone logs into that subscription, modifies a resource or service, or takes an action that occurs within a subscription. These actions can include creating virtual machines or other resources, deleting resources, and using Azure PowerShell or CLI to connect or perform actions within your subscription. Azure activity logs also contain information about Azure resource health, subscription alerts, and more. 

    These logs by default are retained within Azure for 90 days. You can export these logs manually, or send them to a variety of destinations which will be covered later in this article. 

    With activity logs, you can discover incidents of service degradation and validate policies to ensure they are being applied or working as intended.

    Azure AD Logs

    These logs contain the sign-ins, device information, group modifications, and other user-related audit information. You can validate conditional access is working as intended, discover brute force attacks, see if a user has disabled multi-factor authentication, and more. 

    By default these logs are stored for 7 days, but you can extend these retention periods to 30 days with certain licenses such as Azure AD Premium series. Along with the other Azure platform logs, these can be invaluable from a security standpoint.

    Other Azure Logs

    There are other logs to consider that can come from Azure and the applications and resources you use. These products and services are extensions of platform logs and can be used to help provide even greater visibility for additional cost.

    • Microsoft Defender for Cloud. This product can provide you with greater visibility into your security posture within the Azure portal. Similar to Microsoft 365’s security portal, this will give you a Secure Score, provide remediations, and assist you in implementing best practices among other things. Defender is a growing product stack, these products can also be closely tied to Microsoft/Office 365 as well.
    • Microsoft Defender for Endpoint. This is Microsoft’s cloud-based endpoint protection service and application. This can be deployed as a standalone product or in conjunction with Microsoft’s Intune (aka Endpoint Manager) service. Logs generated by Defender for Endpoint also can be integrated with Azure Monitor through diagnostic settings and can provide visibility into the threats affecting your endpoints.
    • Microsoft Defender for Identity (aka Azure Advanced Threat Protection). This is Microsoft’s cloud-based identity security solution that enables you to find and detect potentially malicious activity such as insider threats and account compromises. These logs improve visibility into Azure AD; you can think of them as an extension to the platform logs that Azure AD provides. These logs can be integrated into Azure Event Hubs or Azure Storage for retention. You can integrate your on-premises Active Directory as well.
    • Microsoft Intune (aka Endpoint Manager). Audit logs of your endpoints, compliance logs, and operational logs can all be retrieved through Diagnostic Settings within the Endpoint Portal. These can be useful for monitoring your users’ workstations and remote endpoints now that remote work is on the rise. This is license-dependent and is sometimes included in other licenses through Microsoft 365. While not strictly found within the Azure portal, it does leverage Azure as its host and inherits certain qualities found within other Azure resources.

    Which Logs Should You Monitor?

    Now that you understand the different types of logs, you might be asking yourself, “What do I need to collect and monitor?” 

    Platform logs — which include resource logs, activity logs, and Azure AD logs, are a necessity, as these logs will give you greater visibility with a high level of fidelity. No additional licenses or plans are required, outside of Azure AD logging. 

    If you have the licenses or use Microsoft 365 for your organization, consider logging Azure AD. These logs provide more detailed information about sign-ins, not just on the Azure side of the platform but also in Outlook (or OWA) and other various Microsoft 365 apps and services.

    If you are using services and products in the Other Azure Logs category, you should log them. If you are not receiving logs from these products you are missing a large portion of the value that these products bring.

    How To Collect and Monitor Azure Logs

    The big question that we see come up quite frequently is the “How?” of it all: How do you turn on these settings for platform logs and the other services that exist outside of your Azure subscription? 

    While platform logs and the other log categories are enabled and visible within the portal, this is often not the best for workflows, detecting trends, and running queries. For that you need to enable a few things and choose where you want these logs to go.

    You may have different retention requirements due to compliance, have a favorite data analytics tool to view this type of data, or have a SIEM like Blumira. Azure gives you plenty of options and integrations to support your use case and needs through the Diagnostic Settings blade on platform logs and other logs. The outlier here would be Defender for Microsoft 365 and Identity, which have a separate portal more similar to Microsoft 365.

    Here are some ways to collect Azure logs: 

    Azure Storage

    These are storage accounts that you can leverage for archival storage. Depending on how much data you want to retain and how you want to retain it, this can be a recurring cost that is often hard to plan for reliably. You can export or download the data from a storage account, but Azure does charge for data egress coming from Azure data centers. Data flowing from Azure to Azure — such as reading or downloading the data to a virtual machine hosted in Azure — won’t have a cost for egress, but storage costs would increase.

    If all you need is to retain the data, archive tier storage accounts are not a bad idea. While storage accounts allow for you to pull the data at any point — for example, in the middle of an audit — it’s not generally enough to simply store logs, especially without a SIEM or another tool. Actively reviewing, self-auditing, and monitoring logs will offer far better protection.

    Log Analytics Workspaces

    This data collection option is often better than using Azure Storage since it allows you to configure your workspace to be able to run queries and analyze the log data you are collecting.

    The costs for this are much higher, but there is a lot of value in being able to use the data Azure generates. Dashboard creation, alerting from logs, integration with other Microsoft services, and long term storage (up to 7 years) are some of the highlights of what’s possible with Log Analytics Workspaces.

    Event Hubs

    Event Hubs are the go-to option for exporting log data from Azure to external sources. SIEMs like Blumira, Logstash, or other analytics tools can poll, ingest, and aggregate the data. This is useful if you have these tools on premises or hosted elsewhere, such as other cloud providers or cloud-based solutions. Typically this data is integrated using APIs or other tie-ins.

    You do have to consider the cost of the Event Hub namespace, Event Hub, and egress charges. However, if you’re hosting your external source or SIEM on-premises, then you don’t have to pay for Azure storage and retention. You, or your hosting solution, is responsible for the storage and retention of the log data.

    How To Collect Azure Logs With Blumira

    Blumira offers integrations with Azure for log collection using Event Hubs. We even offer a script to jumpstart your Azure environment’s integration with Blumira that saves you time and gets you logging faster. 

    The manual steps and script to deploy settings allow you to start getting Azure activity logs and Azure resource logs using the diagnostic settings in Azure Monitor. You can see in the screenshot below an example of what a configured environment can look like.

    Manually configuring resources and diagnostic settings in general is not a difficult process. The broad steps are to create an Event Hubs Namespace, Event Hub, create a permission for Blumira to read the data from the Event Hub, and then to configure the resources and subscription to ship logs to the Event Hub as seen in the screenshot below.

    Once you’ve configured your resource settings, you can do the same for the activity logs for the subscription. Here’s an example of a configured subscription.

    Our detailed instructions for configuring the various integrations with Azure, Event Hubs, and the related Azure AD logs can be found within our Support portal accessible within the Blumira app.

    Detecting Threats in Azure with Blumira

    Blumira offers several detections for Azure and the related resources to help you  detect threats quickly and easily. Some of my personal favorite detections that we offer are below. 

    Keep in mind that these detections are near instant or what we would call Indicators. These Indicators will flag as soon as Blumira receives a corresponding log entry that matches the rule.

    • Azure Identity Protection Risky Sign-in. In short, this rule relies on Azure sign-in logs from Azure AD and will alert you when Azure deems a sign-in as risky.
    • Azure AD – Conditional Access Policy Added/Modified/Deleted. This Azure AD-based rule will detect if your Conditional Access (CA) policies have been created, modified, or deleted. This can alert you to potential malicious behavior or to new policies so you can review if they are legitimate or malicious in nature. This is also useful for rule validation, as well as keeping track of who is making changes to your CA policies and when they occurred, allowing you to keep better track of those changes.
    • Disabling of Multi-Factor Authentication on Azure AD User. This Azure AD based rule will detect if a user has had their multi-factor authentication (MFA) disabled. This is incredibly powerful these days, considering the protection that Azure AD’s MFA brings to your users and your environment. This detection will allow you to detect, for example, i a bad actor attempts to disable MFA for a singular user or for multiple users to bypass authentication protections and respond quickly.
    • Successful Single Factor PowerShell Authentication. This detection can help you find potentially malicious PowerShell access into your Azure environment. Azure PowerShell is incredibly powerful, allowing you to create subscriptions, edit virtual machines, access data within storage accounts, and so much more. Almost everything you can do in the Azure Portal is available through PowerShell, so visibility in this tool is invaluable for protecting your cloud environment.
    • T1078.004 AzureAD Anomalous Agent Sign-in Activity. This Azure AD rule can find and detect odd or unusual sign-ins, capturing the IP address and some device information which can speed up time to detection and investigating these sign-ins. This rule relies on Azure AD’s classification of what is considered anomalous based on prior sign-in activity.

    How Blumira Improves Azure Security Logging

    Traditional SIEMs would require you to parse each of the various logs you are ingesting from Azure. They’d also require you to write detection rules, manage the infrastructure, storage, and retention of the log data. Blumira stores and retains Azure log data for 1 year by default. 

    This is usually too much work for many organizations who may not have a large IT team, lack a dedicated security team, or have limited resources to store and retain this data.

    Blumira helps to alleviate the gaps for these organizations and speed up the time to ingest logs and detect threats within Azure. Blumira does things differently by providing more value for better security outcomes, including:

    • Automate Tasks For You – We do all the heavy lifting for your team to save them time, including parsing, creating native third-party integrations, and testing and tuning detection rules to reduce noisy alerts.
    • Faster Time to Security – Our unique approach to detections notifies you of threats other security tools may miss, sending you real-time alerts in under a minute of initial detection to help you respond to threats faster than ever.
    • Easily Meet Compliance – With a year of data retention and deployment that takes minutes to hours, we help you meet cyber insurance and compliance easily and quickly with the team you have today.

    Blumira’s free edition integrates directly with your Microsoft 365 tenant to detect suspicious activity in your environment at no cost, and comes with a variety of Azure-related detections, including:

    • Azure AD: Group changes
    • Azure AD: Account was disabled
    • Azure AD: User or device added

    And more! Get your free account and see the value of Blumira today.

    Sign Up Free

    Justin Kikani

    At Blumira, Justin helps to craft detection rules as part of the Incident Detection Engineering team. Prior to joining the team, he was the Director of IT at Nexus Direct, where he supported the company in its transition to a remote infrastructure. Before that, he held various IT and engineering roles, including a...

    More from the blog

    View All Posts