MDR for Microsoft Sentinel: architecture, detection engineering and containment

The enterprise friction: a SIEM is not a response capability

Most Microsoft Sentinel estates fail in the same place. The workspace exists, the data connectors are green, Content Hub solutions have been installed wholesale and a few hundred rule templates are enabled. What does not exist is an operating model that turns a KQL result into a contained identity within minutes. The SIEM is deployed. The security operation is not.

The failure modes are architectural, not cosmetic.

Telemetry gaps created for cost reasons. Ingestion is billed per gigabyte, so teams trim tables instead of tiering them. The first casualty is usually AADNonInteractiveUserSignInLogs, which is precisely where refresh-token activity and token replay surface. The second is the Defender XDR connector configured for incidents only, without streaming raw advanced hunting tables such as DeviceProcessEvents and EmailEvents. The result is a workspace that can see an alert but cannot investigate it.

Identity attacks that satisfy MFA. Adversary-in-the-middle (AiTM) phishing kits proxy the full Entra ID authentication flow and capture the session cookie after MFA completes. From the tenant's point of view, the sign-in is compliant. What follows is token replay from a new ASN, an inbox rule that forwards or hides finance mail, and occasionally an OAuth consent grant that survives a password reset. A configuration that equates "MFA enforced" with "account protected" has no detection or response path for any of it.

Time asymmetry. A business email compromise (BEC) operator creates a forwarding rule within minutes of session capture. A scheduled analytics rule running hourly, feeding an incident queue that nobody reviews until 08:30, gives the attacker a working day. Detection latency is a product of query frequency, triage capacity and containment authority, and most estates only tune the first.

The authority gap. Traditional MSSP arrangements observe but do not act. The provider raises a ticket; the customer's IT team revokes sessions the next morning. In an identity-led intrusion, the gap between "detected" and "contained" is where the financial loss happens.

Detection drift. Rules edited directly in the portal have no version history, no peer review and no regression testing. When a schema changes (the Parameters field in OfficeActivity is a well-known example), queries fail silently and nobody notices until an incident is missed.

Managed Detection and Response (MDR) on Microsoft Sentinel exists to close these gaps: complete telemetry at a controlled cost, detections engineered and versioned as code, and pre-authorised containment executed by people who are awake when the alert fires.

Before redesigning detection, establish the baseline. Start with a Microsoft 365 security assessment: Guardian reads 133 controls in your tenant and changes nothing.

Technical architecture breakdown

The reference architecture below is how Cyfenced operates Sentinel for customers. The workspace, the data and the automation all stay in the customer's own Azure subscription; Cyfenced operates it through delegated access.

CUSTOMER TENANT · your own Azure subscription

┌─ SOURCES ─────────────────────┐      ┌─ COLLECTION ──────────────────┐
│ Entra ID sign-ins and audit   │      │ Service-to-service connectors │
│   incl. non-interactive       │      │ Azure Monitor Agent           │
│ Defender XDR hunting tables   │  ──► │ Data Collection Rules:        │
│ Office 365 activity           │      │   ingest-time KQL filtering   │
│ Syslog / CEF, Azure activity  │      │   routing by table and tier   │
└───────────────────────────────┘      └───────────────┬───────────────┘
                                                       │
                                                       ▼
┌─ STORAGE ────────────────────────────────────────────────────────────┐
│ Analytics tier   hot, detection-ready: identity, endpoint, email     │
│ Data lake tier   long-term: flows, proxy, audit for hunting and IR   │
│ Summary rules    lift data lake trends back into analytics           │
└───────────────────────────────────┬──────────────────────────────────┘
                                    │
                                    ▼
┌─ DETECTION ──────────────────────────────────────────────────────────┐
│ Scheduled KQL    YAML in Git, CI-deployed, MITRE ATT&CK-mapped       │
│ NRT rules        one-minute cadence for privileged changes           │
│ Defender XDR     correlation into a single incident graph            │
│ Enrichment       UEBA, watchlists, threat intelligence               │
└───────────────┬──────────────────────────────────────────────────────┘
                │
                ▼
┌─ INCIDENT ────────────────────┐      ┌─ TRIAGE · CYFENCED SOC ───────┐
│ Entity-mapped                 │      │ 24/7 on-call analyst          │
│ ATT&CK-tagged                 │  ──► │ Azure Lighthouse access       │
│ Playbook-tagged               │      │ Approves containment          │
└───────────────────────────────┘      └───────────────┬───────────────┘
                                                       │
                                                       ▼
┌─ RESPONSE ───────────────────────────────────────────────────────────┐
│ Automation rules → Logic Apps playbooks                              │
│   • Graph revokeSignInSessions                                       │
│   • Defender for Endpoint device isolation                           │
│   • Inbox-rule removal, search-and-purge                             │
│   • Conditional Access block                                         │
└───────────────────────────────────┬──────────────────────────────────┘
                                    │
                                    ▼
┌─ EVIDENCE ───────────────────────────────────────────────────────────┐
│ Data export → Storage with time-based immutability (WORM)            │
│ Incident timeline and report to the customer                         │
└──────────────────────────────────────────────────────────────────────┘

1. Collection: service-to-service connectors, AMA and DCR transformations

Microsoft first-party sources (Entra ID, Defender XDR, Office 365, Azure Activity) arrive through service-to-service connectors and need no agent. Everything else, including Windows Security events, Linux Syslog and CEF from network appliances, is collected by the Azure Monitor Agent (AMA) and governed by Data Collection Rules (DCRs). The legacy Log Analytics agent (MMA) was retired in August 2024; any estate still depending on it has an unsupported collection path.

DCRs are where cost and fidelity are decided. Ingestion-time KQL transformations drop columns no detection uses, filter noisy event IDs at source and split a single stream across tables. That is how a firewall feed can contribute only denied flows and threat verdicts to the analytics tier while the full flow log goes to cheaper storage.

2. Storage tiering: analytics tier versus data lake tier

Not every byte needs to be detection-ready. The analytics tier holds the tables that scheduled and NRT rules query: identity, endpoint, email and audit. The Microsoft Sentinel data lake tier holds high-volume, low-signal telemetry (verbose network flows, proxy logs, long-retention audit) at a fraction of the cost and with retention measured in years. Summary rules aggregate data lake content back into the analytics tier when a detection needs a trend rather than raw events.

The design principle: tier by detection value, never delete by cost. A table you dropped cannot be hunted during incident response.

3. Detection engineering: KQL as code

Cyfenced maintains its detections as YAML in the same schema as Microsoft's public Azure/Azure-Sentinel repository, version-controlled in Git and deployed through Sentinel Repositories. Every change is reviewed, tested against at least seven days of historical data and traceable to a commit. Each rule carries entity mappings (Account, IP, Host), MITRE ATT&CK tactics and techniques, and the identifier of the response playbook it triggers.

The current library holds fifteen analytics rules mapped to seven playbooks: ransomware, BEC, credential leak, phishing, insider threat, DDoS and SMB-specific scenarios such as Microsoft 365 admin takeover. Rule 0006, MFA fatigue followed by success, illustrates the pattern. It correlates a burst of strong-authentication failures with a successful sign-in inside a 30-minute window:

let window = 30m;
let mfaFailCodes = dynamic([500121, 50158, 50074, 500133]);
let denies =
    SigninLogs
    | where TimeGenerated > ago(1h)
    | where ResultType in (mfaFailCodes)
    | summarize FailCount = count(), LastFail = max(TimeGenerated),
                FailIPs = make_set(IPAddress, 10) by UserPrincipalName
    | where FailCount >= 5;
SigninLogs
| where TimeGenerated > ago(1h) and ResultType == 0
| join kind=inner denies on UserPrincipalName
| where TimeGenerated between (LastFail .. (LastFail + window))
| project UserPrincipalName, FailCount, FailIPs, SuccessIP = IPAddress,
          Location, AppDisplayName   // maps to T1621, T1078.004

A single failed prompt is noise. Five denials followed by an approval from a new IP is an incident, and the query encodes that distinction instead of leaving it to an analyst at 03:00.

Where latency matters more than lookback, as with privileged role assignment (rule 000E: a new Global Administrator outside change control), rules run at 15-minute frequency or as near-real-time (NRT) rules on a one-minute cadence.

4. Correlation and enrichment: Defender XDR, UEBA and ASIM

Once the workspace is onboarded to the unified security operations platform in the Defender portal, Defender XDR's correlation engine stitches Sentinel alerts and Defender alerts into a single incident graph, replacing the legacy Fusion engine. Entity mapping is what makes that graph useful. An Account entity from SigninLogs joins an Account entity from OfficeActivity and a Device entity from DeviceProcessEvents, so the AiTM sign-in, the inbox rule and the follow-on endpoint activity appear as one attack story rather than three tickets.

User and Entity Behaviour Analytics (UEBA) adds the baseline: first-time ASN for this user, peer-group deviation, dormant account activation. Advanced Security Information Model (ASIM) parsers normalise third-party sources, so one detection covers several firewall vendors without per-vendor rewrites. Watchlists hold the context only the customer knows: VIP users, break-glass accounts, approved forwarding domains.

5. Response: automation rules, playbooks and containment authority

Detection without pre-authorised action is reporting. Each incident is auto-tagged by automation rules with its playbook and routed to the on-call analyst, who confirms and executes containment through Logic Apps playbooks running under managed identities with least-privilege Graph and Defender permissions:

• Identity: POST /users/{id}/revokeSignInSessions through Microsoft Graph invalidates refresh tokens. Continuous Access Evaluation enforces the revocation on supported workloads in near real time. A Conditional Access block contains the account while credentials are reset and MFA is re-registered from a trusted device.
• Endpoint: Defender for Endpoint device isolation through the machine actions API, keeping the host powered on so volatile memory survives for forensics.
• Email: removal of malicious inbox rules and forwarding, plus search-and-purge of the phishing message across all mailboxes.

Containment targets are explicit per playbook: 0–15 minutes for ransomware, phishing and DDoS, 0–30 minutes for BEC, and a deliberately covert 0–2 hour window for insider cases, where tipping off the subject destroys the investigation. The response actions customers pre-approve, and those requiring a call first, are agreed during onboarding and written into the runbook, not negotiated during the incident.

6. Access model and evidence integrity

Cyfenced operates the workspace through Azure Lighthouse delegated resource management, using scoped built-in roles such as Microsoft Sentinel Responder rather than standing Owner rights. Elevated actions require just-in-time activation. The customer can see every delegation in their own tenant and revoke it in one step. Because the workspace, rules and playbooks live in the customer's subscription, there is no data egress to a provider-hosted SIEM and no proprietary lock-in at contract end.

Log Analytics is not WORM storage. For evidence that must survive an administrator-level compromise, data export rules continuously stream designated tables to an Azure Storage account with time-based immutability policies. That gives auditors and forensic investigators a tamper-evident copy outside the workspace's own retention controls.

Want to know where your own Sentinel estate stands? Request a Sentinel readiness review and we will map your connectors, rules and response paths against this architecture.

Strategic comparison matrix

Framework compliance and business continuity mapping

The architecture produces evidence auditors can test, not a statement of intent. The mapping below shows which control each component satisfies and the artefact that proves it.

Regulatory reporting deadlines. For organisations in scope of NIS2, Article 23 requires an early warning within 24 hours of becoming aware of a significant incident, a notification within 72 hours and a final report within one month. DORA Articles 17–19 impose equivalent incident management, classification and reporting duties on financial entities. Those clocks are only achievable when the incident timeline (first signal, triage decision, containment action) is captured automatically in Sentinel rather than reconstructed from e-mail afterwards.

Business continuity. ISO/IEC 27001:2022 A.5.30 (ICT readiness for business continuity) and NIST CSF 2.0 RC.RP (incident recovery plan execution) depend on containment that does not wait for business hours. Isolating a ransomware-affected host within 15 minutes is the difference between restoring one file server and invoking the disaster recovery plan for the estate.

In scope of NIS2, ISO 27001 or DORA? Map your controls against NIS2 and ISO 27001 with a gap analysis backed by evidence from your own tenant.

Technical FAQ

How does MDR on Microsoft Sentinel detect token theft when MFA has already been satisfied?

Entra ID Protection risk detections such as Anomalous token, Token issuer anomaly and Attacker in the middle are correlated in KQL with AADNonInteractiveUserSignInLogs, where a replayed refresh token appears as non-interactive activity from a new ASN or device. Follow-on signals in OfficeActivity (new inbox rules) and AuditLogs (OAuth consent grants) confirm the compromise. Containment then revokes sessions through Microsoft Graph revokeSignInSessions and blocks the account with Conditional Access while credentials and MFA methods are re-registered.

Who owns the Sentinel workspace and detection content in a Cyfenced MDR engagement?

The customer does: the Log Analytics workspace, analytics rules, Logic Apps playbooks and all ingested data remain in the customer's Azure subscription. Cyfenced operates through Azure Lighthouse with scoped roles such as Microsoft Sentinel Responder, and that delegation is visible and revocable by the customer at any time. At contract end, the detection library stays deployed and no historical data has to be migrated out of a provider SIEM.

How do you control Sentinel ingestion cost without creating detection blind spots?

Data Collection Rule transformations drop unused columns and filter low-value events at ingestion time, and high-volume sources are routed to the Microsoft Sentinel data lake tier instead of being disabled. Detection-critical tables (SigninLogs, AADNonInteractiveUserSignInLogs, AuditLogs, Defender XDR advanced hunting tables) stay in the analytics tier. Summary rules bring aggregated signals from the data lake back into analytics when a detection needs them.