MCS study materials
MCS study resources

Northwind Logistics: XDR, Sentinel, and a Budget That Fits One

MCS · Put your knowledge to work in context.

All case studies

Northwind Logistics: XDR, Sentinel, and a Budget That Fits One

Northwind Logistics runs a six-analyst SOC. The estate includes 4,500 Windows endpoints, 700 Linux servers, Microsoft 365 E5, eight AWS accounts, and SAP on-premises. Alerts arrive from 14 tools by email. The SOC handles roughly 3,000 alerts per day; 92 percent are closed as benign; mean time to acknowledge is nine hours. Microsoft Defender for Endpoint is deployed, but only its alerts are forwarded by email, and Microsoft 365 alert policies sit mostly at default. The SOC lead has budget for either a SIEM or "the XDR thing" but not both, and EU log residency is a hard requirement. The CFO rejects proposals that ingest every log source. Phishing is the top initial access vector, followed by stolen credentials; a 2023 incident involved an attacker moving from a compromised mailbox to AWS access keys stored in an internal wiki.

1. Distinguish Microsoft Defender XDR from Microsoft Sentinel and recommend an architecture that fits the budget and the EU residency requirement.

Read the worked answer

They solve different problems and are not substitutes.

Defender XDR is the correlation and response layer across Microsoft first-party signals - endpoint, identity, email, cloud apps, and cloud workload protection - producing unified incidents, automatic attack disruption, and advanced hunting. It is included in the E5 licensing Northwind already pays for and is currently almost unused.

Sentinel is the SIEM and SOAR layer: it ingests third-party and custom sources, applies analytics rules, supports long-term retention, and drives playbooks. It is where AWS, SAP, and network logs belong.

Recommendation. Fix XDR first - zero incremental licensing cost, and it addresses the largest alert volume and the credential-theft pattern. Configure incident correlation, tune alert policies, enable automatic attack disruption, and use advanced hunting for the mailbox-to-AWS-key path. Then introduce Sentinel narrowly: connect the Defender XDR incident stream, add AWS CloudTrail and SAP sources, and author a small number of high-value analytics rules rather than migrating all 14 tools.

Residency. Deploy the Log Analytics workspace in an EU region and configure the Sentinel data residency and retention settings so data does not leave the EU. Confirm any Microsoft 365 advanced hunting data is stored per the tenant's geography.

The budget question resolves as: XDR is a configuration project, Sentinel is a scope-controlled incremental project.

2. Map the Defender workloads to the signals Northwind needs and explain how they combine into a single incident rather than 3,000 tickets.

Read the worked answer

Each workload contributes a distinct signal, and the value is in the join.

Defender for Office 365 covers the phishing entry vector: Safe Links, Safe Attachments, and post-delivery ZAP, producing email and campaign entities.

Microsoft Defender for Identity reads domain controller traffic and surfaces reconnaissance, lateral movement, and compromised identity behavior on-premises - directly relevant to SAP-adjacent infrastructure and any hybrid identity path.

Microsoft Defender for Endpoint contributes device telemetry, vulnerability data, and endpoint response actions on the 4,500 endpoints and 700 Linux servers.

Microsoft Defender for Cloud Apps provides the SaaS and shadow-IT view and can detect anomalous mailbox access and mass download.

Entra ID Protection contributes sign-in and user risk, including leaked-credential detections that match the password-theft pattern.

Correlation. The XDR engine stitches these into one incident with a shared entity graph: the phished user, the risky sign-in, the mailbox rule created, the token issued, and the endpoint that accessed the wiki all become one incident rather than five unrelated alerts. That is the mechanism that collapses 3,000 alerts into a manageable queue and lets an analyst see the AWS-key pivot in a single view.

3. Design an ingestion and retention strategy for Sentinel that controls cost without losing the ability to investigate the 2023-style incident.

Read the worked answer

Cost is driven by ingested volume, the table plan, and retention, so treat each source deliberately.

Keep in XDR, do not duplicate. Defender XDR incident data streams to Sentinel through the Defender XDR connector; you do not need to re-ingest raw endpoint telemetry that advanced hunting already retains. Set the connector to incidents and alerts, not every raw event.

Ingest what only Sentinel can see. AWS CloudTrail, SAP security logs, firewall, proxy, and identity provider logs. These are the sources that explain the mailbox-to-AWS pivot and are invisible to XDR.

Use table plans. Put high-value detections - CloudTrail management events, SAP authentication failures - in the Analytics plan so analytics rules can use them. Route verbose low-value sources such as verbose network flow to Auxiliary or Basic, where they remain queryable but cheaper and unsuitable for scheduled analytics.

Retention. Keep interactive analytics retention at 90 days for hunting, and use long-term retention or the data lake tier for the regulatory and post-incident lookback period. Sentinel search jobs can query archived data for investigations without paying analytics-tier rates.

Validate with the team. Before enforcing, run the SOC through a tabletop replay of the 2023 incident against the new data set to confirm the CloudTrail and mailbox audit events are actually present and queryable.