If you are an information security professional whose organization handles credit card information, then unless you have been living under a rock since PCI DSS was first introduced in 2004, PCI compliance is a fact of life. Many love to bash the standard as the "low bar" for security, but when it comes to "Requirement 1: Install and maintain a firewall configuration to protect cardholder data," special attention to these five components (out of 21 outlined in Requirement 1), will a set a high, sustainable standard (yes&really!) for both security and PCI compliance.

1. 1 Verify that there is a formal process for testing and approval of all network connections and changes to firewall and router configurations.

What auditors are looking for here is for you to demonstrate that you have a clearly defined, enforceable change process for firewall policies. The auditor will ask to see a change report with a full audit trail, and then he will select some random changes and request to see the sign off. Problem is that many organizations still don't have a change process in place or, if they do, it is too loose or relies on good will rather than formal procedures. The best way to implement formal, auditable change processes is to automate them.

1.15: Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure. Examples of insecure services, protocols, or ports include but are not limited to FTP, Telnet, POP3, IMAP, and SNMP.

This section is concerned with three main risks:

1. Do you know which connections are required for business?

2. Is your firewall implementing the Principle of Least Privilege and allowing only connections that are required for business?

3. Are any of these connections insecure and do you have compensating controls for them?

The challenge here is that most organizations don't have an up to date list of services that are required for business. At the best case they have documentation per firewall rule. Most likely some of your connections will contain insecure services (remember: the list is open to interpretation by the auditor). Make sure you know about each of these services in advance and that you can justify it from a security perspective.

1.1.6 Requirement to review firewall and router rule sets at least every six months.

Once again, the auditor is looking for proof that you have a process in place to meet this requirement. Complying with this requirement usually entails having a report to show rule sets were in fact reviewed, and that any questionable rules from the last audit were addressed, and that any changes to rules since the last audit were dealt with properly (i.e. old or non-compliant rules/objects were dealt with). Around one third of companies fail to provide the required documentation to satisfy the auditor on this point because of poor processes.

1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment.

Usually the auditor is looking for a set of rules that permit specific PCI services (approved known protocols used by the PCI servers) followed by an explicit drop rule for all other traffic. Exceptions must include proper documentation (such as rule comments) that makes sense to the auditor.

Around one quarter of businesses find it difficult to correctly restrict inbound access; setting explicit drop rules is much easier. Proper definition of PCI services and PCI zones make compliance a no brainer. Make sure that your auditor agrees to the contents of PCI services and PCI zones. If you can prove that you have an active alerting mechanism to prevent non-compliant changes your auditor will be in check box happy mode.

1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ.

You need to allow traffic from the Internet to specific servers (IP Addresses) in the DMZ — everything else should be dropped. Again, a proper definition of traffic that is Internet (i.e. all non-local IP addresses) and a proper definition of the accessible IPs within the DMZ are critical here, and your auditor must agree that these are correct. Once these are in place, and you can prove that there is an active alert mechanism for unauthorized traffic, you're golden.

1.3.3 Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment.

This sounds simple enough, and it is...once you properly define the 'Internet' and 'cardholder data' environments. Your auditor wants to see that there is no direct access between these entities, and that there is proper evidence for this. Using tools to manage and document access will also prove to your auditor that you are serious about maintaining compliance and will also ensure you have the documentation ready for him.

This is not to say the rest of Requirement 1 is easy or unimportant. It's just that these five tend to be problematic because they rely on manual processes that no longer scale to meet the needs of the business — an increasingly common scenario. Level 3 and 4 merchants with large firewall estates will need to automate firewall operations at some point. If simply saying the words "firewall audit" are enough to make you groan, then you might be nearing that point.

While large-scale deployments are always intense, it could be an opportunity to introduce some long terms improvements that align PCI compliance efforts with your organization's specific security needs. The intent of the PCI DSS is to better information security across the board. Especially if you think it standard falls short, then leveraging PCI budget for projects that support compliance and security goals can be a win for the security team and keep your face time with your QSA to a minimum.

Reuven Harrison is the CTO and Co-Founder of Tufin. He led all development efforts during the company's initial fast-paced growth period, and is focused on Tufin's product leadership.