A security review finds that an object storage bucket holding customer records was readable by anyone on the internet for several months. The bucket's access policy had been set to public by the customer's own deployment team during testing and never reverted. How should this threat be categorized?
Select an answer to reveal the explanation.
Short Explanation
Leaving your front door propped open isn't a burglary by the landlord; it's a door you forgot to shut. A bucket your own team set to public is a misconfiguration. The trap is blaming the provider or an attacker when the evidence points to your own settings.
Full Explanation
Misconfiguration and inadequate change control consistently rank among the top cloud threats in CSA's threat research, and exposed storage is its most familiar form. The facts here are decisive: the customer's own deployment team set the access policy to public and never reverted it, so the exposure came from a customer-controlled setting, not from a failure of the provider's service. A provider-side infrastructure breach would involve compromise of the provider's systems, and nothing suggests the storage service behaved other than as configured. Account hijacking requires stolen or abused credentials, but no one needed credentials, because the bucket allowed anonymous reads. A malicious provider insider is contradicted by the evidence that the customer's team made the change. Classifying the threat correctly matters because it drives the corrective action toward configuration governance rather than provider escalation. Exam caveat: misconfiguration often combines with other threats; a public bucket may later be found by attackers, but the root cause is still the configuration. Operational check: enable an organization-wide guardrail that blocks public access on storage by default, run continuous posture management to alert on any public policy, and review access logs for the exposure window to scope what was read.