PCI DSS VPN issues

Posted: December 17, 2008 in PCI, Posts

Received an interesting message from an end user the other day…

We are a large website that deals with a user’s credit card data and therefore must be PCI (Payment Card Industry) compliant.  Some of our workstations are running Windows 2008 Server 64-bit which the Cisco VPN client doesn’t support. However, your NCP VPN client does!

Our own network administrators have informed us that using another client against our Cisco VPN server would violate PCI compliance. I’m not sure if this is the actual picture or just a part of the picture.

Do you have any knowledge of why our scenario would violate PCI compliance?

Can anyone help us understand PCI compliance stipulations around VPNs? Is there something in there about using different vendors for client and server?

  1. Martin White says:

    The cardhold data enviroment should be kept seperate from the rest of your network behind firewalls and no connections of any kind (including VPN) should be allowed to the enviroment unless required for the processing of the card data (requiredment 1.2.1).

    If you do need to transmit cardholder data over a VPN then you must use strong crupto (which is not defined well, but I would sugggest AES256 at a min) and use of an established security protocol such as IPSEC or SSL/TLS (requirement 4.1).

    Bear in mind that the network to which you connect the VPN has now become part of the cardholder data enviroment and is no also subject to PCI DSS.

    Also, this should not be a remote access VPN as this could be seen to violate req 1.3 in some instances (no direct public access to cardholder env) and also woudl give you the impossible problem of having to secure all the posisible source networks and hosts because as soon as they connect they are now part of your cardholder data network and are subject to PCI.

    You must also use strong key management techniques which are fully documenmted (Req 3.5)

    Finally all devices that make up the card holder enviroment, including your VPN end points, must meet the various system config requirements including being configured to best practice guidlines from the Center for Internet Security or NIST, etc (req 1.2 and 2.1a).

    Hope that makes things clearer rather then more confusing 😀

    The latest version of PCI DSS is linked below as is Center For Internet Security were you can download the guidlines mentioned above for free.

  2. VPN is a term for technology that allows you to set up an encrypted tunnel that you can then send data over.

    PCI DSS does not state that you are required to have or use a VPN but if you do then there are some specific controls that you need to follow.

    Do you currently user VPN technology ?

    Often, VPNs are configured so that companies can move data over connections in a secure manner but the PCI DSS does not stipulate this.

    It only states that data sent over an open public network is required to be encrypted.

    One way to achieve this would be a VPN but you could also encrypt the data before transfer and not have to set up a tunnel.

    There certainly isn’t anything about using diffrent vendors as part of the VPN controls.

    Your first question you need to answer, is are you currently using VPN technology and if not do you need to ?

    Do you transmit card data over public open networks ?

    Encryption is only required over an open public network (Internet) but other WAN technologies may not need the data to be encrypted.

    IPSEC tunnels are not always the best solution for data tranmissions but do meet the requirement. As the other poster highlighted, if you do use tunnels then you have to show evidence of managing your keys.

    If you use VPN for remote access, then you need to demonstrate that your end points are managed.

    There are lots of methods of moving data securely, SSL, SCP, SFTP, PGP, HTTPS, Connect Direct and so on.

    Depends if you are doing real time data or batch.

    Why not encrypt higher up the stack at the application instead of using a tunnel.

    What is the business requirements, this is what will dictate good complaint architecture. You don’t decide on the technology first, you state what the business requirements (including the PCI DSS requirements if you need to be compliant) and then design to meet them.

    Looking at your other questions, everything is IPSEC based. IPSEC is powerful and secure but is not always the best solution, it can be overkill and has a resource/administration overhead.

  3. Mark David says:

    Actually, you can easily address the PCI stipulations about cardholder network access by simply placing a firewall inbetween the cardholder environment and an internal network in which the VPN server may exist. However, you must be able to justify the business requirements behind each port you open towards the cardholder environment.

    Don’t let the specifications scare you — they are actually fairly loose in regards to specific control mechanisms, although you can take it much further than minimum requirements if you are so inclined.

    I will add that you should be extremely wary of what many IT professionals will try to promote in regards to security; the culture has a love-affair for security, and so you will often find experienced IT analysts recommending heavy-duty security systems as requirements or at least best-practices when they are almost always neither.

  4. Matt Caston says:

    a lot of what you’re going to see are the inherited problems of connected networks and policies regarding what you can (should) or cannot do while while connected remotely…typically VPNs facillitate remote access which is somthing you’ll want to review relative to PCI. That being said, if you are in a situation where you cannot comply with the letter of the standard, you must be able to demonstrate strong compensating controls. Technically, there are lots of ways to overcome the inherent issues of establishing new site/client based connections, some of which are noted in other responses.

  5. I agree with Martin overall.

    I would say this – if you’re talking about the use of VPN for the transmittal of data (ex.: a POS terminal to a processing server at seprate sites) then you can use a VPN provided that (1.) the connection is constantly logged for audit trail, (2.) uses heavy encryption with anti-replay controls and ACL, (3.) is truly point-to-point; meaning that there’s nothing else on that VPN via policy except the compliant data.

    If you’re talking about having a VPN in a PCI regulated facility, the general rule of thumb is to isolate networks where processing would occur from networks that connect to other servers. With POS systems this is generally accomplished through encrypted terminal sessions or even direct serial connections to the processor; but in either case the networks should by physically separated by a firewall with policy to drop chatter between the two networks completely.

  6. […] info By vpnhaus Categories: Uncategorized Pursuant to our recent discussion of PCI DSS issues, we wanted to spotlight another great […]

  7. I’m not sure exactly why but this weblog is loading extremely slow for me. Is anyone else having this problem or is it a issue on my end? I’ll check back
    later on and see if the problem still exists.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s