This Standard supports and supplements the Information Security (SPG 601.27) policy. It will be periodically reviewed and updated as necessary to meet emerging threats, changes in legal and regulatory requirements, and technological advances.
Insecure software coding and web application design can leave data and IT systems vulnerable to exploitation. This standard seeks to ensure that applications developed or administered by the university reflect secure coding practices, which can reduce likelihood that malicious code will be inserted in software, and lessen the impact of malicious code that is already present in deployed software.
Implementation of this standard can:
- Reduce the likelihood of unauthorized disclosure or theft of sensitive institutional information;
- Prevent unauthorized access to administrative interfaces or systems;
- Increase compliance with legal and regulatory requirements;
- Ensure the ongoing availability of critical university assets and resources;
This Standard lays out requirements and expectations so that security controls applied to applications will result in a level of risk that is appropriate when considering the sensitivity classification of data being processed, stored, and transmitted.
Federal or state regulations or contractual agreements may require additional controls beyond those included in this Standard.
This Standard applies to the Ann Arbor, Dearborn, and Flint campuses, as well as all schools, colleges, institutes, and Michigan Medicine. It also applies to:
- All units, faculty, principal investigators, staff, and workforce members that create, process, maintain, transmit, or store data classified as Restricted, High, or Moderate on any device.
- Software and web applications including mobile applications, irrespective of the application developer or the device used for programming, that run on physical or virtual hosts (including third-party cloud or datacenter hosts).
- Third-party service providers contracted by U-M to perform application development that involves data classified as Restricted, High, or Moderate.
University units must adhere to the requirements of this Standard in all instances that involve data classified as Restricted, High, or Moderate, and ensure, as best as possible, that in-house software and application developers are provided with adequate resources that allow for prioritizing implementation of this Standard’s security controls.
Software and application developers and administrators must ensure that secure coding practices are incorporated into each phase of the software development life cycle. They are responsible for reviewing the code and implementing appropriate application security controls for systems under their management and supervision.
The essential components of secure coding and application security include:
- Software/Application Patching: The timely and consistent application of vendor-supplied security patches or mitigation of a reported vulnerability, in accordance with the Vulnerability Management Standard, are critical components in protecting the campus network, systems, and data from damage or loss due to threats such as worms, viruses, data loss, or other types of external or internal attacks.
- Use of Production Environments: A Production Environment contains an application or service deployment that is ready and approved for its intended use by end users or other systems. The Production Environment must meet all standards for the classification of data that it contains.
- Use of Pre-Production/Quality Assurance/Staging Environments: A Pre-Production/Quality Assurance/Staging Environment contains an application or service deployment undergoing final verification before being deployed into a Production Environment. A Pre-Production/Quality Assurance/Staging Environment meeting all standards for the corresponding Production Environment may contain data of the same data classification as the target Production Environment.
- Use of Test Environments: A Test Environment is any service or application deployment that uses software, configurations, or infrastructure that have not been fully approved for production use. As an example, software that is still in development and has not undergone thorough security testing could be considered part of a Test Environment. Data classified as Restricted or High may not be used in Test Environments without Information Assurance (IA) permission. It is not recommended that data classified as Moderate be used in Test Environments.
- Use of Development Environments: A Development Environment, unlike the Production, Staging, and Test environments, is sometimes run from a software developer’s desktop or laptop system. Software and configurations in such an environment are typically in various stages of construction and should not be trusted to secure data. Therefore, a Development Environment must adhere to the same standards as a Test Environment.
- Secure Coding: Secure coding practices should be incorporated into the university’s security architecture and development lifecycle. This includes defining security requirements early in the software development life cycle and then evaluating for compliance with those requirements.
- Software and web applications that fall under this Standard are required to meet the OWASP Secure Coding Guidelines or their equivalent. Some of the most important secure coding practices are highlighted in the table below.
- Reliance on External or Third-Party Components: Software typically relies on other modules, components, or libraries for its functions. Any of these may contain security vulnerabilities. The application developer should use the latest available version in order to ensure that all known vulnerabilities with available patches will be addressed.
|#||Secure Coding Practice||Restricted||High||Moderate|
|1||Ensure applications validate input properly and restrictively, allowing only those types of input that are known to be correct especially from untrusted sources.||Required||Required||Required|
|2||Ensure applications execute proper error handling so that errors will not provide detailed system information, deny service, impair security mechanisms, or crash the system.||Required||Required||Required|
|3||Authenticate users through central authorization and authentication systems, specifically Kerberos, Active Directory, Shibboleth, MCommunity; consider requiring multi-factor authentication to further enhance security.||Required||Required||Recommended|
|4||Implement multi-factor authentication||Required||Required||Recommended|
|5||Base access decisions for both developers and users on permission rather than exclusion and adhere to principle of least privilege; wherever feasible, provide access to applications based on role, affiliation, or membership, rather than by individual.||Recommended||Recommended||Recommended|
|6||Access given to individuals rather than role-, affiliation-, or membership-based should be reviewed on an annual basis.||Required||Required||Recommended|
|7||Provide for automated review of authorizations where possible.||Required||Required||Recommended|
|8||Encrypt external transmission for applications or software that maintain, process, transmit, or store data classified as Restricted or High; the determination to use encryption can be policy-based and geared to specific regulatory mandates.||Required||Required||Recommended (required if specified by contract or regulation)|
|9||Implement the use of application logs to the extent practicable, given the limitations of certain systems to store large amounts of log data. Log access by all users including time of access according to retention schedule in Security Log Collection, Analysis, and Retention (DS-19).||Required||Required||Required|
|10||Conduct code security reviews (audit the source code to verify that proper security controls are present and work as intended), with professionally trained peers for all new or significantly changed applications, particularly those that maintain, process, transmit, or store data classified as Restricted or High.||Required||Required||Recommended|
|11||Use effective quality assurance techniques (e.g., penetration testing, source code audits, application scanning) to identify and eliminate vulnerabilities in web, application, and database servers. Conduct vulnerability testing/application scanning (allow for emergency situation) of the security posture of web-based applications prior to go-live and before major changes or revisions are implemented.||Required||Required||Recommended|
|12||Remove obsolete or no longer supported or needed software or applications; identified software and applications should be deleted or made no longer available on the campus network.||Required||Required||Required|
|13||Implement and maintain a change management process, including version control, for changes to existing software applications.||Required||Required||Recommended|
In addition to the requirements of this Standard, applications, databases, and APIs that maintain, process, transmit, or store data classified as Restricted or High must also be in compliance with the Security of Enterprise Application Integration Standard (DS-09).
Violations of this Standard may result in disciplinary action up to and including suspension or revocation of computer accounts and access to networks, non-reappointment, discharge, dismissal, and/or legal action. In addition, the connectivity of machines and servers to the U-M network that do not comply with this Standard may be limited or disconnected.
Discipline (SPG 201.12) provides for staff member disciplinary procedures and sanctions. Violations of this policy by faculty may result in appropriate sanction or disciplinary action consistent with applicable university procedures. If dismissal or demotion of qualified faculty is proposed, the matter will be addressed in accordance with the procedures set forth in Regents Bylaw 5.09. In addition to U-M disciplinary actions, individuals may be personally subject to criminal or civil prosecution and sanctions if they engage in unlawful behavior related to applicable federal and state laws.
Any U-M department or unit found to have violated this policy may be held accountable for the financial penalties, legal fees, and other remediation costs associated with a resulting information security incident and other regulatory non-compliance.
Information Assurance is responsible for the implementation, maintenance and interpretation of this Standard.
- NIST SP 800-53 Revision 4
- SA-03 System Development Life Cycle
- SA-08 Security Engineering Principles
- SI-11 Error Handling