DC0027: Cloud Storage Metadata
Cloud Storage Metadata provides contextual information about cloud storage infrastructure and its associated activity. This data may include attributes such as storage name, size, owner, permissions, creation date, region, and activity metadata. It is essential for monitoring, auditing, and identifying anomalies in cloud storage environments. Examples:
- AWS S3 Bucket Metadata: Metadata about an S3 bucket includes the bucket name, region, creation date, owner, storage class, and permissions. - Azure Blob Storage Metadata: Metadata for an Azure Blob container includes container name, access level (e.g., private or public), size, and tags. - Google Cloud Storage Metadata: Metadata includes bucket name, storage class, location, labels, lifecycle policies, and versioning status. - OpenStack Swift Metadata: Metadata for a Swift container includes name, access level, quota, and custom attributes.
Analyst context for executives and security teams
Cloud Storage Metadata is the inventory and context around cloud storage assets: names, owners, regions, permissions, creation dates, size, access levels, tags, lifecycle policies, versioning status, and related activity metadata. For leaders, its value is not just visibility; it is evidence needed to know whether sensitive storage is exposed, unmanaged, misconfigured, growing unexpectedly, or operating outside expected regions and ownership boundaries.
Executive priority
Prioritize this data component as a foundation for cloud security governance, audit readiness, and incident response. Without reliable cloud storage metadata, teams may struggle to prove who owns storage, whether access is private or public, where data resides, and whether configuration drift has occurred. Executives should ask whether storage metadata is complete across cloud environments in scope, reviewed for exposure and ownership gaps, and usable during investigations or compliance evidence collection.
Technical view
SOC, cloud security, and IR teams should validate that they can collect and query cloud storage metadata described by ATT&CK: storage name, size, owner, permissions or access level, creation date, region or location, tags or labels, storage class, lifecycle policies, versioning status, quota, custom attributes, and activity metadata where available. Because ATT&CK provides no detection logic, no mapped tactics, no platforms field, and no relationship context for this object, detection engineering should treat DC0027 as an enabling data source rather than a standalone analytic. Coverage should be measured by completeness, freshness, normalization, and ability to correlate metadata changes with cloud activity records and asset ownership data.
Likely telemetry
- Cloud storage asset inventory records
- Bucket or container metadata including name, region/location, creation date, owner, storage class, size, quota, and tags/labels
- Permission and access-level metadata, including private/public exposure indicators where available
- Lifecycle policy and versioning status metadata
- Cloud storage activity metadata associated with storage resources
Detection direction
- Validate whether metadata is collected for all cloud storage services in scope, including the examples named by ATT&CK: AWS S3 buckets, Azure Blob containers, Google Cloud Storage buckets, and OpenStack Swift containers, where those environments exist locally.
- Build coverage checks for missing owner, unexpected public or broad access level, unusual region/location, absent tags/labels, disabled or changed versioning status, unexpected lifecycle policy, or newly created storage outside expected governance patterns.
- Tune detections against local baselines because metadata such as size growth, storage class, tags, regions, and access levels can be normal for some business workflows and suspicious in others.
- Correlate metadata changes with activity metadata and ownership records before escalating, since ATT&CK does not provide a specific detection analytic for this component.
- Track blind spots where storage metadata exists in cloud consoles but is not centralized, normalized, retained, or searchable by SOC and incident response teams.
Mitigation priorities
- Establish authoritative inventory coverage for cloud storage resources and required metadata fields.
- Define ownership, tagging/labeling, region/location, access-level, lifecycle, and versioning expectations for storage resources.
- Review and remediate storage resources with missing ownership, unclear purpose, unexpected exposure, or noncompliant location/configuration.
- Ensure SOC and IR teams can access historical metadata during investigations and compliance reviews.
- Use metadata completeness and freshness as control evidence for cloud governance and audit readiness.
Analyst notes and limits
This object is a data component, not a technique. Its defensive value is in enabling monitoring, auditing, anomaly identification, and investigation of cloud storage environments. The supplied ATT&CK fields include examples across AWS S3, Azure Blob Storage, Google Cloud Storage, and OpenStack Swift, but the platforms field is not specified, so local applicability depends on the organization’s cloud footprint.
No official detection content, tactics, platforms, labels, aliases, or relationship context were supplied. This take does not infer adversary behavior, active exploitation, attribution, impact, or guaranteed detection coverage. Local cloud architecture, logging configuration, retention, and asset ownership data are required to turn this component into concrete analytics.
Cloud Storage Metadata
Cloud Storage Metadata provides contextual information about cloud storage infrastructure and its associated activity. This data may include attributes such as storage name, size, owner, permissions, creation date, region, and activity metadata. It is essential for monitoring, auditing, and identifying anomalies in cloud storage environments. Examples:
- AWS S3 Bucket Metadata: Metadata about an S3 bucket includes the bucket name, region, creation date, owner, storage class, and permissions. - Azure Blob Storage Metadata: Metadata for an Azure Blob container includes container name, access level (e.g., private or public), size, and tags. - Google Cloud Storage Metadata: Metadata includes bucket name, storage class, location, labels, lifecycle policies, and versioning status. - OpenStack Swift Metadata: Metadata for a Swift container includes name, access level, quota, and custom attributes.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 57e16387bf14… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DC0027Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.