IT Security Policy 111 - Software Development

Status: Draft
Last Revision Date: 21 February 2023

Statement of Purpose

Software applications can be vulnerable to attack based on the way they are coded. Certain design patterns introduce cyber risks, whereas established best practices—known as "secure coding techniques"—help reduce vulnerabilities in code.

This policy seeks to minimize code vulnerabilities in the development work performed by Clackamas Community College ITS staff.

Definitions

For the purposes of this policy, the following definitions apply:

  • System Automation Utilities: Batch files, PowerShell scripts, and equivalents for Linux, Unix, and macOS, typically used for automating routine administrative tasks.

  • Program: Code that requires compilation before use.

  • Script: Code that is compiled at runtime.

Policy Summary

Software developed and deployed within Clackamas Community College Information Technology Services (ITS) resources shall adhere to industry best practices for secure development.

Policy

Separation of Environments

  1. Clackamas Community College shall maintain Development (DEV) and/or Test environments separate from the Production (PROD) environment and primary enterprise systems.

  2. If connectivity to the PROD network exists, access controls shall enforce separation.

  3. Code promotion to the PROD environment shall be executed by a designated agent in accordance with Change Management policies and standards.

System Development Lifecycle (SDLC)

  1. Internal and third-party software development and deployment shall follow industry-recognized SDLC best practices.

  2. Applications handling confidential data must incorporate security controls throughout the development lifecycle, particularly when updating databases.

System Development Lifecycle Standards

  1. Requirements Analysis – Developers shall assess application requirements for inherent security risks.

  2. Design – Application components shall be designed to align with data and network security best practices.

  3. Development – Developers shall mitigate application vulnerabilities (e.g., memory-bound issues, privilege escalation, and access bypass).

  4. Code Review – A second developer shall review all new and modified code to identify security vulnerabilities.

  5. Quality Assurance (QA) Implementation – Implementation shall not compromise existing security controls or introduce new vulnerabilities.

  6. QA Testing – Security features shall be tested alongside functionality and efficiency.

  7. Documentation – Application documentation shall include instructions for proper security configurations.

  8. Production Implementation – Security controls shall not be compromised during implementation.

  9. Production Testing – Security features shall be tested in the production environment.

  10. Maintenance – Ongoing maintenance must preserve existing security controls. All new code shall undergo review and testing as specified above.

Software Development and Code Review

  1. Software applications shall integrate security best practices throughout their development lifecycle.

  2. Custom software and web code shall adhere to Clackamas Community College policies and security standards.

  3. Code that modifies data must undergo review before deployment to production.

  4. A separation of duties shall ensure developers do not test their own applications, and testers do not deploy changes to production.

  5. Code reviews shall be conducted by qualified staff other than the originating developer. All new and modified code requires review.

  6. Web development and deployment shall follow the latest Open Web Application Security Project (OWASP) guidelines.

  7. The following vulnerabilities shall be assessed during code review and testing:

    • Cross-site scripting (XSS)

    • Injection flaws (SQL, LDAP, XPath, etc.)

    • Malicious file execution

    • Insecure direct object references

    • Cross-site request forgery (CSRF)

    • Information leakage and improper error handling

    • Broken authentication and session management

    • Insecure cryptographic storage

    • Insecure communications

    • Failure to restrict URL access

  8. Iterative Development and Software Updates

    • Maintain an inventory of all custom software solutions currently in production.

    • Schedule regular scans and updates for frameworks or libraries to mitigate vulnerabilities in third-party code.

System Automation Utilities

  1. A system automation utility shall be exempt from this policy unless it meets one or more of the following criteria:

    • Accepts input from a public-facing source.

    • Resides in publicly accessible directories on a web server.

    • Runs under a security context with permissions exceeding those of the executing user (excluding pseudo accounts).

    • Functions as a component of a script or program.

  2. System automation utilities shall not store credentials in plain text.

  3. Automation utilities designed for bulk modification or deletion shall undergo peer review and testing before use.

Exemptions

None.

Exceptions

Exceptions to this policy require prior written approval from the Chief Information Officer (CIO).

 

Print Article