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 shares 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 services of the storage devices. Further, administrative login is managed via membership within a UMD 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.
Share snapshot policies help protect against ransomware attacks and other forms of data-loss that is localized to a specific share or export by creating point-in-time copies of files within the share. Snapshots are enabled for each share upon share creation. By default, snapshots are stored for 14-days and are taken every 12 hours daily for each share. Snapshots can be configured for longer retention 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 and the requested retention period.
Replication policies help protect against catastrophic hardware failures in a specific datacenter region. By default, each share on the NSS is configured for scheduled replication every 4 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 six times daily. Replication will replicate all data in a storage account by first taking a read-only snapshot of the source data and then initiating the replication job. Replication schedules and scope can be customized upon request to storage-help@umd.edu.
Shares created for purposes of storing data classified as High Risk (Level 3) will be monitored by a file protocol activity auditing tool that records file activity per user and end-point. Activity collected includes file creation, modification and deletion as well as share connections and disconnects. DIT does not actively alert on any file activity within any share. Auditing data is retained for the purposes of investigating any security incidents reported to the security operations center within DIT's security office.
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, share owners should email storage-help@umd.edu to have DIT storage and security engineers track a request for deletion within an ITSC ticket. Storage engineers will work with the data and share owners to help certify that all instances of share data have been removed from the NSS without any further delay including snapshots, source data and replicated copies. Certification of destruction can be verified with the following process:
Share owners and/or grant writers should also note the following NSS policy on storage array decommissioning practices:
Upon discontinuance of any underlying storage arrays that are part of the NSS, pursuant to UMDs IT-4 "Standard for Protecting Sensitive Information", section 6 and "USM IT SECURITY STANDARDS", section 7.2-4, UMD-DIT's policy is to destroy all data on physical media in one of two methods: