MSSEI Self Assessment 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 MSSEI Self Assessment Plan (SAP) is a tool for describing the controls in place to meet those requirements.  A completed MSSEI SAP for UC P4 classified systems (formerly UCB PL2 & PL3) 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 MSSEI SAP, with instructions for what information needs to be provided in each section.  The self assessment plan is meant to be a snapshot in time of implemented security controls, and should be updated after any significant changes are made.

The self assessment plan is NOT meant to include information that can directly lead to the compromise of protected data, such as account credentials.  A completed SAP should be considered classified as UC P3 data and shared with collaborators on a need-to-know basis.

MSSEI SAP 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 SAP Template                 UC P2/P3 SAP Template*

* Note that self-assessment plans for UC P2/P3 (formerly UCB PL1) systems are strongly recommended, although they are not required to be submitted to ISO.

Who Should Complete the MSSEI SAP?

It is the responsibility of the system Resource Proprietor to implement the necessary security controls to meet MSSEI requirements and for ensuring that the self assessment plan is completed, implemented, and submitted to ISO for review.
 
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 MSSEI SAP 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 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 webaccess@berkeley.edu. If you need a web accessibility review of a website or web-based product, please also fill out a “Request a Clinic” form

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

In the title section of the MSSEI SAP template is a table for entering basic information, such as the Application or System Name, Data Classification, Resource Proprietor, Point of Contact, and Department or Unit Name.

Title Table

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


The Revision History section is provided for tracking major changes and annual reviews of the self assessment plan.
 
Revision History
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 one and other.

1. Application / System Overview

For the Overview section:
Examples:
Describe the purpose of the application 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 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 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 system. “The application contains approximately 7000 student financial aid records.”

3. Architecture Model

Especially important to the description of the system are Section 3 - Architecture Model and Section 4 - Data Flow Description.

For the Architecture Model:
Examples:
Include a detailed diagram* that demonstrates how various parts of the system interact with one and other. Web/app servers, database systems, storage devices, backup systems, admin devices, end-user workstations, etc.
The diagram should include a high-level illustration of the networks involved. Public vs. private
Note on the diagram any devices or systems where the protected data is stored or processed. Databases, storage devices, etc.
Label the data-flow lines with the network protocols for transferring data and communicating between the devices. HTTPS, SFTP, SSH, RDP, IPSec, etc.
* Using a CAD diagramming tool, such as Visio, to create the diagram is encouraged, but a photo of a carefully drawn diagram on a whiteboard, or using pen and paper, is equally acceptable.

4. Data Flow Description

For the Data Flow Description:
Examples:
Describe the inter-connectivity between various devices illustrated in the Architecture Model, including details about how protected data is being stored or processed. “User end-points connect via HTTPS to the application server, which communicates with a backend database system where data is stored and processed.”
Include a brief description of how each of the components of the architecture are being secured. “The database server is hosted on a private subnet with firewall permissions to only allow access from the application server on a separate DMZ subnet.”

5. Support & Development Staff

In Section 5, Support & Development Staff:

  • List any staff members who have elevated privileges* in the application or its underlying devices

  • 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 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.
Section 7

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

Where 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 SAP.  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 MSSEI SAP 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 (e.g., "Not started", "In Progress", or "Fully Implemented").

Not Started Security controls are currently in the planning phase, none of the security control specifications have been put into place to meet the MSSEI requirement.
In Progress* Planning is completed and some controls have been put into place, but not fully completed.
Fully Implemented All of the specifications for the security controls have been completed.
* Requirements that are in the "In Progress" stage should include a timeline to complete the implementation of all control specifications.

MSSEI SAP Inventory Appendices

The MSSEI SAP 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 MSSEI SAP.

Step 3. Submit the MSSEI SAP to ISO

Once the self assessment is completed, it can be submitted to ISO via the MSSEI SAP 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 MSSEI SAP Google Doc must be shared with the members of ISO staff for collaboration purposes.  

  • Share the completed plan with the “mssei-sap@lists.berkeley.edu” Google Group

  • 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 or concerns, contact ISO at security@berkeley.edu.