Minimum Security Standards for Networked Devices (MSSND)

The following revised UC Berkeley Minimum Security Standards for Networked Devices (MSSND) has been approved by the Campus Information Security and Privacy Committee (CISPC) and the campus Chief Privacy and Security Officer (CPSO) with an effective date of March 15, 2012.  This version supersedes MSSND: Appendix A.


UC Berkeley security policy mandates that all devices connected to the UC Berkeley network comply with the following nine requirements, referred to collectively as the Minimum Security Standard for Networked Devices (MSSND). 
 
Compliance with the MSSND helps protect not only the individual device, but also other devices connected through the electronic communications network. The standard is intended to prevent exploitation of campus resources by unauthorized individuals, including the use of campus resources by unauthorized individuals to attack other systems on the campus electronic communications network or the Internet.

An exception is required for any configurations that do not comply with the MSSND.

Questions about MSSND may be directed to itpolicy@berkeley.edu

1. Software Patch Updates

Campus networked devices must only run software 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.

Software Patch Update Guidelines

2. Anti-malware Software

For Microsoft Windows or Mac OS X devices for which anti-malware software is available, anti-malware software must be running and up-to-date. In addition, the software must run real-time scanning and/or scan the device regularly.

Anti-Malware Software Guidelines

3. Host-based Firewall Software

For Microsoft Windows, Mac OS X, or Linux/Unix devices for which host-based firewall software is available, host-based firewall software must be running 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.

Host-Based Firewall Software Guidelines

4. Use of Authentication

Network services and local (console) device access must require authentication by means of passphrases or other secure authentication mechanisms unless the explicit purpose of the service/device is to provide unauthenticated access (for example: public web servers or public kiosks) and it can do so without readily allowing it to be used by attackers.  Notably, the following network services must require authentication: proxy services, email (SMTP) relays, wireless access points, remote desktop, SSH shell access, and printer administrative interfaces.

Simple devices like printers, game consoles, DVR’s, 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 strong encryption to associate (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 campus network. WEP or MAC address restrictions do not meet this requirement.

Use of Authentication Guidelines

5. Passphrase Complexity

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

Passphrases MUST:

  • Contain eight characters or more
  • Contain characters from two of the following three character classes:
    1. Alphabetic (e.g., a-z, A-Z)
    2. Numeric (i.e. 0-9)
    3. Punctuation and other characters (e.g., !@#$%^&*()_+|~-=\`{}[]:";'<>?,./)

Multi-user systems must be configured to enforce these complexity requirements and require that users change any pre-assigned passphrases immediately upon initial access to the account.

All default passphrases for access to network-accessible accounts must be changed at time of network connection.

Passphrase Complexity Guidelines

6. No Unencrypted Authentication

All network-based authentication must be strongly encrypted. In particular, insecure services such as Telnet, FTP, SNMP, POP, and IMAP must be replaced by their encrypted equivalents.

Traffic for one-time password authentication systems (e.g., S/Key, OPIE, SecureID) is exempted from this encryption requirement.

Anonymous FTP servers or other services where authentication credentials are requested but not used are exempt from this requirement.

No Unencrypted Authentication Guidelines

7. No Unattended Console Sessions

Devices must be configured to "lock" or log out and require a user to re-authenticate if left unattended for more than 20 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., appliance stored in a locked office).

Devices which are physically secured

Devices kept in a physically secured space not accessible by unauthorized users are exempt from this standard.

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.

8. No Unnecessary Services

If a network service is not necessary for the intended purpose or operation of the device, that service must not be running.

No Unnecessary Services Guidelines

9. Privileged Accounts

Privileged and super-user accounts (Administrator, root, etc.) must not be used for non-administrator activities.  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. Network services must run under accounts assigned the minimum necessary privileges.

The following case is exempted from this requirement:

Devices that do not support separation of privileges

Devices that do not provide separate facilities for privileged or unprivileged access (e.g., some network appliances and printers with embedded operating systems) are exempt from this requirement.

Privileged Accounts Guidelines