Proprietary Statement

This document was developed specifically for and by Christopher Newport University.  The concepts and methodologies contained herein are proprietary to Christopher Newport University.  Duplication, reproduction, or disclosure of information in this document without the express written consent of Christopher Newport University is prohibited.

All Trademarks, Registered Trademarks, Service Marks, and brand and product names used in this document are the property of their respective owners.

© Copyright 2023 Christopher Newport University. All rights reserved.

Review and Revision History

Table of Contents

Introduction:

Software development is the process by which CNU personnel create applications to support the university business by the collection, processing, and dissemination of data. IT Services supports software development by tailoring the ISO 12207-2008 standard with the easier-to-read and understand OWASP. CNU has tailored ISO 12207-2008 to focus on the Technical 6.4 Processes and OWASP secure coding practices.

Scope:

Custom-developed software is critical to the delivery of services to Christopher Newport’s users. This standard provides the basis for an ongoing and consistent software development and application cycle that stresses standardization to a single technology roadmap and a process to approve software development changes that do not align with the roadmap. All custom software development must conform to this standard.

Definitions:

Automated software deployment tool 

A software tool managed by IT Services that compiles and automatically delivers code to the Non-Production Development and Production environments after the approval of the Release Manager is received.

Centralized Version Control

Software version control application used by University software developers to manage code development and change review

Commits

In version control systems, a commit is an operation that sends the latest changes of the source code to the repository.

ISO 12207-2008 - Systems and software engineering — Software life cycle processes

ISO/IEC/IEEE 12207 Systems and software engineering – Software life cycle processes is an international standard for software lifecycle processes. It aims to be a primary standard defining all the processes required to develop and maintain software systems, including each process's outcomes and activities.

Non-production Development environment

A server environment that emulates the production server environment

Open Worldwide Application Security Project (OWASP)

The Open Worldwide Application Security Project (OWASP) is an online community that produces freely-available articles, methodologies, documentation, tools, and technologies in the field of web application security

Peer Review

In software development, a peer review is a type of software review in which author's colleagues examine a work product, to evaluate the work product's technical content and quality

Pull Request (PR)

A pull request – also referred to as a merge request – is an event that takes place in software development when a contributor/developer is ready to begin the process of merging new code changes with the main project repository. A peer review will approve a pull request.

Release Day

The standardized day and time that software is released to minimize chances of disruption

Release Manager

The release manager is responsible for the release management lifecycle, focusing on coordinating various aspects of production and projects into one integrated solution.

Request for Change (RFC)

A formal part of the Change Management process in which a change is presented to the Change Control Board for review and questioning.

Software Development Lifecycle (SDLC)

The Software Development Life Cycle (SDLC), is a process that produces software with the highest quality and lowest cost in the shortest time possible. SDLC provides a well-structured flow of phases that help an organization quickly produce high-quality software which is well-tested and ready for production use.

Software Development Task Management

Jira is the Software development task management application used by University software developers for software development. Tasks are created as cards or issues and are worked through a Kanban-style board from idea to deployment.

User Acceptance Testing (UAT)

User acceptance testing, also called end-user, user acceptability testing, or beta testing, is the process of testing software by the clients or users to see if the product is acceptable for release or not.

Roles and Responsibilities:

Software Development Management and Roadmap is a management responsibility. This section describes the key roles of the personnel who support and participate in the risk management process.

Software Development Technology Roadmap:

The University supports and actively develops custom applications written to use the .Net Framework, designed to be run on a Microsoft IIS web server, utilizing an Oracle database.

All previously existing software not written in the .Net Framework will continue to be supported until such time as it is either retired or requires major revisions.

Applications that do not conform to this roadmap will be reworked to comply with the roadmap or must have the exception with justification recorded with the University Software Development Workgroup.

Note: This roadmap should not be considered to cover commercial software modifications such as modifications of Banner that require specific programming languages.

Processes:

Application Deployment

All applications conforming to the security practices documented in this standard should be compiled into libraries or binaries when possible. Applications must be deployed without interactive authentication to non-production and production environments using University’s automated software deployment tools.

Code Management

All code is stored in centralized version control. 

Code Documentation

All application documentation is stored in the IT Services knowledge base.

Code Documentation Guidance

Comments in code

• Preambles (comment code blocks) are not required unless meaning and context cannot be derived from the underlying code statements.
• Comments are not source control. 
• Software Development Task Management tools and version control indicate who the code’s author is
• Comments shall be clear and concise, explaining a non-obvious solution for future developers.

Application Documentation

Documentation for an application shall include

• Points of contact for the application, specifically, the application sponsor and their backup, who make decisions regarding the application.
• Meeting notes with the application sponsor
• Critical use periods for the application
• The ways in which the application shall be used, notes on data flow, and notes on user interface flow
• Notes on any troubleshooting shortcuts or places to start troubleshooting
• Any non-application processes that are necessary for the application to function properly

Code Version Control Branching

• Generally, Software Developers must not create “deep branches.” 
• Example: There should not be a feature branch that is then branched off to create individual components for each feature part. If necessary, the University Software Development Workgroup should be consulted before creating this branching pattern.
• Software Developers shall use a task-per-branch strategy. A card and sub-cards can create a "feature" release, but it is all part of one task managed as part of the branch.
• The master branch is what is in production.
• Any changes are made in a branch (type is unimportant).
• When merging a web designer branch with the software developer branch, the software developer will handle conflicts, conferring with the web designer to resolve any conflicts.
• When merging to master, the developer will first merge master into the branch and then merge the branch into master. 
• This will ensure the developer handles merge conflicts, not the release manager.

Peer Reviews

When coding is complete or near-complete, the primary software developer for the current task shall use the version control system to generate a pull request for the code being developed and include two developers for peer review.

Peer Review Guidance

• When generating a pull request, the description field shall describe the changes in plain English, the expected users of the fix, and their roles. This will help with testing.
• Commit comments are important and shall describe for whom, what, and why.
• Participants shall be professional, open-minded, and willing to discuss issues straightforwardly. In the event that the peer review does not end in consensus, The University Software Development Workgroup can decide which suggestions will be implemented.
• Peer review comments shall be used liberally (e.g., if a discussion happens face-to-face about a particular issue, there shall be a comment notating the discussion to capture that information for future development efforts).
• Peer review shall be completed within three working days of the pull request unless extenuating circumstances exist. Those should be discussed with the developer’s immediate supervisor.
• The following review comments must be resolved before proceeding with the deployment of software:
• Blocker - Such an error prevents further functional testing, compatibility testing, load testing, or other testing works.
• Critical - An error of this type is connected with security, leading to a program crash, data loss, or other serious damage (e.g., all ID numbers must display all digits, including leading zeros, and issues related to spelling and grammar fall into this category).
• Major - This is often an error in the program's main functionality.
• Moderate - This is often programming inefficiencies (e.g., code reuse or refactoring opportunities).
• The following review comments may be discussed before proceeding with the software deployment:
• Minor - This may be an insignificant problem in the program's functioning (e.g., currency formatting to numbers in a generated report).
• Cosmetic - Errors of this type have little impact on the program's functioning (e.g., the wrong size of a button or too bright color of an object). Cosmetic issues are ones of style and taste. Note: Cosmetic issues are not accessibility issues and shall not be conflated. Applications must be accessible but may not be cosmetically appealing, although the goal is to achieve both. 
• Other - Programming style differences not previously specified fall into this category.

Software Change Management Process

Software changes must follow the University Change Management policy before deployment to production and are managed via the Software Change Management Process.

New applications and those that undergo significant rewrites must be approved before deployment by the normal University Change Management process.

Software Development Task Management

All application development tasks are managed in IT Service’s software development task management application. Software developers create the tasks in the software development task management application.

Coding standards:

Application development must conform to the following standards to provide the most secure, concise, and clean applications for the University’s use.

Accessibility

All custom-developed applications must conform to the Accessibility of Information and Communication Technology Policy (1060). Specifically, custom-developed applications must meet or exceed Web Content Accessibility Guidelines 2.1 (WCAG 2.0), Level A and AA.

Authentication

All applications that allow the display or querying of data collected by the application or as the result of another application must have an authentication mechanism that shall conform to standard University authentication mechanisms to include the use of Single Sign-On and Multi-factor Authentication (2FA or MFA). Applications that use authentication mechanisms and retrieve data University-stored about a user for population into another application should do so. Any variation from this standard must be documented and justified to the University Software Development Workgroup. The ISO, CIO, and Executive Steering Committee for IT must accept the risk.

Coding Conventions

Coding conventions serve the following purposes:

• They create a consistent look to the code and allow readers can focus on content, not layout.
• They enable readers to understand the code more quickly by making assumptions based on previous experience.
• They facilitate copying, changing, and maintaining the code.
• They demonstrate C# best practices.

All custom-developed applications must conform to the Coding Conventions laid out by Microsoft. 

Database Schema and Database Object Modification

Procedure:

• From the software projects card, create a branch in the appropriate repository
• The software developer will pull down the development branch
• In the development branch folder on the developer’s computer, create or open the folder for the appropriate schema (e.g., HRIS)
• In the schema folder, create or open the folder for the type of database object the developer is making, i.e., packages, stored procedures, functions, etc.
• In the database object folder, the developer shall create a SQL script that will make the modification necessary. 
• The script must be fully qualified! 
• Example: CREATE OR REPLACE PACKAGE "PAIDEIA"."PKG_PAID" AS … 
• This should be a .sql file.
• Conduct testing of the scripts in non-production environments.
• When the developer has sufficiently tested, committed, and pushed changes to the version control system.
• Create a pull request. 
• SQL used to create new databases and tables for new applications or significantly modify application database requirements follows the same peer-review process as application code and will be put into production by the DBA team after it has been approved and merged.
• Once approved in the peer review, the developer submits the database code via the Script Submission process in the Software Development Task Management application.

Security Philosophy

Security is fundamental to quality software development. Security is everyone’s job in the Software Development Lifecycle. Software development should follow the following Design Principles (as adapted from the OWASP):

Defense in Depth

Also known as layered defense, defense in depth is a security principle where single points of complete compromise are eliminated or mitigated by the incorporation of a series or multiple layers of security safeguards and risk-mitigation countermeasures.

Have diverse defensive strategies so that if one layer of defense turns out inadequate, another layer will hopefully prevent a full breach.

Fail Safe

A security principle that aims to maintain confidentiality, integrity, and availability by defaulting to a secure state, rapidly recovering software resiliency upon design or implementation failure. In software security, fail secure is commonly used interchangeably with fail safe, which comes from physical security terminology.

Unless a subject is given explicit access to an object, it shall be denied access to that object, aka Fail-Safe Defaults.

Least Privilege

A security principle in which a person or process is given only the minimum level of access rights (privileges) necessary for that person or process to complete an assigned operation. This right must be given only for a minimum amount of time necessary to complete the operation.

Limits the damage in case of exploited vulnerability.

The proper granularity of privileges and permissions should be established to apply this principle.

Separation of Duties

Also known as the compartmentalization principle or separation of privilege, separation of duties is a security principle that states that the successful completion of a single task depends upon two or more conditions that are insufficient for completing the task by itself.

The Economy of Mechanism

In layman's terms, this is the Keep It Simple, Stupid principle because the likelihood of a greater number of vulnerabilities increases with the software's architectural design and code complexity.

By keeping the software design and implementation details simple, the attack-ability or attack surface of the software is reduced.

Complete Mediation

A security principle that ensures that authority is not circumvented in subsequent requests of an object by a subject by checking for authorization (rights and privileges) upon every request for the object.

In other words, the access requests by a subject for an object are completely mediated every time.

“All accesses to objects must be checked to ensure that they are allowed.”

Performance v/s Security issue:

• Results of access checks are often cached
• What if permissions have changed since the last check?
• Mechanisms to invalidate or flush caches after a change are often missing

Open Design

The open design security principle states that the implementation details of the design should be independent of the design itself, which can remain open, unlike in the case of security by obscurity wherein the security of the software is dependent upon the obscuring of the design itself.

When software is architected using the open design concept, the review of the design itself will not result in the compromise of the safeguards in the software.

“The security of a mechanism should not depend on the secrecy of its design or implementation.”

If the details of the mechanism leak, it is a catastrophic failure for all users.

If the secrets are abstracted from the mechanism, e.g., inside a key, then leakage of a key affects only one user.

Least Common Mechanism

The security principle of least common mechanisms disallows the sharing of mechanisms that are common to more than one user or process if the users and processes are at different levels of privilege. For example, the use of the same function to retrieve the bonus amount of an exempt employee and a non-exempt employee will not be allowed. In this case, the calculation of the bonus is the common mechanism.

According to Saltzer and Schroeder [Saltzer 75] in "Basic Principles of Information Protection" from pages 9-10:

Least common mechanism: Minimize the amount of mechanism common to more than one user and depended on by all users.1 Every shared mechanism (especially one involving shared variables) represents a potential information path between users and must be designed with great care to be sure it does not unintentionally compromise security. Further, any mechanism serving all users must be certified to the satisfaction of every user, a job presumably harder than satisfying only one or a few users. For example, given the choice of implementing a new function as a supervisor procedure shared by all users or as a library procedure that can be handled as though it were the user's own, choose the latter course. Then, if one or a few users are not satisfied with the level of certification of the function, they can provide a substitute or not use it at all. Either way, they can avoid being harmed by a mistake in it.

Psychological acceptability

A security principle that aims at maximizing the usage and adoption of the security functionality in the software by ensuring that the security functionality is easy to use and, at the same time, transparent to the user. Ease of use and transparency are essential for this security principle's effectiveness.

Security mechanisms should not make the resource more difficult to access than if the security mechanism were not present.

Problem: Users look for ways to defeat the mechanisms and “prop the doors open.”

Weakest Link

This security principle states that the resiliency of your software against hacker attempts will depend heavily on protecting its weakest components, be it the code, service, or interface.

Leveraging Existing Components

This security principle ensures that the attack surface is not increased and no new vulnerabilities are introduced by promoting the reuse of existing software components, code, and functionality.

Secure Code Testing

As part of each peer review, reviewing developers should test the changes and overall application using the OWASP Secure Coding Practices.

References:

• Accessibility of Information and Communication Technology Policy (1060)
• Web Content Accessibility Guidelines 2.1 (WCAG 2.0), Level A and AA
• OWASP Secure Coding Practices
• C# Coding Conventions
• Software Change Management Process
• University Change Management policy
• ISO 12207-2008 - Systems and software engineering

Review:

This Software Development Standard/Roadmap will be reviewed annually by the University Software Development Workgroup and Chief Information Officer.