The importance of checking Firewall Rules and PCI DSS

Requirement 1 in the Payment Card Industry Data Security Standard (PCI DSS) is largely concerned with firewalls and how they are such a critical protection mechanism for network security.

What is a firewall and what is it supposed to do?

Let’s start with the basics. Firewalls have been with us since the late 1980s—security industry luminary Stephen Bellovin is credited with making use of the term Firewall to describe the process of filtering (including blocking) network traffic. They can be used to reduce the risk of unauthorised inbound traffic and data loss via outbound traffic.

There are different types of firewall that can operate at different levels of the TCP/IP stack; for example, a Web Application Firewall (WAF) as opposed to a packet filtering firewall that is not capable of filtering at the application layer. WAFs are included in PCI DSS requirement 6 and are not the focus of this article.

Over the ensuing years, network firewalls have steadily become more and more sophisticated to include additional functionality such as advanced threat intelligence, IDS/IPS capability and so on. However, they are not an ‘out of the box’ silver bullet solution and must be configured and maintained appropriately to continue as an effective control.

What does PCI DSS require from a firewall?

Excluding other security configuration requirements (such as not disclosing private IP addresses, and implementing anti-spoofing measures), here is a summary of the main objectives that firewall rules must meet to assist with compliance:

• Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment (CDE);
• Specifically deny all other traffic;
• Prohibit direct public access between the Internet and any system component in the CDE;
• Implement a DMZ to limit inbound traffic to only systems that provide publicly accessible services (like a web site);
• Prohibit unauthorised outbound traffic from the CDE to the Internet.

Over time, larger companies may have implemented an extensive firewall rule-set, and some of the common problems that can occur include rules that have become redundant and not required any more, duplicated or conflicting rules, or ones that are too promiscuous (i.e. they do not provide strict restrictions based upon source, destination, port, or protocol).

PCI DSS specifically requires organisations to carry out a review of firewall rule sets at least every 6 months (requirement 1.1.7), to ensure that only authorised rules are currently in place to match documented business justifications.

Those organisations that have a high volume of firewall changes may need to consider performing a review even more frequently.

How firewall rules can be a security issue

Let’s take a look at a few examples of how firewall rules can pose a security issue and be deemed non-compliant.

Here is a simulated network diagram and matching firewall rule-set. Can you spot any potential issues?

Line 1 define network internet (0.0.0.0/0)
Line 2 define network dmz (192.170.0.0/24)
Line 3 define network secure_area (192.169.0.0/24)
Line 4 define network internal (192.168.0.0/24)
Line 5 define host firewall (192.171.0.1)
Line 6 define host acquirer (8.8.8.8)
Line 7 define host dbserver (192.170.0.4)
Line 8 define host webservers (192.170.0.1, 192.170.0.2, 192.170.0.3)
Line 9 allow ssh from (internal, dmz) to firewall
Line 10 allow (http, https) from internet to dmz
Line 11 allow (https) from internet to 192.168.0.9 comment “temporary testing for project acme”
Line 12 allow (http) from internal to dmz comment “Monitoring”
Line 13 allow (http) from 192.168.0.10 to dmz
Line 14 allow * from internal to internet comment “allow regular staff access to everything”

Here are some indicators:

• Line 7 defines a database server as being placed in the DMZ, when it should be in the secure_area;
• Line 11 has 2 potential issues. It’s commented as a temporary rule, so is it still relevant or now obsolete? Also, it allows access from the internet directly into an IP address that is defined as being in the internal network;
• Lines 13 appears to be redundant as the previous line is allowing all internal IP addresses to access the DMZ;
• Line 14 is allowing unfettered outbound access for everyone.

There are plenty of PCI non-compliances there, which would hopefully be picked up by a diligent firewall administrator carrying out regular reviews as required by the standard. Don’t forget you will also need to maintain some form of evidence—such as details of rules amended, sign-off activity and dates—to show that the review process has occurred.

How PGI can help

PGI consultants can help by reviewing your firewall configuration, rule-sets, and procedures as part of our PCI gap assessment service. If you would like to discuss your PCI DSS compliance, contact us to talk to one of our experts.