Episode 52 — Design Storage Security for DAS, SAN, NAS, Archives, and Removable Media

In this episode, we’re going to slow down and look at storage the way a security architect has to see it, which is as a set of places where data lives, moves, and quietly accumulates over time. Beginners often think security is mostly about networks and applications, but storage is where the proof of everything ends up, including sensitive records, backups, logs, intellectual property, and the files people forget they ever created. Storage is also where small design mistakes can have huge consequences, because a single misconfigured share, a poorly protected backup, or an untracked external drive can expose more data than a dozen application bugs. The topic today is not choosing specific products or running configurations, but learning how to think clearly about storage security across several common forms, including Direct Attached Storage (D A S), Storage Area Network (S A N), Network Attached Storage (N A S), archives, and removable media. The aim is to understand what makes each storage type different, what threats show up most often, and how to design controls that remain strong even when systems grow, teams change, and data gets copied in ways nobody originally planned.

Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.

A strong starting point is to recognize that storage security is not only about confidentiality, because storage has to support integrity and availability in ways that are easy to underestimate. Confidentiality is about preventing unauthorized reading, which matters when storage holds personal data, sensitive business plans, or credentials that could unlock other systems. Integrity is about preventing unauthorized modification, which is just as serious because corrupted data can break operations, distort decision-making, or silently undermine investigations. Availability is about ensuring the data can be accessed when needed, which becomes critical during incidents, audits, and recovery events when time pressure is high. Storage also introduces lifecycle risk, because data tends to outlive the systems that created it, meaning old files, old formats, and old permissions can stick around for years. Beginners sometimes assume that if access is restricted today, it will stay restricted tomorrow, but storage environments change constantly through migrations, reorganizations, and emergency fixes. Designing storage security means designing for the full life of the data, including how it is created, used, copied, backed up, archived, and eventually retired.

Direct Attached Storage (D A S) is a helpful place to begin because it is conceptually simple: storage that is physically connected to a single host, like internal drives or directly connected external enclosures. The security advantage of D A S is that it can reduce network exposure, because the data is not inherently shared across the network. The security risk, however, is that compromise of the host often becomes compromise of the storage, since the host controls access and can read the data as part of normal operation. That means D A S security depends heavily on host hardening, access controls, and careful handling of privileged accounts. It also depends on physical security, because if someone can access the hardware, they might remove drives or copy data without going through logical permissions. Another common misunderstanding is assuming that because storage is local, it is safe from misuse, but local data can still be exfiltrated, copied into cloud sync tools, or backed up to insecure locations. A sound design for D A S focuses on protecting the host, controlling privileged access, and ensuring that local storage is treated as a sensitive asset rather than an invisible default.

As environments grow, organizations often move from D A S toward centralized storage, and that is where storage area networks and network attached storage become important architectural choices. Storage Area Network (S A N) is a model where storage is provided over a specialized network, often presenting storage to servers in a way that looks like local disks even though it is shared infrastructure. Network Attached Storage (N A S) is a model where storage is provided over the network as file shares, meaning clients access files through network protocols rather than seeing raw disk blocks. The security differences matter because they change how access is controlled, how traffic flows, and how failures affect many systems at once. A S A N often concentrates storage for many servers, which increases the impact of compromise but also enables strong centralized controls and consistent monitoring. A N A S exposes shared file access to users and systems, which is convenient but also increases the risk of overly broad permissions and accidental data exposure. Beginners sometimes see both as just shared storage, but the control points are different, and the common failures are different. Good architecture begins by understanding the access model so the controls match the real behavior.

With S A N environments, one of the core security ideas is that you are separating compute from storage while creating a powerful dependency chain between them. Because many servers may rely on the same storage fabric, a disruption or compromise can affect a large portion of the environment at once. That means segmentation and access control within the storage network are essential, because you do not want every host to see every storage resource. Identity in a storage context often means controlling which servers are allowed to connect to which storage volumes, and ensuring that administrative access to the storage system is tightly restricted. Integrity matters because if storage mappings are altered, servers might write to the wrong volumes or lose access at the worst time. Availability matters because storage performance and redundancy can make the difference between a minor failure and a full outage. From an architectural view, S A N security is about controlling the storage fabric as its own high-trust environment, limiting who can administer it, and ensuring that storage connectivity does not become a hidden backdoor into more sensitive zones.

Network Attached Storage brings a different set of concerns because file sharing is inherently about broad access, and broad access is where subtle security errors thrive. A N A S system often serves many users and services, which means permission structures can become complicated and drift over time. One of the most common failures is overly permissive access, where a share intended for a team becomes readable by far more people than intended, or where sensitive folders inherit permissions that were meant only for public content. Another issue is that file shares often become dumping grounds, where people copy data for convenience without considering where it should live, which creates shadow repositories of sensitive data. Availability and quality also matter because N A S systems support collaboration, and outages can interrupt business in immediate ways. A good architectural approach defines clear data ownership, clear permission models, and clear boundaries between shares meant for broad collaboration and shares meant for restricted data. It also builds monitoring into the design so unusual access patterns, mass downloads, and permission changes are visible rather than silent.

Archives require a different mindset because archival storage is about long-term retention, and long-term retention creates long-term risk. Archived data may be less frequently accessed, but it is often more sensitive, because it can contain years of records, old customer data, and legacy information that would be damaging if exposed. Archives also create integrity challenges, because if archived records are altered, it can undermine audits, legal processes, and historical accuracy, and those problems may not be discovered until years later. Availability is still important, but the availability requirement is often about retrieval when needed rather than constant low-latency access. Beginners often assume that if archived data is cold, it is safe, but cold data can still be copied, mishandled, or exposed by misconfigured access. Another common misunderstanding is assuming archives are outside normal security scope, when in reality they can be a prime target precisely because they are neglected. A sound archival design defines retention rules, access restrictions, integrity protections, and a clear process for retrieval and review, so that long-lived data does not become a forgotten liability.

Removable media is sometimes treated as old-fashioned, but it remains a real part of storage security because it introduces portability, and portability is both useful and dangerous. Removable media can include external drives, portable solid-state devices, memory cards, and other forms that allow data to move outside controlled environments. The risk is straightforward: data can be copied quickly, carried away, lost, or stolen, and once it leaves, technical controls may no longer apply. Integrity can also be harmed because removable media can be used to introduce malicious files into a system, especially in environments where devices are connected casually. Availability can be affected when removable media becomes the only copy of important data, which is a surprisingly common mistake in small teams. Beginners may think removable media is only a problem for careless people, but many organizations use it for legitimate reasons, such as transfers to isolated environments, field operations, or recovery processes. The architectural goal is not to ban it blindly, but to define when it is allowed, how it is controlled, how data is protected on it, and how usage is monitored and audited.

Across all storage types, access control is the everyday control that either holds security together or quietly unravels it, and beginners should learn to treat permissions as a living system rather than a one-time setup. Access control answers who can read, who can write, and who can administer storage, and each of those categories has different risk. Read access controls confidentiality, write access controls integrity, and administrative access controls everything, because administrators can change ownership, permissions, and mappings in ways that bypass normal checks. A common failure is permission sprawl, where users accumulate access over time as they change roles, and nobody removes old permissions because it seems risky or inconvenient. Another failure is unclear ownership, where no one knows who should approve access changes, so access gets granted informally and becomes permanent. In storage, least privilege is not only a slogan; it must be expressed through a clear model of data classification, data owners, and approval workflows. A good design also includes regular review, because without review, storage permissions drift into a state that no one intended but everyone depends on.

Encryption is another crucial storage control, but the architectural value comes from understanding where encryption helps, where it does not, and what key management implies for real operations. Encrypting data at rest can protect against certain threats, such as stolen drives, copied storage snapshots, or unauthorized access to raw storage media. However, if a compromised server or user already has legitimate access to decrypted data, encryption at rest does not stop that actor from reading it, because the system must decrypt data for legitimate use. Encryption in transit matters for N A S and for management connections to storage systems, because attackers on networks can otherwise capture or modify traffic. Key management is where designs become fragile if not planned, because keys must be protected, rotated, and recoverable under legitimate conditions. If keys are stored alongside the encrypted data without strong separation, compromise of one system can unlock everything. If keys are managed so strictly that recovery is impossible during incidents, availability is harmed in a different way. A durable design makes encryption and key handling part of the overall trust model, not a checkbox applied after storage is already built.

Backups and snapshots deserve special attention because they are storage of storage, and they often contain the most complete versions of data, making them a high-value target. Beginners sometimes assume backups are automatically safe because they are meant for recovery, but attackers know that backups can be the fastest path to mass data theft or mass disruption. If backup repositories are reachable from production systems with broad permissions, then a compromise of a production server can lead to deletion or encryption of backups, which is a common pattern in ransomware events. Integrity matters because corrupted backups can provide a false sense of safety until you attempt recovery. Availability matters because backups are only useful if you can restore within required time frames. A strong design isolates backup storage from normal access paths, limits who can modify it, monitors access patterns, and tests restoration regularly. Testing is not about running commands in this context, but about ensuring the organization has confidence that the stored backup is usable and complete. When backup design is strong, storage security supports resilience rather than becoming the first thing that fails during crisis.

Monitoring and visibility are often the difference between storage that is quietly leaking and storage that is being defended actively, because storage incidents are frequently discovered late. Logs of access, permission changes, administrative actions, and unusual data movement can reveal threats that otherwise look like normal work. For example, a sudden mass download from a sensitive share, or an unusual spike in archive retrievals, can indicate data exfiltration or credential compromise. Monitoring also supports operational safety, because it can reveal failing disks, capacity pressure, or performance degradation that could turn into availability incidents. A common misunderstanding is thinking storage monitoring is purely an operations concern, but from a security architecture viewpoint, it is part of detection and response. Visibility must be designed so it does not become a new vulnerability, meaning logs should be protected from tampering and access to monitoring views should be controlled. In environments with S A N and N A S, centralization can help, because centralized storage can produce consistent audit trails, but only if the organization actually collects and uses them. A design that includes monitoring but no response plan is incomplete, because visibility is only useful when it supports timely action.

Data lifecycle management connects storage types together because data rarely stays in one place, and the security story must follow the data rather than stopping at the first storage boundary. Data may start on D A S, move into N A S for collaboration, be replicated into a S A N-backed system for production, and later be copied into archives for retention, with backups created at each step. Each movement introduces a chance for policy to be lost, for permissions to be broadened, or for encryption to be applied differently. Beginners sometimes assume the sensitivity of data changes when it moves, but sensitivity usually follows the data itself, not the storage type. This is why classification and labeling concepts matter, even at a simple level, because storage controls must align with what the data is, not merely where it sits. Lifecycle planning also includes deletion and disposal, because leaving data forever increases exposure and makes it harder to know what matters. A strong storage security design includes clear retention rules, clear migration processes, and clear disposal practices, so that older data does not silently become the largest source of risk.

Physical and environmental considerations also matter, especially for D A S systems, archival media, and removable media, because storage can be compromised without any network involvement. If drives are removed, if equipment is stolen, or if media is lost, confidentiality can be harmed even if software access controls were strong. Environmental failures like heat, humidity, power instability, and physical damage can also harm availability and integrity, particularly for archives that must last a long time. Architects think about where storage resides, who can physically access it, and what safeguards exist, such as locked rooms, controlled cabinets, and documented handling procedures for sensitive media. Physical security is not a separate discipline that can be ignored; it is a supporting layer that prevents direct access to storage hardware. Even in cloud-adjacent thinking, organizations still have physical interfaces, such as on-premises caches, on-premises backup devices, or portable media used in special cases. When physical controls are weak, the rest of storage security becomes easier to bypass. A durable design therefore includes physical handling rules, chain-of-custody thinking for critical media, and operational checks that reduce accidental loss.

As we close, the most important takeaway is that storage security is not one control and not one technology choice, but a set of design decisions that must remain coherent across D A S, S A N, N A S, archives, and removable media. Each storage type changes where the control points live and how failures happen, which is why architects focus on boundaries, access control, encryption strategy, monitoring, and lifecycle management rather than chasing a single perfect solution. D A S pushes you to secure hosts and physical access because the storage is tightly bound to the machine. S A N concentrates risk and value, which makes segmentation, administrative control, and fabric protection essential. N A S increases collaboration and therefore increases the need for disciplined permission models, ownership, and visibility into access patterns. Archives demand long-term confidentiality and integrity, which means retention and retrieval processes must be as secure as the storage itself. Removable media requires strict handling because portability turns data into something that can leave the environment in minutes. When you can explain how each storage category fits into a consistent trust model and data lifecycle, you’ve built storage security that is not fragile, not accidental, and not dependent on hope.

Episode 52 — Design Storage Security for DAS, SAN, NAS, Archives, and Removable Media
Broadcast by