Standard for Security in Development and Support Processes

I. Purpose

The purpose of this standard is to establish the university’s obligation to ensure that information security is designed and implemented within the development lifecycle of information systems.

II. Scope

It is the responsibility of any party considering development of an information system within the University environment to understand and apply information security rules which ensure appropriate security for the system.

III. Contacts

Direct any general questions about this standard to your unit’s Information Security Liaison. If you have specific questions, please contact OneIT Information Security Compliance at ISCompliance-group@charlotte.edu.

IV. Standard

Secure development

Secure development is critical for building any secure service architecture, software or system. These requirements should be considered:

• Documented agreement on access levels (i.e., end user, privileged, administrative, etc.) and corresponding authorization requirements
• Submission of change requests only by authorized users
• Reviews to ensure controls and integrity procedures are not compromised by change
• Identification of all software, information, database entities and hardware involved in or impacted by change
• Security review to minimize likelihood of known security weaknesses
• Formal approval prior to commencement of work
• Authorized user acceptance prior to implementation
• System documentation updates
• Version control for all software updates
• Audit trail of all change requests
• Operating documentation and user procedures changed as needed to remain current
• Timing of change to prevent or minimize business impact

Technical review of applications after operating platform changes

When operating platforms including operating systems, databases and middleware platforms are changed, business critical applications should be reviewed and tested to ensure there is no adverse impact on organizational operations or security. The following should also be considered:

• Review of application control and integrity procedures to ensure they have not been compromised by change to the operating platform
• Notification of change with enough lead time to allow appropriate tests and reviews prior to implementation

Restrictions on changes to software packages

Modifications to vendor supplied software packages is discouraged and limited to necessary changes. All changes should be strictly controlled. The following should be considered:

• Risk of compromise of built-in controls and integrity processes
• Possible need for consent from vendor
• Possibility of obtaining required changes from vendor as standard program updates
• Impact if the university becomes responsible for future maintenance of software as a result of changes
• Compatibility with other software in use
• Maintaining original software and making changes to designated copy

Secure development environment

A secure development environment includes people, processes and technology associated with system development and integration.Risks associated with individual system development efforts should be assessed and secure development environments established with the following considerations:

• Sensitivity of data to be processed, stored and transmitted by the system
• Applicable external and internal requirements, e.g., from regulations or policies
• Security controls already implemented by the university that support system development
• Trustworthiness of personnel working in the environment
• Degree of outsourcing associated with system development
• Need for segregation between different development environments
• Control of access to development environment
• Monitoring of change to the environment and code stored therein
• Storage of backups at secure offsite location
• Control over movement of data to and from the environment

Outsourced development

Where a system is outsourced, the following points should be considered:

• Licensing arrangements, code ownership and intellectual property rights related to the outsourced content
• Contractual requirements for secure design, coding and testing practices
• Agreement of an approved approach for analyzing the security of the application
• Acceptance testing for quality and accuracy of deliverables
• Agreement on minimum acceptable levels of security and privacy quality
• Agreement on evidence that sufficient testing has been applied to ensure the absence of intentional and unintentional malicious content upon delivery
• Contractual rights to audit development processes and controls
• Comprehensive documentation of the build environment used to create deliverables

System security testing

Security functionality should be tested throughout the development process and should include a detailed schedule of activities and expected results under a range of conditions.

System acceptance testing

Acceptance testing and criteria should be established for new information systems, upgrades and new versions.The following should be considered:

• Testing of information security requirements
• Testing of received components and integrated systems
• Use of code analysis tools and vulnerability scans to verify remediation of security-related defects
• Use of a test environment which ensures realistic approximation of the university environment without introducing vulnerabilities into the production environment

Related Resources

• University Policy 311 Information Security
• ISO/IEC 27002

ISO/IEC 27002 was adopted by The University of North Carolina at Charlotte in 2012. All standards and guidelines are based on this code of practice for Information Security Management.

Revision History

Initially approved by Information Assurance Committee 5/15/15
Updated 11/02/23