Highlighting Changes to the MSSND (Draft) for 2020

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, Suppliers, and anyone else accessing UC Berkeley IT Resources, network, or Institutional Information. Non-networked devices should meet the MSSND requirements as applicable, e.g. device lockout, passphrase requirements, use of authentication, etc. Berkeley's guest Wi-Fi network (CalVisitor) is not considered a "UC Berkeley network" for the purposes of this standard.

• 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  

  • Workforce Members, students, Suppliers, and anyone else accessing UC Berkeley IT Resources, network, or Institutional Information.

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

• Clarified that CalVisitor is not considered a "UC Berkeley network" for the purposes of the MSSEI.

1. Patching and Updates

Devices connected to a UC Berkeley network, including personal 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.  

Patching and Updates Guidelines

• Scope now explicitly includes OSes, not just software

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

• Clarified that this requirement applies to all devices, including personal devices.

2. Anti-malware Software

When built-in anti-malware features are available in operating systems, such as with current versions of Windows and macOS, they must be enabled. Otherwise, separate anti-malware software that supports real-time scanning is recommended, including for network storage appliances. This requirement does not apply to mobile devices. Please refer to the Guidelines for specific use cases, including Linux.

Anti-malware Software Guidelines

• Requires enabling built-in anti-malware features in Windows, macOS, and where available in other operating systems.

• Recommended for network storage appliances and OSes where built-in features aren't available.

• Separate guidance for Linux.

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. 

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

Host-based Firewall Software Guidelines

• Removed “where available” caveat for Windows, Mac OS,  Linux/Unix

• Included an ACL option

• Added access control requirement for printers, and network attached equipment where available

4. Use of Authentication

Network services and local (console) device access must require authentication by means of passphrases or other secure authentication mechanisms (e.g. biometrics). Notably, the following network services must require authentication: proxy and gateway services, email (SMTP) relays, wireless access points, remote desktop, SSH shell access, and printer administrative interfaces. 

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, confidentiality, or integrity are required.

Use of Authentication Guidelines 

• Incorporated biometrics

• Clarified that unencrypted services must be replaced by their encrypted equivalents if authentication, confidentiality, or integrity are required

5. Passphrase Requirements

When passphrases are used, they must meet or exceed the following complexity specifications:

Passwords MUST contain eight (8) characters or more following this sliding scale:

• 8-11 characters: mixed case letters, numbers and symbols (e.g., !@#$%^&*()_+|~-=\'{}[]:";'<>?,./'space');
• 12-15 characters: mixed case letters and numbers;
• 16-19 characters: mixed case letters;
• 20+ characters: no restrictions.

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.

Individuals must not share user account passphrases, PINs, devices used to authenticate the user (e.g., mobile phones) or tokens (e.g. multifactor tokens, smartcards, etc.) with others.

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.

The same or substantively similar passphrases must not be used across multiple accounts.

Device and account credentials such as passphrases, PINs, or account recovery questions & answers must never be stored in plain text and must be encrypted. Application secrets such as database credentials and API keys should be protected according to industry best practices such as OWASP(link is external). Authentication credential stores on servers must be made resistant to offline attacks according to NIST guidelines (NIST SP 800-63B, Sec. 5.1.1.2)

Passphrase Guidelines (Draft)

• Updated passphrase requirement to align with IS-3 sliding scale - minimum 8 characters, less complexity required for longer passphrases

• Added requirements for PINs and biometrics

• Added requirement that device and account credentials must not be stored in plain text; stored passphrases, PINs, and account recovery Q&As must be encrypted

• Clarified that different standards apply to application secrets such as database credentials and API keys, and to authentication credential stores on servers

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

Kiosks and other public-use devices

Devices configured to satisfy the Campus Guidelines for Kiosk Workstations (e.g., public-use workstations in libraries and room/event scheduling panels) are exempt from this requirement.

• Device inactivity lockout reduced from 20 to 15 min

• Incorporated smartcards and biometrics in addition to passphrases/PINs

7. Unnecessary Services

Only network services, ports, and protocols necessary for the intended purpose or operation of a device may be running. All others must be disabled or removed. 

Unnecessary Services Guidelines

• No substantive changes

8. Remote Access Services

Remote access to systems:

Remote desktop, interactive shell, or terminal-level access that allows broad access from the public Internet to a system is not allowed and must be restricted. Indirect access using a gateway or proxy service approved for campus use by the CISO is allowed. Remote access using a configuration approved though documented Unit policy that meets the configuration requirements below is also allowed.

Remote access to the UC Berkeley network:

Only remote access services, such as proxy servers and VPN gateways, whose configuration and use have been approved by the CISO, or through documented Unit policy, are allowed to provide broad access to the UC Berkeley network from the public Internet. These remote access services must meet the configuration requirements below. 

Configuration Requirements:

All approved remote access to individual systems or the UC Berkeley network must be configured according to the Remote Access Services Guideline

Scope Clarification: 

This requirement does not apply to:

• sessions where access is restricted to a limited number of trusted hosts;
• sessions where access is from one campus host to another.

Remote Access Services Guideline

• This is a new requirement

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.

Privileged Accounts Guideline 

• Clarified that separate admin and non-admin accounts are required, and

• Non-privileged user accounts must be used and only elevated to root or Administrator when necessary

• Limited the exemption for devices that don’t support separation of privileges to devices that don’t handle P3 or P4 data and are not on a network containing P4 data