BCN-T1-NET-002Tier 1 · CriticalNetwork

Publicly Accessible Storage and Data Services

Object storage, file shares, or managed data services readable without authentication from the internet.

Remediation SLA: 24 hours
Tier: 1 · Critical
Domain: Network
Escalation: CISO and executive sponsor notified at 48 hours

What this finding is

A storage resource — S3 bucket, Azure blob container, GCS bucket, network file share, or managed backup target — permits anonymous or unauthenticated read (and sometimes write) access from the public internet. This includes resources made public by an explicit ACL, by an over-broad bucket policy, or by a permissive default inherited at creation.

Why it is Tier 1

There is no exploitation step. An attacker who locates the resource simply reads it, which means time-to-compromise is bounded only by time-to-discovery, and discovery is automated and continuous. Public-storage exposure requires no skill, leaves minimal trace in most default logging configurations, and has produced some of the largest recorded data exposures. Where write access is also permitted, the resource becomes a malware distribution point trading on your domain's reputation.

Most common misclassification

Buckets holding 'non-sensitive' assets are often deferred to Tier 3. Classify by what the bucket *can* hold under its current permissions and by what write access would enable, not by an inventory of what happens to be in it today.

How to detect it

1Enumerate all storage resources across every account, subscription, and project — shadow accounts are the usual source of exposure.
2Run cloud posture checks (PROWLER, Cloudsploit, ScoutSuite) for public-access findings rather than inspecting resources by hand.
3Test anonymously from outside your identity plane: an unauthenticated curl is the only reliable evidence, since a signed-in session masks the finding.
4Check for public access granted indirectly through presigned URLs with long expiry windows, or through a CDN distribution fronting a private origin.

How to remediate it

Steps are ordered. The first step is the one that reduces exposure fastest, which is not always the one that closes the finding.

1Revoke public access on the specific resource first, then confirm no legitimate consumer breaks — reverse this order and the finding stays open through a change-approval cycle.
2Enable account-level public access blocks (S3 Block Public Access, Azure storage-account network restrictions) so the misconfiguration cannot recur.
3Serve genuinely public content through a CDN with an origin access identity, keeping the underlying bucket private.
4Review access logs for the exposure window and, where regulated data was reachable, initiate the breach-assessment process rather than closing the finding silently.
5Add a preventive guardrail — a service control policy or Azure Policy denying public ACLs — so the next occurrence is blocked at creation.

How to verify the fix

An unauthenticated request from an unrelated network returns 403 or 404, and an account-level public-access block is enforced so that a future per-resource misconfiguration cannot take effect.