Ask the PCI Ninja: PCI DSS 1.3.5 (Outbound Traffic)

The PCI Ninja is just like you, except he is a PCI SSC QSA and a CISSP. And he
has a ninja outfit. Other than that, he’s just a regular guy trying to help you get
business done without PCI interfering.

John S. from Tasty Food Restaurants (150 restaurants) sent us this email:

Dear PCI Ninja,

If I read the PCI DSS 1.35 requirement correctly, it seems like systems in our cardholder environment can’t access the Internet directly. How are we supposed to send information to our payment gateway then?

I’ve already locked down my firewall so my systems can only access the payment processor’s
IP address, but it doesn’t look like that’s enough.

Thanks,

John

Good question, John. I was thinking about writing a blog post about just this topic,
and you just happened to write this letter.

It’s fairly easy to implement other areas of requirement 1.3 through implementing
NAT (Network Address Translation) and private addressing, but restricting outbound
traffic to the DMZ is a tricky proposition, even for a ninja.

PCI DSS 1.3.5 states:

“Restrict outbound traffic from the cardholder data environment to the Internet such
that outbound traffic can only access IP addresses within the DMZ.”

Your restaurant probably has a setup like this (if my Ninja sense is accurate, which
it usually is):

Pretty typical configuration, right? Well, except you probably don’t have monitor
screens as tall as your server, and I hope you have an actual firewall instead of
a small red brick wall.

But as you can see, outbound traffic (from the Back of House server) necessarily has
to be able to access the IP address of the FirstData payment gateway.

So how can this issue be resolved?

Let’s take a look at the first option, adding a proxy server:

So now we have a server in the DMZ proxying the requests.

When you look at this option, you might ask: “Ninja, isn’t the Proxy Server now part
of the cardholder data environment, as it is a system that transmits cardholder data?
So it can’t have a direct outbound connection, either.”

Silly reader; aren’t you familiar with PCI Ninja Rule #11?

“Systems in the DMZ do not have to follow Requirement 1.3.3 or 1.3.5”

– PCI Ninja Rule #11

Of course, you may then ask: “But then, couldn’t we put everything in the DMZ?”

[Ninja jedi hand wave] Nothing to see here, reader.

A more related question you may be thinking is “What if the payment application doesn’t
support settings for a proxy?”

Well, dear reader, we could implement a transparent http proxy in that case….hmm…however,
then we would be failing this requirement as the proxy would be doing nothing more
than a firewall with web filtering could do…we can still access an external IP. Touché,
reader, touché. Let’s forget about that, for now. [Ninja jedi hand wave]

If you are slightly immune to ninja jedi hand waves, you may be thinking “Doesn’t
proxying SSL require decrypting the traffic in the DMZ?”

Yes, proxying SSL will fail unless you install a fake root certificate on client systems
and on the proxy, and, yes, the proxy will work by decrypting the stream, then re-encrypting
it. Let’s not talk about the added risk introduced there for now. [Multiple ninja
jedi hand waves]

Right now, reader, if your mind is not a blank slate, you may be asking yet another
impertinent question: “Are you really suggesting that John purchase a server for each
of his 150 restaurants, install Squid Proxy on it, and worry about maintaining that
server?”

Sounds like an expensive proposition, doesn’t it? Well, no, I’m not suggesting that
John invest 180K or so in servers plus another 100K in installation services. That
doesn’t make sense.

Let’s look at another option:

In this option, we’ve connected all the restaurants to a single corporate proxy, which
then accesses the payment gateway. So we’ve reduced our cost considerably, assuming
that we have IPSEC VPN capabilities.

You may be asking: “Doesn’t that introduce additional points of failure, complexity,
bandwidth, latency, security risk, and complexity to my environment?”

Reader, I like your style.

You’re right. What are we actually gaining through this whole effort? Have we actually
reduced John’s risk to any extent? He already has restricted outbound traffic to the
IP address of his processor. What is the possible attack vector? A hacker can’t send
card data to any system on the Internet, just to his processor.

I suppose if the hacker was able to gain administrative access to a cardholder system
AND disable the firewall rule, they could send cardholder data. However, if they could
disable the firewall rule for outbound traffic they could just as easily circumvent
the DMZ (configured in the firewall).

Let’s refer to the intent of PCI 1.3.5, as described by the PCI SSC’s “Navigating
the PCI DSS” document:

“The DMZ also should evaluate all traffic outbound from inside the network to ensure
that all outbound traffic follows established rules. For the DMZ to serve this function
effectively, connections from inside the network to any addresses outside the network
should not be allowed unless they first go through and are evaluated for legitimacy
by the DMZ.”

Hm…I agree that all outbound traffic should follow established rules (e.g., firewall
egress rules, Ninja rules). I don’t agree that the “DMZ” has to evaluate this traffic.
First of all, a DMZ is not a system, it’s a network zone. Secondly, there’s nothing
magical about a system in the DMZ that a firewall can’t do. If the firewall says “no
traffic allowed outbound except for port 80 to 216.22.212.21,” a DMZ proxy adds very
little value.

The only attack scenario I can think of would be if the hacker had compromised the
firewall, but only had non-administrative access to the cardholder data environment,
they possibly might have a problem sending port 80 http traffic to another random
server if the system’s host-based firewall limited traffic to the DMZ. However, that
can be easily mediated by removing the default gateway on the cardholder environment
systems and instead adding static routes for the payment gateway’s internet address.

Therefore, I hereby decree PCI Ninja Rule #14:

“PCI DSS Requirement 1.3.5 offers minimal additional value over what PCI DSS 1.2.1
(restricting outbound traffic that is not needed) provides, and can be safely compensated
for with firewall rules and host-based static routes if 1) it is expensive to implement
and 2) there isn’t a lot of stored cardholder data.”

Problem solved, John. You have to spend exactly $0 to meet the intent of this PCI
DSS requirement; just remove the default gateway on your BOH server and add a static
route for your payment gateway.

If your QSA gives you guff on this topic, refer them to PCI Ninja Rule #1:

“If a PCI SSC requirement is found, after evaluation, to fail to reduce risk commensurate
with the cost of meeting it, its intent should be met with a compensating control.”

Thank you for your excellent question, John, and thank you, dear reader, for your part in creating this new PCI Ninja Rule.