Application Development Policy - Vulnerability Management

Application Development

Separation of Test/Production Environments – Appropriate requirements and controls must be in place requiring the physical separation of the development, test and production environments including, but not limited to, the following:

  • Production, test, and development environments are physically separated.

  • Test environments emulate the production environment as closely as possible, including the use of a common operating system, database, web application server, and similar hardware to the degree possible.

  • Only authorized release managers and system administrators have access to the production environment where the production executable code for an application resides. Application developers may have read-only access to production log and configuration files as deemed necessary.

Outsourced Development – Appropriate requirements and controls must be place in to address outsourced development including, but not limited to, the following:

  • All outsourced development must be reviewed and approved by appropriate iCompaas personnel.

  • All contracts for outsourced development must include:

  • Provisions to ensure secure coding guidelines are used.

  • Defined licensing arrangements, code ownership and intellectual property rights.

  • Service level agreements including quality assurance and control of delivered software.

  • Software escrow arrangements (if needed).

  • The ‘Right to audit’ outsourcer’s processes, infrastructure, development methodologies, security or any other control area deemed necessary by iCompaas Management.

  • Specification of acceptance requirements (including security testing and evaluation).

Secure Coding

Secure Coding – Appropriate requirements and controls must be in place to secure and protect application source code including, but not limited to, the following:

  • Directories or repositories containing application source code are secured from unauthorized access.

  • Source code is not stored on production systems when possible.

  • All changes to code are logged in a central version control solution and to the extent possible, should also log all access to source code files.

  • Access and modification access is properly assigned.

Secure Coding Standards – Developers must be trained in secure coding techniques based on best practice guidelines (i.e. OWASP guide). A secure coding standard must be utilized as part of the software development methodology. All web-based applications must be developed based on a current version of the OWASP secure code guidelines, and must account for the following:

  • Cross-site scripting (XSS) (validate all parameters before inclusion).

  • Injection flaws, particularly SQL injection (validate input to verify user data cannot modify meaning of commands and queries).

  • Malicious file execution (validate input to verify application does not accept file names or files from users).

  • Insecure direct object references (do not expose internal object references to users).

  • Cross-site request forgery (CSRF).

  • Information leakage and improper error handling (do not leak information via error messages or other means).

  • Broken authentication and session management (properly authenticate users and protect account credentials and session tokens).

  • Insecure cryptographic storage (prevent cryptographic flaws).

  • Insecure communications (properly encrypt all authenticated and sensitive communications).

  • Failure to restrict URL access (consistency enforced access control in the presentation layer and business logic for all URL’s).

Data Assurance

Data Validation – Data being entered into iCompaas’s application systems must be validated where possible to ensure information quality and mitigate the impacts of web-based attacks on the systems.

Data Checks – Data checks within information systems and applications to validate business transactions, standing/master data, or parameter tables should be implemented. Dual input checks such as boundary checking, or limiting fields to specific ranges of input data, must be used on critical inputs for systems when applicable. Checks may include:

  • Out-of-range validation checks.

  • Invalid characters in the field.

  • Mandatory field definition.

Data Security

Security of System Files – Operational systems must be securely configured prior to deployment in a production environment to ensure the security of the files contained within and all operational software must be an authorized version supported by the vendor, where applicable, and configured securely. iCompaas IT personnel must ensure that:

  • Operational systems only hold/store approved programs or executable code (i.e. no development code or compilers).

  • Vendor supplied software is maintained at a level supported by the vendor.

  • An audit log of all updates to programs must be maintained and a library of previous source code versions retained.

  • Archive old versions of software along with configurations, parameters, procedures, and other supporting documentation as deemed appropriate.

  • Updates to operational software, applications, and program libraries are performed by designated, trained personnel.

  • All vendor-supplied default passwords are changed prior to the system being placed in a production environment.

  • System default settings are reviewed prior to installation to determine potential security holes and settings that could potentially compromise security must be changed prior to the system being placed into a production environment.

Protection of Live Data in Test Environments – All data classified as private or higher used in any non-production environment must be altered, obfuscated, or otherwise de-identified. Any unaltered production data used for test purposes in nonproduction environments is prohibited.

Three Tier Development Environment

Development – Developers will have full control over this environment. It is not considered to be a “stable” code platform as active development is occurring within the logical instance. Once enhancements have been unit tested and certified for quality assurance, they will be moved to a stable testing environment.

  • Software development staff will not be permitted to have access to production systems and related data unless they are triaging a production outage.

  • Development systems must not contain sensitive or confidential information and will be populated with test or dummy data.

  • Access to program source code shall be restricted to authorized personnel and managed using enterprise configuration management and versioning software.

Test - Quality assurance and user acceptance test personnel operate in this environment to test enhancements and bug fixes scheduled for release into production. The environment is continually refreshed with test data and new functionality until such point the release is deemed stable and ready for promotion into production.

  • Configuration testing is completed prior to promoting to quality assurance testing.

  • Quality assurance testing is completed, documented, and approved prior to scheduling production migration.

  • Test User IDs and passwords must be removed.

  • Confidential and personal data is not utilized in development and testing environments unless prior authorization is provided. Authorization requires a user provisioning process that assesses confidentiality requirements.

Production - The production environment is subject to stringent change management processes and procedures to limit risk and functional downtime to systems.

  • Changes are approved prior to migration to the production environment.

  • Access to deploy change to production is restricted to authorized system administrators.