What restrictions, if any, exist over source code repository management under PCI-DSS?

Question

What restrictions, if any, exist over source code repository management under PCI-DSS?

The company I work at wants to develop a credit card processing service for clients hosted under our network. At the moment we're using SVN for version control. It's secured so that only the developers who need checkout/commit access have it. Meanwhile I was planning on moving from SVN to HG. However, the security team has expressed reservations about using a distributed SCM tool due to lack of access control on remote clones. Specifically, they claim this would violate PCI-DSS compliance. Does it?

Answer 1

First, I'll just say that I'm basing my answer on a quick read of PCI-DSS 2.0, specifically Requirement 6.

I don't see why using Mercurial would be a problem if you use it in a way comparable to how you used Subversion. Here are some reasons why I think this:

• Presumably you do not store customer data in your repository (only code which operates on that data).
• PCI-DSS often uses words like "standard industry practices" or the like. Mercurial is by now a quite common VCS, which is helpful.
• It seems to be the ability to push changesets that needs to be locked down. And specifically, the ability to push to a "canonical" clone of your repositories. Just because Mercurial has these "remote clones" and developers could push random (even malicious) changes into those clones, does not mean that those changes will (or should) end up in your production system.
• With Subversion, it sounds like you had permissions in place to restrict checkins to a subset of your developers (or maybe even just one "gatekeeper"?).
• With Mercurial you can set it up to use SSH on the central (canonical, "production" repository. Give each developer their own SSH credentials for this (this is required by PCI-DSS--no sharing passwords!). In this case you can set permissions on the filesystem where the central repo is hosted, and only give write access in the Mercurial directories to specific users.
• With Mercurial you can instead (or also) publish your central repo via HTTP. In this case you can use Apache (or another web server) to do the authentication and authorization.
• You could also disallow writes to the central repo entirely, and decree that all source changes must be sent through one or two specific people, who will review the changes before pulling (or applying) them.

So I think there is plenty of scope to be PCI-DSS compliant while using a DVCS like Mercurial. Everything above would apply equally to Git.

Answer 2

As others have said, this is one to raise with your QSA if you need more advice. That said, PCI is about having the right controls in place rather than mandating one technology over another.

When developing, you need to think about:

• Segregation of duties between test/dev and production systems
• Being able to detect changes, where they originated, when and by whom
• Having change control procedures when pushing to live

Nothing in this should stop you using the repository manager of your choice

Answer 3

If the security team is right about the access control part depends on what kind of control they do want.

Restricted read

Having any control about what one developer can read is limited both with SVN as with any DVCS. Even when you have a central SVN server typically there is no limitation to read old revisions of paths where you have the permission for. So you could dump the old history revision-by-revision into a local store (hg subversion, git svn and lots of other tools work exactly this way). There is nothing magical in SVN which prevents someone from downloading every single revision and distribute these copies.

At the end if you can't restrict the access to the working copies at the user side, you have no read restrictions at all. Period.

Restricted write

This is a different game, since Mercurial allows you to set any name as committer as you want¹. So you need to add some mechanics at the server so that no developer can introduce False-Flag revisions by committing with the name of one fellow developer, and push this revisions to the server. While AFAIK Subversion does set the username by itself on the server, a hg server must somehow be supplied with a hook to check the usernames for all incoming changesets.

¹ There is a way to change the commiter name in Subversion too, but you have to enable the pre-revprop hook on the server to allow this.