Passing PCI firewall audits: Top 5 checks for ongoing success

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.

[5 myths of encrypting and tokenizing sensitive data]

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?

[Payment card industry clears up confusion over cloud use]

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.

[Little sympathy for merchants in disputes over PCI violations]

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.

[Mobile shopping remains stifled by security, ease of use]

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.

Join the CSO newsletter!

Error: Please check your email address.

Tags security

More about SNMPTelnetTufin

Show Comments

Featured Whitepapers

Editor's Recommendations

Solution Centres

Stories by Reuven Harrison

Latest Videos

  • 150x50

    CSO Webinar: The Human Factor - Your people are your biggest security weakness

    ​Speakers: David Lacey, Researcher and former CISO Royal Mail David Turner - Global Risk Management Expert Mark Guntrip - Group Manager, Email Protection, Proofpoint

    Play Video

  • 150x50

    CSO Webinar: Current ransomware defences are failing – but machine learning can drive a more proactive solution

    Speakers • Ty Miller, Director, Threat Intelligence • Mark Gregory, Leader, Network Engineering Research Group, RMIT • Jeff Lanza, Retired FBI Agent (USA) • Andy Solterbeck, VP Asia Pacific, Cylance • David Braue, CSO MC/Moderator What to expect: ​Hear from industry experts on the local and global ransomware threat landscape. Explore a new approach to dealing with ransomware using machine-learning techniques and by thinking about the problem in a fundamentally different way. Apply techniques for gathering insight into ransomware behaviour and find out what elements must go into a truly effective ransomware defence. Get a first-hand look at how ransomware actually works in practice, and how machine-learning techniques can pick up on its activities long before your employees do.

    Play Video

  • 150x50

    CSO Webinar: Get real about metadata to avoid a false sense of security

    Speakers: • Anthony Caruana – CSO MC and moderator • Ian Farquhar, Worldwide Virtual Security Team Lead, Gigamon • John Lindsay, Former CTO, iiNet • Skeeve Stevens, Futurist, Future Sumo • David Vaile - Vice chair of APF, Co-Convenor of the Cyberspace Law And Policy Community, UNSW Law Faculty This webinar covers: - A 101 on metadata - what it is and how to use it - Insight into a typical attack, what happens and what we would find when looking into the metadata - How to collect metadata, use this to detect attacks and get greater insight into how you can use this to protect your organisation - Learn how much raw data and metadata to retain and how long for - Get a reality check on how you're using your metadata and if this is enough to secure your organisation

    Play Video

  • 150x50

    CSO Webinar: How banking trojans work and how you can stop them

    CSO Webinar: How banking trojans work and how you can stop them Featuring: • John Baird, Director of Global Technology Production, Deutsche Bank • Samantha Macleod, GM Cyber Security, ME Bank • Sherrod DeGrippo, Director of Emerging Threats, Proofpoint (USA)

    Play Video

  • 150x50

    IDG Live Webinar:The right collaboration strategy will help your business take flight

    Speakers - Mike Harris, Engineering Services Manager, Jetstar - Christopher Johnson, IT Director APAC, 20th Century Fox - Brent Maxwell, Director of Information Systems, THE ICONIC - IDG MC/Moderator Anthony Caruana

    Play Video

More videos

Blog Posts