Secondary navigation

You are here

Highlighting Changes to the MSSND (Draft) for 2020

May 8, 2020

The Information Security Office recently updated the Miminum Security Standards for Networked Devices and the Draft of that Standard is currently under Campus review. The update incorporates elements from UC’s systemwide Electronic Information Security Policy, IS-3, and brings the Standard into alignment with current industry best practices.

The below table shows the updated MSSND Requirements on the left and the key updates or changes for that requirement in the right column. Additionally, the newest guideline (where available) is linked under each requirement. We wanted to display these key updates in a clear and concise way so that users may quickly see the changes that were made.

If you have any questions about the MSSND Draft or any of the changes made, email us at security@berkeley.edu.

Updated MSSND Requirements (Draft):

Key Updates, Changes, and Additions:

Scope:

This standard applies to all UC Berkeley IT Resources and all devices, independent of their location or ownership, when connected to a UC Berkeley network, or when storing, processing, or accessing Institutional Information hosted at any location. It applies to Workforce Members, students, and Suppliers. Non-networked devices should meet the MSSND requirements as applicable.

Updated to explicitly state that MSSND applies to:

All UC Berkeley IT Resources and all devices, independent of their location or ownership, when connected to a UC Berkeley network, or when storing, processing, or accessing Institutional Information hosted at any location

Added that non-networked devices should still meet the MSSND requirements as applicable.

1. Patching and Updates

Campus networked devices must only run supported software and operating systems for which security patches are made available in a timely fashion. All currently available security patches must be applied on a schedule appropriate to the severity of the risk they mitigate.

Where extended vendor support is available for software or operating systems deemed “end-of-life”, enrollment is required and an exception must be requested.

Scope now explicitly includes OSes, not just software

Clarified about extended vendor support for "end-of-life" software/OS

2. Anti-malware Software

For Microsoft Windows and macOS devices, anti-malware software must be running, up-to-date, and configured to update automatically. In addition, the software must run real-time scanning and/or scan the device regularly. Anti-malware software is also recommended for mobile devices, network storage appliances, and Linux where available.

3. Host-based Firewall Software

Network attached systems must, wherever possible, utilize host-based firewalls or access control lists (ACLs). These controls must be enabled and configured to block all inbound traffic that is not explicitly required for the intended use of the device. Use of a network-based firewall does not obviate the need for host-based firewalls.

Microsoft Windows, macOS, and Linux/Unix devices are all equipped with firewalls though they may not have them enabled by default.

Further, many printers, and network attached equipment have access controls to restrict connections to a limited number of hosts or networks in compliance with this policy. Where available, these must be enabled.

Services and devices that explicitly provide unauthenticated access to Protection Level 1 data (for example: public web servers and public kiosks) are an exception to this requirement, provided they can do so without allowing it to be used by attackers.

Simple devices like printers, game consoles, DVRs, media extenders, network attached storage, and router/firewalls that don't support local authentication are exempt from this requirement provided that physical access is restricted. This exemption does not extend to network-facing services running on the device.

Wireless access points must require industry-standard, strong encryption to connect (such as WPA2), or use a captive portal or some other strong mechanism to keep casual users near the access point from using it to get full access to the UC Berkeley network. WEP or MAC address restrictions do not meet this requirement.

All network-based authentication must be encrypted in transit using industry-standard, strong encryption mechanisms. Unencrypted services such as HTTP, Telnet, FTP, SNMP, POP, and IMAP must be replaced by their encrypted equivalents if authentication or confidentiality are required.

PINs for mobile devices must be at least 6 characters in length. Authentication using the integrated biometric capabilities of supported devices from major vendors is also acceptable.

Multi-user systems must be configured to enforce these complexity requirements where technically possible.

All pre-assigned passphrases must be changed at the time of the initial login. Multi-user systems must be configured to enforce this requirement.

Default and blank passphrases are prohibited and must be changed to a passphrase that meets the requirements in this Standard. If an account has a default or blank passphrase that cannot be changed, that account must be disabled.

Passphrases must be changed immediately if independently discovered, publicly disclosed, a suspected compromise has occurred, or a device on which they were used or stored has been lost or stolen. This includes the discovery of hashed passwords or passphrases.

Do not use the same or substantively similar passphrases across multiple accounts.

Authentication secrets must never be stored in plain text. Stored passphrases and PINs must be encrypted. Authentication credential stores on servers must be made resistant to offline attacks according to NIST guidelines.

Added requirements for PINs and biometrics

Added requirements that authentication secrets must not be stored in plain text; stored passphrases and PINs must be encrypted.

Added clarification that authentication credential stores on servers must be made resistant to offline attacks according to NIST guidelines.

Added the following:

No default or blank passphrases allowed

No sharing of passphrases

Must be changed if compromised

No re-use across different accounts

6. Device Lock-Out

Devices must be configured to "lock" or log out and require a user to re-authenticate with a strong passphrase/PIN, smart card or biometric lock if left unattended for more than 15 minutes, except in the following cases:

Devices without auto-locking/logoff capability

Devices that do not support a configuration that automatically locks or logs off users after a specified period of time (such as network appliances and consumer electronics) may meet this standard through alternate controls, such as physical access restrictions (e.g., device stored in a locked office not accessible by unauthorized users).

No substantive changes

8. Remote Access Services

Remote desktop, workstation, shell, or terminal-level access from the public Internet must use the Campus VPN, an approved Campus gateway or proxy service; or be approved by the CISO.

Only network proxy or gateway services(link is external) whose configuration and use have been approved by the CISO are allowed to provide access to the UC Berkeley network from the public Internet. Examples of this type of service include modem pools, proxy servers, and VPN gateways. This policy does not cover the installation of routers, switches, and other network devices that extend the internal network without providing external access.

Remote access services and network gateways must not be deployed to circumvent UC Berkeley network and security policies.

Guidelines, including a list of approved services/configurations, are under development

Remote desktop, workstation, shell, or terminal-level access from the public Internet must use the Campus VPN, an approved Campus gateway or proxy service; or be approved by the CISO.

Network proxy or gateway services must be approved by the CISO to be allowed to provide access to the UC Berkeley network from the public Internet

Remote access services and gateways must not be deployed to circumvent UC Berkeley network and security policies

9. Privileged Accounts

Devices must be configured with separate accounts for privileged (administrator) and non-privileged (user) access.

Non-privileged user accounts must be used and only elevated to root or Administrator when necessary. A secure mechanism to escalate privileges (e.g., via User Account Control or via sudo) with a standard account is acceptable to meet this requirement.

Privileged and super-user accounts (Administrator, root, etc.) must not be used for non-administrator activities.

Network services must run under accounts assigned the minimum necessary privileges.

For devices that do not support separation of privileges: Devices that do not provide separate facilities for privileged and unprivileged access (e.g., some network appliances and printers with embedded operating systems) are exempt from this requirement, provided they do not handle P3 or P4 data and are not on a network containing P4 data.