MSSEI Self Assessment Plan
Application Name
Data Classification
Protection Level 1
Resource Proprietor
(Functional Owner)
Application Coordinator
Department/Unit Name
Table of Contents
1. 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
19
Appendix B – Software Inventory
19
Template Revision History
Date
4/23
5/14
UC Berkeley
Author
Leon Wong
Leon Wong
Description
Version 1
Updated with to match administrative changes to MSSEI
Page 1 of 19
1. Project / System Overview
Describe 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 Audience
Describe the users who will use and be affected by the application.
3. Architecture Model
Attach a high-level diagram of data flow and data storage, including all the interconnected system names
and interfaces.
4. Data Flow Description
Provide 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 Model
Please 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
UC Berkeley
Role
Application
Responsibilities
Email Address
Page 2 of 19
6. Meeting MSSEI Requirements
The 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



Progress:
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?
Institutional Devices:
Privileged Access Devices:
MSSEI 1.2 Covered system inventory



Progress:
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)
Institutional Devices:
UC Berkeley
Page 3 of 19
Privileged Access Devices:
MSSEI 1.3 Covered system registration


Progress:
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.
Institutional Devices:
Privileged Access Devices (Future Requirement):
MSSEI 1.4 Annual renewal


Progress:
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.
Institutional Devices:
Privileged Access Devices:
MSSEI 2.1 Managed software inventory



Progress:
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?
Is there an documented inventory process by which the Resource Custodian is
UC Berkeley
Page 4 of 19

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



Progress:
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?
Institutional Devices:
Privileged Access Devices (Future Requirement):
MSSEI 4.1 Continuous vulnerability assessment and
remediation



Progress:
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?
Institutional Devices:
UC Berkeley
Page 5 of 19
Privileged Access Devices (Future Requirement):
MSSEI 4.2 Authenticated scan


Progress:
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?
NOT Required.
MSSEI 4.3 Intrusion detection


Progress:
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)?
Institutional Devices (Future Requirement):
Privileged Access Devices (Future Requirement):
MSSEI 5.1 Device physical security



Progress:
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)
Institutional Devices (Future Requirement):
UC Berkeley
Page 6 of 19
MSSEI 6.1 Secure coding training


Progress:
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?
NOT Required
MSSEI 6.2 Code review



Progress:
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?
NOT Required
MSSEI 6.3 Application security testing



Progress:
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.
NOT Required
MSSEI 6.4 Commercial software assessment

Progress:
What security requirements were included in the vendor review process?
UC Berkeley
Page 7 of 19
NOT Required
MSSEI 7.1 No "institutional" devices on mobile/wireless devices


Progress:
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?
Institutional Devices (Future Requirement):
MSSEI 8.1 Privacy and Security training


Progress:
What privacy & security training are required for users in these following groups?
o Resource Proprietors
o Resource Custodians (Application Developers & Infrastructure
Administrators)
o End Users
How are training requirements communicated to listed group of users?
Institutional Devices (Future Requirement):
MSSEI 9.1 Unique passphrases


Progress:
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?
Institutional Devices:
Privileged Access Devices:
UC Berkeley
Page 8 of 19
MSSEI 9.2 Separation of accounts




Progress:
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?
Institutional Devices:
Privileged Access Devices:
MSSEI 9.3 Separation of system resources



Progress:
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?
Institutional Devices:
MSSEI 10.1 Use of admin accounts only on secure devices


Progress:
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.
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?
UC Berkeley
Page 9 of 19

How are you notifying administrators of this control?
Institutional Devices:
Privileged Access Devices (Future Requirement):
MSSEI 10.2 Admin account security





Progress:
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?
Institutional Devices:
Privileged Access Devices (Future Requirement):
MSSEI 11.1 Managed hardware firewall





Progress:
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)?
Institutional Devices:
UC Berkeley
Page 10 of 19
MSSEI 11.2 Protected subnets




Progress:
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)?
Institutional Devices (Future Requirement):
MSSEI 12.1 Security audit logging





Progress:
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?
Institutional Devices:
MSSEI 12.2 Security audit log analysis


Progress:
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?
Institutional Devices (Future Requirement):
UC Berkeley
Page 11 of 19
MSSEI 13.1 Controlled access based on need to know






Progress:
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?
Institutional Devices:
Privileged Access Devices:
MSSEI 14.1 Account monitoring and management





Progress:
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.
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:
UC Berkeley
Page 12 of 19
MSSEI 15.1 Encryption in transit




Progress:
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?
Institutional Devices:
Privileged Access Devices:
MSSEI 15.2 Encryption on mobile devices and removable
storage media



Progress:
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?
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:
UC Berkeley
Page 13 of 19
MSSEI 15.3 Secure deletion upon decommission




Progress:
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?
Institutional Devices:
Privileged Access Devices:
MSSEI 15.4 Data access agreement


Progress:
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?
Institutional Devices:
MSSEI 16.1 Incident response planning


Progress:
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
definitions and assignments communicated to the stakeholders?
Institutional Devices:
UC Berkeley
Page 14 of 19
MSSEI 16.2 Incident response plan availability


Progress:
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?
Institutional Devices:
MSSEI 16.3 Incident reporting training

Progress:
Have all End Users been made aware of the appropriate way to report an incident?
Institutional Devices (Future Requirement):
MSSEI 17.1 MSSND - Software Patch Updates


Progress:
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?
Institutional Devices:
Privileged Access Devices:
MSSEI 17.2 MSSND - Anti-malware Software


Progress:
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?
UC Berkeley
Page 15 of 19
Institutional Devices:
Privileged Access Devices:
MSSEI 17.3 MSSND - Host-based Firewall Software

Progress:
Do all your systems have host-based firewalls enabled and effectively configured?
Please describe your policy and process to accomplish this.
Institutional Devices:
Privileged Access Devices:
MSSEI 17.4 MSSND - Use of Authentication


Progress:
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)?
Institutional Devices:
Privileged Access Devices:
MSSEI 17.5 MSSND - Passphrase Complexity

Progress:
Describe your passphrase complexity policy and how you enforce it.
Institutional Devices:
UC Berkeley
Page 16 of 19
Privileged Access Devices:
MSSEI 17.6 MSSND - No Unencrypted Authentication

Progress:
How do you ensure that all authentication sessions are encrypted?
Institutional Devices:
Privileged Access Devices:
MSSEI 17.7 MSSND - No Unattended Console Sessions

Progress:
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.
Institutional Devices:
Privileged Access Devices:
MSSEI 17.8 MSSND - No Unnecessary Services

Progress:
How do you ensure that your covered devices do not run any unnecessary network
services?
Institutional Devices:
Privileged Access Devices:
UC Berkeley
Page 17 of 19
MSSEI 17.9 MSSND - Privileged Accounts

Progress:
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?
Institutional Devices:
Privileged Access Devices:
UC Berkeley
Page 18 of 19
Appendix A – Hardware inventory
Host Name
IP address
Virtual?
Managed By
OS/Software
Device Type
Server Type
Appendix B – Software Inventory
Software
e.g., Windows server
Oracle
Eclipse
JDK
Gnu Privacy Guard
UC Berkeley
Version
2008
11g
1.6
Source
www.eclipse.org
www.oracle.com
www.gpg.org
Purpose
Operating System
Database
Integrated Development Environment
Java Libraries
Encryption Too
Page 19 of 19