Developing and Releasing Secure Software with ISO 27001 Controls A.8.28–A.8.31

A.8.28 Secure coding

This control aims to ensure that any software written is written securely to reduce the potential information security vulnerabilities in the software.

Along with the secure coding principles which have been developed in A.8.27 which was covered here, you should also enhance this to include secure coding practises with your development team.

The secure coding practises should include activities before coding, such as enforcing agreed secure coding standards from A.8.27, configuring any IDEs to help enforce creation of secure code, maintenance and update of development tools, controlled environments.

These can be implemented by, at times, planning for updating of development tools used, configuring any IDEs to automatically scan for adherence to rules, or by implementing automated testing and checking before code can be committed to the repository.

While performing coding, things that can be considered are implementing secure programming techniques including pair programming, refactoring, peer reviews and test-driven development.

Things like peer reviews and test-driven development can be incorporated with automatic tools to ensure that a peer review needs to be completed, with any issues addressed before the code can be merged into the main repository branch. Similarly, automated tests, both functional and security-based tests can be run and required to pass before functionality is compiled into the main repository branch.

Once the code has been added to the main repository, measures should be taken to ensure deployment updates are securely packages and deployed. Both the source code and deployment packages should be protected against unauthorised access and tampering

Checks should be performed on any external libraries used or incorporated into the source code to ensure they do not introduce any security vulnerabilities. They should also be managed to incorporate any updates into the release cycle. Particular attention should be paid to cryptographic and authentication components.

Any errors or security vulnerabilities should be logged and handled and incorporated into the technical vulnerability management process outlined in A.8.8, covered in this post.

In the same was as is done for control A.8.27, this should be applied to cover any software components from third parties or open-source software which is incorporated into your code base.

A.8.29 Security testing in development and acceptance

This control aims to validate if information security requirements are met when applications or code are deployed to the production environment.

As we continue along the controls aimed at securing software development lifecycle, we get to the most important, or at least the control where a failure of any other controls in the process so far can be identified, and then rectified before the software is deployed into the production environment.

As well as functional testing, security testing should be performed during the development process. This can be assisted by the inclusion of security requirements as part of the requirements gathering process, so that the functionality can be tested against them.

Additional testing should be performed against new versions or upgrades within a separate testing environment which should resemble the production environment as closely as reasonably possible. This will enable you to test for secure configurations and security components, security functions such as authentication, access restrictions and cryptography.

Before performing testing, test plans should be created using criteria which can be derived from the original requirements of the functionality to evaluate it. When executing the test plans, a detailed schedule should be created and results, decisions on further actions (including any re-work or approval of the test outcomes) should be documented.

Automated tools can be leveraged, including code analysis tools or vulnerability scanners which can be embedded within the CI/CD pipeline.

A.8.30 Outsourced development

This control is in place to ensure information security measures required by the organisation are implemented in outsourced system development, and that any functionality built by outsourced development teams is not at an increased risk of introducing vulnerabilities or security issues.

Outsourcing of development can lead to vulnerabilities being introduced due to many reasons including misunderstanding of requirements, differences in security expectations, and developer skills and experiences.

When deciding to outsource development, you should be careful to ensure that agreements and contracts are in place and cover intellectual property rights to the outsources content, including code ownership and licensing agreements. The scope of the works should be included, including design, coding and testing practices, and who is responsible for them. As part of this, acceptable levels of functionality, including security features should be agreed, as should any responsibility for the implementation of any bugs.

When engaging with an external supplier, care should be taken to communicate and agree to requirements and expectations and continually monitor and review the progress and delivery to ensure that your expectations are being met.

A.8.31 Separation of development, test and production environments

The main focus of this control is to protect the production environment and data from compromise by development and test activities.

As part of your testing process, and testing environment set up, environments are set up to be as close to the production environment as is required to ensure the functionality can be adequately tested and any production problems or issues replicated so they can be addressed.

When determining the requirements for setting up test environments, the following items should be considered

• Separating the environments from each other – gaining access to a test environment should not give you access to any production environments
• Defining, and implementing documented rules and authorisation for the deployment of software to the production environment.
• Displaying environment identification appropriately. This is important… I’m sure that every developer or support person has a story about using the wrong environment. This is mostly caused by different environments not being clearly labelled. Changing the colour is a good way of distinguishing test environments. Having a bright pink test environment is a good way to quickly see you are not using the production environment!
• Ensuring any tools or utilities used for development do not have access to and are not accessible from the production environment when they don’t need to be.
• Ensuring that production data and sensitive information is not copied to development or testing environments. Using anonymisation scripts or other tools when restoring and production data or configurations into testing environments should be done. No matter how much the business users may want to see real data on new screenshots, this should not be done.

All environments, including development, and all testing environments should only be accessible by those who need access to them by controlling access. This includes controlling the access to manage them.

When setting up the processes to deploy code to production, care should be taken to ensure that testing has been carried out, and that no single person, (or automated identity) can make changes to both development and production environments without the need for review and approval.