Secure Software Development Lifecycle Policy

2025.1

Reviewed: 9/26/2024
Updated: 9/26/2024

Purpose and Scope:

1. The purpose of this policy is to define requirements for establishing and maintaining baseline protection standards for company software, network devices, servers, and desktops.
2. This policy applies to all users performing software development, system administration, and management of these activities within IMPLAN. This typically includes employees and contractors, as well as any relevant external parties involved in these activities (hereinafter referred to as "users"). This policy must be made readily available to all users.
3. This policy also applies to enterprise-wide systems and applications developed by IMPLAN or on behalf of IMPLAN for production implementation.

Background:

1. The intent of this policy is to ensure a well-defined, secure and consistent process for managing the entire lifecycle of software and information systems, from initial requirements analysis until system decommission. The policy defines the procedure, roles, and responsibilities, for each stage of the software development lifecycle.
2. Within this policy, the software development lifecycle consists of requirements analysis, architecture and design, development, testing, deployment/implementation, operations/maintenance, and decommission. These processes may be followed in any form; in a waterfall model, it may be appropriate to follow the process linearly, while in an agile development model, the process can be repeated in an iterative fashion.

Controls and Procedures

Secure Software Development Lifecycle

1. IMPLAN's Software Development Life Cycle (SDLC) includes the following phases:
   a. Requirements Definition

   • All requirements are written and tracked in our issue tracking system
   • Requirements are prioritized based on customer value, customer impact, and effort and complexity required.
   • Customer interviews/surveys are performed as applicable to ensure customer needs are met.
   • Requirements are assigned to a sprint for implementation and testing, and sprints are bundled into Releases.
   • Releases are scheduled to bundle a set of requirements. Releases are made no less than quarterly.
   • Release dates are communicated 2 releases in advance with an earliest/latest methodology.

   b. Implementation and testing

   • Requirements are assigned to a development resource(s) for a particular sprint.
   • Release candidates are fully tested with a test sprint prior to deployment.
   • In parallel, our software test team completes the test plan for the requirements. This includes regression coverage, test case and scenario creation and validation, and functional testing.
   • Refactoring bandwidth is assigned for each release to ensure scale, security and performance.
   • All features are deployed to an internal test environment. Formal software testing as well as data quality control testing (by our economics team to ensure input and output data conforms to expected results) are performed in our test environment prior to deployment.
   • All source code must be stored and managed within a fully redundant, decentralized, and secure system, which implements detailed tracking of, but not limited to commits, pull requests, builds and deployments
   • All software is stored in a private cloud based software repository .

   c. Releases

   • Scheduled releases are deployed to our production environment during defined maintenance windows.
   • Best commercial efforts are made for all non-critical software releases to be made during maintenance windows
   • Releases are re-tested against both the formal test plan as well as for data and computational integrity by our economics team.

   d. Continuous Improvement

   • Retrospectives are performed after each sprint to identify opportunities to improve process and software quality

2. During all phases of the SDLC where a system is not in production, the system must not have live data sets that contain information identifying actual people or corporate entities. Information that would be considered sensitive must never be used outside of production environments.

3. The following activities must be completed and/or considered during the requirements definition phase:
   a. Analyze business requirements.
   b. Perform a risk assessment. More information on risk assessments is discussed in the Risk Assessment Policy.
   c. Discuss aspects of security (e.g., confidentiality, integrity, availability) and how they might apply to this requirement.
   d. Review requirements and IMPLAN's policies, standards, procedures and guidelines.
   e. Review future business goals.
   f. Review current business and information technology operations.
   g. Incorporate program management items, including:

   • Analysis of current system users/customers.
   • Understand customer-partner interface requirements (e.g., business-level, network).
   • Discuss project timeframe.

   h. Develop and prioritize security solution requirements.
   i. Assess cost and budget constraints for security solutions, including development and operations.
   j. Approve security requirements and budget.
   k. Make "buy vs. build" decisions for security services based on the information above.

4. The following must be completed/considered during the implementation and testing phases
   a. architecture and design phase:
   - Educate development teams on how to create a secure system.
   - Develop and/or refine infrastructure security architecture.
   - List technical and non-technical security controls.
   - Perform architecture walkthrough.
   - Create a system-level security design.
   - Create high-level non-technical and integrated technical security designs.
   - Perform a cost/benefit analysis for design components.
   - Document the detailed technical security design.
   - Perform a design review, which must include, at a minimum, technical reviews of application and infrastructure, as well as a review of high-level processes.
   - Describe detailed security processes and procedures, including: segregation of duties and segregation of development, testing and production environments.
   - Design initial end-user training and awareness programs.
   - Design a general security test plan.
   - Update IMPLAN's policies, standards, and procedures, if appropriate.
   - Assess and document how to mitigate residual application and infrastructure vulnerabilities.
   - Design and establish separate development and test environments.

   b. The following must be completed and/or considered during the development phase:
   - Set up a secure development environment (e.g., servers, storage).
   - Train infrastructure teams on installation and configuration of applicable software, if required.
   - Develop code for application-level security components.
   - Install, configure and integrate the test infrastructure.
   - Set up security-related vulnerability tracking processes.
   - Develop a detailed security test plan for current and future versions - i.e., regression testing).
   - Conduct unit testing and integration testing.

   c. The following must be completed and/or considered during the testing phase:
   - Perform a code and configuration review through both static and dynamic analysis of code to identify vulnerabilities.
   - Test configuration procedures.
   - Perform system tests.
   - Conduct performance and load tests with security controls enabled.
   - Perform usability testing of application security controls.
   - Conduct independent vulnerability assessments of the system, including the infrastructure and application.

5. The following must be completed and/or considered during the Release phase:
   a. Conduct pilot deployment of the infrastructure, application and other relevant components.
   b. Conduct transition between pilot and full-scale deployment.
   c. Perform integrity checking on system files to ensure authenticity.
   d. Deploy training and awareness programs to train administrative personnel and users in the system's security functions.
   e. Require participation of at least two developers in order to conduct full-scale deployment to the production environment.

6. The following must be completed and/or considered during the continuous improvement phase:
   a. Several security tasks and activities must be routinely performed to operate and administer the system, including but not limited to:

   • Administering users and access.
   • Tuning performance.
   • Performing backups according to requirements defined in the System Availability Policy
   • Performing system maintenance - i.e., testing and applying security updates and patches).
   • Conducting training and awareness.
   • Conducting periodic system vulnerability assessments.
   • Conducting annual risk assessments.
     b. Operational systems must:
   • Be reviewed to ensure that the security controls, both automated and manual, are functioning correctly and effectively.
   • Have logs that are periodically reviewed to evaluate the security of the system and validate audit controls.
   • Implement ongoing monitoring of systems and users to ensure detection of security violations and unauthorized changes.
   • Validate the effectiveness of the implemented security controls through security training as required by the Incident Response Policy.
   • Have a software application and/or hardware patching process that is performed regularly in order to eliminate software bug and security problems being introduced into IMPLAN's technology environment. Patches and updates must be applied within ninety (90) days of release to provide for adequate testing and propagation of software updates. Emergency, critical, break-fix, and zero-day vulnerability patch releases must be applied as quickly as possible.

7. The following must be completed and/or considered during the decommission phase:
   a. Conduct unit testing and integration testing on the system after component removal.
   b. Conduct operational transition for component removal/replacement.
   c. Determine data retention requirements for application software and systems data.
   d. Document the detailed technical security design.
   e. Update IMPLAN's policies, standards and procedures, if appropriate.
   f. Assess and document how to mitigate residual application and infrastructure vulnerabilities.