Skip to main content

Encryption Standard

The Encryption Standard supports and supplements the Information Security policies found in the Information Security Office | University of Missouri System (umsystem.edu). It will periodically be reviewed and updated as necessary to meet emerging threats, changes in legal and regulatory requirements and technological advances.

I. Overview

Encryption is the process of encoding information (commonly from “plaintext”) into a form called “ciphertext” to protect the data and can be applied to data stored (at-rest) or transmitted (in-transit) over networks. It reduces the risk of unauthorized access or disclosure, and may help mitigate financial, regulatory, reputational, and institutional risks to UM related to loss or breach of unencrypted data. The need for encryption of information is based on its classification and use case.

Encryption should be used in conjunction with other data protection controls, such as access control, strong passwords, authentication and authorization.

Federal or state regulations or contractual agreements may require additional actions that exceed those included in this Standard.

II. Scope

The Encryption Standard applies to the UM, UMC, UMH, UMSL, UMKC, and S&T business units, and to all research, teaching and learning, clinical and administrative data. It further applies to:

  • All units, faculty, principal investigators, staff, and students that process, maintain, transmit, or store data classified as DCL3/DCL4 on any device. This included devices that are connected to the campus network as well as those that are not, and whether or not the device is managed by the university or self-managed.
  • Any storage media that has been used to store DCL3/DCL4 university information or data.
  • Websites and web services, for which the entity has administrative responsibility, including those managed and hosted by third-parties on behalf of the entity. Any third-party provider with a contractual relationship with the university that maintains the same data types

III. Standard

The objective of the Encryption Standard is to provide guidance in understanding encryption and the encryption key management required for maintaining the confidentiality and integrity of sensitive data, should data encryption be used as an information protection control.

Where technically feasible, the university requires data classified as DCL3/DCL4 to be encrypted at rest or in transit, depending on storage location and storage medium (see Table 1 below). If data is unable to be encrypted for technical reasons, an exception should be requested from the appropriate information security office for your respective campus.

Specifically, UM requires the use of encryption technologies that meet NIST FIPS minimum requirements:

  • Cryptographic modules validated under the Cryptographic Module Validation Program (CMVP) in accordance with NIST FIPS Publication 140-3 are approved for use by this standard. When selecting a storage encryption technology, the university and its units should prioritize solutions that use existing system features (such as operating system features) and infrastructure.

Encrypting Data-at-Rest

Encryption at rest involves encrypting data when it is stored on a server or hard drive. There are two recognized methods for encrypting data-at-rest:

  • Full disk encryption, also called whole disk encryption, encrypts the entire device or disk partitions at once; it provides good protection against data loss due to theft or other loss and requires less attention to how one handles files. For example, Bitlocker (Win), FileVault (Mac), and LUKs (Linux/REHL).
  • File-Level Encryption encrypts individual files. There are two methods of file-level encryption:
    • When the file is decrypted only when it is in use, typically the case with application-based encryption.
    • When the file is not automatically re-encrypted when one is done viewing or editing it, as it the case with standalone encryption utilities.                                             

Table 1. Encryption Requirements for Data-at-Rest by Location or Type of Device

Location or Device Type

Restricted/DCL4

High/DCL3

Moderate/DCL2

Low/DCL1

Data Centers

Required

Recommended

Recommended

Recommended

Computing Labs

Required

Required

Recommended

Recommended

Databases

Required

Recommended

Recommended

Recommended

Portable and Removable Storage Media

Required

Required

Recommended

Recommended

Laptops (UM owned)

Required

Required

Recommended

Recommended

Desktops (UM owned)

Required

Required

Recommended

Recommended

Cloud Providers

Required

Required

Recommended

Recommended

 

Encrypting Data-in-Transit

Malicious users may intercept or monitor unencrypted data when transmitted on untrusted networks and gain unauthorized access that jeopardizes the confidentiality of sensitive institutional data.

The following are examples of the commonly employed technologies that provide encryption of data in transit:

  1. Virtual Private Network (VPN): Users traveling on university business or who need to access the UM network and any sensitive university data from a non-university or public network must use the UM VPN (Virtual Private Network) which meets this standard. It also permits access to applications or data that require an on-campus connection.
  2. Secure Web Traffic: HTTPS is a protocol that encrypts traffic between a web browser and a web-based application. The recommended Transport Layer Security (TLS) versions and ciphers are listed below. This list is not intended to be comprehensive and may not apply to all use cases. Systems should not be configured to use cipher suites other than those listed in Section 3.3.1 of NIST SP800-52r2).

TLS 1.3:

Rationale for TLS 1.3:
Offers the most modern configuration with extremely high level of security for supporting services and clients.

TLS 1.2:

Rationale for TLS 1.2:
TLS 1.2 is the minimum supported protocol, as recommended by RFC 7525, PCI DSS and others. It may offer greater compatibility with older systems/networks who yet to support TLS 1.3.

Please refer to the following links for the most accurate and current recommendations:

Key Management

Users and groups responsible for storing, maintaining, processing, or transmitting highly sensitive or restricted data are required to ensure this data is encrypted, and a cryptographic key management plan is in place. The key management plan protects the creation, use, distribution, storage and recovery of cryptographic keys.  To prevent unauthorized disclosure and to ensure access to data when needed, effective key management is critical. Lost or destroyed keys may render encrypted data unrecoverable if no other copies of the data exist. Decryption keys should be stored and shared separately from the encrypted data. Cryptography keys must themselves be considered highly sensitive data and encrypted themselves when stored. See Encryption Key Management Best Practices.

Data Encryption & Export Controls

Any export or import of encryption products must comply with the applicable laws and regulations of the countries involved, including those countries represented by foreign nationals affiliated with UM. Faculty conducting research that incorporates, develops or uses data encryption software both mass market and custom-developed—must comply with two federal laws, International Traffic in Arms Regulations (ITAR) and Export Administration Regulations (EAR). It is important to consult with Research Security and Compliance prior to any international travel to confirm country-specific regulations.

IV. Violations and Sanctions

Failure to abide by this policy may result in denial of access to University IT and telecom resources and may also result in disciplinary action up to and including termination.

Exceptions

Exceptions to the standards in this document may be required due to budget, functional or technology limitations. Exceptions must be approved and documented by the Information Security Office at each business unit. Justification must be submitted along with any compensating controls using the standard exception request process.

V. References

SANS Acceptable Encryption Policy

Encryption and Key management Overview

FIPS 140-2, Security Requirements for Cryptographic Modules, 2001

FIPS 140-3, Security Requirements for Cryptographic Modules, 2019

FIPS 200, Minimum Security Requirements for Federal Information and Information Systems, 2006

NIST Special Publication 800-111, Guide to Storage Encryption Technologies for End User Devices, 2007

NIST Special Publication 800-52 Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations

NIST.SP.800-53r5 Security and Privacy Controls for Information Systems and Organizations

NIST Special Publication 800-57, Recommendation for Key Management, Part 1 and Part 2, 2019-2020

NIST Special Publication 800-175b, Guideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms, 2020

VI. Related NIST Security Controls

AC-17 Remote Access

AC-18 (1) Wireless Access

AC-19 (5) Access Control for Wireless Devices

AU-9 (3) Protection of Audit Information

CM-3 (6) Configuration Change Control

IA-5 (1) Authenticator Management

IA-7 Cryptographic Module Authentication

MA-4 (4)(b)(2)(6) Nonlocal Maintenance

MP-5 (4) Media Transport

PE-4 Access Control for Transmission Media

SC-8 (1)(3)(4) Transmission Confidentiality and Integrity

SC-12 (1)(2)(3) Cryptographic Key Establishment and Management

SC-13 Cryptographic Protection

SC-28 (1) Protection of Information at Rest

UM System Data Loss Prevention

Reviewed 2022-12-01