1

I read another question which made me think...

If you encrypt PCI data (credit card numbers, etc.) using PGP or AES and send it through a firewall, is that firewall in scope?

Alternatively, what if you only use a data-in-motion security mechanism like SSH or TLS, would that same firewall be in or out of scope?

Perhaps I can add more context.

Sure, our "PCI Area" firewall is in scope, but what if a firewall separates two different Intranets, and the encrypted PCI data (using either method) passes through it to get to another server. For instance, it passes through our "PCI Area" firewall and our "Intranet 2" firewall to get into Intranet 2.

PCI says that anything that "stores, forwards, or processes" credit card data should be in scope. Does Intranet 2 firewall do those? It definitely routes/forwards the data stream, processes the packets, and stores some information in its logs, but I'm not sure if any of those are actually PCI scoped because the information is encrypted. It's not actually handling any raw PCI data, it's handling encrypted information.

You could make the argument that the encryption is reversable, and therefore could still be PCI, but I'm not clear on where that sits from a QSA's perspective.

I am inclined to treat all networks as PCI, and to layer on additional security mechanisms as I see fit, however I'm trying to figure out priorities should lie for companies that need to be PCI compliant.

JZeolla
  • 2,936
  • 1
  • 18
  • 25

3 Answers3

4

Oh. As per your update...

No. Firewalls not connected to the CDE are not in scope simply because encrypted PAN data transits them. If that were the case, the whole freaking Internet would be in scope.

Part of being PCI compliant involves mapping out cardholder data and network topology. The firewall closest to your CDE is in scope, and if the assessor determines it provides appropriate controls, then it removes outward devices from scope. You may wish to review Network Segmentation on pages 10-11 of PCI DSS 2.0 and Appendix D.

You also need to watch how scope creeps in - you may want to look at the Open PCI DSS Scoping Toolkit, which isn't official but which reflects the way many QSAs try to break this down. So if your second firewall only sees encrypted PAN data, it's not in scope, but what if it protects your Windows Active Directory Domain Controller, and your CDE environment uses AD credentials? Maybe that puts AD in scope. Maybe that puts the firewalls protecting the AD servers in scope. It can get tricky, and it can vary by QSA, and from what I've heard scope infection is going to get worse with DSS 3.0.

Old answer (pre-question update):

Yes, it is. The entirety of PCI DSS Requirement 1 (Install and maintain a firewall configuration to protect cardholder data) is about making sure you've got a firewall in front of your cardholder data environment to protect it, and making sure it's set up and maintained properly.

Encrypting PCI data to send it through the firewall is Requirement 4 (Encrypt transmission of cardholder data across open, public networks). It's a base requirement, not something you do to try and remove firewalls out of scope.

The encryption protects that data. The firewalls protect the servers and networks. PCI DSS require you implement both.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
2

The firewall is not in scope just because it is passing encrypted cardholder data - otherwise, every router on the internet would be in scope when you to enter your card number in PayPal. The firewall is in scope when it is protecting a network that contains machines that handle unencrypted cardholder data.

So your two questions are really the same question. If the firewall is protecting a machine that is encrypting cardholder data, regardless of whether it's using RSA/AES or TLS, it's in scope.

It's common to use multiple firewalls to limit PCI scope. Here's an example. Let's say you're a retailer who has an HQ with many employees, and you operate several stores. Each store has a network with several machines, including customer kiosks, a manager PC, a printer, some cash registers, and each cash register has a PIN pad that does encryption. You use a third party company to serve as your payment processor. For each credit/debit transaction, the PIN pads send the encrypted payment data to the processor. And none of your HQ systems ever get the cardholder data - they only get the payment records.

You almost certainly have a border firewall that isolates your company network from the Internet. If that was your only firewall, then every machine in your company would be in scope for PCI! Also, think about those kiosks. If some hacker breaks into your kiosk, do you want him to be able to connect to your cash registers?

So to reduce the scope, (and to increase your security,) in each store you set up a subnet containing just the cash registers, and you place a firewall on that subnet to isolate it from the rest of the store machines. Your PCI scope can now be limited to just those subnets, and the firewalls that protect them. The border firewall, while obviously a good idea to help protect your business, technically falls outside of PCI scope along with the rest of your HQ machines.

John Deters
  • 33,650
  • 3
  • 57
  • 110
0

The PCI SSC has an FAQ about the scope of encrypted cardholder data:

It is possible that encrypted data may potentially be out of scope for a particular entity if, and only if, it is validated (for example, by a QSA or ISA) that the entity in possession of the encrypted data does not have access to the cleartext cardholder data or the encryption process, nor do they have the ability to decrypt the encrypted data. This means the entity does not have cryptographic keys anywhere in their environment, and that none of the entity’s systems, processes or personnel have access to the environment where cryptographic keys are located, nor do they have the ability to retrieve them.

I am not a QSA, but I've always interpreted that as, with proper segmentation, the system can be de-scoped.

John Downey
  • 1,915
  • 13
  • 12