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.
"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.
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.
- The Evidences Book
- EBook: PCI DSS - That’s the Way It Is.
- PCI DSS V3.2.1 Compliance Dashboard
- PCI Calendar App - Never miss a milestone again
- Ready to use PCI Procedures & Templates
- The 2019 PCI Calendar Board template