PCI DSS - VPN network?

Question

My network is segmented into internal (which holds private cardholder data), DMZ and VPN. There is a gateway in between which restricts access, for example:

VPN: 10.0.0.0/24 DMZ: 10.1.0.0/24 INT: 10.2.0.0/24

GW / firewall has ip .1 in all three networks. Access from DMZ to cardholder (INT) is limited via FW and access from public networks to cardholder (INT) is completely prohibited.

I'm confused about one thing: if I connect to the VPN network from my workstation, am I allowed to make connections to servers in the INT network? For administration purposes, I need ssh access to those nodes, and it seems logical to me that connecting to them from VPN IP, through gateway/firewall, should be OK.

But, I'm getting fuzzy responses from other colleagues working on these issues. They think access from VPN to INT should be forbidden, and the only way to connect to INT servers should be by connecting to VPN, then ssh-ing to one of the DMZ servers and then hopping into INT. I can't find any such notion in PCI DSS docs...

Is the reason for this explanation that the VPN connecting machine is not under PCI DSS scope, so it's treated as unsecure/public access, or does VPN eliminate that notion?

Answer 1

According to PCI, you have 3 kind of networks: 1. INTERNAL (Cardholder Data Enviroment) 2. DMZ 3. INSECURE

If your VPN network is considered as DMZ network, then it's under PCI scope, just like every other device in DMZ zone.

If your VPN network is considered as INSECURE network, then you shouldn't allow direct connection to the servers in INTERNAL network.

So, either you are in PCI scope, or you are INSECURE. Firewall should be configured to not allow direct communication between INSECURE and INTERNAL network.

Answer 2

IANAQSA...

Is the reason for this explanation that the VPN connecting machine is not under PCI DSS scope, so it's treated as unsecure/public access, or does VPN eliminate that notion?

First of all, if you have a VPN, you must have 2-factor authentication to make it PCI compliant. You didn't mention that, so I figured it should be made explicit.

Once you have your 2-factor VPN, the question of whether you can access your CDE (in-scope) comes next. You can do it, or not do it. If you do it, then you're either putting your VPN network in-scope, or you're not, depending upon the segregating controls (DSS 3.1 p11):

To be considered out of scope for PCI DSS, a system component must
be properly isolated (segmented) from the CDE, such that even if the
out-of-scope system component was compromised it could not impact the
security of the CDE. 

So - made-up examples here - if your users can access a web portal in the CDE in-scope network via the VPN, and that portal allows them to manage payments but not to see decrypted PAN data, then you're probably not putting your VPN devices in scope.

On the other hand, if your VPN users can run a database query tool and export decrypted PAN data from the CDE in-scope database to their VPN host, then that VPN network is not properly segregated and it is in-scope.

But, I'm getting fuzzy responses from other colleagues working on these issues. They think access from VPN to INT should be forbidden, and the only way to connect to INT servers should be by connecting to VPN, then ssh-ing to one of the DMZ servers and then hopping into INT. I can't find any such notion in PCI DSS docs...

This is all very much a matter of QSA judgement, but my experience suggests that any interactions between the VPN network and CDE in-scope networks should be mediated by proxies or other application layer control points in order to keep the VPN network out of scope. Whether or not simple island-hopping as you describe is sufficient or not is up to the QSA.

The "docs" talk around these issues without clearly addressing it. The Open PCI Scoping Toolkit was an attempt to regularize the approach that entities and QSAs took to designing, describing, and auditing networks; a way to compensate for that lack in the DSS itself. It's not a standard, but it can be very useful to read through and if your QSA respects it (some do, some don't) then it can ease the difficulties working through network scope boundaries with them.

Answer 3

Let me give you a disclaimer first. Any advice given will be trumped by your QSA and because I have a limited scope of your network I can only provide guidance.

Based on your question, you should have at a minimum, two zones, your DMZ where your application is running, and your internal zone where the data is being held ( I typically refer to this as the database zone as PCI requires to to specifically separate this from your DMZ.

You also have a third zone for Remote Access (Your VPN Zone).

I am going to assume your VPN doesn't transfer CHD across it's wire and your goal is to access your servers remotely. In short, you can VPN and SSH into your back end servers from the VPN network, but you will be required to implement Two-Factor Authentication.

A PCI environment is anything that touches CHD, basically any part of your network that transfers or stores CHD. As you may well know, we limit scope by segregating networks. A VPN network that is segregated out can be eliminated from scope, but your PCI environment still must maintain it's portion of the guidelines.

This means that connections into the environment must be logged , centrally, and you must use two-factor authentication, with an individual account. Proxying through a server on the DMZ can be an added layer of security, but this doesn't absolved you of needing the requirements I listed.