Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My development staff is in the process of automating our end of month process. There is a small manual step that needs to be executed.

We have been thinking about the PCI ramifications for making this accessible over the net. Looking at the PCI standards, notably 1.1 blocking public access to cardholder environment from the public internet.

I read that this wouldn't be considered publicly accessible if I have client certificates in place. This would place this more into the realm of VPN access and the associated rules.

Does this sound correct? Are there any additional gotchas I should look out for?


Perfect. Many thanks. I do have a firewall / HIP / NDS / etc all in place. The way I'm thinking the certificate authentication ( in conjunction with normal password auth) would be being used in lieu of a full fledged VPN tunnel. The certificate authentication would occur at the firewall, before anything dangerous can get into the internal network.

share|improve this question
I still don't get what constitutes "direct public access". Does "direct" mean without an external firewall? Does it mean without a router that changes the IP address? Does "public" mean over the internet? Or without a password that anyone can obtain? Or without a password given to just employees and consultants? Does viewing a web site constitute "access". Is using a console "access"? – user9674 May 11 '12 at 18:52
up vote 9 down vote accepted

You can't use certificate-based authentication to "hide" a machine in the same way that a VPN hides a machine -- which is what the PCI Standard intends in section 1.3 in v2.0 of the PCI-DSS Standards.

1.3. Prohibit direct public access between the Internet and any system component in the cardholder data environment.

Each of the components of 1.3 refer to avoiding direct contact with the system component. Direct contact means that your machine has a publically accessible IP and can be communicated with directly. A certificate-based authentication system does not preclude section 1.3 because it offers no protection against OS/network-stack level (or similar) vulnerabilities which could be used to penetrate and avoid the authentication system.

The sub-requirements go on to describe specific methods that must be in place to prevent public access -- intervening network-level protections such as firewalls, VPNs, etc.

If you have not already read it, please read "Understanding the Intent of the Requirements" as an interpretive guide. Section 1.3's interpretation basically says exactly what I said above:

A firewall's intent is to manage and control all connections between public systems and internal systems (especially those that store, process or transmit cardholder data). If direct access is allowed between public systems and the CDE, the protections offered by the firewall are bypassed, and system components storing cardholder data may be exposed to compromise.

Ultimately, this means that as long as your manual system is protected with an intervening security firewall or other masking solution (eg. VPN) that also conforms to the requirements laid out in (all of) section 1, then you should be fine. You wouldn't even need to use certificate-based solutions as long as all of the other identification & authentication pieces are securely implemented as per the PCI standard.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.