3

I was wondering if anyone could clarify the scope of PCI compliance with regard to multiple networks.

At present, there's one PCI compliant network to which another network connects via VPN. The PCI compliant network will eventually store customer data and credit card information.

I read this article which suggests that as long as you don't store credit card numbers locally on the office network the scope doesn't extend that far. However, it's the VPN connection which leads me to think that it will indeed mean that the office would need to be PCI compliant too.

A large department all have access to the VPN (each with their own usernames) but with none of the password strength and renewal policies in place yet.

Is anyone able to clarify the situation preferably with reference to some official documentation?

2 Answers 2

5

I'm going to call your PCI compliant network #1, and the other #2. If no credit card information is going to traverse the VPN to #2 then it does not have to be PCI compliant. However, if any system located in #2 will need to access credit card information, or systems that store credit card information, then it would have to be PCI compliant.

Honestly though, the PCI rules for network are good practice for all parts of your network, not just the parts of it that deal with credit card information. Strong authentication, logging, etc should be considered standard.

3
  • You say need access to credit card information or systems that store it- the developers will need access to the database servers which store said data over the VPN and in turn SSH. Does that mean network #2 needs to be PCI compliant? Jul 18, 2012 at 14:21
  • 1
    Yes it does if the developers are on #2 as the developers could view credit card information, or modify systems that store it. Your security is only as good as the weakest part, it's no good securing network #1 if network #2 could be an attackers point of entry.
    – GdD
    Jul 18, 2012 at 15:13
  • Ok thanks, that sounds reasonable and pretty much as I expected. I don't suppose you're familiar enough with the documentation to point me roughly in the right area for finding official backing for your statement? (I will need to present these findings) Jul 18, 2012 at 16:14
4

Do you mean your developers can access the production database servers from their development workstations? Sounds like something you do not want to explain in a PCI assessment ...

You should clearly separate your dev and prod environments. The production site should only allow clearly defined access for all people (-> audit trails), no fiddling with databases or the like. If you'll have an on-site audit it would be good to have your local workstations properly secured (AV, password policy ...). Even if the workstations are not within the cardholder data environment QSAs tend to be sceptical about administrative access.

4
  • At present, yes this is the case. However, the plan is to have one person responsible for launching production sites, and only said person having access. The problem is, the pre production environment, used by developers (VPN access), QA testers, client previews etc are on the same network (#1 as described by Greg Dolph). Would it be advisable to separate them completely? General development, before pre production is completed on network #2. Jul 18, 2012 at 20:25
  • 1
    Let's assume 4 parts: dev, testing, staging, production. You could develop and fully test your applications in dev and testing. A release gets deployed to the staging environment which can run "on the production hardware". Staging must then be handled exactly like the production environment.
    – mdo
    Jul 18, 2012 at 20:28
  • But staging and production are on the same network, to which multiple people have access to from their development machines - so I'm guessing this means the compliance scope will need to extend into the office network (#2)? Jul 18, 2012 at 21:41
  • 2
    What exact "access" do the developers need to staging & production? If it is no more than other staff has and limited to documented procedures it may be ok. Everything beyond: look at "separation of duties" topics in PCI DSS. The developers will not be allowed to be the ones deploying their own applications. Here's a similar topic: security.stackexchange.com/questions/12962/…
    – mdo
    Jul 19, 2012 at 6:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .