Minimum Security Standards for Networked Devices - Draft

DRAFT:
This is a working draft of a proposed update to UC Berkeley’s Minimum Security Standards for Networked Devices (MSSND). This update incorporates elements from UC’s systemwide Information Security Policy, IS-3, and brings the Standards into alignment with current industry best practices. This draft is currently undergoing campus review. The old MSSND is still in effect while this update is under review. 

2020 Review Timeline and Audience: 

  • March to Mid-May: 
    • IT leadership and governance 
  • Late-May to mid-June
    • Broad IT review 
  • Est. July through fall
    • Broad campus review

--------------------

The UC Berkeley Minimum Security Standards for Networked Devices (MSSND) are issued under the authority vested in the UC Berkeley Chief Information Officer by the UC Business and Finance Bulletin IS-3 Electronic Information Security (UC BFB IS-3).

Responsible Executive: Associate Vice Chancellor for Information Technology and Chief Information Officer

Responsible Office: Information Security Office

Contact: Information Security Policy Manager, itpolicy@berkeley.edu

I. Introduction

A. Summary

Compliance with the UC Berkeley Minimum Security Standards for Networked Devices (MSSND) helps protect not only the individual device but also other devices connected through the UC Berkeley network and Cloud Services. The standard is intended to prevent exploitation of Campus resources by unauthorized individuals, including the use of Campus resources to attack other systems on the UC Berkeley network, IT Resources, or the Internet. 

All UC Berkeley IT Resources and all devices, independent of their location or ownership, connected to the UC Berkeley network, or that store, process, or access Institutional Information hosted at any location, must comply with the MSSND requirements below. These standards are set by the Campus Information Risk Governance Committee (IRGC). Devices that do not meet these standards may be disconnected from the UC Berkeley network and/or hosted services. Implementing guidelines that provide more information about complying with the minimum security standards are linked to the individual requirements.

Non-networked devices should meet the MSSND requirements as applicable, e.g. device lockout, passphrase requirements, use of authentication, etc.

Devices that handle Protected Data or require a high level of Availability as defined in the Campus Information Security Policy Glossary are required to conform to more rigorous security standards. (See the Minimum Security Standards for Electronic Information.)

B. 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 SuppliersNon-networked devices should meet the MSSND requirements as applicable.

C. Exceptions

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

Non-compliant systems that do not obtain exception approval may face removal from the UC Berkeley network and/or other take-down action. Departments, Units, or individuals with devices that cannot meet the requirements of the MSSND may request an exception to this Standard. Approval is based on whether the risks associated with non-compliance have been adequately mitigated. All exceptions are temporary and must be replaced with compliant solutions.

Use the Request for Exception to the Campus Minimum Security Standards website to submit requests. Questions about the Minimum Security Standards or the exception process may be addressed to: security@berkeley.edu.

D. Key Definitions

Definitions of Key Terms used in this standard are included in UC Berkeley’s Information Security Policy Glossary

II. Updated MSSND Requirements

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.  

Patching and Updates Guidelines

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.

Anti-malware Software Guidelines

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.

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 (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 

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.

Passphrases should meet the MSSND requirements, at minimum.

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

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.

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

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

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 

Change Log

  • Oct. 11, 2019: Draft posted on Information Security Office website.
  • Oct. 17, 2019: Expanded requirement #3 to include access control lists (ACLs) and re-worked the language to further clarify the intent of this requirement. 
  • Nov. 1, 2019: Added requirement #8 "Privileged Accounts" (requirement #8). This requirement was not included in the initial version of this draft.
  • Nov. 26, 2019: Added links to Guidelines for each section
  • Dec. 2, 2019: Removed reference to patterns in #5 Passphrase Requirements; Added exemption for certain devices that do not support separation of privileges to #8 Privileged Accounts.
  • Mar. 4, 2020: 
    • Clarified that non-networked devices should meet the MSSND requirements as applicable.
    • Added network storage appliances to requirement #2, Anti-Malware Software.
    • Clarified exemption to requirement #4, Use of Authentication, for services and devices that explicitly provide unauthenticated access.
    • Clarified that the encryption requirement for credentials in requirement #4, Use of Authentication, applies to SSH and TLS private keys, and API keys, and that credential stores on servers must be appropriately salted and hashed.
  • Mar. 13, 2020: Added new requirement: "Remote Access Services" (requirement #8). Clarified requirement about network proxy and gateway services, and moved it from #7 to the new #8.
  • Mar. 26, 2020: Clarification about the scope of devices that are covered under the MSSND, specifically relating to Cloud Services and Institutional Information that is stored/hosted remotely (Sec. I.A and I.B)
  • Apr. 15, 2020: Added clarification to requirement #8, Remote Access Services, that remote access services and network gateways must not be deployed to circumvent UC Berkeley network and security policies.
  • May 21, 2020: 
    • Separated requirements for storage of authentication credentials and transmission of authentication credentials; moved storage of credentials from Requirement #4 to Requirement #5.
    • Clarified that unencrypted services must be replaced by their encrypted equivalents if authentication or confidentiality are required (requirement #4).
    • Revised March 4th clarification about encryption for stored credentials (requirement #5).
  • Jun. 10, 2020: Additional clarification around requirements for stored authentication credentials and authentication secrets (requirement #5)
  • Sept. 23, 2020: Added integrity requirements to the list of reasons that unencrypted services must be replaced by their encrypted equivalents (Requirement #4).