Policy Owner: Principal Engineer

Effective Date: 2023-05-01

Purpose

To ensure that information security is designed and implemented within the software engineering process for applications and information systems.

Scope

All CloudCard applications and information systems that are business critical and/or process, store, or transmit Confidential data. This policy applies to all internal and external engineers and developers of CloudCard software and infrastructure.

Policy

This policy describes the rules for the acquisition and development of software and systems that shall be applied to software engineering activities within the CloudCard organization.

System Change Control Procedures

Changes to systems within the engineering process shall be controlled by the use of formal change control procedures. Change control procedures and requirements are described in the CloudCard Operations Security Policy.

Significant code changes must be reviewed and approved by at least one other member of the engineering team before being merged into any production branch.

Change control procedures shall ensure that development, testing and deployment of changes shall not be performed by a single individual without approval and oversight.

Software Version Control

All CloudCard software is version controlled and synced between contributors (developers). Access to the central repository is restricted based on an employee’s role. All code is written, tested, and saved in a local repository before being synced to the origin repository.

Technical Review of Applications after Operating Platform Changes

When operating platforms are changed, business critical applications shall be reviewed and tested to ensure that there is no adverse impact on organizational operations or security.

Secure System Engineering Principles

Principles for engineering secure systems shall be established, documented, maintained and applied to any information system implementation efforts.

At a minimum, the following secure-by-design and privacy-by-design principles shall be applied:

Secure-by-design principles:

1. Minimize attack surface area

2. Establish secure defaults

3. The principle of Least privilege

4. The principle of defense in depth

5. Fail securely

6. Don’t trust services

7. Separation of duties

8. Avoid security by obscurity

9. Keep security simple

10. Fix security issues correctly

Privacy-by-design principles:

1. Proactive not Reactive; Preventative not Remedial

2. Privacy as the Default Setting

3. Privacy Embedded into Design

4. Full Functionality – Positive-Sum, not Zero-Sum

5. End-to-End Security – Full Lifecycle Protection

6. Visibility and Transparency – Keep it Open

7. Respect for User Privacy – Keep it User-Centric

Software developers are expected to adhere to CloudCard’s coding standards throughout the engineering process, including standards for quality, testing, and security.

Software and web applications are required to meet the OWASP Secure Coding Guidelines (2010) or their equivalent.

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 possible version in order to ensure that all known vulnerabilities with available patches will be addressed.

Dynamic Inclusion of Software: CloudCard software should not dynamically include other software from other sources at runtime, such as a web application that causes the user’s web browser to fetch JavaScript from a third-party over which CloudCard has no control. If external code is required by a browser application, it should be reviewed by CloudCard and copied into a CloudCard controlled location from which the web browser can fetch the code.

Developers should also consider the following sections of NIST SP 800-53 Revision 5:

• SA-03 System Development Life Cycle

• SA-08 Security Engineering Principles

• SI-11 Error Handling

Engineering documentation and technical references can be found in the CloudCard Docs.

Secure Development Environment

CloudCard shall establish and appropriately protect environments for system development and integration efforts that cover the entire system development life cycle. The following environments shall be logically or physically segregated:

• Production

  • Contains applications ready and approved for use by customers and storage of customer data.

  • Changes are controlled and subject to prior approval and testing.

  • Access is restricted to users who have fulfilled the requirements of access to customer data and have a business need.

• Test

  • Contains applications not fully approved for use by customers or storage of customer data.

    • Available for customers to perform validation or acceptance tests.

    • Must not contain customer data, except data provided by customers for the purpose of validating functionality

  • Changes are coordinated to ensure no conflicts between team members in use of the environment.

  • Segmented from production and does not access or share production resources.

• Local Development

  • Segmented from production and does not access or share production resources.

  • Contains applications under active modification. Typically operated on a developer’s desktop or laptop.

  • Must not contain customer data.

Outsourced Development

CloudCard shall supervise and monitor the activity of outsourced system development. Outsourced development shall adhere to all CloudCard standards and policies.

System Security Testing

Testing of security functionality shall be performed at defined periods during the engineering process. No code shall be deployed to CloudCard production systems without documented, successful test results and evidence of security remediation activities.

Application Vulnerability Management

Application code should be scanned prior to deployment. Patches to address application vulnerabilities that materially impact security should be deployed within 90 days of discovery.

System Acceptance Testing

Acceptance testing programs and related criteria shall be established for new information systems, upgrades and new versions.

Prior to deploying code, a Release Checklist MUST be completed which includes a checklist of all Test Plans which show the completion of all associated tests and remediation of identified issues.

Protection of Customer Data

Test data shall be selected carefully, protected and controlled. Confidential customer data shall be protected in accordance with all contracts and commitments. Customer data shall not be used for testing purposes without the explicit permission of the data owner and the Managing Director.

Developer Training

Software developers shall be provided with secure development training appropriate to their role at least annually. Training content shall be determined by management but shall address the prevention of common web application attacks and vulnerabilities. The following threats and vulnerabilities should be addressed as appropriate:

• prevention of authorization bypass attacks

• prevention of the use of insecure session IDs

• prevention of Injection attacks

• prevention of cross-site scripting attacks

• prevention of cross-site request forgery attacks

• prevention of the use of vulnerable libraries

Exceptions

Requests for an exception to this Policy must be submitted to the Principal Engineer for approval.

Violations & Enforcement

Any known violations of this policy should be reported to the Principal Engineer. Violations of this policy can result in immediate withdrawal or suspension of system and network privileges and/or disciplinary action in accordance with company procedures up to and including termination of employment.