Networked Storage Service Security Practices

In this article

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

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.

Hardware-level security

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.


Network access security

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 practices

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 protocols

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.

  1. Mapping-level permissions can be modified by share owners by accessing the a managed share using the service dashboard. It is the responsibility of each SMB share owner to maintain the list of AD groups and users that can map a share as needed for their own workflows and following proper data access procedures.  Only campus AD users and groups can be defined for mapping permissions. Consequently, passphrase strength and recovery policies are enforced through the central identity management service. Such practices adhere to the UMD Interim Standard Protecting Sensitive Information policy (IT-4) section 5.2.
  2. File-level permissions are also managed by technical or administrative contacts of the share utilizing standard Windows NTFS tools that manipulate NTFS access-control lists. Once the SMB share is provisioned by the Division of IT staff, the identified technical owner should provision underlying folders and files with the permissions necessary for their group’s workflows.

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.

NFS protocols

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.


Data destruction/decommissioning practices

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.


Recommendations for enhanced security practices

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:

Improving SMB data access security

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


Improving NFS data access security

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


Snapshot and replication services

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  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


Anti-virus protection

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.


Improving data destruction/decommissioning practices

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.