The Networked Storage Service (NSS) is available for the University of Maryland (UMD) faculty, staff and researchers to store and process electronic data in a variety of file formats through standard operating system protocols such as NFS and SMB. This article highlights standard security processes for the service. It also outlines best practices and recommendations on enhanced security features. Security features that are account-scoped can be applied to individual storage shares or exports as necessary. Please refer to the DIT service dashboard whenever the storage service dashboard is referenced in the documentation.
Standard security practices are enforced as a qualification to have storage accounts on NSS. Data under Moderate (Level 2) risk data of the UMD Data Classification Standard can be stored and managed with security practices outlined below.
NSS is hosted on university-owned storage systems and maintained by the Division of Information Technology (DIT). Storage systems are housed in two regional locations in climate and access-controlled data centers. The on-campus data center is wholly managed by DIT. A second storage array is housed in a commercial colocation data center with strict, well-certified standard operating procedures, including FISMA, FERPA and PCI-DSS. Access control and all network and storage hardware in this facility are managed and owned by DIT.
Storage hardware hosting storage accounts contain self-encrypting drives (SEDs). The encryption key management system is embedded within the storage hardware operating system. Data is encrypted on disk using the AES-256 cipher, and each SED has a unique data encryption key (DEK) which is used to encrypt and decrypt data as it’s read from and written to disk. The operating system automatically generates an authentication key (AK) that wraps and secures the DEK. This means that the data on any SED which is removed from its source hardware cannot be unlocked and read, thereby guarding against the data security risks of physical drive theft. Encryption of data at rest satisfies a number of industries’ regulatory compliance requirements, including U.S. Federal FIPS 140- 2 Level 2 and PCI-DSS v2.0 section 3.4.
Administrative network access to the storage array management interface is controlled and monitored via network firewalls and router access-control lists. Only members of a well-defined administrative group can reach the management ports of the storage devices. Further, administrative login is managed via membership within a DIT-managed Active Directory group. As such, login authorization is managed by a centralized university identity management system. Passphrase strength and recovery policies are enforced through the central identity management service. Such practices adhere to the UMD Standard Protecting Sensitive Information policy (IT-4) section 5.2.
Standard storage users with storage accounts cannot log into any storage management interfaces. Insecure and unneeded ports and services, such as telnet, ftp and ntp are restricted via firewall and router access-control rules.
Data access security is a factor of endpoint (desktop, mobile device or server) security and workflow security practices. For each protocol available, the following are standard minimal security practices that provide additional security to the endpoint.
SMB share definitions have two layers of access management: mapping-level permissions and file-level permissions. Each layer is authenticated against campus active directory users and groups.
SMB protocol is not allowed from the internet and is blocked at campus border routers. Campus VPN can be used to authenticate to SMB shares from off-campus hosts.
Access to NFS exports are managed through host access control lists that allow listed IP addresses or hostnames to map the NFS export. NFS export owners can modify the host access control lists using the service dashboard. It is the responsibility of the NFS export designated owners to maintain the host access-control lists, as necessary to ensure proper data access and security guidelines. NFS export owners for a given export can further configure file-level access-controls using standard Unix (chmod and chown) tools.
NFS mounts to hosts not within campus IP ranges will not be permitted. Due to the dynamic nature of VPN IP addresses, campus VPN cannot be used to tunnel NFS traffic to hosts off-campus.
When a storage share and all underlying data is no longer needed, storage shares must be decommissioned through the service dashboard by a share owner of that share. The process verifies authorization through the owners list of that share and asks for confirmation before the share is removed from service. The process removes network access to the share and moves the data to a 'recycle' bin location on the storage devices. Share data is completely removed by storage administrators after a minimum of 30 days and a maximum of 60 days.
The following enhanced security policies are necessarily account-based and can be configured per account as needed. By requesting the security settings as outlined below, High (Level 3) risk data may be stored on this service. NOTE: you will want to ensure that additional infrastructure components and workflows are configured to meet security standards in order to secure data access end-to-end. For example, any endpoints (desktops, servers or mobile devices) with access to High (Level 3) risk data will necessarily have to be secured to meet High risk data standards.
Data access security is a factor of endpoint security and workflow security practices. Depending on data workflows and management requirements consider these additional practices:
SMB3 provides end-to-end encryption of communication between endpoint and storage. By default, SMB3 is enabled on operating systems Windows 8 or later, Mac OS X 10.7 or later, and ChromeOS 87 or later. They are authenticated through a centralized university directory account. If you are using one of these operating systems to access SMB data, the data is encrypted end-to-end. SMB3 encryption will enforce encryption-in-flight. You can further restrict host access via an access-control list as your data stewards may require. Access-control lists will be managed by the owners of a share. Access-control list modifications can be modified via the storage service dashboard.
Encryption Info:
The below encryption algorithms are used for data in transit based on the recipient's operating system)
AES-128-CCM encryption - Windows 8 or Windows Server 2012
AES-128-CCM encryption - Windows 8.1 or Windows Server 2012R2
AES-128-GCM encryption - Windows 10/Windows Server 2016
AES-256-GCM and AES-256-CCM - Windows 11 and Windows Server 2022
OSX Encryption Algorithms:
AES-128 - MAC OS X 10.7 and later
By default, NFS 3 protocol is secured by host-based access rules. NFS 4 and Kerberized NFS are not currently supported. To enforce encryption-in-flight for NFS exports at this time, please consult the Division of IT staff for available solutions. If you require NFS access to High risk data, please consult the Division of IT staff at storage-help@umd.edu.
Snapshot policies help protect against ransomware attacks and other forms of data-loss that is localized to a specific share or export. Enabling snapshots is recommended. By default, snapshots are stored for 14-days and are taken daily for a specific share. Snapshots can be configured to be retained for longer time periods or can be custom scheduled. Requests for custom schedules and retention times should be sent to storage-help@umd.edu. Please indicate the share name you need to be updated.
Replication policies help protect against catastrophic hardware failures in a specific datacenter region. By default, data on the NSS is configured for scheduled replication every 12 hours between two storage arrays in distinct regional datacenters. The two available regions are the greater College Park, MD region and the Silver Spring, MD region. Data is not sent to any third-party cloud providers. Data is replicated to a second region two times daily. Replication will replicate all data in a storage account. Replication schedules and scope can be customized upon request to storage-help@umd.edu.
Anti-virus protection should be managed at the end-point (desktop or laptop). Virus scanners can be used to target SMB shares or NFS exports specifically. If this is a requirement for your environment, consider using a virus scanner on a management host that can run the scan against the share as needed. Centralized virus scanning is not supported.
Should there be more stringent requirements for ensuring the removal of data from the NSS, specify that you would like certification that the data was removed from all locations on the NSS. Storage engineers will track the request for deletion within an ITSC ticket and certify that all instances of data have been removed without any further delay including snapshots, replicated copies and source data.