Table of Contents
The most reliable way to protect the university's sensitive data is to avoid handling sensitive university data. Sensitive university data should be retained or handled only when required. Encryption can be an effective information protection control when it is necessary to possess sensitive university data.
IT Owners and IT Custodians should understand that data encryption is not a substitute for other information protection controls, such as access control, authentication, or authorization; that data encryption should be used in conjunction with those other controls; and that data encryption implementations should be proportional to the protection needs of the data.
This guideline serves as a supplement to the Information Resources Use and Security Policy, which was drafted in response to Texas Administrative Code 202 and UT System UTS-165. Adherence to these guidelines will better assure the confidentiality and integrity of the university's sensitive data should data encryption be used as an information protection control.
The objective of these guidelines is to provide guidance in understanding encryption and the encryption key management required for maintaining the confidentiality and integrity of the university's sensitive data, should data encryption be used as an information protection control.
These guidelines apply to all devices, physical or virtual where university data is classified as Confidential, Controlled, or Published (see Data Classification Standard).
4.1.1. Transmission: In order to protect the confidentiality and integrity of the university's sensitive data; any data classified as Confidential data, and having a required need for confidentiality and/or integrity, shall be transmitted via encrypted communication to ensure that is does not traverse the network in clear text. It is further recommended, but not required, that data classified as Controlled be transmitted via encrypted communications when possible. See the university Data Classification Standard for further clarification on the classification of university data. Applications of encryption for data transmission include, but are not limited to, those identified in APPENDIX-A.
4.1.2. Storage: In order to protect the confidentiality and integrity of the university's sensitive data; any data classified as Confidential data, and having a required need for confidentiality and/or integrity, shall be stored encrypted in systems and/or databases and/or portable media. Controlled or Published data classifications do not require such encrypted storage. See the university Data Classification Guidelines for further clarification on data classification. Applications of encryption for data storage include, but are not limited to, those identified in APPENDIX-B.
4.1.3. A combination of business practices and technology can act as mitigating factors and could significantly reduce the risk of unauthorized data exposure, thereby offsetting the specific need to implement data encryption. Examples of such mitigating factors include, but are not limited to, those identified in APPENDIX-C.
4.2.1. The symmetric algorithms referenced in APPENDIX-D shall be used for encrypting Confidential information.
4.2.2. The algorithms referenced in APPENDIX-E shall be used for public key asymmetric encryption of Confidential information.
4.2.3. The encryption services referenced in APPENDIX-F shall be used for digital signature purposes when Confidential information is involved.
4.2.4. Digital signatures shall be used to associate a user or entity with a respective public key.
4.2.5. Digital certificates shall apply recognized standards (e.g., X.509v3) and shall at least:
- Identify the issuing certificate authority; the certificate authority shall be one authorized by DIR or strictly designated for internal UT Austin usage
- Identify its subscriber
- Provide the subscriber's public key
- Identify its operational period
- Be digitally signed by the issuing certificate authority
4.3.1. Encryption keys used to protect Confidential data shall also be considered Confidential data.
4.3.2. Professional key management is critical to prevent unauthorized disclosure of Confidential data or irretrievable loss of important data. A centralized campus key management infrastructure shall be made available to all university users to ensure appropriate controls are applied. The university data managed by all key management infrastructures shall be considered both Confidential and mission critical.
4.3.3. All university key management infrastructures shall create and implement an encryption key management plan to address the requirements of these encryption guidelines, other university and UT-System regulations, and applicable State and Federal law. UT-Austin Internal Audit shall approve such plans.
- The encryption key management plan shall ensure data can be decrypted when access to data is necessary. Backup or other strategies (e.g., key escrow, recovery agents, etc) shall be implemented to enable decryption; thereby ensuring data can be recovered in the event of loss or unavailability of encryption keys.
- The encryption key management plan shall address handling the compromise or suspected compromise of encryption keys. The plan shall address what actions shall be taken in the event of a compromise (e.g., with system software and hardware, private keys, or encrypted data.)
- The encryption key management plan shall also address the destruction or revocation of encryption keys that are no longer in use (e.g., the user has left the university) or that aren't associated with a key management program.
4.3.4. All symmetric encryption keys used on systems associated with Confidential data shall be randomly generated according to industry standards. Acceptable standards include, but are not limited to, those referenced in APPENDIX-G.
4.3.5. Where symmetric encryption is used to protect Confidential data:
- Master keys shall be changed at least once per year.
- Key encrypting keys shall be changed at a minimum of twice per year.
- Data encrypting keys shall be changed once per session or every 24 hours.
4.3.6. When asymmetric encryption is used, the operational period of asymmetric keys associated with a public key certificate are defined by the encryption key management plan of the issuing certificate authority.
4.3.7. Encryption keys shall be stored within an encrypted key store or an otherwise encrypted form using approved algorithms; or the keys may be stored on a security token (e.g., a smart card). The encryption keys shall never leave the device if stored on a security token.
- This requirement does not pertain to keys (e.g. SSH host keys) or protocols (e.g. encryption used by backup technologies) that are providing layers of encryption transport in addition to the strong encryption that has already been applied to Confidential data.
4.3.8. Encryption keys are confidential information, and access shall be strictly limited to those who have a need-to-know. The owner(s) of data protected via encryption services shall explicitly assign responsibility for the encryption key management that should be used to protect this data. If keys are transmitted over communication lines, they shall be sent in encrypted form. The exchange of keys should employ encryption using a stronger algorithm than is used to encrypt data protected by the keys.
4.3.9. Encryption keys that are compromised (e.g., lost or stolen) shall be reported immediately to the Information Security Office (email@example.com), the key manager, and the information owner of the data being protected. The key shall be revoked or destroyed and a new key generated. Key re-assignments shall require re-encryption of the data.
4.4.1. Encryption keys that are generated by a university production certificate authority (CA) and used to control access to the CA server or used by the CA to perform functions shall be stored on Hardware Security Modules (HSM).
4.4.2. All HSMs used within the university shall adhere to recognized standards (e.g., FIPS 140-3).
4.4.3. University CAs must be designed such that all CA administrator functions are accounted for in detail. Ideally, no single administrator shall obtain full access to the CA encryption keys (e.g., separation of duties, dual control, etc.)
4.4.4. University CAs within the university must adhere to a respective encryption key management plan and create a documented Certificate Practice Statement (CPS).
The encryption systems used by the university must comply with applicable laws and regulations. Any export or import of encryption products (e.g., source code, software, or technology) must comply with the applicable laws and regulations of the countries involved, including those countries represented by foreign nationals affiliated with the university. The United States Department of Commerce provides additional guidance specific to such encryption export controls, http://www.bis.doc.gov/encryption/.
5.1. Information Security Office Responsibilities
5.1.1. Development and maintenance of the university Data Encryption Guidelines.
5.1.2. Assess the secure installation and maintenance of all equipment supporting encryption controls at the university.
5.1.3. Assess the performance and security monitoring for all elements of the encryption control processes.
5.1.4. Assess all related key management processes.
5.1.5. The Information Security Office, acting on behalf of the university, reserves the right to refuse any encryption request that may compromise the security of the university's networks or sensitive data.
5.2.1. Adherence to the university Data Encryption Guidelines and related policies established by the university.
5.2.2. Ensure secure installation and maintenance of all respective equipment supporting encryption controls.
5.2.3. Ensure performance and security monitoring for all respective elements of the encryption control process.
5.2.4. Ensure all related key management processes can be accounted for in detail and, if possible, that no single key management supporting staff member can individually obtain full access to master keys or CA encryption keys (e.g., separation of duties, dual control, etc).
5.2.5. Undergo a background check and complete the Acceptable Use Policy Acknowledgement form.
5.3. User Responsibilities
5.3.1. All users shall adhere to the university's Data Encryption Guidelines and related policies established by the university.
5.3.2. All users shall be familiar with the university's Minimum Security Standards for Data Stewardship.
5.3.3. All users shall acknowledge a key escrow agreement, which will identify the required escrow of the subscriber's private key. This requirement will be established for the benefit of the user, the university, and to comply with state and federal law.
5.3.4. All users must manage the storage and transmission of data files in a manner which safeguards and protects the confidentiality, integrity, and availability of such files.
5.3.5. Questions about the classification of a specific piece of data should be addressed to the local supervisor or respective IT Owner. Questions about these guidelines should be addressed to the Information Security Office.
NIST Special Publication 800-57: Recommendation for Key Management: Part 1: General (Revision 3) and Recommendation for Key Management: Part 2: Best Practices for Key Management Organization
Portions adapted from "University of Pittsburgh: Security Guidelines for Encryption," http://technology.pitt.edu/documentation/Security_Guidelines/Encryption…, with permission from the University of Pittsburgh, Pittsburgh, Pennsylvania 15260-3332. No longer available online.
Portions adapted from Encryption at the University of California: Overview and Recommendations, with permission from the University of California Office of the President, Oakland, California 94607-5200.
Encryption of Confidential file transfers can be achieved via the use of an encrypted transmission protocol or network service (e.g., scp, sftp, etc) or by transferring an Confidential file that has been encrypted prior to the transmission.
Confidential content transmitted in e-mail messages shall be encrypted prior to the transmission, presented via a secure web application, or encrypted in a secure message format, given e-mail is exposed to the possibility of unauthorized access at a number of points throughout the delivery process.
Encryption of Confidential data, including login passwords, transmitted during remote login sessions (e.g., Telnet, TN3270, and remote control software for PCs) shall be provided through the use of secure applications or protocols.
Encryption of Confidential data communicated between a user's browser and a web-based application shall be provided through the use of secure protocols (e.g., HTTPS, TLS/SSL, etc.) The display of Confidential data shall be limited to only what is required by the user's authorized use of the application.
Encryption of Confidential data that is output to a printer connected to a network shall be provided through the use of secure printing applications (e.g., JetDirect) or protocols (e.g., IPP) to prevent unauthorized network interception.
Encryption of Confidential data transmitted by remote files services shall be provided through the use of encrypted transmission protocols (e.g., IPSec, ISAKMP/IKE, SSL/TLS) to prevent unauthorized interception.
Encryption of Confidential data transmitted between an application server and a database shall be implemented to prevent unauthorized interception. Such encryption capabilities are generally provided as part of, or an option to, the database server software.
Encryption of Confidential data transmitted between cooperating applications shall be provided through the use of commonly available encrypted protocols (e.g., SOAP with HTTPS) to prevent unauthorized interception.
A VPN connection offers an additional option to protecting Confidential data transmitted via the network when other alternatives are not feasible. The use of VPNs should be carefully considered so that all security and networking issues are understood. ITS-Telecommunications and Networking staff should be consulted prior to any VPN implementations.
Encryption of Category I data stored on portable computing devices (e.g., PDAs, tablet PCs, laptops, and smart phones), as well as storage media, (e.g., CDs, DVDs, and USB drives) shall be provided through the use of a whole disk encryption tool or one that can at least be configured to encrypt all Confidential data.
Encryption of Confidential data shall be provided to facilitate the secure transport of individual files over a network without transmission encryption or to off-line storage devices (e.g., CDs, DVDs, or USB drives.)
Encryption of Confidential data contained in a database server shall be provided through the use of whole disk encryption or through features native to the database server software. Encryption capabilities native to database server software may allow for encryption of specific tables or columns of a database and may also be required to segregate access rights among multiple applications that utilize a single database server.
18.104.22.168. IT Owners and IT Custodians should understand that database server encryption does not imply that data in the database server is encrypted when transmitted over a network. In general, the database server decrypts data before it is transmitted, therefore encryption for data transmission shall also be implemented for database servers processing Confidential data.
22.214.171.124. IT Owners and IT Custodians should consider a number of factors when making decisions on database server encryption (e.g., data classification, need for confidentiality, number of associated applications, system administration, performance, cost, and backup requirements.)
8.2.4. Backup and Archiving
Encryption of Confidential data contained in backups and/or archives copies shall be provided to prevent unauthorized access.
- Firewall Restricting Capabilities
- Detailed Audit Logging
- Detailed Process Logging
- Intrusion Detection Capabilities
- Intrusion Prevention Capabilities
- Integrity Checking Capabilities
- Separation of Sensitive Duties
- Physical Security Capabilities
- AES (128, 192, or 256 bit)
- RC6 (256 bit)
- Serpent (128, 192, or 256 bit)
- Twofish (128, 192, or 256 bit)
- RSA (minimum 2048 bit)
- ECC (minimum 384 bit)
- RSA (minimum 2048 bit) with SHA-2
- DSA (minimum 2048 bit) with SHA-2
- ECDSA (minimum 224 bit) with SHA-2
- FIPS 186-2
- ANSI X9.31
- ANSI X9.62
- ANSI X9.82
9. REVISION HISTORY
|5/2/2020||Updated Protocols and Algorithms||No material changes|
|6/24/2013||Reviewed and fixed broken links|
|6/20/2013||Converted back to HTML|
|Data Encryption Guidelines||2/28/2011||Converted web page to PDF|
Updated visual appearance to new template. Corrected any out of date links to ensure they are pointing to the most current policy documents.
Section IV.2.5: Updated link to HRS background check form and the Position of Special Trust form. "Undergo a background check and complete the Position of Special Trust form."
"Undergo a background check and complete the UT-Austin Security Sensitive Form."
Replaced references to IT Security Operations Manual with Information Resources Use and Security Policy.
Replaced references to Data Classification Guidelines with Data Classification Standard.
Removed link to University of Pennsylvania PDF, which is no longer available online.
"IT Security Operations Manual"
"Data Classification Guidelines"
Replaced references to BPM 53, 66 and 75 with UTS-165.
Removed "draft" reference from section IV.3.2 and section V.
"BPM 53, BPM 66, BPM 75"
"Minimum Security Standards for Data Stewardship (draft)"
|Chief Information Security Officer||Approval||Cam Beasley|
March 3, 2011