ISO 27001 Annex: A.14.2 Security in Development and Support Processes
The purpose of this process is to ensure that information security is created and implemented during the development of information systems.
A.14.2.1 Secure Development Policy
Organizational development should be governed by the same standards for software and systems development.
Secure development involves engineering a safe infrastructure, a secure architecture, and a secure software system. In developing a technology policy, the following factors should be considered:
1. Security of environmental development;
2. Software development security guidelines:
– Software development methodologies that are secure;
– Code security guidelines, regardless of the programming language being used;
3. Protection requirements during the design phase;
4. The security control points in the project milestones;
5. Secure data repositories;
6. Security for version control;
7. Application security knowledge is essential;
8. The ability of developers to identify, prevent, and resolve security issues.
In situations when development requirements are not established or when existing best practices do not apply, secure programming techniques can be used, as well as code replication. It should be taken into consideration to use secure coding, as well as at times mandatory coding, if applicable. Testing and code review should be verified with developers who have been trained and have their use verified.
If development is outsourced, the organization can be confident that it is compliant with these principles.
Applications such as office software, scripts, browsers, and databases can also be created.
A.14.2.2 System Change Control Procedures
Within a software lifecycle, structured change control procedures can be used to manage changes to processes.
To ensure the quality of the systems, software, and products, it is necessary to record and implement formal protocols for monitoring the transition from early design to future maintenance.
A systematic approach to organizing the planning, speculating, testing, quality assurance, and control implementation will accompany new systems as well as meaningful improvements to existing systems.
In addition to risk assessment and impact assessment, security control measures should be considered.
Furthermore, the process keeps security and control protocols within the scope of those already defined and ensures that support programmers only have access to the parts of a system that are required for their work.
It is recommended that application- and operational-change control procedures be integrated wherever possible. Changes will be approved according to the following protocols:
1. Maintain a record of the authorization levels;
2. Make sure only authorized users make changes;
3. Make sure that changes do not compromise processes and procedures of integrity;
4. Inspect software, information, database entities, and hardware to detect any modifications;
5. Identifying and testing sensitive security code so that it can minimize the risk of a security vulnerability being found;
6. Before beginning a job, the detailed proposals must be approved in writing;
7. Confirm that registered users accept changes before their implementation;
8. Upon the completion of each amendment, ensure that the documentation for the system has been updated and old documents have been archived or removed;
9. Maintain version control for all software updates;
10. Keeping an audit trail of every change request;
11. Make necessary modifications to operational documentation and user procedures, as necessary;
12. Make sure that new improvements are introduced on schedule to avoid disruptions to business operations.
Software changes may affect the operating environment and vice versa.
As part of good practice, new software should be tested both in a factory and in a development environment. This allows for the control of new software and the protection of operational information that is used for testing. It is important to include the following information in patches, service packages, and other updates
Automated updates present a risk to the integrity and availability of the system, but they are more advantageous than manual updates. The use of automated updates on critical systems is not recommended since certain updates can cause critical applications to fail.
1. What are the three main types of security?
2. What are your security control measures?
3. What does application-level security mean?
4. What testing is not relevant for application security?
5. What does ISO 27001 Annex: A.14.2 Security in Development and Support Processes do?
6. What are the steps for implementing ISO 27001 Annex: A.14.2 Security in Development and Support Processes control?