Contoso Fabrication: Drawing the Shared Responsibility Line
Contoso Fabrication employs 900 people. Last year it moved email and project files to Microsoft 365 E3 but kept its ERP on a Windows Server 2019 host in a colocation facility and runs a customer quote portal on Azure infrastructure VMs that the IT team patches manually. In March an attacker used a password-sprayed credential to sign in from an unmanaged home PC. The account had no MFA and Conditional Access had never been configured. From the mailbox the attacker reached a SharePoint library holding a marketing plan and a spreadsheet containing 4,000 customer tax identification numbers. Nothing was encrypted beyond platform defaults. The CISO must brief the board next week and has three questions: who is responsible for securing what across the three environments, whether "assume breach" simply means buying more perimeter firewalls, and which single control would most likely have broken this specific chain. She also wants classification and data protection placed correctly among the defense-in-depth layers rather than treated as an afterthought.
1. Allocate security responsibility across the Microsoft 365, colocation ERP, and Azure IaaS environments, and explain the reasoning behind each boundary.
Read the worked answer
Responsibility follows control: you own every layer you configure and can observe.
Microsoft 365 (SaaS). Microsoft owns the physical datacenters, hosts, network fabric, and the service application itself, including patching Exchange Online and SharePoint. Contoso owns its data, the identity accounts and their authentication settings, the devices that connect, and every configuration decision - sharing links, sensitivity labels, DLP policies, retention. The tax-ID spreadsheet is therefore a Contoso problem even though Microsoft stores the bytes.
Azure IaaS. Microsoft owns the physical, host, virtualization, and datacenter network layers. Contoso owns the guest OS, patching, firewall rules, application code, and the identity plane. The quote portal's manual patching is squarely customer responsibility.
Colocation ERP. Contoso owns nearly the whole stack; the provider typically supplies power, physical access control, and connectivity per the contract, so physical security may be shared or delegated.
The useful test for the board: for any incident, ask which party could have prevented it. That answer identifies the owner, and it explains why "the cloud provider secures it" is never a complete answer above the infrastructure layer.
2. Which Zero Trust principle most directly addresses this attack chain, and what does "assume breach" actually require here?
Read the worked answer
Verify explicitly is the direct answer. The sign-in was authorized on a single asserted factor - a password - from an unmanaged device with no risk signal and no location or behavioral context. Explicit verification means every request is authenticated and authorized against all available signals: strong credential, device compliance state, sign-in risk, location, and resource sensitivity. Device compliance plus MFA plus Conditional Access would each have independently interrupted the attack, and together they make the password insufficient on its own.
Least privilege is the secondary failure. The compromised account could reach a SharePoint library containing tax identifiers that its role may not have needed, so blast radius was never constrained by entitlement scope.
Assume breach does not mean buying more firewalls. The attacker used valid credentials, so perimeter inspection would have seen normal traffic. It means designing on the premise that an identity or endpoint is already compromised: segment resources, apply just-enough-access and just-in-time elevation, encrypt data so a copy is useless, and instrument everything so anomalous behavior is detected in hours rather than months. Concretely here: restrict the library to a security group, apply a sensitivity label with encryption, and alert on mass download.
3. Place the layers of defense in depth and state where classification and data protection belong, with reasoning.
Read the worked answer
The canonical ordering runs: physical, identity and access, perimeter, network, compute, application, data.
Where this incident failed. Identity and access. MFA was absent, Conditional Access unconfigured, and the device was unmanaged. Perimeter and network controls were untouched because the credential was valid.
Where classification belongs. The data layer, but its reach crosses layers. A sensitivity label on the tax-ID spreadsheet does three jobs at once: it raises user awareness, it can carry encryption that travels with the file even if it is downloaded or emailed externally, and it feeds DLP and retention policies that act wherever the content lands.
Reasoning for the ordering. Controls closer to the data survive failures further out. If identity fails again, encryption and rights management still make the exfiltrated file unreadable to the attacker; DLP still blocks it leaving by email or endpoint copy; audit still records the access. Conversely, a network control cannot protect a document that a legitimate user opens on a legitimate device.
So for the board: identity is the layer to fix first because it failed, and the data layer is the one to invest in next because it is the only layer that keeps working after identity has been defeated.