SYS.1.8 Storage Solutions

Description

Introduction

The steady growth of digital information and the increasing volume of unstructured information mean that institutions use central storage solutions. The requirements for such storage solutions are subject to constant change, as can be observed, for example, in the following aspects:

• An institution’s data should be available at any time, from any location, and for different application scenarios. This means that modern storage solutions are often subject to increased availability requirements.
• The progressive digitization of all information in an institution makes it necessary to observe and comply with extensive legal requirements (compliance requirements).
• Storage solutions should be dynamically adaptable to constantly changing requirements and should be able to provide storage capacity centrally.

In the past, storage solutions were often implemented by connecting storage media directly to a server. These so-called Direct Attached Storage (DAS) systems can, however, frequently no longer meet current and future requirements. Therefore, the widespread central storage solutions of today and their components are necessary; they can be distinguished as follows:

• Storage solutions: A storage solution consists of one or more storage networks and at least one storage system.
• Storage networks: Storage networks enable access to storage systems on one hand and replication of data between storage systems on the other.
• Storage systems: A storage system is the central instance that provides storage capacity for other IT systems. A storage system also allows simultaneous access by multiple IT systems to the available storage capacity.

Objective

The objective of this building block is to show how central storage solutions can be securely planned, implemented, operated, and decommissioned.

Scope and Modeling

The building block SYS.1.8 Storage Solutions is to be applied whenever central storage solutions are used. It can thus be applied to Network Attached Storage (NAS) systems, Storage Area Network (SAN) systems, hybrid storage, object storage, or cloud storage. However, the following must be taken into account:

• Network Attached Storage (NAS) provides access to storage systems via protocols such as NFS (Network File System), AFP (Apple Filing Protocol), and CIFS (Common Internet File System). Its main use case is to provide file server services. For NAS systems, the building blocks SYS.1.1 General Server and APP.3.3 File Server must also be applied in addition to this building block.
• Storage Area Networks (SAN) are typically created by a dedicated storage network between storage systems and connected IT systems. For SAN systems, the building block NET.1.1 Network Architecture and Design should therefore be appropriately considered. Storage systems that can provide data via both NAS and SAN are often referred to as Hybrid Storage or combined storage systems (Unified Storage). For hybrid systems, the building blocks SYS.1.1 General Server and APP.3.3 File Server must also be applied in addition. Furthermore, the building block NET.1.1 Network Architecture and Design should be appropriately considered.
• Object Storage (often also referred to as Object-based Storage) enables object-based access to data in contrast to traditional block-based and file-based access methods. Access to object-based storage is via a leading application. The application accesses the object storage via a special interface (Application Programming Interface, API) and its possible commands, or directly via Internet Protocol (IP). For object-based storage solutions, the building block SYS.1.1 General Server must also be applied in addition. Furthermore, security requirements arising from the use of web services must also be considered. Web services are not addressed in the present building block.
• In connection with developments in the storage environment, the concept of Cloud Storage is increasingly becoming established. This refers to storage solutions as the basis for cloud services. The storage solution itself remains largely unchanged; however, access to the stored data differs from classic SAN or NAS architectures. This is typically realized via a web service interface (via Representational State Transfer, REST, and Simple Object Access Protocol, SOAP).

Backup devices connected to the storage system or storage network are not addressed here but are covered in building block OPS.1.2.2 Archiving. Conceptual aspects of data backup are explained in building block CON.3 Data Backup Concept.

Often a large number of accounts can access storage solutions. Therefore, storage solutions should be appropriately included in the role and authorization concept. Requirements for this can be found in building block ORP.4 Identity and Authorization Management.

If external services are used to operate a storage solution, the requirements of building block OPS.2.3 Use of Outsourcing must be separately taken into account.

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to describe the threat landscape. The following specific threats and vulnerabilities are of particular significance for building block SYS.1.8 Storage Solutions.

Insecure Default Settings in Storage Components

Storage components are frequently delivered with a default configuration so that the devices can be put into operation quickly and with the most comprehensive features possible. As a result, many devices have unneeded protocols activated, such as HTTP, Telnet, and insecure SNMP versions. If storage components are used productively with insecure factory settings, unauthorized access to them becomes easier. This can result in, e.g., services no longer being available or unauthorized access to confidential information of the institution.

Manipulation of Data via the Storage System

Poorly configured Storage Area Networks (SANs) can inadvertently connect networks. For example, if a server with a SAN connection is reachable from the internet and thus can be compromised from outside, it can be used as an entry point to gain unauthorized access to sensitive information stored in the SAN. Since this bypasses all security and monitoring measures — such as firewalls or Intrusion Detection Systems (IDS) — in the institution’s networks, the damage potential is considerable.

Loss of Confidentiality Through Storage-Based Replication Methods

Storage-based replication methods are intended to duplicate stored or archived data in real time over a storage network and thus store it redundantly. This is meant to prevent data loss. However, automated replication of unencrypted data carries risks both in the institution’s own network and when using public networks. Unauthorized access to replication traffic can occur, for example via FC analyzers (FC replication) or sniffers (IP replication).

Access to Other Tenants’ Information via WWN Spoofing

Devices in an FC SAN are internally managed and assigned via World Wide Names (WWNs). These correspond in some ways to the MAC addresses of Ethernet network adapters. Programs provided by the manufacturers of Host Bus Adapters (HBA) can be used to change the WWN of an HBA. This can enable unauthorized access to data. The manipulation of WWNs, also known as WWN spoofing, poses a significant risk to an institution. Particularly in connection with multi-tenant storage systems, unauthorized persons can access the information of other tenants.

Overcoming Logical Network Separation

If the network structures of different tenants are separated not by physically separate networks but by virtual Storage Area Networks (VSANs), this can jeopardize the information security of the institution. If attackers manage to penetrate the network of another tenant, they can access both that tenant’s virtual SAN and the transmitted user data.

Failure of Components of a Storage Solution

Complex network-based storage solutions often consist of many components (e.g., FC switches, storage controllers, virtualization appliances). If individual components of a storage solution fail, this can mean that important applications no longer work correctly and data loss becomes imminent.

Gaining Physical Access to SAN Switches

If an institution has inadequate or missing access and entry controls to the components of a storage system, it may be possible to gain physical access to existing switches or to connect additional FC-SAN switches to the network. The goal of such an attack could be to access the distributed zoning database in order to modify it so that access to the storage systems is possible.

Requirements

The following are the specific requirements of building block SYS.1.8 Storage Solutions. The Information Security Officer (ISO) is responsible for ensuring that all requirements are fulfilled and verified in accordance with the established security concept. The ISO must always be involved in strategic decisions.

Additional roles are defined in the IT-Grundschutz Compendium. They should be filled insofar as this is sensible and appropriate.

Exactly one role should be Primarily responsible. In addition, there may be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, that role is listed in square brackets after the heading of the requirement. The use of singular or plural says nothing about how many persons should fill these roles.

Basic Requirements

The following requirements MUST be fulfilled as a priority for this building block.

SYS.1.8.A1 Suitable Placement of Storage Systems (B) [Facility Management]

The IT components of storage solutions MUST be placed in locked rooms. ONLY authorized persons MUST have access to these rooms. Furthermore, a secure power supply MUST be ensured. The recommendations of the manufacturer regarding the recommended ambient temperature and humidity MUST be complied with.

SYS.1.8.A2 Secure Basic Configuration of Storage Solutions (B)

Before a storage solution is put into productive use, it MUST be ensured that all software components used and the firmware are up to date. Then a secure basic configuration MUST be established.

Unused interfaces of the storage system MUST be deactivated. The files for the default configuration, the basic configuration applied, and the current configuration SHOULD be stored redundantly and in a protected manner.

SYS.1.8.A3 DISCONTINUED (B)

This requirement has been discontinued.

SYS.1.8.A4 Protection of Administration Interfaces (B)

All administrative and management access to the storage systems MUST be restricted. It MUST be ensured that the administration interfaces cannot be accessed from untrusted networks.

Protocols considered secure SHOULD be used. If insecure protocols must nonetheless be used, a dedicated administration network (see NET.1.1 Network Architecture and Design) MUST be used for administration.

SYS.1.8.A5 DISCONTINUED (B)

This requirement has been discontinued.

Standard Requirements

Together with the basic requirements, the following requirements reflect the state of the art for this building block. They SHOULD generally be fulfilled.

SYS.1.8.A6 Creation of a Security Policy for Storage Solutions (S)

Based on the institution’s general security policy, a specific security policy for storage solutions SHOULD be created. It SHOULD contain traceable requirements describing how storage solutions can be securely planned, administered, installed, configured, and operated.

The policy SHOULD be known to all administrators responsible for storage solutions and should form the basis for their work. If the policy is changed or if deviations from the requirements occur, these SHOULD be coordinated with the ISO and documented. It SHOULD be regularly reviewed whether the policy is still being correctly implemented. If necessary, it SHOULD be updated. The results SHOULD be meaningfully documented.

SYS.1.8.A7 Planning of Storage Solutions (S)

Before storage solutions are deployed in an institution, a requirements analysis SHOULD be performed. The requirements analysis SHOULD address, among other things, the topics of performance and capacity. Based on the identified requirements, a detailed plan for storage solutions SHOULD then be created. The following points SHOULD be taken into account:

• selection of manufacturers and suppliers,
• decision for or against central management systems,
• planning of the network connection,
• planning of the infrastructure, and
• integration into existing processes.

SYS.1.8.A8 Selection of a Suitable Storage Solution (S)

The technical foundations of different storage solutions SHOULD be examined in detail. The implications of these technical foundations for possible deployment in the institution SHOULD be reviewed. The possibilities and limitations of the various storage system types SHOULD be presented transparently to the responsible persons at the institution. The decision criteria for a storage solution SHOULD be traceably documented. Likewise, the decision to select a storage solution SHOULD be traceably documented.

SYS.1.8.A9 Selection of Suppliers for a Storage Solution (S)

Suitable suppliers SHOULD be selected based on the specified requirements for a storage solution. The selection criteria and the decision SHOULD be traceably documented. Furthermore, aspects of maintenance and upkeep SHOULD be recorded in writing in so-called Service Level Agreements (SLAs). The SLAs SHOULD be unambiguous and quantifiable. It SHOULD be precisely regulated when the contract with the suppliers ends.

SYS.1.8.A10 Creation and Maintenance of an Operations Manual (S)

An operations manual SHOULD be created. All regulations, requirements, and settings required to operate storage solutions SHOULD be documented in it. The operations manual SHOULD be regularly updated.

SYS.1.8.A11 Secure Operation of a Storage Solution (S)

The storage system SHOULD be monitored with regard to the availability of internal applications, system utilization, and critical events. Furthermore, fixed maintenance windows SHOULD be defined for storage solutions, during which changes can be carried out. In particular, firmware or operating system updates of storage systems or network components of a storage solution SHOULD only be performed within such a maintenance window.

SYS.1.8.A12 DISCONTINUED (S)

This requirement has been discontinued.

SYS.1.8.A13 Monitoring and Management of Storage Solutions (S)

Storage solutions SHOULD be monitored. In doing so, all collected data (messages) SHOULD primarily be checked for compliance with the requirements of the operations manual.

The key messages SHOULD be filtered out using message filters. Individual components of the storage solution and the overall system SHOULD be centrally managed.

SYS.1.8.A14 Hardening a SAN Through Segmentation (S)

A SAN SHOULD be segmented. A concept SHOULD be developed that assigns SAN resources to the respective servers. For this purpose, based on security requirements and administrative effort, it SHOULD be decided which segmentation to use and in which implementation (e.g., FC-SANs or iSCSI storage networks). The current resource assignment SHOULD be easily and clearly identifiable using management tools. Furthermore, the current zoning configuration SHOULD be documented. The documentation SHOULD also be available in emergencies.

SYS.1.8.A15 Secure Separation of Tenants in Storage Solutions (S)

It SHOULD be defined and traceably documented what requirements the institution places on the multi-tenancy of a storage solution. The storage solutions used SHOULD meet these documented requirements.

In block storage environments, LUN Masking SHOULD be used to separate tenants from one another. In file service environments, it SHOULD be possible to operate with virtual file servers. Each tenant SHOULD be assigned their own file service.

When using IP or iSCSI, tenants SHOULD be separated from one another via network segmentation. If Fibre Channel is used, separation SHOULD be achieved using VSANs and soft zoning.

SYS.1.8.A16 Secure Deletion in SAN Environments (S)

In multi-tenant storage systems, it SHOULD be ensured that Logical Unit Numbers (LUNs) assigned to a specific tenant are deleted.

SYS.1.8.A17 Documentation of System Settings for Storage Systems (S)

All system settings of storage systems SHOULD be documented. The documentation SHOULD contain the technical and organizational requirements as well as all specific configurations of the institution’s storage systems.

If the documentation of system settings contains confidential information, these SHOULD be protected against unauthorized access. The documentation SHOULD be regularly reviewed. It SHOULD always be up to date.

SYS.1.8.A18 Security Audits and Reporting for Storage Systems (S)

All storage systems deployed SHOULD be regularly audited. A corresponding process SHOULD be established for this purpose. It SHOULD be regulated which security reports with what content are to be regularly produced. Furthermore, it SHOULD also be regulated how deviations from requirements are handled and how frequently and with what depth audits are carried out.

SYS.1.8.A19 Decommissioning of Storage Solutions (S)

If entire storage solutions or individual components of a storage solution are no longer needed, all data present on them SHOULD be transferred to other storage solutions. A transition period SHOULD be planned for this. Subsequently, all user data and configuration data SHOULD be securely deleted. All references to the decommissioned storage solution SHOULD be removed from all relevant documents.

SYS.1.8.A20 Emergency Preparedness and Emergency Response for Storage Solutions (S)

An emergency plan SHOULD be created for the storage solution in use. The emergency plan SHOULD describe exactly how to proceed in specific emergency situations. It SHOULD also contain instructions in the form of measures and commands to support error analysis and error correction. Suitable tools SHOULD be used to correct errors.

Regular exercises and tests SHOULD be carried out using the emergency plan. After exercises and tests, as well as after an actual emergency, the data generated during these activities SHOULD be securely deleted.

Requirements for High Protection Needs

The following are exemplary proposals for requirements for this building block that go beyond the protection level corresponding to the state of the art. The proposals SHOULD be considered in the case of high protection needs. The specific determination is made within the framework of an individual risk analysis.

SYS.1.8.A21 Use of Storage Pools for Tenant Separation (H)

Tenants SHOULD be assigned storage resources from different so-called storage pools. A storage medium SHOULD always be assigned to only one pool. The logical hard drives (LUNs) generated from such a pool SHOULD be assigned to only one tenant.

SYS.1.8.A22 Use of a Highly Available SAN Solution (H)

A highly available SAN solution SHOULD be deployed. The replication mechanisms used SHOULD meet the institution’s availability requirements for the storage solution. The configuration of the storage solution SHOULD also meet the availability requirements. Furthermore, a test and consolidation system SHOULD be available.

SYS.1.8.A23 Use of Encryption for Storage Solutions (H)

All data stored in storage solutions SHOULD be encrypted. It SHOULD be defined at which levels (Data-in-Motion and Data-at-Rest) encryption is to be applied. In doing so, it SHOULD be noted that encryption on the transport path is also relevant for replication and backup traffic.

SYS.1.8.A24 Ensuring the Integrity of the SAN Fabric (H)

To ensure the integrity of the SAN fabric, protocols with additional security features SHOULD be used. For the following protocols, their security properties SHOULD be taken into account and corresponding configurations should be used:

• Diffie Hellman Challenge Handshake Authentication Protocol (DH-CHAP),
• Fibre Channel Authentication Protocol (FCAP), and
• Fibre Channel Password Authentication Protocol (FCPAP).

SYS.1.8.A25 Multiple Overwriting of Data in a LUN (H)

In SAN environments, data SHOULD be deleted by overwriting the associated storage segments of a LUN multiple times.

SYS.1.8.A26 Hardening a SAN Through Hard Zoning (H)

To segment SANs, hard zoning SHOULD be used.

Additional Information

Good to Know

The International Organization for Standardization (ISO) provides requirements for hardening storage solutions in the standard ISO/IEC 27040:2015 “Information technology - Security techniques - Storage security”.

The Information Security Forum (ISF) makes requirements for hardening storage solutions in its standard “The Standard of Good Practice for Information Security” in Chapter SY1.4 Network Storage Systems.