UC Berkeley security policy mandates compliance with Minimum Security Standard for Electronic Information for devices handling covered data. The recommendations below are provided as optional guidance for meeting application software security requirements.
Resource Proprietors and Resource Custodians must validate that commercial software meets security criteria used by the Campus Application Security Testing Program prior to purchase.
Security vulnerabilities in application software allow data theft.
Whether software is developed in-house or procured from 3rd party vendors, MSSEI requires that resource proprietors and resource custodians ensure covered data is secured and protected against breaches. To ensure the equivalent set of security requirements applies to commercial software, prior to making purchase decisions, resource proprietors and resource custodians must evaluate commercial software against the following set of security criteria:
- Secure coding practices should be integrated into the software development lifecycle phases employed by software vendors' development team. Example questions to ask include:
- What processes are in place to ensure secure coding practices are integrated into SDLC?
- How does vendor's development team address OWASP top 10 application security risks?
- Commercial software should provide features and functions that comply with relevant MSSEI technical requirements. The following guidance provides additional clarification on MSSEI technical requirements as they relate to vendor software security:
- 3.1 - Secure device configuration. Commercial software must allow for configuration settings to be setup securely as required by MSSEI 3.1.
- 7.2/15.2 - Data encryption at rest. Commercial software must allow for encryption of covered data residing on storage media either through native functionality or third party encryption tools.
- 7.3/15.1 - Data encryption in transit. Commercial software must be able to utilize strong encrypted transmission protocols when sending data across the network.
- 9.1 - Separation of System Resources. Commercial software must provide user management functionality to create application user accounts for each individual users. Commercial software must also accommodate infrastructure components such as operating system, databases and application services to be deployed across separate physical or virtual servers.
- 10.2 - Admin account security. Commercial software must allow granular account security configuration to use strong authentication as defined in MSSEI 10.2.
- 12.1 - Audit logging. Commercial software must log and retain application events in compliance to MSSEI 12.1 requirements.
- 13.1 - Controlled access based on need to know. Commercial software must provide identity and access management functionality that enables resource proprietors and resource custodians to "Regularly review access permissions" as defined in MSSEI 13.1.
- 14.1 - Account monitoring and management - Commercial software must provide account management functionality that enabled resource proprietors and resource custodians to protect all application accounts.
- Some MSSEI requirements are less reliable on technical features of commercial software, and require operational processes to ensure compliance with requirement. Resource proprietors and resource custodians should implement processes utilizing the vendor software to address non-technical MSSEI requirements. An example is the software inventory requirement, which should be met by developing a process to collect and manage software assets installed on covered devices.
- Where commercial software supports Single Sign-On authentication, it must support authentication protocols that comply with the CalNet terms of service. If proxied CalNet authentication is chosen as Single Sign-On solution, resource proprietor and resource custodian must obtain an approval for the exception to proxy CalNet credentials per terms of service.
- Software vendor should demonstrate a proven track record in responding timely to software vulnerabilities and releasing security patches on a schedule that corresponds to vulnerability risk level. For additional guidance on vulnerability management timeline, refer to MSSEIGuideline 4.1 - Continuous Vulnerability Assessment.
- Software vendor should provide a Software Obsolescence Policy that demonstrates willingness to support older version(s) of software and provide adequate lead time prior to dropping support for a major version of the software. Support functions for older version(s) of software should include:
- Software updates to address security vulnerabilities
- Software updates to address functional design flaws
- Technical support including configuration and installation
- When web browsers are used to access covered systems, software vendors should demonstrate a willingness and track record to support (with full functionality) the two most recently released major browser versions for the following browsers on Mac and Windows PC:
- Software vendor should be willing and able to provide the following set of documentation during the evaluation process:
- Security architecture diagrams and documentation with details on security technologies employed such as IDS, IPS, WAF, and network firewall
- Results of 3rd party security audits, vulnerability assessments, penetration tests and source code audits; results should include methodologies used, findings identified, and remediation plans
- Documentation on APIs used by commercial software to exchange data with other software components
- (Cloud Software Service) Documentation demonstrating compliance to industry best practices such as Cloud Security Alliance's CSA Cloud Controls Matrix
In addition to security requirements noted above, any contractual relationship with vendors must also comply with UCOP material management procurement policy, BUS-43, Appendix DS - Additional Terms and Conditions – Data Security and Privacy.