MSSEI Self Assessment Plan

Application Name

Data Classification Protection Level 1

Resource Proprietor(Functional Owner)Application Coordinator

Department/Unit Name

Table of Contents1. Project / System Overview 2

2. Target Audience 2

3. Architecture Model 2

4. Data Flow Description 2

5. Support Model 2

6. Meeting MSSEI Requirements 3

Appendix A – Hardware inventory 18

Appendix B – Software Inventory 18

Template Revision HistoryDate Author Description4/23 Leon Wong Version 15/14 Leon Wong Updated with to match administrative changes to MSSEI

UC Berkeley Page 1 of 20

1. Project / System OverviewDescribe the overall application / system purpose, the data classification level given by IT Policy, as well as the sensitive data elements that qualifies the application at specified data protection level.

2. Target AudienceDescribe the users who will use and be affected by the application.

3. Architecture ModelAttach a high-level diagram of data flow and data storage, including all the interconnected system names and interfaces.  

4. Data Flow DescriptionProvide description of data movement and data storage depicted in the architecture model.  Please include brief description of how each component in the architecture model is being secured.  

5. Support ModelPlease 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 (3 – 6 months). Elevated privileges in this case may mean permissions to change application configuration, bulk access to covered data, etc.

Name Role Application Responsibilities

Email Address

UC Berkeley Page 2 of 20

6. Meeting MSSEI RequirementsThe Minimum Security Standards for Electronic Information (MSSEI) define the minimum set of confidentiality controls required for Electronic Information as well as the device types for which these controls are applicable.

For each MSSEI standard (1.1 – 17.1), describe how compliance with the standard are achieved for the device types listed with existing tools and practices. If a standard is a future requirement (+) on a device, indicate how the standard will be met or document the considerations for not meeting the control.

Device type definitions, and detailed descriptions of each control with links to implementation guidelines are available at: security.berkeley.edu/mssei. Assessment questions are provided here as prompts, with the caveat that they are subject to change. They are not intended to be comprehensive and may not be applicable for all systems. If compliant controls are not yet implemented, describe any future plans or proposal to meet applicable standard, and use “Progress” column to indicate whether implementation status of the security standard is “Not Started”, “In Progress”, “Fully Implemented”.

MSSEI 1.1 Removal of non-required covered data

What do you do with systems or storage media that are being replaced or otherwise decommissioned and have handled covered data?

Do you have a documented process for securely deleting covered data from decommissioned devices?

What tools do you use to securely delete covered data?

Progress:

Institutional Devices:

Privileged Access Devices:

 

 MSSEI 1.2 Covered system inventory

Is there a documented inventory of devices used in the covered system? Do you have a list of devices that are used to support covered system? See

Appendix at the end of the document for a device inventory template.

Is there a documented process to update inventory list as the devices and covered system are updated (e.g. changes in business function, specification)

Progress:

Institutional Devices:

 

UC Berkeley Page 3 of 20

Privileged Access Devices:

 MSSEI 1.3 Covered system registration

Is a security contact assigned in Security Contacts application and maintained for each IP address?

Are covered devices registered in RDM? Covered devices may include privileged devices such as system admin workstations that are used to access institutional devices.

Progress:

Institutional Devices:

 

Privileged Access Devices (Future Requirement):

 MSSEI 1.4 Annual renewal

Do you have a written procedure that assigns the responsibility to an individual to annually review your RDM registration and Security Contacts?

Is it apart of their responsibilities to verify all information provided is accurate and up to date?  Be sure to provide the name of the individual responsible.

Progress:

Institutional Devices:

 

Privileged Access Devices:

 

 MSSEI 2.1 Managed software inventory

Do you have an inventory of all installed software on all Privileged Access and Institutional devices? Does this inventory include software title, version and patch level?

Do you have a list of authorized software which is necessary to meet business needs for Privileged Access and Institutional devices?

Progress:

UC Berkeley Page 4 of 20

Is there an documented inventory process by which the Resource Custodian is notified when unauthorized software packages are discovered on Privileged Access and Institutional devices?

Is there a written procedure to periodically review and who is assigned that responsibility to approve of a maintained software list?

Institutional Devices:

 

Privileged Access Devices (Future Requirement):

 MSSEI 3.1 Secure device configuration

Are your devices built, configured, and deployed with a recognized security configuration benchmark? (e.g. RedHat KickStart, custom build scripts, hardening checklists)

Does a process exist to regularly check device configurations and notify the Resource Custodian of any changes? What follow-up actions are planned when unplanned configuration changes are detected?

For example, is there an email send to Resource Custodian listing configuration changes? Once an unplanned change is detected, will Resource Custodians create a ticket in a ticket tracking system to track the issue?

Progress:

Institutional Devices:

 

Privileged Access Devices (Future Requirement):

MSSEI 4.1 Continuous vulnerability assessment and remediation

Have you verified that all Privileged Access and institutional devices allow the ISP scanners? 

What is the process to ensure covered devices have been scanned within the last week (5 business days)?

If you do not allow ISP scanners, what is your documented process for continuous scans?

Progress:

Institutional Devices:

UC Berkeley Page 5 of 20

 

Privileged Access Devices (Future Requirement):

 

 MSSEI 4.2 Authenticated scan

Do you have a process in place to perform authenticated scan on covered devices? (Secunia for PC, Nessus departmental scanner for Unix/Macs)

How are vulnerabilities remediated after they are identified in the authenticated scan?

Progress:

NOT Required.

 

 MSSEI 4.3 Intrusion detection

Are your covered devices on the campus network to take advantage of centrally provided IDS service?

Are the covered devices registered properly per MSSEI system registration requirement (1.2)?

Progress:

Institutional Devices (Future Requirement):

 

Privileged Access Devices (Future Requirement):

 

 MSSEI 5.1 Device physical security

Where are your institutional devices physically located?  If not at Warren data center, 

o how is access to that room controlled (key, keycard, etc.)?o Do you have a documented process for adding or removing people

granting/denying access to institutional device?o Do you have an audit trail of who entered and left your data center?

What's your process to generate and review the list of personnel who have physical access to your institutional devices? (Including warren)

Progress:

Institutional Devices (Future Requirement):

UC Berkeley Page 6 of 20

 

 

 MSSEI 6.1 Secure coding training

What coding training has been taken by developers of covered applications? Please highlight components of training specific to developing secure code.

What is your training plan for your developers? How are you identifying developers that should go to training? What is the process to review training progress?

Progress:

NOT Required

 MSSEI 6.2 Code review

Do you have documented code review process? How are staff identified to participate? Does all code go through the process?

What Software Development Life Cycle(SDLC) methodologies were used to develop application?

What security requirements are incorporated into SDLC?

Progress:

NOT Required

 

 MSSEI 6.3 Application security testing

Have you contacted the Application Security Testing Program (ASTP) to schedule an assessment?

If you've received an ASTP assessment, what was the grade given to your system from that assessment? 

If assessment was done by 3rd party, please describe the assessment methodology and results of that assessment.

Progress:

NOT Required

 

 

  MSSEI 6.4 Commercial software assessment Progress:

UC Berkeley Page 7 of 20

What security requirements were included in the vendor review process?

 NOT Required

 

 

 MSSEI 7.1 No "institutional" devices on mobile/wireless devices

Do any institutional systems have wireless network interface installed? 

If installed a) is it Enabled?; b) do you have a document process to ensure it is always disabled?

Progress:

Institutional Devices (Future Requirement):

 

 MSSEI 8.1 Privacy and Security training

What privacy & security training are required for users in these following groups? o Resource Proprietorso Resource Custodians (Application Developers & Infrastructure

Administrators)o End Users

How are training requirements communicated to listed group of users?

Progress:

Institutional Devices (Future Requirement):

 

 MSSEI 9.1 Unique passphrases

How are users made aware that they must use unique and significantly different passphrases for each separate account under their control?  Is this documented process?

How are users made aware that they cannot reuse passphrases for personal/consumer accounts?

Progress:

Institutional Devices:

 

UC Berkeley Page 8 of 20

Privileged Access Devices:

MSSEI 9.2 Separation of accounts

How are user accounts tied to institutional identities? Does each user account, including administrative accounts, in the application and

underlying systems correspond to an individual? For accounts that are required to be shared due to application/system constraints and/or institutional requirement, what's the process to inventory these shared accounts along with description?

What's the process to disable built-in administrator accounts and instead assigned a administrative function to individuals?

When working with databases, is each application given a unique login account? Are password changed in different environments, for example, is the production database passwords different from development?

Progress:

Institutional Devices:

 

Privileged Access Devices:

 MSSEI 9.3 Separation of system resources

Are web servers and database only hosting systems of like data protection level, for example, are all databases hosting only PL2 data on server 1 and only PL1 data on server 2?

Are you DB servers segmented from other services? How are your databases separated? Do your DB servers run multiple services? If so, which services?

Are all critical services, such as, file server, database, operate on separate host machines or virtual machines?

Progress:

Institutional Devices:

 

 

 MSSEI 10.1 Use of admin accounts only on secure devices

How are administrative accounts used to perform privileged operations? Please include in the description the various devices that are required to perform the privileged operations. E.g. if a work laptop is used to login to a secured host before performing privileged operation, please include the work laptop in your description. 

Progress:

UC Berkeley Page 9 of 20

Please include description the function of all devices where admin credentials are entered. 

What devices are being used for administrative functions? How do you identify these devices? Do you have enforcement that limit administrator functions being performed only on approved privileged devices?

How are you notifying administrators of this control?Institutional Devices:

 

Privileged Access Devices (Future Requirement):

 

 MSSEI 10.2 Admin account security

What password complexity requirements are enforced for administrative accounts? Is this process documented?

Where application or script require access to administrative credentials, how are the credentials stored and protected?

Are administrative accounts used for high risk activities such as web browsing, email, etc.?

How are you managing shared service account credentials that have elevated privileges?

where administrative accounts keys can read any private key, how do you identify and manage these administrative accounts?

Progress:

Institutional Devices:

 

Privileged Access Devices (Future Requirement):

 

 MSSEI 11.1 Managed hardware firewall

Do you have hardware firewall or router with Access Control Lists configured to protect Institutional System devices? What type and model? What is your context name?

Do you have active outbound rules?  Do you have default deny rule enabled? Do you have documented justifications for each of your firewall rules? If so, what's

information are required to be included in the firewall justification rules? Please describe the process in which firewall rules are added or changed, including

any review or approval process. Define the responsible person for your firewall.

How are changes in the firewall configuration and rules logged and traceable back to the original request (e.g. a ticketing system)?

Progress:

Institutional Devices:

UC Berkeley Page 10 of 20

  

 MSSEI 11.2 Protected subnets

What devices reside in the same protected VLAN(s) as covered devices? Do you have an inventory of the devices connected to the protected VLAN(s)?

If non-covered devices reside in the protected VLAN, please describe the system supported by these non-covered devices in terms of their associated data classification level and MSSEI compliance (Level 1 or Level 2 compliance or no compliance).

Where is the network device(s) connecting the covered devices located? How is the network device(s) physically protected?

Do you have any wireless access points on your PL2 private VLAN (subnet)?

Progress:

Institutional Devices (Future Requirement):

  

 

 MSSEI 12.1 Security audit logging

Are you sending your logs to campus logging program?  Have you reconfigured your apache, IIS, or Jboss logs to use syslog to securely transmit your logs?

Do you have full audit trail for user access to cover data?  If web application, are the IIS, apache logs enabled and collecting source IP address, time, date, etc.? 

Can you show which user has access covered data when? How are the log files protected from tampering or unauthorized access?

How does your system ensure time synchronization?

Progress:

Institutional Devices:

 MSSEI 12.2 Security audit log analysis

Do you have a dedicated staff to review audits daily?

How are log events prioritized and reviewed? What rules or algorithms is being used to determine a log event require further investigation?

Progress:

Institutional Devices (Future Requirement):

UC Berkeley Page 11 of 20

 MSSEI 13.1 Controlled access based on need to know

What is the process in place to review request for access to covered application and devices (Institutional and Privileged)?   Is the process documented? Who is responsible for the review?

What kind of approval requirements need to be met before requested access is granted?

What procedures are in place to review access granted to covered systems? Is your system automated to remove employees' access once they are no longer

employed or they have a change in job responsibility? At what frequency do you review access to your application and devices

(Institutional and Privileged)?

How have you implemented the principal of least privilege in your application?

Progress:

Institutional Devices:

 

Privileged Access Devices:

 MSSEI 14.1 Account monitoring and management

Are there any automated reports showing inventory of user accounts in covered systems?

Are there any automated reports showing account and group level changes? Examples of account and group level changes include:

o Status changes that enable or disable accounts/groups

o Account access privilege updates

o Account creation/deletion

o Group access privilege updates

o Group membership updates

o Group creation/deletion

What documented procedures are in place to remove stale accounts that no longer require access to covered systems? Examples of stale account may include terminated or transferred employees, old service accounts, old administrative accounts, etc.

Progress:

UC Berkeley Page 12 of 20

Are there expiration dates assigned to user accounts? If so, how are expiration dates determined?

Are account locked after multiple failed login accounts?Institutional Devices:

 

 

 MSSEI 15.1 Encryption in transit

Have you identified the entire flow of covered data over networks, including to and from external vendors/entities, backup systems, and redundant systems? Ensure that you have thoroughly "followed" the flow of covered data over networks. A common pitfall when identifying data flow is failing to consider external systems that receive or send covered data such as via FTP, Web Services, and other batch data processing components with network access.

Do your QA or Development environments contain copies of covered data? Ensure that your security plan includes encryption mechanisms for these common environments and not just Production systems.

Have you documented the type of encryption protocols and authentication methods in use for each network transmission of covered data related to your system?

Have you identified any vendor products in your system that use encryption and can you provide documentation for the protocols and mechanisms used by those products?

Progress:

Institutional Devices:

 

Privileged Access Devices:

 MSSEI 15.2 Encryption on mobile devices and removable storage media

Will covered data be stored in mobile devices and removable storage media? If so, o what encryption mechanisms are used to protect covered data on mobile

devices and removable media?o How are encryption keys stored and managed?o Please describe any documented policies or procedures to physically secure

mobile devices and removable storage media.o How do you keep track of removable storage media location and data

owner?o What is the backup plan for covered data stored in mobile devices and

removable storage media?

Progress:

UC Berkeley Page 13 of 20

How do you ensure that all covered data is encrypted on your backup media? 

If proprietary encryption algorithms are used, how have you ensured the encryption methods are "industry acceptable"?

Institutional Devices:

 

 MSSEI 15.3 Secure deletion upon decommission

What documented procedures are used to delete covered data when it is no longer needed?

How is removable storage media storing covered data handled after it is no longer needed?

How is covered system hardware handled after it is decommissioned?

How is this handled in backups?  What is your documented process to ensure that all backup media are securely deleted when no longer needed?

Progress:

Institutional Devices:

 

Privileged Access Devices:

 

 MSSEI 15.4 Data access agreement

What data access agreement is in place between end users and resource proprietor?

Does the data access agreement explain the assigned data classification level and protection profile required for individual devices?

Progress:

Institutional Devices:

 

 

 MSSEI 16.1 Incident response planning

Are you using ISP incident response plan template? If not, please describe the components of your incident response plan.

What roles are defined and assigned in your incident response plan? Are those role

Progress:

UC Berkeley Page 14 of 20

definitions and assignments communicated to the stakeholders?Institutional Devices:

 

 

 MSSEI 16.2 Incident response plan availability

How are you making your incident response plan available to members of the local incident response team?

Have you documented or had incident response team members otherwise acknowledge that they have read and understood the incident response plan?

Progress:

Institutional Devices:

 

 MSSEI 16.3 Incident reporting training

Have all End Users been made aware of the appropriate way to report an incident?

Progress:

Institutional Devices (Future Requirement):

 

 

 MSSEI 17.1 MSSND - Software Patch Updates

How do you deploy patches to your covered devices, workstations, laptops, servers, etc?

Do you operate any systems that have outdated security updates, outdated OS versions, oudated browser versions, etc. and/or that are not supported by their respective vendors for which security updates are not available?

Progress:

Institutional Devices:

 

Privileged Access Devices:

 

UC Berkeley Page 15 of 20

MSSEI 17.2 MSSND - Anti-malware Software

Do all your systems, for which anti-malware solutions are available, have AV installed?

How often are the anti-malware software and its malware definition files updated?

Progress:

Institutional Devices:

 

Privileged Access Devices:

MSSEI 17.3 MSSND - Host-based Firewall Software

Do all your systems have host-based firewalls enabled and effectively configured? Please describe your policy and process to accomplish this.

Progress:

Institutional Devices:

 

Privileged Access Devices:

MSSEI 17.4 MSSND - Use of Authentication

Do you ensure that all covered devices require a valid and strong password before they can be accessed and/or used?

How do devices validate the user account before granting access (e.g. Active Directory, application level accounts, etc)?

Progress:

Institutional Devices:

 

Privileged Access Devices:

MSSEI 17.5 MSSND - Passphrase Complexity

Describe your passphrase complexity policy and how you enforce it.

Progress:

Institutional Devices:

UC Berkeley Page 16 of 20

 

Privileged Access Devices:

MSSEI 17.6 MSSND - No Unencrypted Authentication

How do you ensure that all authentication sessions are encrypted?

Progress:

Institutional Devices:

 

Privileged Access Devices:

MSSEI 17.7 MSSND - No Unattended Console Sessions

Describe your screen/console lock policies and how they are enforced to ensure that no covered devices are left unlocked when not under direct control of the authorized user.

Progress:

Institutional Devices:

 

Privileged Access Devices:

MSSEI 17.8 MSSND - No Unnecessary Services

How do you ensure that your covered devices do not run any unnecessary network services?

Progress:

Institutional Devices:

 

Privileged Access Devices:

UC Berkeley Page 17 of 20

MSSEI 17.9 MSSND - Privileged Accounts

How do you ensure that holders of administrative accounts do not use those accounts for non-administrative activities, such as e-mail and web browsing?

Progress:

Institutional Devices:

 

Privileged Access Devices:

 

UC Berkeley Page 18 of 20

Appendix A – Hardware inventory

Host NameIP address Virtual?

Managed ByOS/Software Device Type

Server Type

Appendix B – Software Inventory

SoftwareVersion

Source Purposee.g., Windows serverOracleEclipseJDK

200811g

1.6

www.eclipse.orgwww.oracle.comwww.gpg.org

Operating SystemDatabaseIntegrated Development Environment Java Libraries

UC Berkeley Page 19 of 20

Gnu Privacy Guard Encryption Too

UC Berkeley Page 20 of 20