PCI DSS 6.4.2 requires separation of duties between personnel assigned to the development / test environments and those assigned to the production environment. People whose function is to develop applications have no need for accessing production. Common sense. At least for companies where such activities are well structured and separated. But what if this is not the case, for companies where the network system administration population is also involved at some level in such activities.
Case study
For the purpose of our reasoning, we will study the applicability of 6.4.2 for a population of network and system administrators whose main function is to set up, manage and maintain the system/network components for which they are responsible. These components include vendor products and solutions but also in-house technical tools (scripts, batches,…) supporting or facilitating their aforementioned activities and specific core interfaces (API's) facilitating the inter-systems communication such as between application servers and middleware components. In such a case, one could state that this population is involved both in production and development activities. Is there a ground for a non-compliance with 6.4.2?
Reasoning
It is important to note that 6.4.2 does not address the validation of codes prior production nor the control of changes. These concerns being covered by requirements 6.4.5 - Change Management, 6.3.2 - Code Reviews and 6.6 - Review code security.
"Duties" and « environments » are the key terms of 6.4.2. They underpin the real expectation of this requirement, meaning that development, testing and production activities be carried out in dedicated and separated environments, namely development , test and production with separated access and rights according to the needs, as covered by 7.1.
6.4.2 guidance stresses that this requirement aims to reduce the "risks" of omission or disabling of security features in the code and the introduction of malicious code in production by limiting access to production and therefore potentially to card data to those who need it. A condition definitely met by the population of network and system administrators. Their accesses to the production environment with privileged rights being clearly justified by their function.
6.4.2 guidance continue by highlighting the need to separate development, testing and production functions. Each environment being subjected to its own accounts and permissions management. Condition also met by the population of our case study. The technical tools being designed and tested in dedicated environments prior production with separate accounts and authorizations.
The guidance ends with the example of a developer being assigned with a first account with privileged rights in the development environment and a second account with restricted "user » rights in the production environment where he does not have the ability to install and configure anything. This is on this last part of the guidance that QSA's could be tempted to raise a non-compliance on the facts that our population of network and system administrators has sufficient rights allowing them to install and configure the technical tools they conceived in the development environment.
This point highlights a paradox. On the one hand, QSA's understand and accept that the network and system administrators be assigned with privileged rights and therefore the abilities to install and configure vendor products, tools and solutions as well as the associated patches into production. On the other hand, they do not accept that the same population may install their technical tools developed in separated environment. A non-senses far as I’m concerned.
"Duties" and « environments » are the key terms of 6.4.2. They underpin the real expectation of this requirement, meaning that development, testing and production activities be carried out in dedicated and separated environments, namely development , test and production with separated access and rights according to the needs, as covered by 7.1.
6.4.2 guidance stresses that this requirement aims to reduce the "risks" of omission or disabling of security features in the code and the introduction of malicious code in production by limiting access to production and therefore potentially to card data to those who need it. A condition definitely met by the population of network and system administrators. Their accesses to the production environment with privileged rights being clearly justified by their function.
6.4.2 guidance continue by highlighting the need to separate development, testing and production functions. Each environment being subjected to its own accounts and permissions management. Condition also met by the population of our case study. The technical tools being designed and tested in dedicated environments prior production with separate accounts and authorizations.
The guidance ends with the example of a developer being assigned with a first account with privileged rights in the development environment and a second account with restricted "user » rights in the production environment where he does not have the ability to install and configure anything. This is on this last part of the guidance that QSA's could be tempted to raise a non-compliance on the facts that our population of network and system administrators has sufficient rights allowing them to install and configure the technical tools they conceived in the development environment.
This point highlights a paradox. On the one hand, QSA's understand and accept that the network and system administrators be assigned with privileged rights and therefore the abilities to install and configure vendor products, tools and solutions as well as the associated patches into production. On the other hand, they do not accept that the same population may install their technical tools developed in separated environment. A non-senses far as I’m concerned.
Conclusion
The risks targeted by 6.4 are mitigated by the fact that the technical tools are subjected to code review and change control as any other piece of code. Prohibiting administrators to deliver, install and configure their own technical tools in production does not help further.
My point is that 6.4.2 is intended for populations with extended rights outside production but restricted rights in production such as development teams in charge of functional applications. It can’t be used as a non-compliance argument for our population of network and system administrators installing, configuring and maintaining their own technical tools in production.
My point is that 6.4.2 is intended for populations with extended rights outside production but restricted rights in production such as development teams in charge of functional applications. It can’t be used as a non-compliance argument for our population of network and system administrators installing, configuring and maintaining their own technical tools in production.
RSS Feed
