Contact us
PCI-GO
  • Dashboards
  • PCI eBook
  • Blog

PCI Newsletter #60 - 6.4.2. - A case study for network and system administrators

2/14/2019

1 Comment

 
Picture

​​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.

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. 

Resources

  • 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
​​
Didier Godart
1 Comment

    Archives

    October 2023
    September 2023
    July 2023
    June 2023
    May 2023
    April 2023
    March 2023
    February 2023
    April 2020
    July 2019
    February 2019
    January 2019
    August 2018
    May 2018
    February 2018
    January 2018
    December 2017
    October 2017
    July 2017
    June 2017
    April 2017
    February 2017
    January 2017
    December 2016
    July 2016
    June 2016
    May 2016
    April 2016
    February 2016
    January 2016
    October 2015
    August 2015
    January 2015
    July 2014

    RSS Feed

Powered by Create your own unique website with customizable templates.