# MSSP Microsoft Sentinel Lifecycle

At a high level, a greenfield Microsoft Sentinel deployment should be
treated as a **lifecycle**, not just "turn on connectors and start
writing detections."

## 1. Discovery / Requirements

-   What are we protecting and what are the customer's priorities?
-   Microsoft licensing: M365 E3/E5, MDE, MDI, MDO, Entra P1/P2, etc.
-   Azure subscriptions/tenants and hybrid/on-prem footprint
-   Third-party security products and infrastructure
-   Compliance/retention requirements
-   Expected ingestion volume and budget
-   MSSP/customer responsibility boundaries
-   Incident escalation, notification, and SLA expectations

## 2. Design the Sentinel Architecture

-   Subscription/resource group structure
-   Log Analytics workspace strategy
-   Region/data residency
-   RBAC and least privilege
-   MSSP cross-tenant access, typically Azure Lighthouse
-   Retention/archive strategy
-   Dedicated vs. shared customer resources
-   Naming/tagging standards
-   Dev/test/prod strategy if appropriate

## 3. Design the Data Ingestion Strategy

-   Inventory required log sources
-   Prioritize security-value data instead of simply ingesting
    everything
-   Prefer native Sentinel connectors
-   Azure Monitor Agent + DCRs where applicable
-   Syslog/CEF for appliances
-   API/Event Hub/custom collection only where necessary
-   Determine which tables each connector actually produces
-   Normalize where useful with **ASIM**
-   Filter noisy/unnecessary data before ingestion where possible
-   Estimate GB/day and Sentinel/Log Analytics cost

## 4. Deploy the Baseline

-   Sentinel workspace
-   RBAC/Lighthouse
-   Connectors
-   DCRs
-   Content Hub solutions
-   Analytics rules
-   Watchlists
-   ASIM parsers/functions
-   Automation rules
-   Logic Apps/playbooks
-   Workbooks/dashboards
-   Threat intelligence feeds

Ideally, most of this becomes **IaC/Git-controlled configuration**,
rather than analysts manually configuring every tenant.

## 5. Validate Telemetry

This is one of the most important MSSP steps and is easy to
underestimate.

Don't just verify that a connector says **Connected**. Validate:

-   Expected tables exist
-   Events are actually arriving
-   Expected event types exist
-   Volume is reasonable
-   Timestamp/latency is reasonable
-   Required fields are populated
-   Customer licensing actually supports the telemetry you expected

Build some sort of **data-source health matrix**:

`Source → Connector → Table(s) → Expected volume → Last seen → Health`

## 6. Build / Tune Detection Coverage

-   Start with Microsoft content where it makes sense
-   Map detections to MITRE ATT&CK / customer use cases
-   Tune thresholds and exclusions
-   Identify detection dependencies on particular tables/products
-   Add customer-specific detections
-   Test detections using known activity or simulation
-   Track false-positive rates
-   Version detections and document why tuning decisions were made

## 7. Design Incident Operations

-   Severity model
-   Incident ownership
-   MSSP triage procedures
-   Customer escalation path
-   Evidence requirements
-   Ticketing integration
-   Automation boundaries
-   What analysts can automatically contain versus what requires
    customer approval
-   Runbooks for common incident types

## 8. Operationalize Monitoring

Now you're monitoring **Sentinel itself in addition to security
events**:

-   Connector failures
-   Missing/stale tables
-   Sudden ingestion drops/spikes
-   DCR/collector failures
-   Analytics rules that stop firing
-   Logic App/playbook failures
-   API authentication/certificate expiration
-   Ingestion latency
-   Daily ingestion and cost anomalies
-   Retention/archive status

## 9. Continuous Maintenance

-   Microsoft connector/schema changes
-   New Sentinel Content Hub releases
-   Deprecated connectors/APIs
-   Detection updates
-   ASIM changes
-   Customer infrastructure changes
-   New products/licenses
-   New log sources
-   Detection tuning
-   RBAC/access reviews
-   Credential/certificate rotation
-   Cost optimization
-   Periodic coverage/gap assessments

## Managed Service Model

The MSSP architecture should ultimately look roughly like:

**Customer environment → ingestion/normalization → Sentinel → detections
→ incidents → automation → MSSP SOC → customer escalation**

with a second operational layer watching the whole thing:

**Telemetry health + detection health + automation health + cost +
configuration drift**

That second layer is what turns a Sentinel deployment into a **managed
Sentinel service** instead of just a Sentinel installation.