Introduction
The purpose of the Self Assessment Plan (SAP) is to develop an information repository to document the key pieces of information about your
application and to describe the security controls in place for meeting
MSSEI (Minimum Security Standard for Electronic Information) requirements. A completed SAP for PL2 application is required before ISP team can assess the application.
While the SAP is meant to be a snapshot in time of implemented security controls, the Resource Proprietor, along with the Application Coordinator, is also responsible for updating the SAP after any significant changes are made to the application, including any of its privileged access and institutional devices (e.g. servers are added/removed, new privileged access devices are added/removed, etc).
The SAP is NOT meant to be the repository of information that can directly lead to compromise of covered data, such as vulernability details, account credentials, or actual PL1/PL2 data elements. A completed SAP should be considered PL1 data, and shared with collaborators on a need-to-know basis.
How to Submit SAP?
Google document templates are provided to help with the documentation effort for both PL1 and PL2+ applications.
PL2+ SAP Template PL1 SAP Template
Once the SAP is completed, please send it to ISP via the following web form (requires CAS authentication). The submitted SAP will be tracked via our ticketing system, where an security analyst will be assigned to respond to your submission and review the SAP within 2 weeks.
Note that SAPs for PL1 applications are strongly recommended, though they are not required to be submitted to ISP.
Who should use a SAP?
Applications using data covered by MSSEI are all required to meet security requirements outlined in MSSEI. It is the responsibility of the Resource Proprietors for all covered applications to implement the necessary security controls to meet security requirements.
The
Resource Proprietor for the covered application is the person responsible for meeting the MSSEI requirements, and ultimately responsible for ensuring the SAP is prepared, implemented, monitored for effectiveness, and finally submitted to the Information Security and Policy (ISP) for review.
The broad scope of questions asked in the SAP will likely require an individual, which we are calling Application Coordinator, who is most knowledgeable about all the essential parts of the application in question. The resource proprietor may choose to delegate the responsibility to fill out the details of the plan to the Application Coordinator. To speed up the assessment process and avoid confusion, ISP also strongly recommends that the person assigned the Application Coordinator role to be the main contact person to interact with ISP during the SAP review process and subsequently through the entire MSSEI assessment. While the Application Coordinator may not be the expert on all technical topics, he or she should know who are the experts that can be tapped to describe the technical aspect of application and relevant security controls.
What's in a SAP?
ISP provide templates for the SAP for both PL1 and PL2+ applications. At the start of each SAP template is a table to write down the basic information about the application, such as name of the Resource Proprietor, Application Coordinator, Application Name, etc.
Every application's resource proprietor is responsible to know application data's protection level. If you have not yet confirmed your data protection level from the IT Policy office, please go to
Data Registration, where you will be asked to complete a brief questionnaire, and upon review of the questionnaire, you will receive your classification from IT Policy staff.
If your system is classified as PL2+ (protection level 2 or protection level 3), the next step is to verify that your covered devices has been registered with
RDM (Restricted Data Management). By registering with RDM, your system will be automatically enrolled in campus intrusion detection and vulnerability scanning, and monitoring can begin within 24 hours.
Sections 1 - 6 provides space to document important information about the application in question, such as the purpose of the application, the intended audience and users, what data is being used in the application, how do all the different systems and devices interact with each other. Especially important to the description of the application are Section 3, Architecture Model and Section 4,Data Flow Description.
In the
Architecture Model section, please provide a visual representation of how various systems interact with each other within the application. In devices or systems where the
covered data is stored or being processed, please also note that in the architecture diagram. In
Data Flow Description section, please describe narratively the interfaces between various devices and systems listed in the Architecture Model, including notes on how
covered data is being stored or processed in relevant systems.
The Architecture Model section, along with the Data Flow Description section, are particularly important because they help to formalize the workflows within all the components (web servers, databases, backup systems, admin workstations, end user workstations, etc) of the applications. The architecture model will also help to identify places in the architecture where systemic violations of security requirements might occur (i.e. finding design flaws).
For applications that will undergo significant change in the near future (within 6 months), please document the future state architecture model. For applications that are looking to make changes beyond 6 months horizon, please document architecture model at the time when SAP is being completed, with a brief note to explain the scope of future application changes.
In section 5, Support Model, list any support and development staff that have elevated privileges in the application or its underlying systems, including their roles and responsibilities in supporting/developing this application. In the responsibilities column, please make note if a role is temporary. Examples of temporary roles may include short-term contractors or support staff that will lose their elevated access to application in the near future (within 6 months). Elevated privileges in this case may mean permissions to change application configuration, bulk access to covered data, etc.
In section 6, Meeting MSSEI Requirements, each of the MSSEI requirements are listed along with key questions that are prompts to help application coordinator and resource proprietor to come up with details of how your application is meeting or will meet each control. If a control is planned for the future, please also include an estimate time frame for when the control is expected to be fully in place. MSSND requirements are also listed, along with key questions, as part of MSSEI requirement #17.
The SAP template provides space to document controls applicable to institutional and privileged access devices, as required by MSSEI. For applications that have multiple privileged access devices, and they are managed differently (e.g. Windows workstations vs. Mac workstation), please specify which documented procedures and tools are applicable to which privileged access devices. Similarly, if institutional devices are secured using more than one set of procedures and tools, please document all of them and specify the applicable device within the documentation.
While MSSEI is applicable to individual devices, requirement-by-requirement documentation of compliance on individual devices is not necessary in the plan. However, Application Coordinator, along with Resource Proprietor, is required to establish data access agreements with end users of the application to inform them of the MSSEI individual device requirements. The data access agreement should make clear that by agreeing to use the application, end users are also agreeing to meet MSSEI individual device requirements.
The "Progress" field on the upper left corner in each requirement is provided to document the implementation status of security controls as either "Not started", "In Progress", or "Fully Implemented". "Not Started" is meant to represent security controls that are currently in the planning phase, where none of the procedures and tools are put into place to meet the security requirement. Security controls are "In Progress" if some procedures and tools have already been put into place, but not all are ready to be assessed against the corresponding MSSEI requirement. "In Progress" security controls must also include a formal (i.e. documented and approved by Resource Proprietor) timeline to finish implementation of all procedures and tools. Finally, if a security control is designated as "Fully Implemented", then the full specification of the control is implemented, and every part of the control is ready to be assessed against MSSEI requirements.
The appendices are tables for application coordinator to provide an inventory of key systems, devices and software that are being used for application in question. In hardware inventory table, there's also a column to the far right to note the devices type, as defined by MSSEI, of the device or system in the inventory list. Only privileged access and institutional devices are required to be listed in the inventory. For servers (institutional devices), please aslo note the functional role of the server in the Server Type column (e.g. web server, file server, application server, etc)
Definition of Key Terms:
Application - In the context of a MSSEI assessment, an application is a set of software and hardware components logically grouped to perform functions that store, process or transmit institutional data.
Application Coordinator - The person who is most knowledgeable about all the essential parts of the application to be assessed, and is the primary contact person to work with ISP assessment team during the assesssment process.
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.”
Data Protection Levels - The data protection levels are a set of categories, defined in Data Classification Standard, for assessing data sensitivity, measured by the adverse business impact a breach of the data would have upon the campus.
Institutional Device - Stores of 500 or more records of structured or unstructured* protection level 2 data. OR Servers that store, process or transmit protection level 2 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.
Privileged Access Device - Any device where credentials are used to provide privileged access (super user, root, administrator, database administrator and equivalent) to an institutional protection level 2 device (physical, logical and virtual devices included).
SAP - Self Assessment Plan
Security Control - A set of security procedures and tools used to meet a defined set of security requirements.
