Minimum Security Standards for Electronic Information (MSSEI)

PLEASE NOTE:
This is the previous version of the MSSEI. An updated version was approved by the campus Information Risk Governance Committee on 2/29/2024. 

New Link: MSSEI Home Page

During the implementation period of the updated version, the Standards below are still in effect. 

Version 2.2, Rev 10/11/2019

I.  Introduction

A. Purpose

The Minimum Security Standards for Electronic Information (MSSEI) define baseline data protection profiles for UC Berkeley campus data.  Each baseline data protection profile is a minimum set of security controls required by UC Berkeley. Additional statutes or regulations may apply. Resource Proprietors are responsible for partnering with their Resource Custodians to achieve compliance with MSSEI.

B. Scope

Covered Data

This standard covers Berkeley campus data as defined in the Berkeley Data Classification Standard.  The phrase "covered data" refers to UC Protection Level 2-4 data (UCB PL1-3), except when a control is required, "future" or recommended only for UC Protection Level 4 data (UCB PL2).

Covered Devices

Compliance with baseline data protection profiles is required for all components of information systems used with covered data, regardless of device ownership (e.g., University, 3rd-party vendor, partner institution, individual) or location (e.g., on-site, off-site, cloud).  

The meaning of the phrase "covered device" depends on the specific control in question.  The Device/Use Categories for which a control is required, "future" or recommended are “covered devices.”

C. Exceptions

Resource Proprietors and Custodians who believe their environments require configurations that do not comply with the Minimum Security Standards must obtain an exception for each MSSEI control that is not met. The Information Security Office (ISO) establishes procedures for submission and review of exception requests. Non-compliant systems that do not obtain exception approval may face removal from the campus network and/or other take-down action.

D. Usage

The baseline data protection profile required for a specific information system component is determined by the system's data classification [UC Protection Level 1-4 (UC P1-P4)] and the component's device/use category [Individual, Privileged Access (Privileged) or Institutional]. Protection levels are defined in the Berkeley Data Classification Standard. Device/use categories are defined below. Baseline data protection profiles are currently defined for UC Protection Level 2/3 and UC Protection Level 4 data classifications. 

Each baseline data protection profile references a minimum set of required (mandatory), future (slated to become required in future versions of the standard) and recommended (not mandatory, but encouraged) security controls. Most controls also include supplemental guidance (not mandatory) and links to guidelines that provide more information about the assessment of the control and implementation details.

E. Device/Use Categories

Old UCB Protection Level	New UC Protection Level	Individual Device	Privileged Access Device	Institutional Device
UCB PL0	UC P1	TBD	TBD	TBD
UCB PL1	UC P2/3	Devices processing, storing or transmitting UC protection level 2 or 3 data, provided these devices cannot be classified as either institutional or privileged access. [By default, all employee workstations (including laptops, tablets and smartphones) issued by the University are categorized, at a minimum, as individual UC protection level 2 devices.]	Any device where credentials are used to provide privileged access (superuser, root, administrator, database administrator, and equivalent) to an institutional UC protection level 2 or 3 device (physical, logical and virtual devices included).	Servers (i.e., devices that provide access to data from other devices) that store, process or transmit 1,000 or more records of structured or unstructured* UC protection level 2 or 3 data. This includes database servers, application servers, web front-end servers, back-up and storage systems, and any systems that provide authentication, authorization or configuration management for those systems. OR Systems with stored credentials to access UC protection level 2 or 3 data in any of the above systems.
UCB PL2	UC P4	Devices accessing data in a UC protection level 4 information system or otherwise processing, storing or transmitting UC protection level 4 data, provided the devices cannot be classified as either institutional or privileged access.	Any device where credentials are used to provide privileged access (superuser, root, administrator, database administrator and equivalent) to an institutional UC protection level 4 device (physical, logical and virtual devices included).	Stores of 500 or more records of structured or unstructured* UC protection level 4 data. OR Servers that store, process or transmit UC protection level 4 data. This includes database servers, application servers, web front-end servers, back-up and storage systems and any systems that provide authentication, authorization or configuration management for those systems.
UCB PL3	UC P4	TBD - treated as old UCB PL2, new UC P4	TBD - treated as old UCB PL2, new UC P4	TBD - treated as old UCB PL2, new UC P4

* structured or unstructured data: Structured data has a format where information is organized by data type (e.g., columns and rows in a database, table or spreadsheet), whereas unstructured data has no identifiable organization (e.g., information embedded in an email paragraph).

The following component devices are not covered under this standard:

• Infrastructure service devices (e.g., DNS servers, NTP servers)
• Network infrastructure devices (e.g., switches/routers)

F. Background

The MSSEI is derived from industry-accepted best practices for cyber defense, most heavily from the SANS 20 Critical Security Controls.

---

II.  Baseline Data Protection Profile Summary

Each row in the far left column of the following table lists the title to an MSSEI control (1.1 - 17.1) and links to detailed information about each control's requirements. The far-right column provides links to implementation guidelines for each control. Each of the middle columns represents a baseline data protection profile defined in the header row by its data classification [UC Protection Level 1-4 (UC P1-4)] and device/use category [Individual, Privileged or Institutional]. Each cell in the baseline data protection profile indicates whether that row’s MSSEI control is required (√), a future requirement (+), recommended (o), or not required (empty). Protection profiles for UC P1 are not yet defined, so that column is blank and is not divided into device/use categories.

√   = Required (mandatory)
+   = Future requirement
o   = Recommended (strongly encouraged best practice)
[empty] = Not required

UC P = New UC Data Protection Level
UCB PL = Former Berkeley Data Protection Level

MSSEI Controls	UC P1	UC P2/3	UC P2/3	UC P2/3	UC P4	UC P4	UC P4	Guidelines
	UCB PL0	UCB PL1	UCB PL1	UCB PL1	UCB PL2	UCB PL2	UCB PL2
	(TBD)	Individual	Privileged	Institutional	Individual	Privileged	Institutional
1.1 Removal of non-required covered data		o	√	√	√	√	√	see secure deletion guideline and UCOP disposition schedules database
1.2 Covered system inventory			√	√		√	√	1.2 guideline
1.3 Covered system registration			+	√		√	√	1.3 guideline
1.4 Annual registration renewal			√	√		√	√	1.4 guideline
2.1 Managed software inventory			+	√	o	√	√	2.1 guideline
3.1 Secure configurations		o	+	√	√	√	√	3.1 guideline
4.1 Continuous vulnerability assessment & remediation			+	√		√	√	4.1 guideline
4.2 Authenticated scan						√	√	4.2 guideline
4.3 Intrusion detection			+	+		√	√	4.3 guideline
5.1 Device physical security		o	o	+	o	o	√	5.1 guideline
6.1 Secure coding training		√	√	√	√	√	√	6.1 guideline
6.2 Code review							√	6.2 guideline
6.3 Application security testing							√	6.3 Application Security Testing program
6.4 Commercial software assessment							√	6.4 guideline
7.1 No "institutional" devices on mobile/wireless devices				+			√	7.1 guideline
8.1 Privacy & security training		o	+	+	√	√	√	8.1 guideline
9.1 Unique  passphrases		√	√	√	√	√	√	9.1 guideline
9.2 Separation of accounts		√	√	√	√	√	√	9.2 guideline
9.3 Separation of system resources				√			√	9.3 guideline
10.1 Use of admin accts only on secure devices			+	√		√	√	10.1 guideline
10.2 Admin account security			+	√		√	√	10.2 guideline
11.1 Managed hardware firewall				√			√	11.1 guideline
11.2 Protected subnets				+			√	11.2 guideline
12.1 Security audit logging				√			√	12.1 guideline
12.2 Security audit log analysis				+			√	12.2 guideline
13.1 Controlled access based on need to know		√	√	√	√	√	√	13.1 guideline
14.1 Account monitoring and management				√	√	√	√	14.1 guideline
15.1 Encryption in transit		√	√	√	√	√	√	15.1 guideline
15.2 Encryption on mobile devices and removable storage media		+	+	√	√	√	√	15.2 guideline
15.3 Secure deletion upon decommission		+	√	√	√	√	√	15.3 guideline
15.4 Data access agreements				√			√	15.4 guideline
16.1 Incident response planning				√			√	16.1 guideline
16.2 Incident response plan availability				+			√	16.2 guideline
16.3 Incident reporting training		√	√	√	√	√	√	16.3 guideline
17.1 MSSND Compliance		√	√	√	√	√	√	17.1 guideline

top of page

---

III. MSSEI Control Descriptions

1: Annual Review and Registration

(SANS Critical Control 1: Inventory Of Authorized And Unauthorized Devices)

Threat Scenario

Attackers can discover and compromise covered data on devices not authorized to store, process, or transmit such data.  If data on a device is not correctly registered, it will not receive sufficient security monitoring and appropriate prioritization of response to vulnerabilities and compromises.

Requirements

1.1 Removal of non-required covered data

Resource proprietors must annually review devices and storage media within their jurisdiction to identify and securely remove or destroy covered data that is no longer required for business purposes.

1.1	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)	o	√	√
UC P4 (Formerly UCB PL2)	√	√	√

Secure deletion guidelines
UCOP disposition schedules

1.2 Covered system inventory

Resource Proprietors, in conjunction with Resource Custodians, must inventory all covered data and devices within their domain.

1.2	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)		√	√
UC P4 (Formerly UCB PL2)		√	√

Covered system inventory guidelines

1.3 Covered system registration

Resource Proprietors, in conjunction with Resource Custodians, must register all covered data and devices in the campus data registry system.

1.3	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)		+	√
UC P4 (Formerly UCB PL2)		√	√

Covered system registration guidelines

1.4 Annual inventory and registration renewal

Resource Proprietors and Custodians must review and update these registrations at least annually and at the time of any changes that affect registration information.

1.4	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)		√	√
UC P4 (Formerly UCB PL2)		√	√

Annual inventory and registration Renewal Guideline

top of page

---

2: Managed Software Inventory

(SANS Critical Control 2: Inventory of Authorized and Unauthorized Software)

Threat Scenarios

Attackers use and deploy malicious software to gain unauthorized access to systems and sensitive data.  When software on a device is not required for business purposes, it unnecessarily introduces potential vulnerabilities, thereby increasing the likelihood of compromise.

Requirement

2.1 Managed software inventory

Resource Custodians must manage and regularly review installed software, and install only software packages required for business purposes.

• “Manage” means:
  • Resource Custodians must utilize a process to maintain inventories of installed software packages for all devices. Inventories must include, at a minimum, detailed information about installed software, including the version number and patch level.
  • Resource Custodians must create a list of authorized software for each type of device that includes only software necessary to meet business needs.
  • The inventory process must detect and alert the Resource Custodian about unauthorized software packages discovered on a device.
• “Regularly review installed software” means:
  • A process exists for the Resource Custodian to review the list of installed software packages and reconcile that list against the authorized list of software packages. Any unauthorized software must be removed or authorized.
• “Install only software packages required for business purposes” means:
  • Software must be installed only where necessary for the business purpose or purposes for which the covered data is required.
  • Necessity must be construed narrowly, e.g., software required only for a short-term/one-time solution and not part of the standard maintenance and build of the system (such as remote administration software installed to allow a vendor to troubleshoot a problem) should be installed for that task and then promptly removed.

2.1	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)		+	√
UC P4 (Formerly UCB PL2)	o	√	√

Managed software inventory guideline

Supplemental Guidance

• Whitelisting technology that blocks the execution of unauthorized software on a device or system should be deployed.
• Software inventories should be updated on at least a monthly basis using an automated process.

top of page

---

3: Secure Device Configurations

(SANS Critical Control 3: Secure Configurations for Hardware and Software on Devices)

Threat Scenario

Overly permissive default configuration settings provide an attacker with the ability to access data without authorization.

Requirement

3.1 Secure device configurations

Resource Custodians must utilize well-managed security configurations for hardware, software, and operating systems based on industry standards.

• “Well managed” means:
  • Devices must have secure configurations in place prior to deployment.
  • Any deviations from defined security configurations must be approved through a change management process and documented. A process must exist to annually review deviations from the defined security configurations for continued relevance.
  • A process must exist to regularly check configurations of devices and alert the Resource Custodian of any changes.
• Secure configurations must include blocking autorun on removable and remotely-mounted media.

3.1	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)	o	+	√
UC P4 (Formerly UCB PL2)	√	√	√

Secure configurations guidelines

Supplemental Guidance

• Resource Custodians should use an automated process to regularly check configurations of laptops, workstations, and servers and send alerts based on any changes.
• Resource Custodians should follow Center for Internet Security (CIS) platform-specific system hardening benchmarks, documenting the reasons for any variances. Several GPO templates, based on the CIS benchmarks, have been created and are available for sysadmins.

top of page

---

4: Vulnerability Assessment and Remediation

(SANS Critical Control 4: Continuous Vulnerability Assessment and Remediation)

Threat Scenario

Attackers can discover and compromise covered data on devices that are not secured against vulnerabilities.

Requirements

4.1 Continuous vulnerability assessment & remediation

Resource Custodians must continuously assess and remediate vulnerabilities on all covered devices.

"Continuously assess and remediate vulnerabilities" means:

• Automate daily vulnerability testing.
• Generate alerts and escalate the visibility of critical vulnerabilities within 48 hours.
• Compare prior scans to verify that vulnerabilities are addressed.
• Report on unmitigated vulnerabilities to department and senior management.
• Measure the delay in implementing patches.

Participation in the campus vulnerability scanning program meets these requirements.

• "Participation in the campus vulnerability scanning program" means enabling all relevant firewalls to pass all IP traffic from Information Security Office (ISO) scanners. In the event a system can be disrupted by scanning, scanning exceptions can be made to alleviate the potential problem.
• "Scanning exception" means Resource Custodians block the minimum necessary to avoid the problem, and notify ISO of the block and the reason for the block. The notification is required so participation in the campus program can be adequately assessed.
• "Minimum necessary" means blocking the least amount of traffic possible to avoid the problem. For example, blocking a specific TCP port rather than all TCP traffic, or blocking a specific IP protocol rather than all IP traffic.

4.1	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)		+	√
UC P4 (Formerly UCB PL2)		√	√

Continuous vulnerability assessment & remediation guideline

4.2 Authenticated scan

Resource Custodians must implement authenticated scans for vulnerability assessment of covered devices. Campus-provided scanning resources and campus-licensed software may be implemented to meet this requirement.

4.2	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)
UC P4 (Formerly UCB PL2)		√	√

Authenticated scan guideline

4.3 Intrusion detection

Resource Custodians must continuously monitor for signs of attack and compromise on all covered devices.  

"Continuously monitor for signs of attack and compromise" means:

• Using industry-standard network intrusion detection system (IDS) tools to analyze signatures and network behavior for signs of attack or compromise.
• Capturing at least network connection data of traffic and retain for at least 7 days, to be used as forensic data in case of a possible compromise.

Participation in the campus IDS meets this requirement.

4.3	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)		+	+
UC P4 (Formerly UCB PL2)		√	√

Intrusion detection guideline

Supplemental Guidance

• Track authorized services per device.
• Route IDS data to a Security Information and Event Management system (SIEM) to correlate security events across the environment.
• Apply patches in a development/test environment before patching production systems. If patching results are unacceptable for implementation in the production environment, use other mitigation strategies to compensate for the delay in patching.
• For non-server devices implement automated patching (e.g., TEM, Red Hat Satellite Network, Secunia, etc.)

top of page

---

5: Device Physical Security

Threat Scenario

Attackers with physical access to covered devices can access data without authorization.

Requirement

5.1 Device physical security

Resource Custodians must secure covered devices from unauthorized physical access.

• Access must be restricted to those that need to maintain the covered devices and/or media.
• Restricted areas must be clearly marked for authorized personnel only.
• Restricted areas must be secured by locked doors.
• Access to the restricted areas must produce a physical or electronic audit trail.

5.1	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)	o	o	+
UC P4 (Formerly UCB PL2)	o	o	√

Device physical security guidelines

top of page

---

6: Application Software Security

(SANS Critical Control 6: Application Software Security)

Threat Scenario

Security vulnerabilities in application software allow data theft.

Requirements

6.1 Secure coding training

Resource Proprietors and Resource Custodians must ensure that programming staff who develop applications involving covered data complete secure development training.

6.1	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)	√	√	√
UC P4 (Formerly UCB PL2)	√	√	√

Control 6.1 is not device specific

Secure coding practice guidelines

6.2 Code review

Resource Proprietors and Resource Custodians must ensure that code review is incorporated into each phase of the software development life cycle.

6.2	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)
UC P4 (Formerly UCB PL2)			√

Secure coding practice guidelines

6.3 Application security testing

Resource Proprietors must ensure that web-based and other application software handling covered data passes a security assessment prior to release to production and every two years thereafter.

Application security assessments must include:

• Testing methodology and risk assessment criteria equivalent to the criteria used by the Campus Application Security Testing Program.
• Review of documented requirements and use cases.
• Credentialed and non-credentialed vulnerability scans conducted on a testing environment that includes web, application and database servers.

Participation in the Campus Application Security Testing Program meets this requirement. Resource Proprietors must obtain exception approval to substitute an alternate assessment program, and the results and the results of any alternative assessments must be submitted to the Campus Application Security Testing Program for a final pass or fail determination.

6.3	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)
UC P4 (Formerly UCB PL2)			√

Application Security Testing Program

6.4 Commercial software assessment

Resource Proprietors and Resource Custodians must validate that commercial software meets security criteria used by the Campus Application Security Testing Program prior to purchase.

6.4	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)
UC P4 (Formerly UCB PL2)			√

Commercial software assessment guideline

top of page

---

7: Mobile and Wireless Device Control

(SANS Critical Control 7: Wireless Device Control)

Threat Scenario

Devices on insecure networks are open to multiple attack vectors. Mobile devices and removable media can be stolen or lost. Attackers can gain access to covered systems through wireless devices connected to the network.

Requirement

7.1 No "institutional" devices on mobile/wireless devices

Resource Custodian must not implement institutional devices (as defined in the Device/Use Categories of this standard) on mobile or wireless devices.

7.1	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)			+
UC P4 (Formerly UCB PL2)			√

Mobile and wireless device guideline

Supplemental Guidance

• Covered data should not be stored on mobile or wireless devices.
• Review controls 15.1 and 15.2 regarding encryption requirements applicable to mobile and wireless devices. 

top of page

---

8: Privacy and Security Training

(SANS Critical Control 9: Security Skills Assessment and Appropriate Training to Fill Gaps)

Threat Scenario

Regardless of implemented controls, the actions of individuals can result in the compromise of covered data.

Requirement

8.1 Privacy and security training

At least every two years, Resource Custodians, Resource Proprietors, Security Contacts, and End Users of covered data must complete privacy and security training appropriate for their role.

8.1	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)	o	+	+
UC P4 (Formerly UCB PL2)	√	√	√

Privacy and security training guideline

Supplemental Guidance

System Administrators, DBA's, programmers, etc. should complete role-specific advanced training on secure practices.

top of page

---

9: Separating Resources and Limiting Reuse

(SANS Critical Control 11: Limitation and Control of Network Ports, Protocols, and Services)

Threat Scenario

Sharing between systems or services increases security risk.  A compromise of one system can lead to a compromise of all of systems sharing the same database or credentials.  

Requirements

9.1 Unique passphrases

Resource Proprietors, Resource Custodians and Users of covered devices must meet the following password uniqueness requirements:

• Individuals in possession of credentials for UC  P4 devices must use passphrases that are significantly different for each separate account under their control.
• Individuals in possession of credentials for UC P2/3 devices must not reuse those passwords for consumer accounts or UC P1 devices.

9.1	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)	√	√	√
UC P4 (Formerly UCB PL2)	√	√	√

Separation of system resources guideline

9.2 Separation of accounts

Resource Proprietors and Resource Custodians must create one application account per individual so that there is no sharing of an individual account between multiple people. 

9.2	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)	√	√	√
UC P4 (Formerly UCB PL2)	√	√	√

Separation of system resources guideline

9.3 Separation of system resources

Resource Proprietors and Resource Custodians must appropriately limit the sharing and re-use of databases and system hardware across unique systems or environments.

9.3	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)			√
UC P4 (Formerly UCB PL2)			√

Separation of system resources guideline

Supplemental Guidance

Resource Proprietors and Resource Custodians should evaluate and implement the following controls where possible:

• Track a list of authorized services per device. 
• Maintain and monitor a list of authorized devices.
• Segment subnets.
• Separate critical services on unique systems.

top of page

---

10: Controlled Use of Administrative Privileges

(SANS Critical Control 12: Controlled Use of Administrative Privileges)

Threat Scenario

Attackers make unauthorized use of administrative privileges to discover and compromise covered data. High-risk activities increase the likelihood of introducing malicious code that takes advantage of unpatched vulnerabilities.

Requirements

10.1 Use of admin accounts only on secure devices

Administrative credentials must be used only on devices that have been configured according to the Secure device configurations control.

10.1	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)		+	√
UC P4 (Formerly UCB PL2)		√	√

Use of admin accounts only on secure devices guideline

10.2 Admin account security

Administrative accounts and credentials must use strong authentication, be separated from high-risk activities, and meet all requirements from the Account Monitoring and Management control.

• "Use strong authentication" means using passwords or passphrases that are highly resistant to persistent brute force attacks.
• "Be separated from high-risk activities" means that activities at high risk of introducing malware (e.g. reading email, using a web browser, reading or editing general documents) must be separated from administrative accounts such that malware introduced through the high-risk activities is not able to capture administrative passwords or read files containing private keys or other administrative credentials.

10.2	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)		+	√
UC P4 (Formerly UCB PL2)		√	√

Admin account security guideline

Supplemental Guidance

Public/private key authentication or true two-factor authentication is strongly encouraged and is likely to be required in the future. True two-factor authentication is distinguished from other forms of strong authentication in that it requires presentation of two different categories of authentication factors (something the user knows, something the user has, and something the user is).  Requiring presentation of multiple factors from the same category does not constitute multi-factor authentication.

top of page

---

11: Boundary Defense

(SANS Critical Control 13: Boundary Defense)

Threat Scenario

Attackers can more readily discover and exploit vulnerabilities in services and applications when those systems are unnecessarily open to untrusted networks. A compromised system may be able to send confidential data to unauthorized systems.

Requirements

11.1 Managed hardware firewall

Resource Custodians must protect all institutional devices with a well-managed hardware firewall configured according to the principle of least privileges. These firewall rules must be reviewed annually and updated as necessary.

• “Well-managed” means:
  • All acceptable inbound and outbound traffic flows are cataloged and maintained.
  • Changes to the firewall rules go through an established approval process based on clear criteria.
  • Changes are logged and can be traced back to the request (via a ticketing system, for example).
• "Hardware firewall” means:
  • A physical network device designed to act as a stateful packet-inspecting device (i.e., it monitors the state of network connections and rejects packets not matching a known active connection). This includes network-based firewalls. If a network segment cannot support a hardware firewall or a network-based firewall is not available, a router/switch with an Access Control List may be substituted.
• “The Principle of Least Privileges” means:
  • Only traffic that is necessary is allowed through the firewall.
  • A default deny rule is set for inbound traffic with explicit allow rules for valid traffic.
  • Rules are as granular as possible, i.e., the entire campus network must not be allowed to connect to a device if only a small number of systems actually need to connect.

11.1	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)			√
UC P4 (Formerly UCB PL2)			√

Managed hardware firewall guidelines

11.2 Protected subnets

Resource Proprietors and Resource Custodians must implement institutional devices on protected subnets.

• “Protected subnets” mean, at a minimum:
  • The subnet must not contain systems and applications that grant access solely based on an implicit trust (e.g., allowing shell access based solely on IP address, or database access based solely on a specific user ID).
  • Physical protection from public access.
  • No wireless access points.

11.2	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)			+
UC P4 (Formerly UCB PL2)			√

Protected subnets guidelines

Supplemental Guidance

• Limit allowed outbound traffic based on business requirements and implement a default deny rule for all other outbound traffic.
• Restrict outbound flows to other devices.

top of page

---

12: Security Audit Logging

(SANS Critical Control 14: Maintenance, Monitoring, and Analysis of Security Audit Logs)

Threat Scenario

Without appropriate audit logging, an attacker's activities can go unnoticed, and evidence of whether or not the attack led to a breach can be inconclusive. 

Requirements

12.1 Security audit logging

Resource Custodians must collect and store security audit logs for covered devices.

• "Collect and store security audit logs" means:
  • Relevant activity on institutional devices (as defined by the campus Security Event Audit Logging Program) must be logged immediately.
  • Audit data must contain date, timestamp, source address, destination address, and other details about the packet.
  • Audit data must be stored on write-only devices or sent to dedicated logging servers running on separate machines from the hosts generating the logs.
  • All devices must use automatic time synchronization to ensure accurate time stamps for audit logs.

This requirement can be satisfied by participation in the campus Security Event Audit Logging Program.

12.1	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)			√
UC P4 (Formerly UCB PL2)			√

Audit logging guideline

12.2 Security audit log analysis

Resource Custodians must analyze security audit logs for covered devices.

• "Analyze security audit logs" means:
  • Industry-standard Security Information and Event Management (SIEM) and log correlation tools are used to analyze audit logs on all institutional devices.
  • At least one full-time staff with explicit security analyst duties is responsible for daily log evaluation.
  • Device detection identifies non-responsive devices within 24 hours.

This requirement can be satisfied by participation in the campus Security Event Audit Logging Program.

12.2	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)			+
UC P4 (Formerly UCB PL2)			√

Audit log analysis guideline

Supplemental Guidance

• Administrative actions on institutional devices should be logged. Administrative actions typically require elevated privileges such as those gained from sudo in Unix or "Run as Administrator" in Windows systems.
• Audit log information should be protected against tampering and unauthorized access.

top of page

---

13: Controlled Access Based on the Need to Know

(SANS Critical Control 15: Controlled Access Based on the Need to Know)

Threat Scenario

When access to covered data is broader than what is required for legitimate purposes, there is an unnecessary risk of an attacker gaining access to the data.

Requirement

13.1 Controlled access based on need-to-know

Resource Proprietors must control access to covered data and regularly review access permissions to allow the use of and access to covered data only where strictly necessary for legitimate business processes.

• “Control access” means maintaining an inventory of who has access to the data and managing those accounts according to the Account Monitoring and Management control.
• "Regularly review access permissions" means a process exists to review individual access to covered data and to remove or modify access when there is a change in responsibilities. A review must be conducted at least annually and at defined trigger points, such as job code changes and employment terminations.

13.1	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)	√	√	√
UC P4 (Formerly UCB PL2)	√	√	√

Controlled access based on need-to-know guideline

top of page

---

14: Account Monitoring and Management

(SANS Critical Control 16: Account Monitoring and Management)

Threat Scenario

Attackers can discover and exploit user accounts still valid in the system but no longer needed for business purposes.

Requirement

14.1 Account monitoring and management

Resource Proprietors and Resource Custodians must manage, protect from attack, and regularly review accounts.

• “Manage” means:
  • Employ a process to grant and revoke access to accounts based on legitimate business needs.
  • Access is not granted outside that process.
• “Protect from attack” means:
  • Make it difficult for non-authorized persons to access the account.
• “Regularly review” means:
  • A process exists to review accounts assigned to both users and applications/services on a quarterly basis. That process validates the continued business need for each active account with the Resource Proprietor and ensures that application/service account credentials will be disabled when no longer needed.

14.1	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)			√
UC P4 (Formerly UCB PL2)	√	√	√

Account monitoring and management guideline

Supplemental Guidance

• Use intrusion prevention mechanisms to prevent brute force password attacks; for example, automatically block IP addresses and lock accounts upon multiple failed logins.
• Deploy two-factor authentication or CalNetKeys.

top of page

---

15: Data Loss Prevention

(SANS Critical Control 17: Data Loss Prevention)

Threat Scenario

Portable media are prone to physical theft and loss. Unauthorized parties can acquire unencrypted data stored on a device or transmitted on a network.

Requirements

15.1 Encryption in transit

Resource Custodians and anyone moving covered data through a network must use secure, authenticated, and industry-accepted encryption mechanisms. (See the Encryption in transit guidelines for important considerations and exceptions regarding this control.)

15.1	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)	√	√	√
UC P4 (Formerly UCB PL2)	√	√	√

Encryption in transit guidelines

15.2 Encryption on mobile devices and removable storage media

Anyone storing covered data on portable devices (such as laptops and smartphones) or removable and easily transported storage media (such as USB drives or CDs/DVDs) must use industry-accepted encryption technologies.

• “Industry-accepted” means accepted by the cryptographic community.

15.2	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)	+	+	√
UC P4 (Formerly UCB PL2)	√	√	√

Encryption on mobile devices and removable storage media guidelines

15.3 Secure deletion upon decommission

Resource Custodians must ensure that any systems (laptops, workstations, and servers) and devices (smartphones, USB drives) storing covered data must be securely overwritten or wiped using an approved secure file deletion utility upon decommissioning of the device to ensure that the information cannot be recovered. For those devices that cannot be overwritten (defective hard drives, CDs/DVDs), Resource Custodians must ensure the device is destroyed prior to disposal.

15.3	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)	+	√	√
UC P4 (Formerly UCB PL2)	√	√	√

Secure deletion upon decommission guidelines

15.4 Data access agreements

Resource Proprietors must establish Data Access Agreements that define appropriate use and access to covered data, as well as procedures for obtaining approval for deviance from restrictions.

15.4	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)			√
UC P4 (Formerly UCB PL2)			√

Data access agreement guidelines

Supplemental Guidance

Data Access Agreements should define restrictions on access or transfer of data:

• To other persons, applications, or systems that have not independently completed an agreement for access.
• Outside the campus network, including off-site hosting, third-party vendors, and non-University email systems.
• Using removable media and unauthorized devices, including personal devices.
• Via mobile and wireless devices, and devices on networks with wireless access points.

Covered data should not be stored on any portable device (laptop, smartphone, etc.) unless absolutely necessary and if so must always be strongly encrypted.

Systems should be configured so all data written to removable storage media are automatically encrypted without user intervention. 

top of page

---

16: Incident Response Capability

(SANS Critical Control 18: Incident Response Capability)

Threat Scenario

If users and system administrators are not aware of incident response procedures, the response will be delayed and evidence can be corrupted or lost, greatly increasing the potential impact of an incident.

Requirements

16.1 Incident response planning

Each system custodian must develop and review at least annually a system-level incident response plan that contains:

• Names and contact information for the local incident response team, including:
  • Security Contact and alternate contact(s) who have system admin credentials, technical knowledge of the system, and knowledge of the location of the incident response plan.
  • A local authority/decision maker for the system who understands the business impact of the system and its unavailability.
• System details, or reference to the location of such information, including:
  • Data Flow Diagrams
  • Network Diagrams
  • System hardware inventory (as required by the Annual Registration control)
  • Logging information (as required by the Audit Logging control)
• Procedures for reporting and handling a suspected incident, defined per role: e.g., Resource Custodians, End Users
  • Who to contact
  • How NOT to tamper with potential evidence (i.e., not to attempt forensics when not authorized).

16.1	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)			√
UC P4 (Formerly UCB PL2)			√

Incident response planning guidelines

16.2 Incident response plan availability

Printed copies and/or electronic copies of the incident response plan must be accessible to all members of the local incident response team.

16.2	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)			+
UC P4 (Formerly UCB PL2)			√

Incident response plan availability guidelines

16.3 Incident reporting training

Resource Proprietors are responsible for training all End Users on incident reporting procedures.

16.3	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)	√	√	√
UC P4 (Formerly UCB PL2)	√	√	√

16.3 is a system-based rather than device-specific control.

Incident reporting training guidelines

Supplemental Guidance

Train System Administrators and Resource Custodians on how to identify potential incidents.

top of page

---

17: MSSND Compliance

Threat Scenario

Devices accessing data both from on-campus and off-campus are subject to attack.

Requirement

17.1 MSSND Compliance

Users, Resource Proprietors, and Resource Custodians must ensure that all devices accessing covered data, regardless of their location, comply with the requirements defined in the UC Berkeley Minimum Security Standard for Networked Devices as if they were on the campus network.

17.1	Individual Device	Privileged Access Device	Institutional Device
UC P2/3 (Formerly UCB PL1)	√	√	√
UC P4 (Formerly UCB PL2)	√	√	√

top of page

---

Issue Date: November 1, 2009 - version 1.0
Effective Date: January 1, 2010

Revised Issue Date:   July 16, 2012 - version 2.0
Effective Date:  July 16, 2013       

Revised Issue Date: April 23, 2013 - version 2.1
Effective Date:  July 1, 2014  

Revised Issue Date: October 11, 2019 - version 2.2
Effective Date: October 11, 2019

Replaced by version 3.0
Effective Date: April 1, 2024
Version 2.2 is still in effect during the implementation period for version 3.0             

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

Contact:    IT Policy Manager, security-policy@berkeley.edu.

[Protection Profile Matrix by role pdf diagram - prints on legal-sized paper]

---

Change log:

• May 1, 2013:  Per information Security Office (ISO) request and approval by Andy Goldblatt as an administrative revision: 6.3: changed "annually" to "every two years"
• May 6, 2014: Administrative update approved by CISPC and Andy Goldblatt.  See CISPC agenda item 3 for discussion of changes.
• Oct. 11, 2019: Administrative update per UC BFB IS-3. UC Protection Levels added; no effective change in requirement.
• Feb. 29, 2024: New version approved by IRGC: MSSEI - Published Version
• May 30, 2024: Updated link to the policy exception process. Updated version log.