Sorry, you need to enable JavaScript to visit this website.

How to set up logging and detection basics with Microsoft Sentinel or Wazuh


At a glance

Audience
IT & security teams
Difficulty
Intermediate
Time needed (minutes)
240 min
Last reviewed

What you need

  • An Azure subscription with Contributor rights (for Microsoft Sentinel) or a Linux server (for Wazuh)
  • A list of your critical systems and log sources
  • Budget approval for log ingestion or storage

When an incident hits, the first question is what happened, and the answer lives in logs. Many small and mid-sized organizations discover too late that the logs they needed were never collected, were kept for only a few days or were stored on the very system the attacker controlled. This guide covers a practical baseline, then shows two ways to build it: Microsoft Sentinel for organizations already invested in Microsoft 365 and Azure, or Wazuh, a free open-source platform you run yourself.

Step 1: Write a short logging policy

In August 2024, the Australian Signals Directorate published Best practices for event logging and threat detection with partners including the Canadian Centre for Cyber Security (Cyber Centre), CISA and the U.K. NCSC. It sets a baseline that takes resourcing limits into account. Its themes translate into a one-page policy:

  1. Name which events you will capture, from which systems, and who reviews them.
  2. Send logs to a central location the source systems cannot alter or delete.
  3. Synchronize time on every system so events can be put in order. Record time zones consistently.
  4. Set retention long enough to investigate intrusions that go unnoticed for weeks or months, within your budget and privacy obligations.
  5. Protect the logs themselves: restrict who can read them (they contain personal information) and who can change retention.

Step 2: Prioritize log sources

Start with the sources that catch the most common attacks:

  • Identity: Microsoft Entra ID sign-in and audit logs, Active Directory domain controller security logs.
  • Edge devices: VPN, firewall and remote-access gateways. The Cyber Centre recommends alerting on successful administrator logons and configuration changes on these devices.
  • Endpoints: endpoint detection and response (EDR) alerts, plus Windows security events and PowerShell logging on servers.
  • Email and collaboration: Microsoft 365 audit logs, mailbox rule changes, sharing events.
  • Cloud control plane: Azure Activity logs or the equivalent for AWS and Google Cloud.
  • DNS and proxy: useful for spotting command-and-control traffic.

Option A: Microsoft Sentinel

Microsoft Sentinel is a paid, cloud-based SIEM built on a Log Analytics workspace. Microsoft is moving it into the unified Microsoft Defender portal at security.microsoft.com, and says the Sentinel experience in the Azure portal will be retired on March 31, 2027, a date pushed back from July 2026. New customers with Owner or User Access Administrator rights are onboarded straight to the Defender portal. Build your procedures there.

Step 3A: Enable Sentinel

  1. Confirm you have Contributor rights on the subscription, and Microsoft Sentinel Contributor on the resource group.
  2. In the Azure portal, search for Microsoft Sentinel, select Create, then Create a new workspace (or pick an existing one) and select Add. Choose a Canadian region if data residency matters to your clients.
  3. Raise workspace retention to at least 90 days; Microsoft notes some legacy tiers default to 30.
  4. Open the Defender portal. Sentinel appears in the navigation pane, and Settings > Microsoft Sentinel > Workspaces shows connected workspaces.

Step 4A: Connect data and turn on detections

  1. In Sentinel, open Content hub and install solutions for your sources, for example Microsoft Entra ID, Microsoft 365, Azure Activity and your firewall vendor.
  2. Go to Configuration > Data connectors, select each connector and choose Open connector page to finish setup. Non-Microsoft devices usually connect through Syslog or Common Event Format.
  3. From the content hub, create analytics rules from the solution templates, starting with sign-in anomalies, mass file deletion and suspicious mailbox rules.
  4. Add a rule that alerts whenever an emergency access (break-glass) account signs in.
  5. Set a daily ingestion cap or alert on costs; log volume drives the bill.

Option B: Wazuh

Wazuh is an open-source security platform with an indexer, server and dashboard, plus agents for Windows, macOS and Linux. It is free to use; you pay in hardware and staff time.

Step 3B: Install the central components

  1. Provision a 64-bit Linux server (supported options include Ubuntu 22.04 or 24.04 and Red Hat Enterprise Linux 9 or 10). For up to 25 agents and 90 days of data, Wazuh documents 4 vCPU, 8 GiB of RAM and 50 GB of storage; 51 to 100 agents need 8 vCPU and 200 GB.
  2. Run the all-in-one installer described in the Wazuh quickstart (version 4.14 at the time of writing).
  3. Sign in to the dashboard at the server's address as admin with the password printed at the end of the install. Replace the self-signed certificate and store the generated password file securely.

Step 4B: Enrol agents and forward device logs

  1. Deploy agents to servers first, then to workstations.
  2. Send firewall and VPN logs by syslog to the Wazuh server.
  3. Review the built-in rules and file integrity monitoring, then tune noisy rules rather than ignoring them.

Step 5: Test that detections fire

  1. Generate safe test events: a failed sign-in burst on a test account, a new mailbox forwarding rule, an administrator logon to the firewall.
  2. Confirm each produces an alert, reaches the right person and has a written response step.
  3. Repeat after any major change to log sources.

Choosing between the two

Sentinel suits teams that already hold Microsoft 365 or Defender licences, want built-in connectors and prefer paying for a managed cloud service over running servers. Wazuh suits teams with Linux skills and tight budgets, or those that want logs kept on hardware they control. Either works only if the log sources in Step 2 actually reach it, so check connector status weekly during the first month.

Step 6: Make someone responsible

Tools do not watch themselves. Assign a person or a managed detection provider to review alerts daily, and set out-of-hours escalation for high-severity alerts. Log a short weekly summary: alerts received, false positives tuned, gaps found. Review your log sources and retention twice a year against the Five Eyes baseline.

Sources

 

Editor's Picks

The best of cybersecuritynews.ca, delivered to you weekly.

On Display

Exposed to PHP2Shell? Cyber Experts Weigh in With Advice

PHP

PHP shares mitigation for new RCE vulnerability with no patch

Data breach from Crime Stoppers

Millions of Crime Stoppers tips exposed