
History Log | ||
Version | Date | Author |
1.0 | 1stNovember 2017 | Information Dynamics |
1.1 | 26th January 2019 | Shibin |
1.2 | 29th December 2019 | Shibin |
1.3 | 24th December 2020 | Shibin |
1.4 | 24th December 2021 | Shibin |
1.5 | 24th December 2022 | Shibin |
Scope
The scope will be applicable to all activities under the scope statement of Information Dynamics.
This document represents Information Dynamics Software Development Policy. This standard must be referred to by the in house application development teams or the external service providers while development or integration of the application for the Information Dynamics.
ISO 27001:2013 Domain Reference: A.14 – System Acquisition Development and Maintenance
ISO 27001:2013 Reference | |
A.14.1.1 | Information security requirements analysis and specification |
A.14.1.2 | Securing application services on public networks |
A.14.2.1 | Secure development policy |
A.14.2.2 | System change control procedures |
A.14.2.3 | Technical review of applications after operating platform changes |
A.14.2.4 | Restrictions on changes to software packages |
A.14.2.5 | Secure system engineering principles |
A.14.2.6 | Secure Development Environment |
A.14.2.8 | System Security Testing |
A.14.2.9 | System Acceptance Testing |
General Guidelines
The ISO 12207 standard must be referred by the in house application development teams or the external service providers while development or integration of the application for the Information Dynamics.
The development and operational environments should be different physical environments, configured and located. Testing takes place in the development environment itself. The test environment simulates the operational environment with exception that live credit card data is not used.
All development tools should be only accessible within the development environment. Operational software is only transferred from the test environment to the operational environment after completion of the system testing.
Test data and accounts like custom application accounts, usernames and/or passwords should be removed before a production system becomes active.
All the changes (including security patches, system and software configuration changes) to the applications must undergo testing by developers and UAT before deployed into production.
Code reviews should be performed for new codes and after every change and should be reviewed by the independent internal team knowledgeable in source coding (other than the programming team) before release to production systems after management approval. This is applicable for internal as well as web applications.
Operational databases containing personal information should not be used for testing of operational software.
Test data should be generated internally by the developers as per the business requirements.
Change control document must be used for every change in all the applications and must document following into it:
Customer impact
Management sign-off
Operational functionality testing
Back-out procedures
The developers must follow the Application Security Standard document while developing/modifying the applications.
Any change to the source code is prohibited without the prior approval of the Information Owner and the Application Owner.
Changes must be implemented based on the related SDLC procedure that outlines the steps and necessary approvals to be obtained.
Source code changes are to be reviewed in accordance with the secure coding practices (e.g. OWASP input validation, and other secure coding methodologies as per business requirements) and by the knowledgeable code reviewers other than the author of the code.
Along with the OWASP Top 10 or SANS TOP 25; the vulnerabilities ranked as HIGH as per the RISK RANKING should also be included in the Test Cases.
All the changes to the source code are to be tested in the test environment for any corrections before it is released to the production environment.
All changes being made to the production environment must have management
approval.
NA