ISO 27001:2022 A 8.31 Separation of development, test and production environments

Audio version of this article

Separation of development, test and production environments are important to achieve segregation of functions involved. It is appropriate that the rules for the development to transfer to a production environments are well defined and documented.Failure to properly segregate development, test, and production environments may result in loss of availability, confidentiality, and integrity of information assets. Production computing environments shall be either logically or physically separate from development and test environments. Developer access to production environments shall be prohibited or limited to troubleshooting and all activity recorded and monitored. Logon procedures and passwords shall be different for production and development/test environments. Procedures shall exist for transferring software or hardware from development and test to production. Where physical separation for development/test is not feasible, security measures shall be equal to or higher than that required for the production environment. Therefore, organisations should implement appropriate procedures and controls to securely segregate development, test, and production environments to eliminate security risk. When developing and testing staff have access to the production environment, they can introduce untested or unauthorized code, or even change the actual data of the system. In some systems, this capability can be hardly used to implement fraud or introduction of malicious code or not tested. This type of code can cause serious operational problems. The development of staff and in charge of the tests also pose a threat to confidentiality of production information. The development and testing activities may cause unintended changes to software and information if they share the same computing environment. The separation of resource development, test and operational is this very desirable way to reduce the risk of accidental modification or unauthorized access to operational software and business data.

Control

Development, testing and production environments should be separated and secured.

Purpose

To protect the production environment and data from compromise by development and test activities.

ISO 27002 Implementation Guidance

The level of separation between production, testing and development environments that is necessary to prevent production problems should be identified and implemented. The following items should be considered:
a) adequately separating development and production systems and operating them in different domains (e.g. in separate virtual or physical environments);
b) defining, documenting and implementing rules and authorization for the deployment of software from development to production status;
c) testing changes to production systems and applications in a testing or staging environment prior to being applied to production systems;
d) not testing in production environments except in circumstances that have been defined and approved;
e) compilers, editors and other development tools or utility programs not being accessible from production systems when not required;
f) displaying appropriate environment identification labels in menus to reduce the risk of error;
g) not copying sensitive information into the development and testing system environments unless equivalent controls are provided for the development and testing systems.

In all cases, development and testing environments should be protected considering:
a) patching and updating of all the development, integration and testing tools (including builders, integrators, compilers, configuration systems and libraries);
b) secure configuration of systems and software;
c) control of access to the environments;
d) monitoring of change to the environment and code stored therein;
e) secure monitoring of the environments;
f) taking backups of the environments.
A single person should not have the ability to make changes to both development and production without prior review and approval. This can be achieved for example through segregation of access rights or through rules that are monitored. In exceptional situations, additional measures such as detailed logging and real-time monitoring should be implemented in order to detect and act on unauthorized changes.

Other information

Without adequate measures and procedures, developers and testers having access to production systems can introduce significant risks (e.g. unwanted modification of files or system environment, system failure, running unauthorized and untested code in production systems, disclosure of confidential data, data integrity and availability issues). There is a need to maintain a known and stable environment in which to perform meaningful testing and to prevent inappropriate developer access to the production environment. Measures and procedures include carefully designed roles in conjunction with implementing segregation of duty requirements and having adequate monitoring processes in place. Development and testing personnel also pose a threat to the confidentiality of production information. Development and testing activities can cause unintended changes to software or information if they share the same computing environment. Separating development, testing and production environments is therefore desirable to reduce the risk of accidental change or unauthorized access to production software and business data. In some cases, the distinction between development, test and production environments can be deliberately blurred and testing can be carried out in a development environment or through controlled roll outs to live users or servers (e.g. small population of pilot users). In some cases, product testing can occur through live use of the product inside the organization. Furthermore, to reduce downtime of live deployments, two identical production environments can be supported where only one is live at any one time. Supporting processes for the use of production data in development and testing environments. are necessary. Organizations can also consider the guidance provided in this section for training environments when conducting end user training.

In the software development life cycle, three environments are commonly used: development environment, testing environment, and production environment. The development environment is the place where software applications and services are created and developed. In a testing environment, developers and quality assurance professionals can test an application’s functionality, performance, and reliability before it is released to users. Software applications or services are deployed and made available to users in production environments. There are several types of environments, each of which serves a different purpose. These environments differ in their level of control, access, and stability. The organisations is to maintain the confidentiality, integrity, and availability of sensitive information assets by segregating developing, testing, and production environments through appropriate procedures, controls, and policies.

• Development Environment: A development environment allows developers to write code and make changes or updates without breaking anything in a live environment. New features and updates can be tried and your end users aren’t affected. This environment is great in reducing potential errors and maintaining a streamlined workflow. Additionally, at this stage, a lot of preliminary testing happens before moving on to the testing environment.
• Testing Environment: You know that a test environment is a setup where software undergoes a series of experimental tests. These environments allow you to test individual components of your app, eliminate bugs, provide accurate feedback about the quality and behavior of the app, and encourage improvement and innovation, among others.
• Production Environment: The production environment is the stage where all apps, software, or product are live for their intended use and its users. Any bugs, issues, or versions are tested and fixed prior to this stage, so the product or update should work perfectly. The production environment contains only the final version of the product or app in order to avoid any confusion or security vulnerabilities. This type of infrastructure (development, testing, staging) allows teams to ensure high-quality products for their users, while encouraging fast innovation and improvements.

In all three environments, developers and other stakeholders have varying degrees of control and access. To minimize disruptions to end users, changes to the application or service in a production environment are usually restricted to a few authorized users. Access is typically more open in the testing environment to test different scenarios and configurations, and changes can be made more quickly and easily. Typically, developers have even greater access to the code base in a development environment and can experiment and make changes as needed to explore different approaches and ideas.Organisations should take into account the potential production problems that should be prevented when determining the required level of separation between the three environments.

1. Segregation and operation of development and production systems to an adequate degree. For example, the use of separate virtual and physical environments for production could be an effective method.
2. Appropriate rules and authorisation procedures should be established, documented, and applied for the use of software in the production environment after going through the development environment.
3. Organisations should review and test changes made to applications and production systems in a test environment separate from the production environment before these changes are used in the production environment.
4. Testing in production environments should not be allowed unless such testing is defined and approved prior to testing.
5. Development tools such as compilers and editors should not be accessible from the production environments unless this access is absolutely necessary.
6. To minimise errors, proper environment identification labels should be prominently displayed in menus.
7. Sensitive information assets should not be transferred into development and testing environments unless equivalent security measures are applied in the development and testing systems.

Environment	Purpose	Control and access	Stability and reliabil
Development Environment	Development and building environments for software applications and services.	Developers are free to experiment with the codebase and make changes as necessary to explore different ideas.	Application or service is still being built and refined. Therefore, stability and reliability are less than in a testing environment.
Testing Environment	An environment that simulates the production environment so developers and QA professionals can test the application’s performance, functionality, and reliability.	The environment is more open for testing different scenarios and configurations, and changes can be made more quickly and easily.	Due to stress tests and scenarios, the application or service is less stable and reliable than in production.
Production Environment	The application or service is deployed and made available to end users in this live environment.	The service is limited to a limited number of authorized users, and any changes must be carefully planned and coordinated, so that end users are not disrupted.	Minimal downtime and disruption, with stable and reliable performance.

There is also an important difference in each environment’s stability and reliability levels. Due to the fact that the application is yet in the process of being created and refined, it may need to be more stable and reliable in the development environment. As the application or service undergoes different stress tests and scenarios in the testing environment, it might be less stable and reliable. Application or service stability and availability are expected in the production environment, with very little downtime or disruption.Organisations should protect development and testing environments against security risks taking into account the following:

1. All development, integration, and testing tools such as builders, integrators, and libraries should be regularly patched and updated.
2. All systems and software should be configured securely.
3. Access to environments should be subject to appropriate controls.
4. Changes to environments and code stored in it should be monitored and reviewed.
5. Environments should be securely monitored and reviewed.
6. Environments should be backed-up.
7. No single individual should be given the privilege to make changes in both development and production environments without obtaining approval first. To prevent this, organisations can segregate access rights or establish and implement access controls.

In addition, organisations can also consider extra technical controls such as logging of all access activities and real-time monitoring of all access to these environments.

If organisations fail to implement necessary measures, their information systems can face significant security risks. For instance, developers and testers with access to the production environment may make unwanted changes to files or system environments, execute unauthorized code, or accidentally disclose sensitive information. Therefore, organisations need a stable environment to perform robust testing on the code and to prevent developers from accessing the production environments where sensitive real-world data is hosted and processed. Organisations should also apply measures such as designated roles together with separation of duty requirements. Another threat to the confidentiality of production data is the development and testing personnel. When the development and testing teams perform their activities using the same computing devices, they may accidentally make changes to sensitive information or software programs. Organisations are advised to establish supporting processes for the use of the production data in testing and development systems in compliance.Moreover, organisations should take into account the measures addressed in this Control when they perform end-user training in training environments.Organizations need to establish and appropriately protect secure development environments for system development and integration efforts that cover the entire system development life-cycle. Development environments need to be protected to ensure the malicious or accidental development and update of code that may create vulnerabilities or compromise confidentiality, integrity, and availability. Protection requirements should be determined from risk assessment, business requirements, and other internal and external requirements including legislation, regulation, contractual agreement, or policies. In particular, if any form of live data is used in development environments it needs to be specially protected and controlled. Separating development, testing, and production environments have several benefits.

• This ensures a controlled and predictable development and testing process for the application or service. With distinct environments for each stage, developers and QA professionals can concentrate on one aspect of the application or service without being diverted by other components of the codebase. When errors and bugs occur, this can help minimize them and make it easier to identify and resolve them.
• The second benefit of separating environments is that it ensures that the application or service is released to users stably and reliably. Developers and quality assurance professionals can identify and fix potential problems before deploying the application to the production environment by testing the application or service in a simulated testing environment. It can also help to maintain the reputation and trust of the application or service by preventing disruptions and downtime.
• In addition to flexibility and scalability, having separate environments is also advantageous. Developers and other stakeholders can easily switch between environments at each stage of the development process and scale each environment up and down as needed. In addition to supporting agile development methods, it can make experimentation and iteration easier.