Based on ISO 27001 control A.10.1.4 a separation of environments must be in place between development, test and production environments. When separation is not in place there is the risk of unauthorized changes to production data. In such a scenario it is possible that a developer promotes an unapproved version to production. This can lead to financial losses due to fraud or unavailability.
The control speaks of a separation between development, test and production. In a lot of large corporate environments an additional acceptance environment is added to this environment. The whole of environments is also known as a DTAP (development, test, acceptance and production).
One of the business drivers for implementing virtualization is to efficiently make use of the hardware resources by combining the development, test and production environment on the same hardware. The hypervisor provides isolation between the virtual machines through the second formal requirement from Popek and Goldberg [1].
Running different virtual machines for development, test and production on the same hypervisor and on the same physical hardware would mean that the ISO control for segregated environments is met. The virtual machines are isolated from each other via the hypervisor.
However developers and testers often have administrative rights on the systems they use for their activities or they can gain access by using programming facilities. They can run developments programs on a system and also perform debugging activities. This also gives them the opportunity to run harmful software. Due to bugs in the program, system resources can be consumed or changed accidentally or on purpose. Within a virtualized environment they very well can also have the ability to access the
management console of the hypervisor, so that they can add, start, and stop virtual machines or change resources. These possibilities pose risk against the production being run on the same system.
Based on the risk assessment the following risks were identified that are related to the segregated environments:
Layer Risk Risk description
Management console
Unauthorized changes to configuration
Key configuration files are not protected with sufficient access rights. Changes are being made by development staff and resources needed for production are consumed by development or testing.
Rogue virtual machines are created and started. Resources needed for production are consumed by development or testing. Virtual machines Segregation of environments is not in place
Virtual machines that are used for development, testing, acceptance and production are run on the same hardware.
Hypervisor Memory exploitation Memory is used by different virtual machines. If not protected well virtual machines can change data from other virtual machines.
Memory in use or used by a virtual machine can be read by another virtual machine.
Denial of service Shared resources are completely claimed by one virtual machine or process and not freed on time or on request. This can lead to
unavailability issues for other virtual machines within the same hypervisor of which make use of the same shared resources.
Buffer overflows Virtual machines are able to break out of the control of the hypervisor and can access
resources allocated to other virtual machines or to the hypervisor.
Based on the above it can be concluded that having different virtual machines for
development, test and production on same physical hardware doesn’t mean that the ISO control for segregated environments is met. Additional controls must be put in place to mitigate the risks further.
There is a difference between the DTAP environment for applications/database management systems and the infrastructure layer (operating system/hardware). Development, testing and acceptance for applications or database management
systems should ideally only be performed on production infrastructure. If these activities are performed on hardware or operating systems that are not fully accepted there are too much dependencies for the application development live cycle. Bugs on the infrastructure layer can influence the application development. For the infrastructure layer the most secure solution is also to implement a DTAP environment.
The DTAP environment in a traditional environment would ideally look like this:
Fig 8 DTAP traditional .
Based on the risk assessment, the business value of the applications, and a cost benefit analysis it must be decided whether it is acceptable to have complete separate hardware for all phases or whether phases can be combined on the same hardware.
Still it remains very questionable if development, testing, acceptance and production can be combined on the same host for critical systems. For development and testing it can be necessary to turn on memory settings such as transparent page sharing or memory swapping. These settings can influence the availability of the production. This may be acceptable for non sensitive systems.
To meet the ISO control for segregated environments the hardware should be split between the different phases. On the hardware layer new hardware could step through the phases and promote from development, via test and acceptance to production. Once the hardware is labeled as production it can be used for development and testing on the application layer. For the acceptance and production on the application layer separate hardware should be available. Based on this scenario the absolute minimum is two separate hardware environments.
Ideally in a virtualized environment the DTAP would look like this†:
Fig 9 DTAP virtualization
†
If a type II hypervisor is available for the hardware and operating system that is in use in the company, it can also be considered to deploy the development and test
environments via a type II hypervisor. In that case it is possible to do development from the workstation of the developer or on less costly hardware.