Networked Storage Service Security Practices

Table of Contents

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


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

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


File Protocol Activity Auditing

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

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.


Certified data destruction/decommissioning practices

Should there be more stringent requirements for ensuring the removal of data from the NSS, share owners should email 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:

  1.  The data owners can delete the data from their respective shares themselves or submit a request for DIT to perform the action in a manner that will log the deletion in our auditing software utility.  
    2.  Audit logs can be provided for certification through DIT compliance and confirmed with ORA as documented in the KB article titled "Unfunded Data Use Agreement Data Destruction Process".  Once data is confirmed to be deleted at this point, data recoverability is not possible. Hardware-based encryption with FIPS-140-2 certification at the drive-level will prevent any ability to retrieve data blocks from disk drives should storage media ever need to be replaced physically as a result of failure, retirement, or theft.

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: