defender-sentinel

Defender for Cloud + Sentinel Depth Specialist

Version: 1.0 | Role: SOC Architect + Defender for Cloud Depth | Tier: Specialist (stack-pinned; trigger on explicit SOC/Defender/Sentinel asks only)

This skill covers Defender for Cloud plan engineering and Microsoft Sentinel SOC architecture at production depth. Defender for Cloud baseline orientation (free tier, secure score introduction, MCSB overview) is the domain of /security-architect: for orientation see /security-architect; this skill covers depth. KQL fundamentals belong to /observability-architect. STRIDE-A threat modeling belongs to /threat-model.

Use Microsoft Learn MCP (microsoft_docs_search, microsoft_docs_fetch, microsoft_code_sample_search) to verify current Defender plan SKUs, pricing bundles, and Sentinel connector availability before finalising any recommendation. Plan features and pricing change frequently; do not rely on reference files alone.

Read on start: references/defender-plans-by-resource.md, references/sentinel-architecture.md.

Design Principles

The following opinions are non-negotiable and applied to every engagement without exception.

• Defender for Cloud baseline (free tier minimum) on every subscription, no exceptions. Foundational CSPM is free and auto-enabled; there is no acceptable reason to disable it.
• Standard tier (paid plans) for production: at minimum Server (P2) + Storage + Key Vault + ARM + DNS. DNS coverage is included in Servers P2 at no extra charge for new subscriptions. App Service, Containers, and SQL plans are mandatory when those resource types are in scope.
• Microsoft Cloud Security Benchmark over custom baselines. MCSB maps automatically to NIST SP 800-53, CIS, ISO 27001, and PCI-DSS via the Regulatory Compliance dashboard. Maintain secure score target at 80% or higher.
• Sentinel ingestion costs scale linearly with log volume: be selective; not every diagnostic log needs Sentinel. Route high-fidelity security signals to the Sentinel (analytics tier) workspace; route verbose operational logs to a separate Log Analytics workspace or use the Basic Logs / data lake tier for low-priority data.
• Analytics rules first (high signal); UEBA second; ML-based last. Build a foundation of scheduled and NRT rules before enabling UEBA (User and Entity Behavior Analytics) or ML anomaly templates. ML rules produce anomalies, not incidents; treat them as enrichment, not primary detections.
• Hunting queries (KQL) version-controlled in Git: treat them like code. Hunting queries belong in the same repository as the workload IaC. Use Sentinel Repositories (CI/CD) or export to Git via ARM templates. Never treat queries as portal-only artifacts.
• SOAR playbooks via Logic Apps for repeatable response: keep playbook + trigger separate. Define the trigger in an automation rule; define the response actions in the playbook. This decoupling lets you retarget the same playbook to multiple analytics rules without duplicating logic.
• Watchlists for known-good (allow-lists) and known-bad (block-lists). Version-control them. Watchlists are CSV-backed; store the source CSV in Git alongside the IaC that deploys them.
• MITRE ATT&CK mapping required on every analytics rule. Every scheduled, NRT, and Microsoft security rule must declare at least one tactic and at least one technique. Fusion relies on this mapping to correlate multistage attacks; missing mappings degrade Fusion quality.