UC Berkeley security policy mandates compliance with Minimum Security Standard for Electronic Information for devices handling covered data. The recommendations below are provided as additional guidance to assist with achieving requirements 6.1 Encryption In Transit and 11.3 Wireless Network Security.
Requirements
Requirement 6.1 Encryption In Transit: Transmission of Institutional Information classified at P2 or higher must be encrypted using non-deprecated, industry-accepted encryption technologies. (See this guideline for important considerations and exceptions regarding this control.) 6.1 Implementation Information
Requirement 11.3 Wireless Network Security: Units that provide protected wireless networks for use with data classified at P2 and above must ensure that those networks:
- Are encrypted using non-deprecated, industry-accepted encryption technologies;
- Use segmentation to ensure separation from public networks or the campus guest network;
- Have access controls;
- Do not interfere with the normal operation of other campus networks.
11.3 Implementation Information
Description of Risk
Malicious users may intercept or monitor plaintext data transmitting across unencrypted networks and gain unauthorized access to that jeopardizes the confidentiality of the sensitive data.
Recommendations
Covered data must be encrypted when transmitted across networks to protect against eavesdropping of network traffic by unauthorized users. In cases where source and target endpoint devices are within the same protected subnet, covered data transmission must still be encrypted as described below due to the potential for high negative impact of a covered data breach. The types of transmission may include client-to-server, server-to-server communication, as well as any data transfer between core systems and third party systems.
Email is not considered secure and must not be used to transmit covered data unless additional email encryption tools are used. See Additional Resources section for email encryptions options and see Approved Exceptions section to see where this requirement is not applicable.
Consider the following recommendations for designing secure transit of covered data.
- Where the covered device is reachable via web interface, web traffic must be transmitted over Secure Sockets Layer (SSL), using only strong security protocols, such as Transport Layer Security (TLS).
- Covered data transmitted over email must be secured using cryptographically strong email encryption tools such as PGP or S/MIME (see email encryption link in Additional Resources section). Alternatively, prior to sending the email, user should encrypt covered data using compliant File Encryption tools and attach the encrypted file to email for transmission.
- Non-web transmission of covered data should be encrypted via application level encryption
- Where the application database resides outside of the application server, the connection between the database and application should also be encrypted using FIPS compliant cryptographic algorithms.
- Where application level encryption is not available for non-web covered data traffic, implement network level encryption such as IPSec or SSH tunneling (for more details on these technologies, see Additional Resources)
- In general, encryption should be applied when transmitting covered data between devices in protected subnets with strong firewall controls. *See Approved Exceptions section to see where this requirement is not applicable.
Examples of insecure network protocols and their secure alternatives include:
| Instead of... | Use... | |
|---|---|---|
| Web Access | HTTP | HTTPS |
| File transfer | FTP, RCP | FTPS, SFTP, SCP, WebDAV over HTTPS |
| Remote Shell | telnet | SSH2 terminal |
| Remote desktop | VNC | radmin, RDP |
Picking Encryption Algorithms
When selecting algorithms to encrypt covered data, keep these considerations in mind:
- For the same encryption algorithm, longer encryption key length generally provides stronger protection.
- Long complex passphrases are stronger than shorter passphrases. Please refer to campus passphrase security standard for speicific requirements.
- Strong encryption generally consumes more CPU resources than weak encryption.
Wireless Connections
When connecting to wireless networks to access a system handling covered data, only connect to wireless networks employing cryptographically strong wireless encryption standards such as WPA2. Encryption mechanisms described in the section above must also be applied in addition to strong wireless network encryption to ensure end-to-end protection.
Relevant Campus Services
The ISO CalNet team provides InCommon Certificate Services that distributes digital certificates for encryption and authentication needs.
Link: https://calnet.berkeley.edu/calnet-technologists/incommon-certificates
Approved Exceptions
Data encryption in transit (as defined in MSSEI requirement 6.1, and further described in this guideline) is not required in the following three narrowly defined scenarios. Information Security and Policy approved these exceptions based on an exception request submitted by Network and Operations Services, after performing a security risk assessment. Because these exceptions are the result of a point-in-time evaluation of risk, they will be reviewed periodically, and will be updated as needed.
- Data classified as Protection Level P2 or P3 traversing only within the Earl Warren Hall (EWH) data center network does not require encryption in transit. For example, this exception applies when transferring covered data between two servers residing in the EWH data center. However, the exception does NOT apply – i.e., encryption is required – when a user is accessing covered data on a server in the EWH data center from a desktop in a second floor office in EWH.
Any device on the same subnet as a Protection Level P4 system that uses this encryption in transit exception is required to meet P4 requirements. All other P4 security controls, including the protected subnet requirement, do still apply to covered devices residing on the Earl Warren Hall data center network.
- P2 and P3 data is not required to meet MSSEI encryption in transit requirements when traversing the UC Berkeley campus wired network. The UC Berkeley campus wired network generally falls under UC Berkeley campus IP address spaces as defined at http://net.berkeley.edu/access/ucb-nets.shtml. For more specific guidance on which IP address ranges are part of the campus wired network, please review the Wired Campus Network Firewall Recommendations page (requires CAS authentication).
This exception does not include transmission over the CENIC network to the San Diego Super Computer data center (e.g., UC Backup), off campus networks that are still part of the campus IP address space, or wireless networks such as eduroam. Applications or systems (e.g. file servers) wishing to take advantage of the campus wired network encryption exception must restrict access to and from all other networks. This can be accomplished by applying firewall rules.
- Email with P2 or P3 data routed only within the berkeley.edu domain (bMail) is encrypted in transit by default, and therefore does not require additional encryption.
Email forwarding to non-berkeley.edu addresses invalidates this exception, because encryption between UC Berkeley and external mail servers cannot be guaranteed. In addition to campus restrictions on auto-forwarding campus email outside of the UC system, campus units using email for institutional processes involving P2/P3 data should establish unit-wide policies that restrict staff and faculty from forwarding their email outside of the berkeley.edu domain.