Module 13 — Copilot for Security & Microsoft Sentinel Integration¶

1 — Copilot for Security Overview¶

Microsoft Copilot for Security reached General Availability (GA) in April 2024. It is an AI-powered security assistant built on large language models, grounded in Microsoft's global threat intelligence and your organization's own security data. Copilot operates through a natural language interface — you describe what you want in plain English (or other supported languages) and Copilot translates your intent into queries, investigations, and recommendations.

How It Works¶

flowchart LR
    A[Security Analyst] -->|Natural language prompt| B[Copilot for Security]
    B --> C{Plugin Router}
    C --> D[Azure WAF Plugin]
    C --> E[Sentinel Plugin]
    C --> F[Defender XDR Plugin]
    C --> G[Threat Intelligence Plugin]
    D --> H[WAF Logs & Policies]
    E --> I[Sentinel Workspace]
    B -->|Grounded response| A

Key characteristics:

2 — Copilot for WAF — Use Cases¶

The Azure WAF plugin for Copilot for Security enables analysts to interact with WAF telemetry conversationally. Instead of writing KQL from scratch, you describe what you need and Copilot generates the query, executes it, and summarizes the results.

Example Prompts and Expected Outputs¶

Below are practical prompts you can use in Copilot, along with descriptions of what each returns:

3 — Copilot WAF Plugin Capabilities¶

The Azure WAF plugin exposes a structured set of capabilities that Copilot can invoke:

4 — Microsoft Sentinel Overview¶

Microsoft Sentinel is a cloud-native Security Information and Event Management (SIEM) and Security Orchestration, Automation, and Response (SOAR) solution built on top of Azure Monitor and Log Analytics.

flowchart TB
    subgraph Data Sources
        A[Azure WAF Logs]
        B[Azure AD / Entra ID]
        C[Microsoft Defender XDR]
        D[Third-Party Feeds]
    end
    subgraph Microsoft Sentinel
        E[Data Connectors]
        F[Log Analytics Workspace]
        G[Analytics Rules]
        H[Workbooks]
        I[Hunting Queries]
        J[Incidents]
        K[Playbooks / Logic Apps]
    end
    A & B & C & D --> E --> F
    F --> G --> J
    F --> H
    F --> I
    J --> K

Sentinel's value for WAF operations lies in correlation. A WAF block in isolation tells you a rule matched. Sentinel can correlate that block with sign-in anomalies from Entra ID, endpoint alerts from Defender, and threat intelligence to determine whether the block is part of a larger attack campaign.

Core Components¶

5 — Connecting WAF to Sentinel¶

If you followed Module 12 and configured your WAF diagnostic logs to flow to a Log Analytics workspace, you are already 80% done. Sentinel is enabled on top of an existing Log Analytics workspace — the same data that powers your KQL queries and workbooks becomes available to Sentinel's analytics engine.

Step-by-Step: Enable Sentinel¶

# Enable Sentinel on an existing Log Analytics workspace
az sentinel onboarding-state create \
  --resource-group "rg-waf-workshop" \
  --workspace-name "law-waf-workshop" \
  --name "default"

# Verify Sentinel is active
az sentinel onboarding-state show \
  --resource-group "rg-waf-workshop" \
  --workspace-name "law-waf-workshop" \
  --name "default"

Verifying WAF Data in Sentinel¶

After enabling Sentinel, navigate to Sentinel → Logs and run:

AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"
| take 10

If results appear, your WAF data is accessible to Sentinel's analytics engine.

6 — Sentinel Analytics Rules for WAF¶

Analytics rules are the detection engine of Sentinel. Each rule runs a KQL query on a schedule and creates an Incident when the query returns results. Below are three production-ready rule definitions for WAF scenarios.

Rule 1: High-Volume WAF Blocks from Single IP¶

This rule detects potential brute-force or DDoS-layer-7 attacks where a single IP accumulates more than 100 blocks in a 5-minute window:

// Sentinel Analytics Rule: High Volume WAF Blocks
// Frequency: Every 5 minutes | Lookback: 5 minutes | Severity: High
AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"
| where action_s == "Blocked"
| summarize
    BlockCount = count(),
    DistinctRules = dcount(ruleId_s),
    TargetedURIs = make_set(requestUri_s, 10),
    FirstBlock = min(TimeGenerated),
    LastBlock = max(TimeGenerated)
  by clientIp_s
| where BlockCount > 100
| extend
    IPCustomEntity = clientIp_s,
    Description = strcat("IP ", clientIp_s, " triggered ", BlockCount, " WAF blocks across ", DistinctRules, " distinct rules")

Rule 2: SQL Injection Campaign Detection¶

This rule identifies coordinated SQL injection attacks — multiple SQLi rule matches from the same source within a short window, targeting different URIs:

// Sentinel Analytics Rule: SQL Injection Campaign
// Frequency: Every 10 minutes | Lookback: 10 minutes | Severity: High
AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"
| where ruleGroup_s has "SQLI" or ruleGroup_s has "SQL"
| where action_s in ("Blocked", "Detected")
| summarize
    SQLiHits = count(),
    DistinctRules = dcount(ruleId_s),
    TargetedURIs = dcount(requestUri_s),
    URISamples = make_set(requestUri_s, 5),
    RulesSamples = make_set(ruleId_s, 10),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)
  by clientIp_s
| where SQLiHits > 10 and DistinctRules > 2
| extend
    IPCustomEntity = clientIp_s,
    Description = strcat("Potential SQLi campaign from ", clientIp_s, ": ", SQLiHits, " hits across ", TargetedURIs, " URIs using ", DistinctRules, " distinct rules")

This rule requires both volume (>10 hits) and diversity (>2 distinct rules) to avoid alerting on single-rule false positives.

Rule 3: Anomalous Geographic Access Pattern¶

This rule detects WAF blocks from countries that have not appeared in your traffic baseline during the previous 14 days — a potential indicator of a new attack source:

// Sentinel Analytics Rule: Anomalous Geo Access
// Frequency: Every 1 hour | Lookback: 1 hour | Severity: Medium
let baseline = AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"
| where TimeGenerated between(ago(14d) .. ago(1h))
| distinct client_country_s;
AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"
| where action_s == "Blocked"
| where TimeGenerated > ago(1h)
| where client_country_s !in (baseline)
| summarize
    BlockCount = count(),
    DistinctIPs = dcount(clientIp_s),
    SampleIPs = make_set(clientIp_s, 5)
  by client_country_s
| where BlockCount > 5
| extend Description = strcat("New source country detected: ", client_country_s, " with ", BlockCount, " blocks from ", DistinctIPs, " IPs")

7 — Sentinel Workbooks for WAF¶

Sentinel workbooks extend the Azure Monitor Workbooks concept with security-focused templates. A WAF security dashboard in Sentinel should include the following panels:

To create a workbook:

1. Navigate to Sentinel → Workbooks → + Add workbook.
2. Click Edit to enter the workbook editor.
3. Add a Query step for each panel above.
4. Set the visualization type (chart, table, map) for each step.
5. Add a Parameter step at the top with a time range picker.
6. Click Save and assign it to a resource group.

8 — Playbook Automation¶

Sentinel playbooks are Azure Logic App workflows that execute automatically when an analytics rule fires. They enable automated response without human intervention — critical for high-volume WAF scenarios.

Example: Auto-Block Attacking IP¶

When the "High Volume WAF Blocks" analytics rule creates an incident, a playbook can automatically add the offending IP to a WAF custom rule that blocks it at the edge:

flowchart LR
    A[Sentinel Analytics Rule fires] --> B[Incident created]
    B --> C[Playbook triggered]
    C --> D[Extract IP from incident entities]
    D --> E[Check IP against allow-list]
    E -->|Not in allow-list| F[Add IP to WAF custom deny rule via Azure REST API]
    E -->|In allow-list| G[Add comment to incident: IP is allow-listed]
    F --> H[Add comment to incident: IP blocked]
    H --> I[Close incident as True Positive]

Playbook Implementation Steps¶

1. Create a Logic App with the Microsoft Sentinel incident trigger.
2. Add an action to parse the incident entities and extract the IP address.
3. Add a Condition to check the IP against a known allow-list (stored in a SharePoint list, Key Vault, or hardcoded).
4. If not allow-listed, use an HTTP action to call the Azure Management REST API:
   • PUT to update the WAF policy's custom rules, adding a match condition for the offending IP with Block action.
5. Add a Sentinel — Add comment to incident action to document the automated response.
6. Optionally close the incident as True Positive with a classification reason.

PowerShell: Add IP to WAF Custom Rule¶

If you prefer a script-based approach over Logic Apps, the following PowerShell snippet adds an IP to an existing WAF policy's custom rules:

# Requires Az.Network module
$policy = Get-AzApplicationGatewayFirewallPolicy `
  -Name "pol-prod-frontend" `
  -ResourceGroupName "rg-waf-workshop"

$newRule = New-AzApplicationGatewayFirewallCustomRuleMatch `
  -MatchVariable (New-AzApplicationGatewayFirewallMatchVariable -VariableName "RemoteAddr") `
  -Operator "IPMatch" `
  -MatchValue "203.0.113.45"

$customRule = New-AzApplicationGatewayFirewallCustomRule `
  -Name "BlockAttacker_203_0_113_45" `
  -Priority 10 `
  -RuleType "MatchRule" `
  -MatchCondition $newRule `
  -Action "Block"

$policy.CustomRules.Add($customRule)
Set-AzApplicationGatewayFirewallPolicy -InputObject $policy

9 — Azure Policy for WAF Governance¶

Azure Policy enforces organizational standards at the subscription or management group level. For WAF, this means ensuring that every public-facing Application Gateway or Front Door has WAF enabled and configured correctly — without relying on individual teams to remember.

Built-In WAF Policies¶

Azure provides several built-in policy definitions for WAF governance:

Assigning a Policy via CLI¶

The following commands assign the "WAF should be enabled for Application Gateway" policy at the resource group level with an Audit effect:

# Find the policy definition ID
POLICY_DEF_ID=$(az policy definition list \
  --query "[?displayName=='Web Application Firewall (WAF) should be enabled for Application Gateway'].id" \
  --output tsv)

# Create the policy assignment
az policy assignment create \
  --name "require-waf-on-appgw" \
  --display-name "Require WAF on all Application Gateways" \
  --scope "/subscriptions/<sub-id>/resourceGroups/rg-waf-workshop" \
  --policy "$POLICY_DEF_ID" \
  --params '{"effect":{"value":"Audit"}}'

To switch from Audit (reports non-compliance) to Deny (prevents resource creation without WAF), change the effect parameter:

az policy assignment create \
  --name "enforce-waf-on-appgw" \
  --display-name "Enforce WAF on all Application Gateways" \
  --scope "/subscriptions/<sub-id>/resourceGroups/rg-production" \
  --policy "$POLICY_DEF_ID" \
  --params '{"effect":{"value":"Deny"}}'

Custom Policy: Enforce Prevention Mode¶

You can create a custom policy that ensures all WAF policies in your subscription are in Prevention mode:

{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies"
        },
        {
          "field": "Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies/policySettings.mode",
          "notEquals": "Prevention"
        }
      ]
    },
    "then": {
      "effect": "audit"
    }
  }
}

Compliance Monitoring¶

After assigning policies, monitor compliance through:

# Check compliance state
az policy state list \
  --resource-group "rg-waf-workshop" \
  --filter "complianceState eq 'NonCompliant'" \
  --query "[].{Resource:resourceId, Policy:policyAssignmentName}" \
  --output table

The compliance dashboard in the Azure portal (Policy → Compliance) provides a visual overview of all policy assignments, their compliance percentage, and the specific resources that are non-compliant.

Related Labs¶

• LAB10
• LAB11

Key Takeaways¶

1. Copilot for Security is GA and provides a natural language interface for WAF investigation — ask questions instead of writing KQL from scratch.
2. Sentinel sits on top of Log Analytics — if your WAF logs already flow to a workspace, enabling Sentinel requires no data duplication.
3. Analytics rules are scheduled KQL queries that auto-generate incidents. Deploy rules for high-volume blocks, SQLi campaigns, and anomalous geo patterns.
4. Playbooks enable automated response — auto-blocking IPs via Logic Apps — but always include safeguards (allow-lists, expiry, rate limits).
5. Azure Policy enforces WAF governance at scale — ensure WAF is enabled and in Prevention mode across all resources without manual checks.
6. Combine Copilot + Sentinel for a powerful SOC workflow: Sentinel detects and creates incidents, Copilot helps analysts investigate and triage them conversationally.

References¶

• Microsoft Copilot for Security — Overview
• Copilot for Security — WAF Plugin
• Microsoft Sentinel — Overview
• Sentinel Data Connectors
• Sentinel Analytics Rules
• Sentinel Playbooks
• Azure Policy for WAF
• Azure Policy — Built-In Definitions