Deploy Your First SOC Detection Rules

Objective

Deploy 3 KQL analytics rules from Module 3 (Building Identity & Access Detections) into your Sentinel workspace: DET-SOC-001 (anomalous sign-in), DET-SOC-002 (MFA fatigue), and DET-SOC-007 (distributed password spray). By the end of this lab, you have 3 running detection rules with correct entity mapping, MITRE ATT&CK tagging, and alert grouping.

Required: Microsoft Sentinel workspace with the Entra ID sign-in logs connector enabled (SigninLogs table populated). Security Contributor role on the workspace.

Step 1: Review the detection rule specifications

Before deploying any rule, review its specification from Module 3. For each of the 3 rules, confirm you understand:

• What it detects — the specific adversary technique
• Which table and fields it queries — SigninLogs with specific field filters
• The scheduling parameters — frequency, lookback window, NRT vs scheduled
• The entity mapping — which fields map to Account, IP, and Host entities
• The MITRE ATT&CK technique — the specific technique ID

Step 2: Deploy DET-SOC-001 — Anomalous Sign-In from Unfamiliar Infrastructure

Navigate to: Sentinel → Analytics → Create → Scheduled query rule

General tab:

Set rule logic tab:

Paste the KQL query from Module 3, subsection 3.2. Ensure the watchlist references (CorporateIPRanges, TrustedMobileASNs) exist in your workspace. If they do not exist yet, create empty watchlists with those names — you will populate them in Step 5.

Query scheduling:

Alert threshold: Generate alert when number of query results is greater than 0.

Entity mapping:

Incident settings:

Click Review + create → Create.

Step 3: Deploy DET-SOC-002 — MFA Fatigue Detection

Follow the same process with the MFA fatigue query from Module 3, subsection 3.3.

Key differences from DET-SOC-001:

Entity mapping: Account (UserPrincipalName) + IP (SuccessIP).

Step 4: Deploy DET-SOC-007 — Distributed Password Spray

Follow the same process with the password spray query from Module 3, subsection 3.8.

Key differences:

Entity mapping: IP (Address) — the primary entity for password spray is the source IP, not the individual accounts (which may number in the hundreds).

Step 5: Create supporting watchlists

If you have not already, create the watchlists referenced by the rules:

CorporateIPRanges:

Navigate to: Sentinel → Watchlist → Add new

Upload a CSV with your corporate egress IP ranges:

1
2
3

IPAddress,Location,Description
203.0.113.0/24,HQ Office,Main office egress
198.51.100.0/24,Branch Office,Branch egress

TrustedMobileASNs:

Same process. Upload a CSV with the ASN numbers for mobile carriers your users commonly connect from.

Step 6: Validate deployment

After the first query cycle (5-15 minutes depending on the rule), verify each rule is running:

Navigate to: Sentinel → Analytics → Active rules

For each deployed rule, confirm:

• Status is Enabled
• Last run shows a timestamp within the last 15 minutes
• Last run result shows Success (even if zero results — the query ran without error)

Validation query — confirm the rules are executing:

1
2
3
4
5
6

SentinelAudit
| where TimeGenerated > ago(1h)
| where SentinelResourceType == "Analytic Rule"
| where Description has "DET-SOC"
| project TimeGenerated, Description, Status
| sort by TimeGenerated desc

If any rule shows a failed execution, check the query for syntax errors or missing table/watchlist references.

Step 7: Test with a controlled scenario (optional)

If your lab environment has test users, generate a sign-in from an unfamiliar IP (use a mobile phone on cellular data, not office WiFi) and check whether DET-SOC-001 generates an alert within the next query cycle. This validates the end-to-end pipeline: sign-in → log ingestion → query execution → alert → incident.

Verification checklist

• 3 analytics rules deployed and enabled
• All rules show successful execution in the last 15 minutes
• Entity mapping configured for each rule
• MITRE ATT&CK tagging applied to each rule
• Alert grouping configured by Account entity
• CorporateIPRanges and TrustedMobileASNs watchlists created
• (Optional) Test scenario generated an alert