2026-08-01 · 9 min read · Infrastructure Revamp

Mastering Microsoft Sentinel SIEM Setup for SMBs: An Implementation Guide by SkyCore Solutions

A vibrant Microsoft Sentinel dashboard displaying security events, threat intelligence, and incident management views, symbolizing robust SIEM setup for an SMB.

In today's evolving threat landscape, Small to Medium-sized Businesses (SMBs) are increasingly targeted, often lacking the dedicated security teams of larger enterprises. Implementing a robust Security Information and Event Management (SIEM) solution is no longer a luxury but a necessity to protect digital assets. Microsoft Sentinel offers a cloud-native, AI-driven SIEM platform that scales cost-effectively, making it an ideal choice for SMBs looking to enhance their security posture without significant upfront infrastructure investment. This guide from SkyCore Solutions will walk you through a comprehensive, authoritative Microsoft Sentinel SIEM setup for SMBs, enabling you to detect, investigate, and respond to threats efficiently. By the end of this guide, you will have a foundational Microsoft Sentinel environment configured, ingesting critical security logs, and actively detecting threats within your Azure and Microsoft 365 ecosystems.

Prerequisites

Step 1: Prepare Your Azure Environment and Log Analytics Workspace

Before deploying Microsoft Sentinel, you need a dedicated Azure Resource Group to logically organize your resources and a Log Analytics workspace. This workspace acts as the central data store for all logs that Microsoft Sentinel will analyze. For SMBs, we recommend a single, well-managed workspace.

# Define variables for your deployment
$RESOURCE_GROUP_NAME="SkyCore-Sentinel-RG"
$LOCATION="eastus"
$WORKSPACE_NAME="SkyCore-Sentinel-Workspace"

# 1. Create a Resource Group
az group create --name $RESOURCE_GROUP_NAME --location $LOCATION

# 2. Create a Log Analytics Workspace
az monitor log-analytics workspace create \
    --resource-group $RESOURCE_GROUP_NAME \
    --workspace-name $WORKSPACE_NAME \
    --location $LOCATION \
    --sku PerGB2018 \
    --retention-time 90

Portal alternative:

  1. Sign in to the Azure portal.
  2. Search for "Resource groups" and click "Create". Provide the resource group name (e.g., SkyCore-Sentinel-RG) and region (e.g., East US).
  3. Search for "Log Analytics workspaces" and click "Create". Select the newly created resource group, provide a workspace name (e.g., SkyCore-Sentinel-Workspace), and choose the same region. Under "Pricing tier", select "Per GB (2018)". Navigate to "Retention" and set it to "90 days" (or more if compliance requires).

Run this to verify:

az monitor log-analytics workspace show --resource-group $RESOURCE_GROUP_NAME --workspace-name $WORKSPACE_NAME --query "{name:name,sku:sku.name,retentionDays:retentionInDays}"
Pro tip: While the PerGB2018 SKU is flexible, continuously monitor your data ingestion volume. If your daily ingestion consistently exceeds 5-10 GB, consider evaluating a Capacity Reservation tier to potentially reduce costs in the long run. Use Azure Cost Management to track your Log Analytics costs closely.

Step 2: Onboard Microsoft Sentinel to Your Workspace

With your Log Analytics workspace ready, the next step is to enable Microsoft Sentinel on it. This action activates Sentinel's powerful SIEM and SOAR (Security Orchestration, Automation, and Response) capabilities, allowing you to centralize security event collection and analysis.

# Onboard Microsoft Sentinel to the Log Analytics Workspace
az sentinel create \
    --resource-group $RESOURCE_GROUP_NAME \
    --workspace-name $WORKSPACE_NAME

Portal alternative:

  1. Sign in to the Azure portal.
  2. Search for "Microsoft Sentinel" and select it.
  3. Click "Create".
  4. You will see a list of Log Analytics workspaces. Select the SkyCore-Sentinel-Workspace you created in Step 1 and click "Add".
  5. Allow a few minutes for the onboarding process to complete.

Run this to verify:

az sentinel workspace list-incidents --resource-group $RESOURCE_GROUP_NAME --workspace-name $WORKSPACE_NAME --query "length(@)"

This command attempts to list incidents. If it executes successfully (even if it returns 0, meaning no incidents yet), it confirms Sentinel is active on the workspace.

Common pitfall: Once deployed, moving a Microsoft Sentinel-enabled Log Analytics workspace to another resource group or subscription is NOT supported. Plan your resource group and subscription strategy carefully from the start, especially if you anticipate future organizational changes or tenant migrations.

Step 3: Connect Essential Data Sources for Comprehensive SMB Security

To detect threats effectively, Microsoft Sentinel needs data. For SMBs, integrating foundational Microsoft services is paramount. We'll focus on connecting Microsoft Entra ID (Azure Active Directory) for identity logs and Azure Activity for control plane operations, as these provide immediate and critical visibility into your cloud environment. The most efficient way to onboard these for SMBs is often by installing the relevant "solutions" from the Content Hub or directly via the Data Connectors blade.

# Define variables
$ResourceGroupName = "SkyCore-Sentinel-RG"
$WorkspaceName = "SkyCore-Sentinel-Workspace"

Write-Host "For Azure AD, Azure Activity Logs, and Microsoft 365 Defender, SkyCore Solutions recommends using the Azure portal's Sentinel Data Connectors or Content Hub for initial setup to ensure all dependencies and configurations are correctly applied for SMBs. There is no direct, universal CLI/PowerShell command to enable all aspects of these high-level service-to-service connectors automatically due to their integrated nature."
Write-Host "You would typically configure diagnostic settings for specific Azure AD log categories (e.g., SigninLogs, AuditLogs) and for Azure Activity logs to stream to your Log Analytics workspace."

# Example of what *would* be done conceptually for diagnostic settings for Azure AD:
# (This is illustrative; actual implementation for Azure AD tenant requires specific Graph API or Azure Portal steps)
# az monitor diagnostic-settings create \
#     --name "AzureAD-to-Sentinel" \
#     --resource "/providers/Microsoft.AzureActiveDirectory/diagnosticsSettings/<tenant_id>" \
#     --workspace $WORKSPACE_ID \
#     --logs '[{"category": "AuditLogs", "enabled": true}, {"category": "SigninLogs", "enabled": true}]'

# For Microsoft 365 Defender, it's a one-click integration in the portal.
Write-Host "Ensure relevant 'Solutions' are installed from the Content Hub (e.g., Azure Active Directory, Azure Activity) to get pre-built analytics and workbooks."

Portal alternative (Recommended for Data Connectors):

  1. In the Azure portal, navigate to your Microsoft Sentinel workspace.
  2. From the Sentinel navigation menu, select "Content hub". Search for "Azure Active Directory" and "Azure Activity" solutions. Click on each and select "Install" if not already installed. This typically includes the data connectors and pre-built content.
  3. Alternatively, select "Data connectors" from the Sentinel navigation menu.
  4. Search for "Azure Active Directory" and click on it. Select "Open connector page". Follow the instructions under "Configuration" to configure diagnostic settings to stream logs (e.g., AuditLogs, SigninLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs) to your Log Analytics workspace.
  5. Repeat for "Azure Activity". For Azure Activity, ensure your subscription's activity logs are sent to the Log Analytics workspace.
  6. If you have Microsoft 365 Business Premium or higher, search for "Microsoft 365 Defender". Select "Open connector page" and click "Connect". This connector brings in logs from various M365 services (e.g., M365 Audit Logs, Azure AD, Defender for Endpoint).

Run this to verify:

# Check if data is flowing for AzureActivity (wait a few minutes after connecting)
az monitor log-analytics query --workspace $WORKSPACE_NAME --analytics-query "AzureActivity | take 10"

# Check for Microsoft Entra ID Sign-in logs
az monitor log-analytics query --workspace $WORKSPACE_NAME --analytics-query "SigninLogs | take 10"

# Check for Microsoft 365 Defender (if connected and data has started flowing)
az monitor log-analytics query --workspace $WORKSPACE_NAME --analytics-query "AlertEvidence | take 10"
Pro tip: Start with essential Microsoft data sources. Once those are stable, consider adding other critical data sources like firewalls (via Syslog/CEF), Microsoft Defender for Endpoint (if not using M365D connector), or cloud infrastructure logs (AWS/GCP if applicable). Focus on data that provides high security value first to manage costs.

Step 4: Enable Built-in Threat Detection and Analytics Rules

With data flowing into Sentinel, the next step is to activate its intelligence to detect threats. Microsoft Sentinel provides numerous out-of-the-box analytics rules, which significantly reduce noise and group related alerts into actionable incidents. For SMBs, starting with these built-in rules is the most efficient approach.

# Define variables
$ResourceGroupName = "SkyCore-Sentinel-RG"
$WorkspaceName = "SkyCore-Sentinel-Workspace"

# Get pre-built analytics rules that are currently disabled
$rulesToEnable = Get-AzSentinelAnalyticsRule \
    -ResourceGroupName $ResourceGroupName \
    -WorkspaceName $WorkspaceName \
    | Where-Object { $_.Kind -ne 'Fusion' -and $_.Enabled -eq $false -and $_.Query -ne $null }

# Enable a selection of high-value, built-in rules for SMBs. Fusion rule is auto-enabled.
$highValueRules = @(
    "Multiple failed sign-ins to non-existent accounts",
    "Suspicious sign-in activity",
    "Unusual resource deployment",
    "Impossible travel activity",
    "Multi-stage attack detected by Microsoft Defender XDR" # If M365D connector is active
)

foreach ($ruleName in $highValueRules) {
    $rule = $rulesToEnable | Where-Object { $_.DisplayName -eq $ruleName }
    if ($rule) {
        Write-Host "Enabling analytics rule: $($rule.DisplayName)"
        $rule.Enabled = $true
        $rule | Update-AzSentinelAnalyticsRule
    } else {
        Write-Host "Rule '$ruleName' not found or already enabled, or its query is null."
    }
}

# The 'Fusion' rule is Microsoft's AI-driven detection. It is usually enabled by default and cannot be disabled manually via this method.
# You can verify its status via the portal if needed.

Portal alternative:

  1. In the Azure portal, navigate to your Microsoft Sentinel workspace.
  2. From the Sentinel navigation menu, select "Analytics".
  3. Go to the "Rule templates" tab.
  4. Filter by "Data connectors" to see rules relevant to your connected sources (e.g., "Azure Active Directory" or "Azure Activity").
  5. Select high-priority rules (e.g., "Suspicious sign-in activity", "Impossible travel activity", "Multiple failed sign-ins"). Click "Create rule" or "Enable" for each. Review the settings, ensuring "Enable rule at time of creation" is selected, and then "Review and create".
  6. Under the "Active rules" tab, verify your newly enabled rules. Ensure the "Fusion" rule is active.

Run this to verify:

Get-AzSentinelAnalyticsRule -ResourceGroupName $ResourceGroupName -WorkspaceName $WorkspaceName | Where-Object { $_.Enabled -eq $true } | Select-Object DisplayName, Status

Step 5: Configure Basic Incident Investigation and Automated Response

Effective SIEM goes beyond detection; it includes rapid investigation and response. For SMBs, establishing a basic automation rule can significantly reduce alert fatigue and accelerate initial response to common, high-confidence threats. We'll set up a simple automation rule to change the status of an incident upon creation, signaling it's being reviewed.

# Define variables
$RESOURCE_GROUP_NAME="SkyCore-Sentinel-RG"
$WORKSPACE_NAME="SkyCore-Sentinel-Workspace"

# Create an Automation Rule to set incident status to 'Active' upon creation
az sentinel automation-rule create \
    --resource-group $RESOURCE_GROUP_NAME \
    --workspace-name $WORKSPACE_NAME \
    --name "Set New Incidents to Active" \
    --order 1 \
    --triggers-on IncidentCreation \
    --actions '[{"actionType": "Incident", "parameters": {"classification": null, "classificationComment": null, "severity": null, "owner": null, "status": "Active"}, "order": 1}]' \
    --display-name "Set New Incidents to Active" \
    --rule-type Playbook \
    --enable-rule true

Portal alternative:

  1. In the Azure portal, navigate to your Microsoft Sentinel workspace.
  2. From the Sentinel navigation menu, select "Automation".
  3. Go to the "Automation rules" tab and click "Create" > "Add new rule".
  4. Provide a "Rule name" (e.g., "Set New Incidents to Active").
  5. Under "When incident is created", ensure "When incident is created" is selected.
  6. Under "Actions", click "+ Add action", choose "Change status", and set "Status" to "Active".
  7. Click "Apply" and then "Create".

Run this to verify:

az sentinel automation-rule list --resource-group $RESOURCE_GROUP_NAME --workspace-name $WORKSPACE_NAME --query "[?displayName == 'Set New Incidents to Active'].{Name:displayName,Enabled:enabled,Order:order}"

When to bring in a consultant

While this guide provides a solid foundation for your Microsoft Sentinel SIEM setup for SMBs, several scenarios warrant specialized assistance. If your environment includes complex hybrid Active Directory infrastructures, requires deep integration with diverse third-party security tools (e.g., specialized firewalls, EDR solutions), or demands advanced custom threat intelligence feeds, a consultant can be invaluable. Additionally, navigating intricate regulatory compliance requirements (like HIPAA, PCI DSS) or designing custom SOAR playbooks for automated remediation often benefits from expert guidance. SkyCore Solutions excels in tailoring Microsoft Sentinel deployments to meet unique SMB challenges, ensuring optimal security posture and operational efficiency.

Book a free consultation

References