Applications and systems that handle protected data are required to meet the campus Minimum Security Standard for Electronic Information policy (MSSEI). The UC Berkeley System Security Plan (SSP) is a tool for describing the controls in place to meet those requirements. A completed UC Berkeley SSP for UC P4 classified systems is required before the Information Security Office (ISO) can assess compliance with campus security policies.
The following is a step-by-step guide for completing the UC Berkeley SSP, with instructions for what information needs to be provided in each section. The system security plan is meant to be a snapshot in time of implemented security controls, and should be updated after any significant changes are made, and at least annually.
The system security plan must NOT include information that can directly lead to the compromise of protected data, such as account credentials. A completed SSP should be considered classified as UC P3 data and shared with collaborators on a need-to-know basis.
Google document templates are available to help with the documentation effort for both UC P4 and UC P2/P3 applications. Copy the template to a shared departmental drive, with appropriate account access permissions.
* Note that system security plans for UC P2/P3 systems are strongly recommended, although they are not required to be submitted to ISO.
Other Compliance Responsibilities:
Please be aware that this assessment only addresses information security requirements and risks. A Privacy or Accessibility consultation may also be needed if your use case has privacy or accessibility implications. Some examples include:
- Information about European or Chinese residents is involved;
- If there are questions about the applicability of privacy-related laws or regulations, including data de-identification, data breach notification laws, HIPAA, FERPA, GDPR, and the California Consumer Privacy Act (CCPA);
- A Supplier is passing information classified at Protection Level P3 or higher to other third parties.
- Please contact firstname.lastname@example.org
- Applications, tools, or products intended for student, departmental, or campuswide use
- Please contact email@example.com if you have questions about the accessibility of your product.
In the title section of the UC Berkeley SSP template is a table for entering basic information, such as the Application or System Name, Protection Level, Availability Level, Key Data Elements, Proprietor, Point of Contact, and Department or Unit Name.
Refer to the campus Data Classification Standard and guideline for details about how to classify campus data, including examples for each data class. If unsure about the correct classification, contact ISO at firstname.lastname@example.org for additional guidance.
The Revision History section is provided for tracking major changes and annual reviews of the system security plan.
1. Application / System Overview
|Describe the purpose of the application/system and how it is being used.||“This is a web-based application used for HR on-boarding purposes.”|
|Include a list of the types of protected data involved.||Social Security numbers, human-subject research data, etc.|
|Note any 3rd-party applications/system or service providers.||Oracle PeopleSoft platform; the application is a hosted SaaS service or uses AWS infrastructure|
|Note any laws or regulations that apply to the application data, or any governing research data use agreements.||HIPAA, GDPR, FERPA, etc.|
2. Target Audience
|Include a description of the application/system users.||“Accounts Payable staff in the Finance office who will be administering vendor payments.”|
|Also include a description of the people who may be affected by the application/system.||“The application contains approximately 7000 student financial aid records.”|
3. Architecture Model
Especially important to the description of the application/system are Section 3 - Architecture Model and Section 4 - Data Flow Description
For the Architecture Model, the diagram should depict:
All components of the system (e.g. web/app servers, databases, storage, etc)
Network protocols for transferring data and communicating between all components (e.g. HTTPS, SFTP, SSH, RDP, IPSec, etc.)
Whether the system is accessible from the internet, remotely, or internally only.
All connectivity with external systems and services
How admins access the system (e.g. admin devices)
How users access the system
Where the system is located (e.g. campus data center, in the department, vendor location, etc.)
4. Data Flow Description
The Data Flow Description should depict data flow into and out of the and how the connection is secured and where the data is stored, for example:
Who is the external entity
How authentications is addressed (e.g. CalNet SSO and Duo MFA)
How encryption is addressed (e.g. HTTPS, SSH, etc.)
Data flow direction (incoming, outgoing, both)
Key data elements being transmitted
Where key data is stored
Whether or no data is protected at rest
In Section 5, Support & Development Staff:
List any people who have elevated privileges* in the application or its underlying devices. This includes third parties.
Include a description of their responsibilities and email contact information
* Elevated privileges may mean administrator permissions to make changes to the application configuration, or bulk access to protected data, etc.
Section 6, Resources, is intended for referencing system security documentation.* The campus security policies are listed, but this section can also reference other documents or resources that impact or describe security controls, such as departmental policies.
* These references should not include any technical documentation that could be exploited by an attacker.
Before attempting to complete this section, read the policy and guidelines for each requirement first.* The guidelines provide detailed recommendations about how to meet control requirements, including resources for campus services to help support MSSEI compliance efforts.
Instructions are provided for each MSSEI requirement. Include as much detail as seems relevant, so that others reading the SSP will readily understand.
* There is a link to the guidelines for each MSSEI requirement in Section 7.
The MSSEI policy defines three Device/Use Categories that are covered by the requirements:
Each covered device has its own subset of MSSEI requirements based upon the protection level classification of the application or system. To see which requirements apply for each device category, refer to the MSSEI Baseline Data Protection Profile Summary table.
As applicable for each of the requirements in Section 7, space is provided to enter a description of the controls that apply for covered Institutional and Privileged Access Devices.
* While MSSEI also applies to Individual Devices, documentation of compliance for these devices is not required for the MSSEI SSP. MSSEI requirement 15.4 Data access agreements specifies that an agreement is established with end users of the application to inform them of MSSEI Individual Device requirements. The data access agreement should make clear that by agreeing to use the application or system, end users are also agreeing to meet MSSEI Individual Device requirements.
Tracking UC Berkeley SSP Progress
For each requirement in Section 7, the "Progress" field in the right-hand column is intended for tracking the implementation status of the security controls. For each MSSEI requirement, select the implementation state of each control using the Status dropdown menu for Institutional Devices and Privileged Access Devices
Implementation of the control has not started. Also use this status if you have planned to meet a control, but have not taken any action to begin implementation.
Implementation of the control has started, but is not complete.
|Fully Implemented||Implementation of the control is complete and operational.|
|Alternative Implementation||A compensating security control that provides equivalent protections is implemented (e.g. technical or operational constraints).|
|Not Applicable||The control is not applicable to the system.|
* Requirements that are in the "Partially Implemented" stage should include a timeline to complete the implementation of all control specifications.
UC Berkeley SSP Inventory Appendices
The UC Berkeley SSP hardware and software inventory appendices (A & B) are provided for tracking the key application/system devices and installed software (per MSSEI requirements 1.2 Covered system inventory & 2.1 Managed software inventory). Only Institutional and Privileged Access devices are required to be listed in the inventory appendices (Individual Devices are optional).
Alternatively, these inventories can be maintained in separate files and referenced in the UC Berkeley SSP.
Once the system security plan is completed, it can be submitted to ISO via the UC Berkeley SSP submission form (form requires CalNet login). The submission will be tracked via the ISO ticketing system, where a Security Analyst will be assigned to the assessment.
Before completing the submission form, the UC Berkeley SSP Google Doc must be shared with the members of ISO staff for collaboration purposes.
Share the completed plan with the email@example.com CalGroup
Assign “Edit” permissions to allow ISO Security Analysts to provide comments and suggested edits to the document
To get an overview of the MSSEI assessment process, refer to the Details of the MSSEI Assessment Service page. If you have any questions about MSSEI assessments, you may create a ServiceNow ticket by emailing firstname.lastname@example.org.