Measures for “management workstations” that can access storage facilities should include:

1. Organization-approved security controls: Management access to storage infrastructure, including access, monitoring, and auditing, should be managed using organization-approved security controls.
2. Security at least as stringent as data protection: Security measures for “management workstations” (including home-based workstation environments) accessing storage facilities should be at least as strict as those for “data protection” or “systems using data.”

• Data sanitization approaches should cover various components within the storage infrastructure, which may contain sensitive information. Ensure that components within the storage infrastructure are included in the organization’s data sanitization policy. These components include:
  • Non-volatile memory
  • Cache objects (storage arrays, SAN switches, routers, etc.)
  • Firmware/BIOS settings and HBA-level configurations

In this section, we mainly discuss the objectives and related activities of data protection, controlling them from various perspectives, including:

1. Data Backup and Recovery: This is a crucial control measure to ensure data recovery after unexpected failures or catastrophic events.
2. Archiving: This is a control measure to retain data in long-term storage, typically used for preserving historical data or data required by regulations.
3. Replication Technologies: This involves creating data copies between different locations or systems as a control measure to ensure availability in case of primary system failures.
4. Continuous Data Protection: This is a control measure that involves continuous monitoring of data changes and real-time backups, allowing for rapid recovery to specific points in time.
5. Point-in-Time Copies and Snapshots: This control measure involves copying data at specific points in time for restoration or querying when needed.

When discussing storage management and data protection, distinguishing between different data planes is crucial for a better understanding and management of storage systems. This is because data planes provide a way to organize and differentiate access methods, protocols, operations, and permissions related to data, ensuring that the system operates effectively on different levels. The main types of data planes include:

1. Data Consumption Plane: This plane involves access methods and protocols for performing I/O operations, as well as related network connections. It is the plane where users and applications read and write data.
2. Data Management Plane: This plane involves the management of metadata and configuration information related to data, such as creating, configuring, and mapping devices. It focuses on managing data’s metadata and configuration information within storage systems.
3. Data Protection Plane: This plane is concerned with data protection and backup operations, including copying, snapshots, backups, archiving, etc., to ensure data persistence and disaster recovery capabilities.

In general, increasing the granularity and separation of data planes can positively impact the security of data assets, and the designs and implementations that can have a significant impact include:

1. Two-layer separation at the network layer: For example, using different VLANs to increase separation.
2. Logical network separation: Using separate IP subnets to increase separation.
3. Filtering and Access Control Lists (ACLs): Adding ACLs to the data consumption plane to prevent management operations, increasing the separation between “consumption” and “management” planes.
4. Authorization Separation: Restricting permissions for each role, using different roles for different planes.

This document aims to ensure that the organization has a comprehensive and secure data protection plan in place before deploying systems or data storage solutions to address potential data corruption, failures, or security issues. These measures will help to ensure data integrity and availability while ensuring compliance with relevant regulatory requirements.

Backups and replication are fundamental components of data protection, ensuring data availability in the event of data loss or system failures. Organizations must establish comprehensive policies and procedures for backups and replication to meet their data recovery objectives.

Archiving is essential for preserving historical data, complying with regulatory requirements, and ensuring data availability when needed. Organizations should have policies and procedures for data archiving.

• Both synchronous and asynchronous “replication” require data protection at the same level as primary storage.
• This includes encrypting data at rest and configuring access restrictions.

• When there are no shared replicated volumes between arrays, the replication trust relationship between them should be disabled.
• When there are shared replicated volumes between arrays, privileges for replication trust between them should be limited to the shared volumes only.

• During replication and mirroring, data confidentiality and integrity during “transmission” should be protected using encryption.
• Encryption requirements can be relaxed when appropriate mitigation controls are in place, such as when mirroring occurs within the same cabinet or server room.

• When the synchronous progress of secondary storage servers lags behind the updates on primary data, the automatic I/O pause feature should be enabled to prevent write operations on the primary storage device. Continuing to allow write operations on the primary storage device may result in
  • Data inconsistency and data loss risks.
• However, please note that enabling this feature increases the risk of attacks on the primary storage device, as adversaries may attack the replication network path to trigger denial of service on the primary storage device.

• Regularly delete outdated replicas to reduce the attack surface.

• Ensure that the configuration of point-to-point copies (e.g., snapshots) meets the Recovery Point Objective (RPO) requirements of the target dataset.
• If business or compliance standards require that no more than five minutes of committed data can be lost during recovery, then the snapshot interval should be five minutes or shorter.
  • Ensure the configuration includes a sufficient number of hourly snapshots to meet retention requirements.

Regularly delete outdated snapshots and clones to reduce the attack surface.

1. Functional Advantages: Improved Recovery Point Objectives (RPO), more granular retention policies.
2. Technologies for Continuous Data Protection: Includes Continuous Data Protection (CDP), version control of “source data or copies” in cloud file and object storage, and “transaction log shipping.”
3. Assisting in enhancing the forensics of sensitive data: Backtracking to previous versions can help understand attack characteristics, timing, etc., but may be time-consuming.

1. All users, including administrators, should have a unique identifier for personal use only.
2. The identifiers assigned to administrators should meet at least Identity Assurance Level 3 (IAL 3) as specified in NIST document SP800-63A [35] sections 4.2 and 4.5.
3. The only exception is emergency use accounts, which are governed by AC-SS-R16.

1. In large environments, a centralized authentication solution (e.g., Active Directory, Lightweight Directory Access Protocol [LDAP], Single Sign-On [SSO], organization-approved cloud authentication services) should be deployed to closely monitor and control user access to storage resources.
2. Ensure consistent enforcement of the organization’s authentication policies.
3. Avoid using built-in authentication and permission management functions and preferably disable them.

1. Communication between the centralized authentication server and authentication clients should use the latest security protocols, such as Transport Layer Security (TLS) 1.2 or higher.

1. Access configurations for infrastructure components storing critical data should employ at least two-factor authentication.
2. These authenticators should meet at least the requirements specified in NIST document SP800-63B [36] section 5.1.9. This requirement should be mandatory for users in the roles of Security Administrators and Storage Administrators.

1. Secure password policies should apply not only to personal accounts but also to service accounts (e.g., Simple Network Management Protocol (SNMP), Network Data Management Protocol (NDMP), and accounts used by automation tools).
2. These passwords should at least meet the requirements for memorized secrets as described in NIST document SP800-63B [36] section 5.1.1.

• A strong password should have a minimum of 15 characters, preferably 20 characters.

• A strong password should include a combination of uppercase and lowercase letters, numbers, and special characters. It should not resemble the username and should not contain repeated character sequences.

• All passwords should have expiration times set. The expiration time for administrator accounts should be shorter than for regular user accounts.

• Users should not reuse the most recent four (or more) passwords, depending on organizational risk factors.

• Passwords should not be saved in plaintext anywhere (e.g., documents or scripts).
• Even if passwords are stored in encrypted form, enabling storage management applications to locally remember usernames and passwords for automatic login should be strictly prohibited unless managed through authorized central authentication services (such as LDAP SSO).

• Default passwords that come with system installations or deployments should be changed immediately.

• Disable accounts not associated with any users, such as those not present in Active Directory, like “guest,” “anonymous,” “nobody.”
• Their default configurations, such as passwords and permissions, should be changed per the organization’s policy scope.

• After a certain number of failed login attempts, the user should be locked out.
• Some implementations of account lockout include automatic resets (account unlocking) after a certain time or power cycle.
• Automatic reset should not be allowed on sensitive storage systems.

• A separate local user account should be reserved for providing emergency-only access to storage resources in case the “central authentication system” is unavailable.
• This account should comply with:
  • All organizational policies (e.g., password length).
  • Its usage should be restricted to specific, secure locations.
  • Follow well-documented procedures, including appropriate approvals and notifications to relevant stakeholders.

• Default user accounts that come with system installations should be eliminated or disabled if associated functionalities exist.
• If the elimination or deactivation of default user accounts’ functionality is not possible or there is a legitimate reason to retain any account, AC-SS-R18 requirements should be met.

1. At least four roles specified in the ISO standard ISO/IEC 27040 [10] (i.e., Security Administrator, Storage Administrator, Security Auditor, and Storage Auditor) should be implemented for access to all storage resources.
2. Ensure that storage products have sufficiently granular role control mechanisms for handling sensitive information, and if the storage product does not have such functionality, it can achieve similar effects through compensatory controls.

Follow the “Principle of Least Privilege” to assign privileges to roles and assign roles to users. It should include at least the following:

Additionally:

• Data Management: Permissions related to tasks such as creating new storage volumes or sharing resources for the normal operation of storage resources.
• Data Protection: Permissions related to configuring, stopping, or deleting backups, ensuring the security of stored data, and preventing data loss.
• Host Management: Tasks such as creating/deleting objects in storage controllers, permissions related to managing the hardware and infrastructure of storage systems.

• Any privileges assigned to roles should follow the “Principle of Least Privilege.”
• The permissions allocated to roles should not exceed what is required for the functions they perform, such as accessing specific storage resources like block devices, files, objects, etc.

• All sessions between clients and storage infrastructure systems should be managed according to the required levels of authentication assurance, as per the requirements of [63B] Section 7, including termination and automatic logout.

• “Daily Message” or “Login Banner” notifications should be displayed before logging into any storage infrastructure component or system through the user interface (UI), command-line interface (CLI), or application programming interface (API), if applicable. The message should include legal statements:
  • “Warning users are accessing restricted systems with sensitive data.”
  • And provide any other warnings and meaningful messages per the organization’s security and privacy policies.

Access to a set of Storage Area Network (SAN) devices by a set of hosts should be restricted through zoning (software or hardware) and masking to achieve the minimum required access permissions.

• Access to a set of SAN-copied block devices, snapshots, and other types of point-in-time replicas by a set of hosts should be restricted through partition zoning and masking to achieve the minimum required access permissions.
• In many cases, hosts granted access should not be allowed to access replicas.

• The permissions for default zoning (possibly product-specific) should always be configured as “deny all.”

Zoning should be implemented based on reasonable logic in a switched SAN architecture, especially with relevance to “environments” and “traffic” types, which should be separated as much as possible:

When implementing software zoning, only allow hosts to connect to storage devices through Simple Name Servers (SNS) by consulting the software zoning table rather than directly using device discovery.

• In SAN, there is a policy-defined feature that can “create a whitelist” listing the switches, data storage devices, and hosts that can join the storage area network. It is recommended to fully utilize this feature where applicable.

Limit access to all types of object storage data (e.g., files, objects) following the “Principle of Least Privilege,” including:

• Unauthenticated users should be disabled (e.g., anonymous, empty, guest, or “public access” users).
• Exceptions may be provided to allow critical organizational functions, such as network discovery, but in such cases, these users should be mapped to the “nobody” user group rather than “ID 0.”

• Regularly review the security settings of all stored data mentioned above, including various types of data (e.g., files, objects), to ensure no deviations.
• Record the results of the reviews.

• Use anti-malware tools to scan sensitive information files.
• Whenever “access” involves “sensitive information” in “files,” first scan with organization-approved anti-malware tools to ensure the files are not compromised.

• Implement fine-grained permission assignments:
  • For file and object sharing systems (e.g., NFS, CIFS, cloud object storage), use more granular permission granting.
  • Do not use coarser-grained methods (e.g., controlling files or objects instead of controlling entire folders, or controlling shares or storage buckets).

• Restrict root access to protect NFS, including using the “nosuid” option.
• Avoid using “no_root_squash” to prevent programs on clients from running as the root user.
• And avoid remote root users from modifying shared files. In general, NFS clients should not be allowed to run “suid” and “sgid” programs on exported file systems.

• Require that NFS shares that are set to “read only” mode have the “noexec” option added to their mount configurations to prevent the execution of executable files on the share.

• Do not export administrative file systems, including the ‘/’ file system and restricted operating system or storage array system folders.

• When using CIFS, do not grant “full control” permissions to any users, as recipients may use this permission to modify permissions, leading to privilege leakage.

• For sensitive information, if supported, use advanced controls to prevent unauthorized object deletion.
• (For example, requiring multi-factor authentication when deleting objects or locking objects to prevent deletion).

• This is an information security requirement that states that all storage infrastructure components should enable audit logging and use reliable transmission methods and secure communication protocols.

• Network Time Protocol (NTP) service is crucial for time synchronization.
• If NTP service is disabled:
  • Dependent systems may receive inaccurate timestamps for messages, events, and alerts.
  • Time inconsistencies among different devices, making it impossible for log analysis, correlation analysis, anomaly detection, or forensics.
• Establish and use a common and accurate time source throughout the environment to ensure that event records from different sources can be correlated.
• The following are recommendations for deploying and integrating NTP with storage-related devices:
  |
  Requirement
  | Requirement Content |
  |---------|----------|
  | AL-SS-R2.a | All devices (including log servers and storage infrastructure) should enable the NTP service. |
  | AL-SS-R2.b | Have devices configured to synchronize time with time source servers (e.g., NTP servers). |
  | AL-SS-R2.c | Access should only be granted to centrally managed users and roles, such as users in the enterprise directory or approved business services, and not to specific system local users. |
  | AL-SS-R2.d | Establish at least three independently located time servers to ensure that even if one server fails or becomes unavailable, the other servers can still provide accurate time information. |
  | AL-SS-R2.e | Use certificates to verify the identity of time source servers to ensure the security of the time synchronization service. |
  | AL-SS-R2.f | - Access restrictions options like “ntpd” access restrictions can be utilized to limit access to time source servers.
  - You can configure an access control list listing devices allowed or denied access to the time server. (e.g., configure restrict 192.168.2.10 to allow only this IP to access). |

• By writing logs to a central log server (e.g., syslog server, cloud log service), the risk of log loss or tampering is reduced because they are more secure within the internal network. Here are recommendations for deploying and integrating centralized log logging with storage-related devices:
  |
  Requirement
  | Requirement Content |
  |---------|----------|
  | AL-SS-R3.a | The organization should “define” the organizational log record “standard” for storage devices and specify the required log record levels. (For more specific recommendations, see AL-SS-R4). |
  | AL-SS-R3.b | “All devices” should be configured to transmit log event data to the organization’s approved “central log server” based on the applicable “organizational log record standard.” |
  | AL-SS-R3.c | The effectiveness of the central log configuration should be monitored on all devices (e.g., log service stays active, log record levels are configured per organizational standard, each device is configured with an approved log server), and anomalies detected should be given high priority for resolution. |
  | AL-SS-R3.d | Multiple syslog servers should be deployed to achieve continuous logging and prevent a single point of failure. |
  | AL-SS-R3.e | At least one offline copy of each log should be retained. |
  | AL-SS-R3.f | To prevent the loss of entries before stopping and restarting all log entries, log records should be configured to write to disk in real-time, without using buffering, and using reliable protocols. |

Storage audit logs should include (but are not limited to) the following events related to the protection of all storage-related objects, sites, and accounts:

The following measures should be taken for audit log retention and protection:

• If supported, “integrate storage infrastructure logs” with Security Information and Event Management (SIEM) for potential threat detection.

The following elements should be considered in the organization’s risk analysis, isolation, remediation, recovery, and testing procedures:

• Combine the recommendations provided in section 4.7 regarding the protection of network recovery copies to ensure they remain isolated during incident management.

• Ensure that recovered executable files, applications, containers, and operating system images are free from infection before deploying them into the production environment.

• Each host and storage switch should have unique identities and should undergo authentication before joining the network (e.g., FC-SP-2 AUTH-A).

• Use organization-approved and certified centralized PKI systems to manage switch certificates (e.g., Fibre-Channel Certificate Authentication Protocol or FCAP) instead of using self-signed certificates from devices.

Implement an approach that combines different types of zoning mechanisms rather than using a single type of zoning (i.e., host, switch, and storage device):

• Zoning refers to making block devices visible or invisible to hosts.
• It is preferred to place the zoning as close to the data as possible, as far away from data users or clients as possible (e.g., prioritize array zoning over switch zoning, core switches over edge switches, and switches over HBAs).

• Create a backup of switch configuration data, including zone configuration profiles.
• This backup should be kept outside of SAN switches to enable redeployment in case of errors, malicious damage, or deletion.

• Soft Zoning relies on host identity to restrict access to storage areas, is relatively less secure but may be more suitable for scenarios involving cross-facility and physical security risks.
• Hard Zoning, on the other hand, uses physical port numbers and does not depend on host identity, is more secure, and is especially suitable for situations where physical access is strictly controlled.

• Restrict which Fibre Channel physical and logical ports of Storage Area Networks (SANs) can be used for management.
• Only specific Fibre Channel ports should be able to perform management tasks, such as setting up, configuring, or monitoring SANs. Other Fibre Channel ports should be disabled or have their functions restricted to ensure they cannot be used for management tasks.

• Limit communication between switches.
• Ensure that only necessary switches can communicate with each other, reducing the risk of unauthorized devices entering the Storage Area Network.

• Disable unused Storage Area Network (SAN) ports to prevent accidental or intentional connections by unauthorized devices.

This section primarily discusses the principles of segmentation in IP storage networks aimed at securing storage-related communication over IP networks. Here’s a summary of the key points in this paragraph:

1. In storage-related communication, segmentation of environments and traffic should occur at the Network Layer Layers 2 and 3 based on different types of traffic to ensure security.
2. For sensitive environments, maximum segmentation should be implemented, and the basis for segmentation includes:
   |
   Requirement
   | Requirement Content |
   |---------|----------|
   | NC-SS-R11.a | Types of traffic: Data access protocols, management, replication, backup, host, and application networks, etc. |
   | NC-SS-R11.b | Further differentiate management traffic for different solutions, vendors, and technologies. If two or more storage solutions are in use (e.g., different array technologies, server-based SAN products, switch technologies, storage virtualization, etc.), management traffic for each environment should be segmented from others. |
   | NC-SS-R11.b | Data access protocols (e.g., iSCSI, NFS, proprietary vendor protocols, etc.). |
   | NC-SS-R11.b | Types of servers or hosts accessing data: Virtualized hosts vs. physical hosts. |

These segmentation principles aim to ensure the security of IP storage networks, allowing different types of traffic and sensitive information to be appropriately isolated in the network, reducing potential security risks.

• IP or Ethernet management ports on SAN switches should be placed in separate subnets, including data access subnets between hosts and storage, and separate subnets for inter-host communication.

Device IP access control should be enabled, and relevant security features, such as built-in firewall rules, IP filtering, and access control lists, should be configured on storage devices to achieve:

Use routing, firewalls, access control lists, Virtual Private Cloud (VPC) security groups, and similar mechanisms to restrict all traffic types (data access and management traffic) between servers or applications and their associated storage objects to allowed IP addresses and TCP/UDP ports and protocols:

Access to non-public storage objects from the internet or other public networks should be blocked.

(a) Minimize access.
(b) Use physically and logically separated storage subnets, preferably with different storage devices and pools for non-public storage objects.
© Consider protection against denial of service attacks.
(d) Cache copies (e.g., using Content Delivery Networks (CDNs), copies, and proxies) while maintaining at least the same security characteristics as the source data.
(e) Consider regulatory requirements (e.g., confidentiality, storage location restrictions).
(f) Any other applicable security controls (e.g., encryption, authentication).

When configuring SNMP, all traffic should be directed to valid internal organization IP addresses as destinations, and the effectiveness of the configured settings should be periodically reviewed.

For server-based SAN deployments, consider using isolated non-routable VLANs to protect data storage environments and mitigate security concerns.

• Deprecated, unsupported, or insecure protocol versions such as SMB v1, NFS 1 and 2 should be blocked.
• It is recommended to disable these protocols on both clients and servers for increased security.

(a) If SNMP is not in use, it should be disabled.
(b) Modify the default known community strings, even if SNMP is not enabled. The configured strings should comply with the organization’s password policy.
© Use different community strings for devices with different sensitivities.
(d) Use at least SNMP version 3.
(e) Enforce SNMP authentication and encryption features.
(f) If not absolutely necessary, do not configure SNMP with read-write access. If required, limit and control the use of read-write SNMP.
(g) Use access control lists to control access to devices via SNMP.
(h) Regularly verify that SNMP traps are sent to authorized managers.
(i) Refer to the U.S. Department of Homeland Security (CISA) TA17-156A guidelines for additional guidance.

Regularly review the configurations of all storage elements (such as devices, switches, management workstations, management software) that provide services to ensure only approved configurations are in use and remediate any inconsistencies.

Consider using non-standard ports to obscure applications or services, making it harder for hackers to identify the correct port number.
The disadvantage of using non-standard ports is that security scanning tools may not recognize suspicious activity on non-standard ports, as these tools expect specific behavior on standard ports.

FIP listening is a security mechanism to prevent unauthorized access and data transmission to the FC network.
FCoE adapters connect FC initiators (servers) to FCoE forwarders (FCFs) to enable FIP snooping on the relevant VLANs.

Prevent hosts on the iSCSI network from accessing any TCP ports other than those specified for iSCSI on that network.

Authenticate iSCSI initiators (e.g., CHAP, SRP, Kerberos, SPKM1/2) when establishing sessions. Use bidirectional authentication instead of unidirectional CHAP. Note that authentication does not provide channel encryption or integrity protection.

When using NDMP, the following security features should be configured:
(a) Control which hosts can initiate NDMP sessions.
(b) Use challenge-response authentication (do not use plaintext authentication options).
© Log NDMP connection attempts.
(d) NDMP passwords should adhere to the organization’s password policy (e.g., length, complexity).
(e) Assign only the necessary NDMP-related permissions to users.
(f) Encrypt NDMP control connections.
(g) Rate-limit NDMP sessions or server.

When configuring Active Directory options for storage systems, use TLS to secure LDAP connections.

When using other protocols (such as SymAPI, SMI-S, GNS, etc.), consider adopting the recommendations in sections 4.6.2 and 4.6.3.
Specifically:
(a) Segment traffic for data access and management from other environments.
(b) Limit TCP and UDP ports.
© Enable encryption as appropriate.

(a) In private clouds, backup copies designed to guard against network attacks should be established within specified dedicated storage environments. In public clouds, these backup copies should be created using separate accounts (or equivalent accounts).
(b) Long-term backups and storage systems should be physically separated from the production data storage systems.

• The management of storage systems storing network attack recovery copies should come from a designated management system that is separated from the production environment and other systems connected to production (including data protection mechanisms).
• Production and regular backup systems should not have access to these management systems. The system should be hosted in a dedicated environment only connected to the isolated network.

(a) For sensitive information, network attack recovery copies and their systems should not be visible to regular IT personnel. They should only be accessible by a single individual (e.g., CISO) or a very limited group of senior executives or security managers using special credentials. This ensures that if IT administrator credentials are compromised, attackers cannot use them to access network attack recovery copies. This restricted team can access network attack recovery copies, but administrative privileges will be granted to a smaller subset for granting permissions to other users.
(b) Permissions to access long-term backups should be separate from permissions used for other storage management tasks (e.g., SAN management, storage allocation) and should involve different user IDs, accounts, and credentials.

• Network attack recovery backups should be stored offline, not in the same location as production data. This ensures that even if attackers physically enter the production site or successfully infiltrate the physical location, they cannot access or compromise network attack recovery backups.

• Backup systems typically use incremental backups, capturing changes to data relative to a baseline backup. These incremental backups must be used together with the baseline backup for recovery. For some backup schemes (e.g., snapshots), only incremental backups are used (i.e., the baseline backup is the production data itself).
• To handle recovery scenarios correctly, dependencies between backups should be considered and sufficient isolation between different types of backups should be maintained. Specifically:
  • (a) Replicated disaster recovery backups should not depend on production baseline data.
  • (b) Network attack recovery backups should not depend on production baseline data. Dependency on disaster recovery baseline data is only allowed if these backups are sufficiently isolated from production baseline data and comply with IS-SS-R1, IS-SS-R2, and IS-SS-R3 recommendations.
  • © Archived data for long-term storage should not depend on production and disaster recovery baseline data.

All unnecessary services and protocols should be disabled on the network attack recovery storage system. In environments where management is done solely through application programming interfaces (APIs) or command-line interfaces (CLIs), it’s also recommended to disable any interactive web interfaces.

(a) During data restoration, data copies should not be mounted, exported, or mapped to hosts or applications. Instead, they should be restored to an isolated temporary environment (e.g., offline environment) rather than directly restoring to the target host or application. Alternatively, a less secure approach may allow the target host or application limited read-only access during the restoration process (e.g., mapping or mounting), but such access should be removed immediately after restoration.
(b) Data copies for long-term backups should not be directly mounted, exported, or mapped to hosts or applications.

• Organizations should consider establishing an air gap around sensitive data for data recovery copies.
• Strict air gaps should provide complete physical and network-level separation.
• Some storage technologies introduce less strict isolation techniques also referred to as “air gaps” that can be turned off for limited periods when synchronizing with production systems. The effectiveness of each technology should be evaluated based on data value and adversary capabilities. When choosing to implement strict air gaps, precautions should be taken to bypass known air gap system vulnerabilities, including:
  • (a) Preventing visual, auditory, and thermal signal transmission between air gap systems and other devices (e.g., maintaining sufficient distance or using vibration damping and/or adequate physical separation).
  • (b) Preventing any potential wireless transmission functions in air gap devices.
  • © Disabling exposed data ports (e.g., USB, network).
  • (d) Using power regulation or isolated circuits.

Regularly review the isolation recommendations mentioned above at least once a year as part of routine audits to ensure that there are no configuration gaps or deviations that could compromise the isolation of recovery copies. For sensitive and high-value storage systems, audits may need to be conducted at least quarterly and after major changes, depending on which occurs first. Audit results should be documented.

Consider the use of immutable storage technologies, which can further isolate and protect recovery data (e.g., retention locks, vault locks, immutability policies).

(a) Restoration procedures should be documented, maintained, and periodically reviewed. They should clearly describe how to restore data from different types of recovery copies.
(b) Organizations should periodically test restoration procedures, with a focus on validating that data can be successfully restored and that the restored data is usable and accurate.
© For recovery from network attacks, organizations should validate that the network attack recovery copies can be restored successfully in an isolated environment, and the restoration process itself should not introduce vulnerabilities.
(d) Restoration procedures should specify how to validate the integrity and authenticity of restored data.
(e) Organizations should maintain a record of restoration tests and outcomes, addressing any issues discovered during testing.
(f) In situations where immutable storage technologies are employed (as mentioned in IS-SS-R10), ensure that restoration procedures include how to verify the immutability of the data and its suitability for restoration.

(a) Organizations should assess the timeframes required for restoration based on different scenarios, including recovery from network attacks. These assessments should consider the volume of data, complexity of the restoration process, and the specific characteristics of the organization’s environment.
(b) Based on the assessments, organizations should set restoration time objectives (RTOs) for different data types and scenarios. RTOs should be realistic and achievable.
© Periodically review and update RTOs as the organization’s data environment evolves.

All relevant software and hardware components used to operate the system (e.g., drivers, firmware) should be backed up, protected, and available for recovery operations.

• RTO stands for “Recovery Time Objective” and is used to measure the desired recovery speed.
• The ability to meet the RTO comprehensively should consider all relevant components (such as data recovery, configuration files, encryption keys).
• Balancing the actual speed required for recovery and adjusting all relevant components to achieve the desired recovery speed should also consider the associated costs.

Regularly perform recovery testing operations to ensure successful completion and compliance with the required timeframes.

• Set a “Recovery Point Objective” for each data asset, which measures the amount of data loss that can be tolerated in terms of time after a failure occurs.
• The design and implementation of backup and data replication technologies should support data recovery under this objective.

Determine the “data retention and replication frequency requirements for each data asset” (see DP-SS-R1 for more details). The design and implementation of backup and data replication technologies should support these requirements.

• “Periodically verify the status of backup copies.”
• This includes checking for relevant error logs and ensuring that backup and data replication media are in good condition.
• The verification frequency should align with the sensitivity and value of the protected data but should not be less than once a year.
• Maintaining a sample rate within one to one and a half orders of magnitude lower than the backup frequency, such as verifying daily backups weekly or monthly, can serve as a reliable benchmark.

To avoid restoring infected code or software when restoring data, “data should be separated from applications” during restoration.

A “disaster recovery plan for storage infrastructure” must be written, including all resources, mappings to the formal production environment, processes, and testing procedures. Backup of these documents should also be maintained.

• For mission-critical information, disaster recovery copies should be “scanned using various anti-malware scanning tools” to detect known vulnerabilities and anomalies.
• Ideally, “all copies should be scanned.” If not possible, “at least a subset of copies should be scanned,” and these scanned and secure copies should be documented. Network security tools include antivirus software, anti-malware, vulnerability scanning, and security analysis tools.

• “The recommendations should be reviewed as part of periodic audits” to check the integrity of copies, reassess dependencies, software and hardware requirements, the technical suitability to support recovery speed, Recovery Point Objectives (RPOs), retention periods, health checks, disaster recovery plans, and network security measures.
• Identify and track issues and perform remediation.
• Audit frequency should align with the sensitivity and value of the protected data but should not be less than once a year.
• For sensitive and high-value storage systems, audits may need to be conducted quarterly and after major changes, depending on which occurs first.
• Audit results should be documented.

• To support encrypted communication between storage clients and servers, the “Transport Layer Security (TLS) protocol” should be used.
• The selection and configuration of the TLS protocol implementation should follow relevant guidelines, including the choice of TLS versions and cryptographic algorithms.
  • Guidelines sources include “NIST SP800-52 Rev2” and “SNIA TLS Specification for Storage Systems Version 1.1.”

• Plain text protocols are susceptible to eavesdropping, interception, and other attacks because they do not encrypt traffic or login details.
• In sensitive storage environments, “using HTTP for redirection to HTTPS should not be allowed” unless it’s only used for handling URLs related to error inputs.

• Encryption should be applied to all API and CLI client sessions and can be achieved using specific configuration options within “management software” or “API/CLI software components.”

• Administrative sessions using HTTP should be encrypted using “TLS (HTTPS).”
• Command Line Interface (CLI) access should use “SSH for encryption” instead of Telnet.
• Authentication during API access should not use plaintext, and the session itself should be encrypted.

• FIPS 140-3 requires that cryptographic modules should be a combination of hardware, software, firmware, or any combination thereof, used to implement cryptographic functions or processes, including cryptographic algorithms, and optionally key generation, within a defined cryptographic boundary.
• FIPS specifies certain cryptographic algorithms as secure and dictates which algorithms should be used when a cryptographic module is called FIPS-compliant.
• Organizations that comply with FIPS standards should ensure that FIPS mode is enabled in their FIPS-compliant storage infrastructure components.

Static encryption protects data from various data-related risks, including unauthorized access, media loss, or theft. Static encryption should be enabled for sensitive data, considering the following:

1. Use Infrastructure Encryption: Utilize built-in encryption features provided by disks, storage arrays, or cloud storage, whether using keys provided by vendors or keys provided by the organization, to protect against threats like device loss, misplacement, or theft. However, this may not protect against:
   1. Insider Attacks - When an attacker infiltrates a host already associated with storage (or when storage can be mapped to an unauthorized host through legitimate means).
   2. Privilege Escalation Attacks - Where administrators or attackers with high privileges may turn off encryption or decrypt data.
2. Use End-to-End Encryption: Data is encrypted at its source (e.g., applications, databases, volumes), and only ciphertext is presented to storage infrastructure and administrators. This significantly enhances security but may come with considerable costs:
   1. Data Reduction Mechanisms Are Affected - For instance, compression and deduplication may become inefficient.
   2. Management Becomes More Complex.
3. Use Dual Independent-Layer Encryption Where Possible: Consider using dual independent-layer encryption for stored sensitive data. This configuration enhances resilience if keys are compromised, especially when different encryption services are used.
4. Consider Data Retention Requirements: If “encrypted data is backed up or archived,” related keys should be protected, and the protection duration should match that of the data. Alternatively, backup data should regenerate new keys. In either case, “data and encryption keys should not be kept together.”

• (a) Block Transfers on Fibre-Channel: While Fibre-Channel link encryption is defined in ANSI/INCITS 545-2019 standards, most Host Bus Adapters (HBAs) and storage vendors do not currently support it. For sensitive information, “end-to-end encryption (host to storage)” should be used.
• (b) Block Transfers on IP: IP storage traffic faces the same security risks as regular IP networks. By default, IP block transfer protocols do not provide data confidentiality, integrity, or authentication for each data packet. Similar to link encryption, although there are technical specifications for encrypting IP storage traffic, current technologies do not natively support it. When using IP block transfer protocols (e.g., iSCSI, FCIP, proprietary protocols), consider using “IPsec tunnels to protect segments exposed on the network.” Additionally, for sensitive information, “end-to-end encryption (host to storage)” should be used.
• © File and Object Storage Access: Data encryption should be enabled for data transfer during backups and remote replication, where supported. For file access, mechanisms like SMB encryption should be used to encrypt sensitive data, or options for NFS encryption provided by cloud service providers, or NFS over TLS using channel encryption (e.g., ‘stunnel’). Ensure that object access is done via HTTPS with TLS.

• “Interactions between storage system components” should be reviewed, and available encryption options should be used.
• Encryption should be used to protect communication between “storage nodes and managers,” active storage nodes and witness devices, and with policy servers and antivirus servers.

• Follow general recommendations for key management outlined in “NIST SP 800-57” parts 1-3, especially focusing on:
  • Key Lifetimes.
  • Maximum Data That Keys Can Protect.
  • Key Management Infrastructure.
  • Key Regeneration.
  • Auditing.
  • Key Backup and Recovery.

• Limit network access to SAN switch management ports to specifically assigned devices and administrators using mechanisms like access control lists (ACLs).

This includes CLI servers, management consoles, API gateways, witness hosts, and storage devices with control privileges. Specifically:
(a) Actively identify components with storage management privileges and ensure that only authorized components have these privileges. If unnecessary components are identified, they should be immediately removed and reported.
(b) Remove unnecessary permissions and capabilities from authorized devices.

• Restrict the privileges of users with administrative access to the minimum necessary.
• This includes limiting the minimum actions users can perform and restricting the scope of these privileges to cover only relevant systems or areas.
• Full administrative privileges should only be granted to users who require them.

• Service accounts (e.g., accounts used by monitoring tools) should be restricted to read-only and metadata-only access.

• Authentication and authorization should be applied to CLI/API usage.
• If authentication and authorization are not possible, additional security measures should be in place to protect unauthorized access, such as using privilege management tools to limit control to the minimum necessary commands and objects.

• API access control should be prioritized, as CLI/shell access has the capability to access the operating system and file system, including configuration files.
• If CLI/shell access is the only option, it should be used over secure protocols like SSH.

• Access to management consoles should only be provided through specified storage accounts and not use operating system management accounts (see also AC-SS-R20).

• Web services providing access to the management console should be hardened to meet or exceed the minimum standards of other web application servers within the organization.

• In certain shared data compute cluster configurations (e.g., clusters, geoclusters, scale sets, or storage virtualization infrastructure), hosts are granted management privileges over storage to control the allocation and behavior of shared cluster data resources.
• When this management access is required, the scope and privileges granted to hosts should be limited to specific elements (e.g., LUNs, shares, files, objects) that the hosts need to control and specific operations they need to perform.

Some storage arrays allow hosts to have control over special block devices (referred to as “command devices” and “gateways”) that provide access to specific block devices. When used, the following security guidelines are recommended:
(a) Limit the use of control devices: If feasible, eliminate the use of these devices entirely (e.g., switch to API access). If elimination is not possible, ensure that they are mapped only to necessary hosts (e.g., management hosts).
(b) Scan control devices: Conduct network scans to discover control devices and ensure they are only mapped to necessary and authorized hosts.

Call home or remote access is typically used for collecting telemetry and diagnostic data for manufacturer analysis and resolution of technical issues, as well as for automatic software updates. However, these features can also become targets for hacking, so they should be disabled if not needed and restricted and controlled if required.
(a) Modify default credentials: Change the default credentials for remote connections.
(b) Limit privileges: Grant only the minimum necessary privileges.
© Enforce encryption: Use secure protocols like TLS/SSH/IPsec and FIPS-approved encryption algorithms.
(d) Use an allow list to restrict access: Use an allow list to restrict access to specific IPs and users.
(e) Maintain complete logs of remote access: For audit purposes, all remote access should be fully logged.
(f) Enable built-in data obfuscation features: For storage devices that allow obfuscation of sensitive data (such as IP addresses, WWNs, device names, and usernames), this feature should be enabled.
(g) Limit the scope of data sent: Limit the scope of data sent to the minimum required.
(h) Regularly review and approve: Regularly review data sent to vendors either periodically or automatically, ensuring that it does not contain sensitive information like IP addresses, usernames, or actual storage device content. Also, review to ensure that connections go to valid vendor IP addresses.
(i) Authorize each connection: If possible, implement a mechanism that requests permission before allowing each connection.
(j) Limit access to gateway systems: Special attention should be paid to protecting and restricting access to gateway systems when vendors access them remotely through devices, servers, or appliances.
(k) Disable software updates over vendor remote access links: In sensitive environments, software components and updates should not be allowed to be downloaded and deployed over vendor remote access links (either manually or automatically).

1. It is recommended to separate management networks from other traffic (see sections 4.6 and 4.7).
2. Further enhance access control for management networks, which can be achieved through the following mechanisms:
   (a) Virtual Private Networks (VPNs), IPsec, or one or more “jump servers”: Use VPNs, IPsec, or one or more “jump servers” or “login proxy servers,” which are dedicated servers located in the management network and can only be accessed from outside the network. These servers can be used for connecting to other servers only after proper authentication and authorization.
   (b) Enhance logging and tracking capabilities, such as session logging.

1. Storage management software typically includes configuration files used to control the operation of storage systems, including undocumented options.
2. These sensitive directories and files should have appropriate access restrictions and correct owners and group memberships.
3. This includes the following:
   • Configuration files: Record users and roles, network settings, consistency groups, device groups, and other storage options. Configuration files defining consistency and device groups are typically automatically propagated from central management hosts to other hosts connected to managed storage systems. Therefore, if compromised, it could affect multiple systems.
   • Scripts: Used to control the startup, monitoring, and stopping of storage management services and daemons, as well as their own executables. These scripts and other critical management-related files should be securely protected.
4. Controls for configuration files, scripts, and other critical management-related files should include:
   (a) Restrictions on access and permissions, and control of ownership of key directories and files.
   (b) For sensitive environments, consider monitoring changes to the contents of these files to prevent unauthorized alterations.

• For storage device management and storage management consoles, it is recommended to use organization-approved and certified centralized PKI systems rather than self-signed certificates from devices or software.

1. Arrays
2. Storage virtualization systems
3. Management consoles
4. Hosts monitoring storage remote network connectivity status (e.g., Witness hosts)
5. Hosts with storage management software or plugins installed
6. Data protection appliances
7. Backup clients and servers
8. Storage network switches
9. Storage adapters or Host Bus Adapters (HBAs)
10. I/O multipathing software
11. Pairing of primary storage systems and (replica) target storage systems
12. Designated host backup servers or off-site backup situations
13. Tape libraries and tape drives
14. Disk drives and removable media

1. Storage pools, LUNs, masking, and partitions
2. Initiators and initiator groups
3. File shares and Access Control Lists (ACLs)
4. Object storage pools, buckets, etc.
5. Backup replicas and snapshots
6. Backup catalogs and access permissions
7. Backup sets (local, archive, cloud virtualization, tape, archival devices, etc.)
8. Users, groups, roles, and permissions
9. Host access configurations to storage assets (e.g., LUNs, file shares, global file systems, object storage)
10. Images of storage software, virtual devices, etc.

• A storage security policy can be a standalone policy or part of the organization’s security policy.
• The policy should be based on the following sources:
  • Recommendations from this publication and cited sources.
  • Internal organization-specific storage-related security standards.
  • Best security practices from relevant vendors.

• The storage security policy should be reviewed and updated regularly (at least annually).
• Security baselines should be updated based on the latest vendor and industry recommendations for available storage systems and/or specific storage devices (preferably quarterly and at least annually).

• (a) Ensure that the actual configuration complies with the storage security baseline and identify gaps.
• (b) Timely address and remediate identified gaps.
• © Consider defining key performance indicators (KPIs) for storage security baseline compliance based on data types, organizational functions, and sensitivity.

• This can be a dedicated process or part of the organization’s general change management process.
• Covers:
  • (a) Planning, reviewing, and approving storage configuration changes.
  • (b) Updating environmental documentation and inventory (e.g., infrastructure, data, configurations).
  • © Evaluating compliance after any changes to sensitive storage environments.

• Establish a process to detect unauthorized changes to storage configurations, which can be done using log records, comparing configuration storage assets with past states, or comparing with organization-approved baselines.

(a) Ensure updates to storage software versions: Establish a process for regularly updating storage software to the latest stable and secure versions. This includes managing software, API and CLI suites, array and HBA firmware versions, and operating system driver software.
(b) Install critical security updates and patches: Establish a proactive and frequent process for installing important and emergency storage security patches.
© Mitigation plans for unobtainable patches - If certain storage components have critical vulnerabilities, and updates or patches are not provided by the vendor, suspend the use of these components unless an appropriate mitigation plan can be defined.

Keep storage-related network documentation up to date, including drawings of both Fibre Channel (FC) and IP.

Over time, certain security changes may not reliably propagate throughout the entire Fibre Channel (FC) fabric.

• Regularly review FC SAN (similar to IP and Ethernet networks) to assess its security, identify and prioritize vulnerabilities, and define improvement plans.
• Security audits should be conducted at least annually and, in sensitive environments, at least quarterly or after any major changes - whichever comes first.
• Audit results should be documented.

A storage security training plan should be developed and incorporated into existing organizational training activities and schedules to meet the following target audiences:

1. Information security professionals: Provide them with fundamental knowledge of storage security.
2. Storage administrators: Familiarize them with storage security principles, as well as the organization’s policies and security baselines.
3. Managers: Understand the fundamental principles of data protection.