Wazuh Microsoft Azure monitoring

Decide the source one log category at a time. Azure does not keep all of its logs in one place, and each source holds different data. Platform resource logs typically land in a Log Analytics workspace, identity and directory data is reached through Microsoft Graph, and exported logs can be written as files to Azure Storage blob containers. Start by listing the categories your detection and audit requirements need, such as sign-in activity, administrative changes or resource activity. For each one, note the subscription, tenant or resource it comes from. That list drives every other decision in this section, and it is the fastest way to find out which categories need a different path from the rest.

Each source also asks for a different identity and different permissions, and this is where most approval delays happen. Reading from a workspace requires an identity with a read role scoped to that workspace. Microsoft Graph access uses permissions that a tenant administrator must consent to, and those can be broad, so your security owner should review each one against the categories you selected. Blob storage access depends on how the export is configured and which authentication methods the module supports. Confirm the exact role names, permission identifiers and authentication options in the azure-logs module documentation before you request approval, and record who approves each one.

Latency and cost follow the path you choose. A workspace query reflects events as Azure ingests them. A storage export adds stages: the diagnostic configuration, the write to blob storage and the module's polling cycle. Graph data follows its own collection cadence and query limits. Ask your Azure team for the current ingestion and retention charges for each category you plan to forward, along with any export or storage transaction costs. Azure bills these on usage, so they recur for as long as the data flows. On the Wazuh side, ask your implementation partner to size indexer storage from the event volume you measure during a pilot. In the quote, ask for one-time setup effort and recurring run costs separately, and state which party owns each Azure bill.

Before you commit, run a short pilot in a non-production subscription. Pick one category per source, confirm that the module supports it and how it is queried, and measure the delay between an event in Azure and its appearance in the Wazuh dashboard. Check that your alert rules fire on test activity. Keep a decision table with the category, source, identity, observed latency, owner and cost owner for each row. Some activity inside virtual machines may be better covered by a Wazuh agent on the instance, which is a separate decision. Record any category without a confirmed module path as an open gap for your Azure and security teams to resolve before go-live.

Install Wazuh agents on an Azure virtual machine when you need host-level visibility that the azure-logs module cannot provide. The module collects control-plane and platform logs from Azure services, so it tells you what happened to a resource in your subscription. An agent on the VM tells you what happened inside the operating system: file integrity changes, process activity, local logs and the software inventory that Wazuh uses for vulnerability detection. If a workload on the VM is a regulated system of record, or if an attacker could act from inside the guest, you will usually need the agent even when the module is already running.

The trade-off is operational. Each agent must reach the Wazuh server over the network, so the VM's network security group, route table and any private DNS or firewall path must allow that traffic before the agent is useful. Every host then needs a deployment method, a way to upgrade the agent in step with the server, and an enrollment process that defines how new VMs register and how retired VMs are removed. Scale-set and autoscaling workloads add to this, because instances appear and disappear without manual steps. Ask your team who owns the agent lifecycle, and whether that owner can keep pace with the number of VMs in scope.

Agents and module collection usually complement each other rather than competing for the same data. The module brings in subscription-level events such as configuration changes to Azure resources, while agents bring in what happens on the guest. Plan for both where the workload justifies it, and document which source covers which detection use case so that a gap in one does not go unnoticed. Avoid building the design around one source alone.

Operating system matters because the Wazuh documentation describes agents for Linux, Windows, macOS, Solaris, AIX and HP-UX. Most Azure VM estates are Linux or Windows, and those are the common cases to confirm first. Before committing, check the exact distribution and version you run against the agent compatibility notes for your Wazuh release, and confirm support for any older or specialized images. A VM on an unsupported platform will need a different monitoring approach, such as syslog forwarding from the host or an agentless method, and that choice should be recorded in the design rather than discovered during rollout.

The first check before go-live is a known-activity test. In a non-production Azure tenant or subscription, generate a defined set of events, with one event for each log category you plan to collect in the azure-logs module, such as a sign-in, an activity log operation and a resource configuration change. Record the time you generated each event, the actor, the target resource and the operation name. Then confirm in the Wazuh indexer that each event arrived and carries the expected source fields, such as the log category, the tenant identifier and the operation. Field names depend on the decoders shipped with your Wazuh version, so check them against the decoder files in that version rather than against older examples or blog posts.

Next, confirm that the decoders and rules fire. An event can be stored in the index without being parsed, and an unparsed event will not trigger any rule. Check that the decoded fields are populated for each test event. Then trigger a case a rule in your chosen rule set is designed to flag, such as a change to a sensitive resource in the test subscription, and confirm the rule ID, level and description on the resulting alert. If an expected rule stays silent, work through the likely causes in order: whether the event was decoded, whether the decoded values match the rule conditions, and whether the rule is enabled in your deployment. Record any gaps rather than adjusting thresholds during the test.

Then confirm that a sample alert reaches the Wazuh dashboard. Check that the alert appears under the index pattern your analysts use, that it can be filtered by the tenant and log category fields, and that a user with the analyst role can see it. Compare the generation timestamp you recorded with the timestamp shown in the dashboard to confirm that time handling is consistent. Record the observed delay between generation and display for each category. Do not treat this delay as a target. Agree the acceptable value with the security operations owner before go-live, because it depends on how the alerts will be worked.

The final check is failure behavior. In the non-production tenant, revoke or disable the credential that the module uses: the app registration secret or certificate for Microsoft Graph or Log Analytics access, or the storage access for an Azure Storage collection, depending on the method you chose. Generate new activity and observe what happens. Look for the error in the Wazuh server logs, confirm whether collection stops silently, and check whether any health signal or alert tells operations that collection has failed. Restore the credential, confirm that collection resumes, and determine whether the events from the outage window are collected or lost. Document the result, because that window is a monitoring blind spot that the operations team must know about.

Keep the results in a test script or table with one row per log category. Include the generation action, the expected source fields, the expected decoder output, the expected rule IDs, the expected dashboard view, and the observed failure behavior. Store it with the configuration under version control so the same test can be repeated. Rerun the full sequence after any upgrade and after each Wazuh patch release you apply, because decoders and rules can change between releases. Comparing the new results with the recorded baseline shows quickly whether an upgrade broke parsing, detection or alert delivery.