Understanding PCI Requirement 1.3.4

One of the most important things you can do as an organization to harden your environment, is to limit the outbound traffic from your cardholder data environment (CDE), or from your environment that you might consider sensitive, to the Internet. This outbound traffic should be limited only to that which is necessary to support your business. If you do need internet access for business purposes, that is okay. However, you need to make sure that it is documented and approved.

PCI DSS Requirement 1.3.4 explicitly states, “Do not allow unauthorized traffic from the cardholder data environment to the Internet.” Your assessor will be examining your firewall and router configurations to verify that outbound traffic from the cardholder data environment (CDE) to the Internet is explicitly authorized. Requirement 1.3.4 verifies that there is no unfiltered access to the CDE, and that all traffic is approved based on the list of authorized protocols, ports, and services from Requirement 1.1.6. Any traffic that is not authorized, should be denied.

PCI DSS Requirement 1.3.4

One of the most important things, in my opinion, that you could do is as organization to help harden your environment is limit the outbound traffic from your Cardholder Data Environment, or from your environment that you might consider sensitive, you limit that traffic out to the Internet to only that which is necessary to support your business. If you for some reason need Internet access, that’s great, that’s fine. Document it, making sure that it’s approved. However, what we expect is, we look at that list of authorized protocols, ports, and services from 1.1.6, and if it’s not authorized, you should be denying it.

Most organizations are really pretty good at doing the inbound filtering, but they seem to fail pretty bad at the outbound traffic. If it’s not required to process a transaction or required for the operations of your environment, it’s expected to be shut off.

PCI DSS Requirement 1.3.3 requires that organizations, “implement anti-spoofing measures to detect and block forged source IP addresses from entering a network.” Assessors will be looking at your firewall and router configurations to verify that anti-spoofing measures are implemented. There are several types of spoofing attacks, but in general, a spoofing attack is a situation in which “a malicious party impersonates another device or user on a network in order to launch attacks against network hosts, steal data, spread malware, or bypass access controls.”

In other words, PCI Requirement 1.3.3 ensures that your organization implements anti-spoofing rules to prevent attackers from “spoofing” their source address to trick your router into believing that the traffic originated from inside your network, allowing that traffic to pass through.

PCI DSS Requirement 1.3.3

PCI DSS has a requirement that you implement anti-spoofing rules. If you’re not aware of what spoofing is, I would recommend taking an opportunity to spend some time with Google and finding out what a spoofing attack is. But effectively what is happening is an attacker can mimic inbound traffic from the Internet, making it look as though it originated from your internal assets.

As an assessor, what we do is we look to make sure that you’re limiting inbound traffic based on 192, 168, 10.0 network, and 172.16 network. What this will do for you is it prevents someone from spoofing the traffic and making your router believe as though the traffic originated from inside of your network and then passing through.

What’s in PCI Requirement 1.3.2?

PCI Requirement 1.3.2 states, “Limit inbound Internet traffic to IP addresses within the DMZ and examine firewall and router configurations to verify that inbound Internet traffic is limited to IP addresses within the DMZ.”  PCI Requirement 1.3.2 requires that where your organization has established rules based on the list of approved protocols, ports, and services (from Requirement 1.1.6), traffic is stopped within the DMZ and it’s vetted against a set of appropriate rules before it’s allowed to traverse into your cardholder data environment (CDE). This doesn’t necessarily mean that the traffic originating from outside of your environment can’t eventually get into the CDE for some reason, for example, if you needed inbound traffic for processing. The purpose is to limit traffic to that which is necessary, and is authorized.

PCI DSS Requirement 1.3.2

We need to limit the inbound traffic from the Internet into your DMZ. This doesn’t necessarily mean that the traffic originating from outside of your environment can’t eventually get into the CDE for some reason, if you needed inbound traffic for processing or something of that nature. What it effectively means is that where we’ve established rules based on those protocols, ports, and services, we want to make sure that the traffic is stopped somehow within the DMZ and it’s vetted against a set of appropriate rules before it’s allowed to traverse into your Cardholder Data Environment.

Understanding PCI Requirement 1.3.1

PCI DSS Requirement 1.3.1 requires that you, as an organization, develop and implement a DMZ, otherwise known as a demilitarized zone.

What is the PCI DSS DMZ?

The PCI DSS requirements often refer to DMZs, or demilitarized zones. A DMZ is a sub-network that separates the internal network, in this instance your CDE, from all other untrusted sources. The DMZ should be a place where your public-facing web services exist and will keep you from exposing your CDE – where cardholder data and other sensitive data exists – from the Internet.

The DMZ can be configured a couple of different ways. You could have two physical firewalls between the Internet and DMZ and the DMZ and internal networks, or one single firewall that is appropriately configured with two network zones that are appropriately restricted between the two. Requirement 1.3.1 specifically states, “Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.” As assessors, we will be verifying if you have a DMZ, if it’s in place, and if it is operating effectively.

PCI DSS Requirement 1.3.1

Requirement 1.3.1 requires that you as an organization develop a DMZ. This DMZ is really established as a place where you can put your web services so that you’re not exposing your credit card information, your credit card processing, or any of the services that would be subject to cardholder data, to the Internet as whole. What we look for here is that you do indeed have a DMZ. This DMZ can be established by having two physical firewalls, or you can have a single firewall that’s appropriately configured with two network zones that are appropriately restricted between them.

What is PCI Requirement 1.3?

PCI Requirement 1.3 focuses on ensuring that you prohibit direct public traffic from the Internet into the Cardholder Data Environment (CDE). PCI Requirement 1.3 states, “Prohibit direct public access between the Internet and any system component in the Cardholder Data Environment.” The PCI DSS v3.2 says that the purpose for PCI Requirement 1.3 is to protect system components that store cardholder data. If the protections put in place are bypassed, your system could be compromised.

There are several ways that assessors determine PCI Requirement 1.3 compliance:

  • First, they will look at your organization’s policies and procedures. Policies and procedures are an important basis for compliance.
  • Assessors also examine to ensure that there is a firewall established between the DMZ and the Internet, as well as between your DMZ and your CDE.
  • The inbound traffic must terminate in the DMZ.
  • Assessors examine firewalls and routers and look to see what organizations are filtering for.
  • They make sure that all traffic that’s inbound into your environment is explicitly authorized as part of Requirement 1.1.6.
  • No cardholder data should be stored within the DMZ; if you’re doing that, then you don’t have a real DMZ.
  • If your organization has applications that accept credit card data for payment or for processing and temporarily write it into a file, assessors will tell you that this is specifically prohibited in the PCI DSS v3.2.

PCI DSS Requirement 1.3

Requirement 1.3 is primarily focused on ensuring that you prohibit direct traffic from the Internet into the Cardholder Data Environment. There’s several things that we look at in order to achieve this. First of all, we look at your policies and procedures. We look to make sure that you have a firewall established between the DMZ and the Internet. Next, we look to make sure that you have a firewall established between your DMZ and your Cardholder Data Environment.

Secondary to that, we also look to make sure that all inbound traffic is going to terminate into the DMZ in some capacity. We look at your firewalls and routers, and we look to see what you’re filtering for. We make sure that all traffic that’s inbound into your environment is explicitly authorized as part of Requirement 1.1.6, which we’ve often talked about. We look to make sure that you’re not storing any cardholder data within the DMZ; if you’re doing that, then you really don’t have a DMZ.

One of the areas where many organizations get in trouble here, is where they have applications that accept credit card data for payment or for processing, and they will temporarily write it into a file; that is specifically prohibited by the PCI DSS. Once again, Requirement 1.3 is making sure that we’re going to prohibit the inbound traffic directly into your Cardholder Data Environment and it is terminated into the DMZ.