Examining PCI Requirement 1.5

At the end of each of the PCI DSS v3.2 Requirements, we have what we like to call a “capstone.” At the end of Requirement 1, there is PCI Requirement 1.5. It states, “Ensure that security policies and operational procedures for managing firewalls are documented, in use, and known to all affected parties.” PCI Requirement 1.5 is not only saying that your organization needs to maintain documented security policies and operational procedures; the policies and procedures needs to be known and in use by all relevant parties. It is a requirement of this framework that the affected parties use the policies and procedures as a way of managing your organization’s assets. It is not sufficient that you generate documentation just for the sake of the audit.

PCI DSS Requirement 1.5

At the end of each of the PCI DSS Requirements, we have what I call a “capstone.” Requirement 1, dealing with firewalls and routers and networking is not an exception to this. Each one of these capstones talks about the need to maintain policies and procedures and that these policies and procedures be documented and, effectively, known to all affected parties.

So it’s not just sufficient that you have this documentation in place. It’s not sufficient that you generate documentation just for the sake of the audit. It’s required that you as an organization implement the documentation, you implement the policies, and people are using this documentation as means and methods for managing their assets.

Unpacking PCI Requirement 1.4

PCI Requirement 1.4 states, “Install personal firewall software or equivalent functionality on any portable computing devices (including company and/or employee-owned) that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the CDE.” PCI DSS v3.2 explains that portable computing devices that are allowed to connect to the Internet from outside the corporate firewall are more vulnerable to Internet-based threats. The use of firewall functionality (e.g., personal firewall software or hardware) helps to protect devices from Internet-based attacks, which could use the device to gain access the organization’s systems and data once the device is re-connected to the network.

Requirement 1 has primarily been talking about securing your networks and establishing rules around firewalls and routers and all of those things to keep the bad guys out. Within the specific requirement, PCI DSS Requirement 1.4, it requires that where you have an employee-owned device or a laptop or a portable device that connects to the Internet and would also connect to your environment, we want to make sure that it as well has a personal firewall enabled. All of the rules that are subject to PCI DSS surround inbound and outbound traffic and establishing rules for authorized ports – all of that applies to this as well.

When we’re assessing for PCI Requirement 1.4, we expect that you have authorized ports and services that are allowed in and out of those personal laptops, employee-owned devices, or portable devices as well. These personal firewalls must be enabled, they cannot be alterable by the end-users. We want to make sure they don’t have the ability to open up a port or service that isn’t authorized to do so, or to shut if off if they desire to do so.

What is PCI Requirement 1.3.7?

The goal of your organization is to make it as difficult as possible for someone to hack into your environment. Disclosing the IP addresses you have within your internal environment are one of the things we, as assessors, look for to help you to achieve that goal.

PCI Requirement 1.3.7 states, “Do not disclose private IP addresses and routing information to unauthorized parties.” Additionally, methods to obscure IP addressing may include, but are not limited to: Network Address Translation (NAT), placing servers containing cardholder data behind proxy servers/firewalls, removal or filtering of route advertisements for private networks that employ registered addressing, and internal use of RFC1918 address space instead of registered addresses.

PCI DSS Requirement 1.3.7

We want to make it as difficult as we can to prevent somebody from hacking your environment. Disclosing the IP addresses that you have within your internal environment is one of those things that can help us achieve that goal. We do that by natting the traffic, inbound and outbound. We do not disclose your internal IP addresses unless it’s required for business.

In most cases, most organizations, based on their internal IP schema, are already hiding or masking their internal IP addresses. But if you’re a large organization, like a public university – a lot of times public universities will have public IP addresses to the desktop and running their own BCP routing rules – if that is the case, if there is an IP schema that is subject to your PCI DSS environment, you need to exclude that from your advertised routing routes.

What’s in PCI Requirement 1.3.6?

To meet PCI Requirement 1.3.6, your organization must not store cardholder data within the DMZ. PCI Requirement 1.3.6 states, “Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks.” PCI Requirement 1.3.6 also says, “Examine firewall and router configurations to verify that system components that store cardholder data are on an internal network zone, segregated from the DMZ and other untrusted networks.”

If your organization is storing cardholder data within your DMZ, assessors must examine the means and methods for moving that data into the internal environment. We see issues with this when organizations have an SFTP server or web server that is processing data. We recommend that you map a drive to your SFTP server, or web server, and when that data comes in, rather than writing it in to the local system within the DMZ, write that data into the corporate environment or into a server that resides within the cardholder data environment (CDE).

PCI DSS Requirement 1.3.6

PCI DSS Requirement 1.3.6 requires that we do not store cardholder data within the DMZ. The purpose and intent behind this particular requirement is that we’ve spent all this time within your environment hardening your assets, hardening the network, and doing everything we can to prevent the attack from getting any access to that asset. So if you’re storing cardholder data within your DMZ, we need to look at the means and methods for moving it into the internal environment.

A lot of times where we see issues with this is when organizations have an SFTP server or web server that might be processing data. When we talk about storage, we’re talking about persistent storage, meaning that if you’ve written it to hard drive, even for a millisecond, it’s considered stored. So what we would recommend that you do is take an opportunity to perhaps map a drive to your SFTP server or your web server, and when that data comes in, rather than writing it to the local system within the DMZ, is to write that data into the corporate environment or write it into a server that resides within the CDE.

PCI DSS Requirement 1.3.5 says to, “Permit only ‘established’ connections into the network.” The testing procedures for this requirement state that your assessor is to examine your firewall and router configurations to verify that only established connections are permitted into the internal network, and any inbound connections not associated with any previously established sessions, be denied. In years past, this configuration setting was called “stateful inspection,” also known as dynamic packet filtering, which is “a firewall technology that monitors the state of active connections and uses this information to determine which network packets to allow through the firewall.” Essentially, this ensures that your organization is only allowing established traffic back into your environment.

PCI DSS Requirement 1.3.5

When we look at the PCI DSS, it has a requirement that’s specific to Requirement 1.3.5, that says you need to allow established traffic. Effectively, what this is about is in years past, it was called “stateful inspection.” This is usually a configuration setting; most new hardware that you would implement today would support this by default. It’s either an actual setting that you use or it’s a checkbox on some types of devices. But effectively, we’re only allowing established traffic back into your environment.