PCI DSS placement of puppet (or chef) server?

Question

I'm puzzled as to whether I am allowed to set up a puppet server in a PCI DSS environment, and if I am, where should it be located?

I was planning on installing it on gateway, and all the hosts would connect to gateway https/8140 to pick up node manifests.

Would this violate PCI DSS requirements, and if it would, is there a better place to put it? Maybe DMZ?

What are your experiences Puppet/Chef/Salt in PCI DSS environments?

Thanks

Answer 1

I worked for a QSA company for 2 years, so here is one ex-assessor vision of your case.

It is absolutely fine to use configuration management (CM) tools from the PCI DSS perspective. In short, to be OK with the standard compliance you must make this system PCI DSS compliant itself and align your configuration management and support processes with PCI DSS requirements.

First of all, deal with the PCI DSS scope. While tools such as Puppet/Chef are not directly involved in payment card data processing, they are affecting the security of such system components. It will not be considered a part of cardholder data environment (CDE), so it is not required to sit within isolated network segment. Any Puppet/Chef service dependencies that affect its own security will also be in scope of PCI DSS review. These may include: AV server, log server, authentication , version control, package repository servers and so on. So, in case you have such infrastructure within PCI DSS scope, it is a good idea to reuse it (for example, forwarding logs to already-in-PCI-scope log server).

There are generally two recommended patterns when you incorporate CM tools into your environment:

1. Install self-contained server within CDE and use only for the purposes of managing PCI-related system components. This way, you are minimizing impact to your existing PCI DSS scope but losing flexibility.
2. Use multiserver architecture and install some part of it within CDE. This way, you get more flexibility, but some systems from your “regular” non-PCI network will be in scope as well.

In any case, you should work closely with your QSA to determine if your intended scope is correctly defined and no important systems left behind.

Once you understand what changes to PCI DSS scope will be made by incorporating configuration management tools, you may plan how you’d implement technical and procedural PCI requirements for this changed scope. I will not describe process here, since it is too lengthy and is not different from what you already should be doing with your existing infrastructure anyway.

One important point that I want to note though: introducing CM tools usually greatly impacts established change management routines. Per requirements listed in clause 6.4, there are a lot of tasks one should be doing when applying changes. This means literally anything you do with the whole your CM system must be planned/tested/reviewed/approved in PCI-prescribed way. And that’s the reason why a lot of DevOps shops end up using completely isolated CM system to manage PCIDSS-related systems. Anyway, make sure you have your change management procedures updated.

I hope this helps – it is hard to address this issue and not write a lengthy paper with a lot of “if else” conditionals.