{ "kind": "synthetic-educational-scenario", "version": "1.0", "slug": "cloud-misconfig", "title": "Whose mistake is on the screenshot?", "description": "Two simulated consoles at Northline Analytics. Name the customer-owned misconfiguration, the first fix, and the evidence that would show it is gone.", "minutes": 10, "skill": "Shared responsibility", "evidence": "SYNTHETIC TABLETOP / CLOUD-044\nOrganization: Northline Analytics (fiction). No live account.\nEvery console below is marked SIMULATED.\n\nCase A — object store\n Bucket northline-analytics-exports\n Prefix customer-exports/\n Policy: Allow s3:GetObject for Principal *\n Block public access: Off\n\nCase B — workload role\n Role analytics-export-worker\n Statement: Allow Action * on Resource *\n Used by a batch job, not by a human MFA prompt.\n\nYou cannot change a real cloud. Write the owner, the first fix,\nand the verification evidence for each case.", "exhibits": [ { "system": "AWS-like object store", "title": "Case A · customer-exports/ is world-readable", "rows": [ { "label": "Account", "value": "Northline Analytics (fiction)" }, { "label": "Bucket", "value": "northline-analytics-exports" }, { "label": "Prefix", "value": "customer-exports/", "mark": "Public prefix" }, { "label": "Statement", "value": "Allow s3:GetObject", "mark": "Customer policy" }, { "label": "Principal", "value": "*", "mark": "Anyone" }, { "label": "Block public access", "value": "Off", "mark": "Customer setting" } ], "note": "Annotation: a public GetObject on this prefix is customer configuration of data and access. It is not a finding about the provider’s physical hosts." }, { "system": "AWS-like identity console", "title": "Case B · analytics-export-worker can do anything", "rows": [ { "label": "Role", "value": "analytics-export-worker" }, { "label": "Trusted by", "value": "Batch job (machine identity)" }, { "label": "Action", "value": "*", "mark": "Data-plane wildcard" }, { "label": "Resource", "value": "*", "mark": "No resource boundary" }, { "label": "Human MFA", "value": "On for console users", "mark": "Does not bind this role" } ], "note": "Annotation: MFA on human logins does not narrow a machine role. The wildcard is still a customer identity decision." } ], "worksheet": { "caption": "Fill this table as you answer. The reflection shows one defensible version.", "headers": [ "Case", "Owner", "First fix", "Verification" ], "rows": [ [ "A · public object store", "You decide", "You decide", "You decide" ], [ "B · over-permissive role", "You decide", "You decide", "You decide" ] ] }, "record": { "caption": "Responsibility table for Northline Analytics (simulated).", "headers": [ "Case", "Owner", "First fix", "Verification" ], "rows": [ [ "A · public GetObject", "Customer: configuration, identity, and data", "Block public access and remove Principal * from customer-exports/", "Policy diff plus public-access block on; simulated access-analyzer finding cleared" ], [ "B · Action * / Resource *", "Customer: the workload role", "Replace the wildcard with the job’s read on one prefix", "Policy diff; denied call outside that prefix; role still not a human MFA session" ] ] }, "steps": [ { "prompt": "Case A shows public GetObject on customer-exports/. Who owns that mistake?", "choices": [ { "text": "Northline owns it. The bucket policy and the public-access block are customer configuration of data and access.", "correct": true, "feedback": "The provider still runs the facilities and the object-store service. Publishing this prefix is a setting Northline chose. A provider infrastructure audit does not rewrite that policy." }, { "text": "The provider owns it, because a public bucket is their infrastructure and they will notice and close it.", "correct": false, "feedback": "Shared-responsibility pages from AWS and Microsoft describe the provider securing the cloud, and the customer securing data, identities, and configuration in the cloud. Those pages are vendor guidance, not a standard. They do not promise the provider will fix this prefix." }, { "text": "Nobody owns it. The prefix says exports and the environment label says non-prod, so public read is harmless.", "correct": false, "feedback": "The objects are customer data. “Non-prod” and “exports” are labels Northline applied. They do not move the duty to the provider or make a world-readable prefix safe." } ] }, { "prompt": "What is the first fix for Case A, and what evidence would show it worked? Stay inside the simulation.", "choices": [ { "text": "Turn on block public access, remove Principal * from customer-exports/, and keep the policy diff plus a cleared public-access finding.", "correct": true, "feedback": "The fix is a configuration change Northline can make. The evidence is the new policy and the block, not a claim that the provider’s data center was audited." }, { "text": "Ask the provider to rebuild the region. Their infrastructure audit is the verification.", "correct": false, "feedback": "Passing a provider infrastructure review does not prove this bucket policy. NIST SP 800-144 (final, December 2011) is useful here only as an accountability theme: outsourcing does not move the risk off the organization. It is not a modern control checklist." }, { "text": "Leave the policy and add a wiki note that analysts should not click the public URL.", "correct": false, "feedback": "A note does not change GetObject for Principal *. Verification has to observe the policy and the public-access block, still on the simulated console." } ] }, { "prompt": "Case B allows Action * on Resource * for a batch role. Humans use MFA. What belongs in the second row?", "choices": [ { "text": "Northline owns the role. Replace the wildcard with the job’s read on one prefix, then show a denied call outside that prefix.", "correct": true, "feedback": "The machine role is customer identity. MFA on human console users does not constrain it. The first verification is a policy diff and a denied action, not a screenshot of someone else’s MFA prompt." }, { "text": "The role is fine because MFA is on for humans, so the wildcard cannot be abused.", "correct": false, "feedback": "The batch job presents the role without that human prompt. A broad machine credential is still a customer decision about identity and blast radius." }, { "text": "The provider must delete every role that uses a wildcard. Customer IAM is their host duty.", "correct": false, "feedback": "The provider operates the identity service. Northline still writes the policy attached to analytics-export-worker. Do not copy the provider’s physical-security duty into this row." } ] } ], "takeaway": "On these screenshots the mistake is customer configuration and identity, not the provider’s buildings. Name the owner, make the smaller policy, and keep the diff that shows the public path and the wildcard are gone.", "note": "NIST SP 800-144 (final, December 2011) supports the accountability theme: the organization remains accountable for risk it places in a public cloud. It is not a modern service-control checklist. The AWS and Microsoft pages are vendor guidance, not standards.", "links": [ { "title": "Cloud and SaaS shared responsibility", "href": "/learn/topics/shared-responsibility-cloud/" }, { "title": "Glossary: shared responsibility", "href": "/reference/terms/shared-responsibility/" }, { "title": "Least privilege and layers (F5)", "href": "/learn/topics/least-privilege-and-layers/" } ], "sources": [ { "title": "NIST SP 800-144: Guidelines on Security and Privacy in Public Cloud Computing (final, December 2011)", "url": "https://csrc.nist.gov/pubs/sp/800/144/final" }, { "title": "AWS Shared Responsibility Model (vendor guidance, not a standard)", "url": "https://aws.amazon.com/compliance/shared-responsibility-model/" }, { "title": "Microsoft Azure shared responsibility in the cloud (vendor guidance, not a standard)", "url": "https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility" } ] }