{"id":14848,"date":"2025-09-24T11:09:50","date_gmt":"2025-09-24T11:09:50","guid":{"rendered":"https:\/\/newestek.com\/?p=14848"},"modified":"2025-09-24T11:09:50","modified_gmt":"2025-09-24T11:09:50","slug":"what-i-learned-extending-zero-trust-to-the-storage-layer","status":"publish","type":"post","link":"https:\/\/newestek.com\/?p=14848","title":{"rendered":"What I learned extending zero trust to the storage layer"},"content":{"rendered":"
\n
\n
\n
\n
\n
\n
<\/div>\n<\/section>\n

When I first started thinking seriously about applying zero trust principles to the storage layer, it wasn\u2019t because of some white paper or vendor presentation. It was because of what I saw happen during a ransomware incident that still keeps me up at night. The attackers didn\u2019t just target production systems; they also went after backups. At that moment, I realized we\u2019d been fooling ourselves about what true resilience looked like.<\/p>\n

That gut-punch experience taught me something crucial: if your storage layer isn\u2019t zero trust-ready, everything else you\u2019ve built is standing on quicksand. This isn\u2019t theoretical anymore. Let\u2019s look at what happened to Change Healthcare in February 2024. The attackers didn\u2019t stop with encrypting their data; they also systematically destroyed the organization\u2019s ability to recover by targeting backups that weren\u2019t properly isolated. Months of chaos. Billions in losses. All because storage was treated as a trusted afterthought.<\/p>\n

The numbers can be scary. Ransomware attacks continue to get more frequent and more devastating<\/a>. We\u2019re not just dealing with more attacks \u2014 we\u2019re dealing with smarter ones. Today\u2019s ransomware isn\u2019t content to just encrypt your files. Strains like Qilin are purpose-built to hunt down and destroy your backups. Dire Wolf goes even further, making restoration technically impossible. Criminals have industrialized their approach with Ransomware-as-a-Service<\/a> platforms, such as Medusa<\/a>, and are specifically targeting the one thing we\u2019ve always counted on: our ability to recover.<\/p>\n

Why storage remains our Achilles\u2019 heel<\/h2>\n

After years of helping organizations implement zero trust for networks, identities and applications, I consistently observe the same pattern: storage is often overlooked. Every. Single. Time.<\/p>\n

I\u2019ve identified three reasons this keeps happening:<\/p>\n

    \n
  1. Storage feels invisible.<\/strong> Most teams view it as \u201cback-end infrastructure\u201d; something passive that simply sits there. However, the reality is that MITRE ATT&CK techniques<\/a> such as T1485 (Data Destruction)<\/a> and T1490 (Inhibit System Recovery)<\/a> are specifically targeted at storage. Attackers know exactly where to hit us, and we\u2019re still thinking of storage as scenery instead of a battlefield.<\/li>\n
  2. It\u2019s genuinely complex.<\/strong> Try enforcing consistent policies across multiple cloud providers, regions and on-premises systems. I\u2019ve seen teams spend months just mapping their storage footprint, let alone securing it.<\/li>\n
  3. We inherited bad assumptions.<\/strong> For years, we\u2019ve treated data as \u201ctrusted\u201d simply because the application accessing it was secure. But what happens when an attacker bypasses the application entirely and goes straight to the storage APIs? Game over.<\/li>\n<\/ol>\n

    3 principles that actually work<\/h2>\n

    After implementing storage-layer zero trust across multiple organizations, I realized the importance of framing this challenge around three leadership principles to ensure strategic outcomes are understood by executives.<\/p>\n

    1. Control where data can be touched<\/h3>\n

    Perimeter controls for storage require setting clear policy boundaries so that only trusted networks and environments can use storage APIs, rather than relying on a single firewall.<\/p>\n

    In one rollout I led, we used network boundaries to prevent cross-project sprawl in a multi-tenant cloud environment. The result was immediate: even with valid credentials, an attacker outside the perimeter had no pathway to sensitive datasets.<\/p>\n

    The important lesson here? Make \u201cdeny by default\u201d the organizational norm, and treat every exception request as a risk decision.<\/p>\n

    2. Control who can touch it and when<\/h3>\n

    Identity and Access Management (IAM) for storage needs to go beyond static role assignments. That means:<\/p>\n