UC Berkeley System Security Plan Step-by-Step Guide

Introduction

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.

UC Berkeley SSP Templates

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.

                              

           UC P4 SSP Template                 UC P2/P3 SSP Template*

* Note that system security plans for UC P2/P3 systems are strongly recommended, although they are not required to be submitted to ISO.

Who Should Complete the UC Berkeley SSP?

It is the responsibility of the system Resource Proprietor to implement the necessary security controls to meet MSSEI requirements and for ensuring that the system security plan is completed, implemented, and submitted to ISO for review when required.
The Resource Proprietor may choose to delegate the responsibility to fill out the details of the plan to a Point of Contact, a person who is knowledgeable about all of the essential parts of the system.  The Point of Contact will be the main person to interact with ISO during the UC Berkeley SSP assessment process.  
While the Point of Contact may not be the expert on all technical topics, they should be able to identify the experts that can be called upon to describe the technical aspects of the system and relevant security controls.  

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:

  • Privacy:
    • 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 privacyoffice@berkeley.edu
  • Accessibility:
    • Applications, tools, or products intended for student, departmental, or campuswide use
    • Please contact digital-accessibility@berkeley.edu if you have questions about the accessibility of your product.

Step 1: Provide a Detailed Description of the Application or System

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 security-policy@berkeley.edu for additional guidance.


The Revision History section is provided for tracking major changes and annual reviews of the system security plan.
Sections 1 - 6 are provided for documenting the purpose of the application or system, the intended audience and users, the types of protected data involved, and a description of how all the different system components interact with each other.

1. Application / System Overview

For the Overview section:
Examples:
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

For the Target Audience section:
Examples:
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. 

  • Firewalls

  • 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

  • Port number

  • Where key data is stored

  • Whether or no data is protected at rest

5. Support & Development Staff

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.

6. Resources

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.

Step 2. Describe How MSSEI Requirements Are Being Met

Section 7, Meeting MSSEI Requirements, lists each requirement with space to describe how compliance is being met for each type of covered device.

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.

Covered Devices

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

Not Started

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.

Partially Implemented

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.

Step 3. Submit the UC Berkeley SSP to ISO - only required for P4 SSPs

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 ciso-mssei-ssp@calgroups.berkeley.edu 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 security-assessments@berkeley.edu.