So you’re going through a PCI assessment for the first time and you start reading through the requirements mandated by your Qualified Security Assessor (QSA) and the PCI Council auditor. Naturally you start with the first Requirement: Install and maintain a firewall configuration to protect cardholder data. Well you have a firewall installed and the last time you checked there were rules configured, so you can just move on to requirement 2, right? Wrong! This Requirement can make or break your assessment. Without the proper configurations, audit tracking and proof of compliance, etc. you’re going to be hard pressed to pass it.
As an information security analyst, I have a lot of experience preparing for PCI audits. In this three part blog series I’m going to review the key points of PCI Requirement 1 and its subsections, and share some of the tips and tricks of the trade that I’ve learned over the years.
Requirement 1.1: Establish a firewall and router configuration standards
Requirement 1 ‘Install and maintain a firewall configuration to protect cardholder data’, is actually broken out into 5 subsections, and many of those have their own subsections too. Today we’ll focus on Requirement 1.1 which has seven sub requirements in total. These sub-requirement are actually the meat of PCI requirement 1. They help to ensure that you have your documentation in order and approved by the QSA before the audit.
- Formal process for approving all network connections and changes to the firewall (1.1.1):
- This is something that should already be in place in your organization, but the key here is that you’ll need to prove to the QSA that you have the ability to trace a change control ticket through your defined process. This is easier said than done. Make sure you have all parts flowing here (E.G Firewall changes that match up to change control tickets), before you present it to the QSA. If you miss one, they’ll want to dig deeper into your processes.
- Current network diagram with all connections to cardholder data, including wireless (1.1.2):
- The QSA is going to comb through all the network diagrams you give him or her to satisfy this requirement. A word of advice: make sure they don’t show any equipment that’s been removed and double check that these diagrams include all the latest network devices. You’re not doing yourself any favors by sending a QSA an outdated or incorrect network diagram – it generates more questions than you’re going to want to answer. Keep it simple and make sure to show any network devices, including wireless, that touch the CDE on the diagram. I would even go as far as to create “sanitized” versions of your network diagrams showing only the network devices within the PCI zone. There’s no reason to show them any more information than they need.
- Current diagram that shows all the cardholder data flows across systems and networks (1.1.3):
- This is a new requirement within the PCI 3.0 standard. Previously this requirement was ‘recommended’; now it’s mandatory. What the QSA wants to see is a flow of how card data moves within your network. What systems process the data, transmit the card information or store them. It also helps that you personally understand how the wheels of your environment work while looking at it graphically.
- Requirements for a firewall at each internet connection and between the demilitarized zone (DMZ) and the internal network zone (1.1.4):
- Okay, this is somewhat straight forward. You don’t need PCI to tell you to create a DMZ, or to put a firewall at every internet connection. If you don’t already do both, stop reading this blog post and get it done. And make sure that all the firewalls, DMZs and internet connections are on the network diagram you’re handing over to the QSA!
- Description of groups, roles, and responsibilities for logical management of network components (1.1.5):
- This is a document that shows the general responsibilities and roles of the network admins that manage the firewalls, routers, etc. These responsibilities need to be formalized in a document to show that everyone managing these devices knows what’s expected of them.
- Documentation and business justification for use of all services, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure. (1.1.6):
- This is another document that shows which ports and services are open within the PCI zone. This can be a major exercise, and an eye opening experience if you’re doing it for the first time. Why are certain ports and services allowed? Are they still being used? etc. The QSA will want to make sure that you have a handle on your open services and will most likely test this by running the router/firewall configs through some type of verification tool. The QSA will also be looking for any justification of insecure protocols, such as FTP, Telnets, RSH, etc. which may be in use on your network. It’s here that you’ll need to show justification as to why they’re being used and what you’re doing to compensate for them. The biggest issue here is to make sure you know what you have open within your network. Don’t let the QSA find it first and ask you why it’s missing from the documentation.
- Requirement to review firewall and router rule sets at least every six months (1.1.7):
- This is purely a documentation exercise, but it’s something that not only helps your enterprise mature, it’s also needed for PCI. To pass this requirement you’ll need to show that you have a scheduled audits or reviews of your firewall rulesets every 6 months. This is something you’ll have to sign off on and show dates as to when they took place. The QSA is going to want to see notes as to what was removed, if anything, and how the review was handled. This all needs to properly documented, including policies and procedures. A simple, “yeah we do that”, is not going to fly. You need the documentation to prove it.
In my next blog post we’ll focus on the second sub-section of Requirement 1 (1.2) Building a firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment. Be on the lookout for part two of our three part series coming soon.
Subscribe to Blog
Receive notifications of new posts by email.