This post contains the text from the White Paper: How to Implement and Maintain PCI Compliant Firewalls. Download the PDF below.
Because many aspects of data security start with firewalls, network firewalls comprise a huge part of the Payment Card Industry Data Security Standard (PCI DSS). A firewall’s goal is to filter potentially harmful Internet traffic to protect confidential data.
Simply installing a firewall on your organization’s network perimeter doesn’t make you PCI DSS compliant.
Firewalls are often riddled with configuration flaws and aren’t accurately protecting systems that touch payment card data. According to recent breaches analyzed by SecurityMetrics’ team of forensic investigators, 76% of investigated organizations had incorrectly configured firewalls.
To address these issues, there are over 20 PCI DSS sub-requirements outlining firewall specifics on how firewalls should be installed, updated, and maintained (e.g., semi-annual reviews on firewall rules). Your firewall obligations might seem overwhelming, but in this white paper, you will learn essential PCI DSS 3.2 and 3.2.1 changes, basic PCI DSS firewall requirements, and best practices for firewall implementation and maintenance.
PCI DSS FIREWALL UPDATES
PCI DSS 3.2 and 3.2.1 requirements for firewalls received minimal changes, with most of these updates being minor clarifications to existing requirements or geared towards testing procedures.
Service providers saw the most changes for firewall monitoring and testing procedures. A service provider is an organization that’s not a payment brand, but is directly involved in the processing, storage, or transmission of cardholder data on behalf of another organization (e.g., merchant processor). This also includes companies that provide services that control or could impact the security of cardholder data.
TIMELY DETECTION AND REPORTING FOR SERVICE PROVIDERS (REQ. 10.8, 10.8.1)
Service providers are required to “implement a process for the timely detection and reporting of failures of crucial security control systems,” such as firewalls.
Service providers need to respond to failures of any critical security controls (e.g., firewalls) in a timely manner. Processes for responding to failures in security controls must include:
- Restoring security functions
- Identifying and documenting the duration (date and time start to end) of the security failure
- Identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root cause
- Identifying and addressing any security issues that arose during the failure
- Performing a risk assessment to determine whether further actions are required as a result of the security failure
- Implementing controls to prevent cause of failure from reoccurring
- Resuming monitoring of security controls
Document that processes and procedures are in place to respond to security failures. Make sure staff are aware of their responsibilities in the event of a failure. If you are breached, document your organization’s actions and responses to the security failure.
Since February 1, 2018, service providers who use segmentation (e.g., segmentation through firewalls) will be required to perform penetration testing (e.g., segmentation checks) on segmentation controls at least every six months and after any changes to segmentation controls/methods.
The purpose of the penetration testing is to test segmentation controls/methods in use and verify whether segmentation controls/methods are operational and effective. This penetration testing should be performed by a qualified internal resource or third party.
QUARTERLY PERSONNEL REVIEWS (REQ. 12.11, 12.11.1)
Service providers need to perform reviews at least quarterly to confirm personnel are following security policies and operational procedures (e.g., firewall rule-set reviews, daily log reviews).
In addition, service providers need to maintain documentation of quarterly review process, including:
- Documenting results of the reviews
- Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program
Network firewalls can be software or hardware technologies that provide a first line of defense to a network. Firewalls restrict incoming and outgoing network traffic through rules and criteria configured by the organization. Secure payment card environments rely on hardware, software, and web application firewalls.
A hardware firewall–or perimeter firewall–is typically installed at the perimeter of an organization’s network to protect the internal networks from the Internet. Hardware firewalls are also used inside an environment to create isolated network segments. Higher security internal network segments would be created to limit access to sensitive data from networks that don’t need that access.
In summary, a properly configured hardware firewall protects environments from the outside world. For example, if attackers try to access your network from the outside, your hardware firewall would act as the first line of defense and should block them.
Most robust security option
Rules need to be carefully documented
Protects an entire network
Difficult to configure properly
Can segment internal parts of a network
Needs to be maintained and reviewed regularly
You also need a firewall between systems that store sensitive data and other systems on your network. Typically, this is a second hardware firewall installed inside your corporate network to create a secure zone to further protect sensitive data.
Many personal computers come with pre-installed software firewalls. This feature should be enabled and configured for any laptop computers that commonly connect to sensitive data networks. For example, if a sales manager accidentally clicks on a phishing email scam, their computer’s software firewall should stop the malware from propagating through the corporate network.
Protects mobile workers when outside the corporate network
Should not replace hardware firewalls for network segmentation
Easier to maintain and control
Doesn’t protect an entire network
Fewer security options
WEB APPLICATION FIREWALLS
Web application firewalls (WAFs) should be implemented in front of public-facing web applications to monitor, detect, and prevent web-based attacks. They can also be used to perform application security assessments. Even though these solutions can’t perform the many functions of an all-purpose network firewall, (e.g., network segmentation), they specialize in one specific area: monitoring and blocking web-based traffic.
A WAF can protect web applications visible or accessible from the Internet, including outward facing or intranet applications involving payment card acceptance. As per PCI DSS regulations, your WAF must be up-to-date, generate audit logs, and either block cyber attacks or generate a cyber security alert if an imminent attack is suspected.
Immediate response to web application security flaws
Requires more effort to set up
Protection for third party modules used in web applications
Possibly break critical business functions (if not careful)
Deployed as reverse proxies
May require some network re-configurations
A common firewall mistake is assuming they are a ‘plug and play’ technology. Organizations often don’t realize it’s necessary to configure the firewall to help with their unique environment.
After installation, you likely need to spend some time setting up your firewall so it restricts network traffic to only those authorized to access it (e.g., ports/services necessary for business).
Configuring firewalls can be difficult because there are many firewall rules to write, configure, and maintain, and even small mistakes can completely negate your firewall’s effectiveness and open you up to a data breach.
In a recent data breach investigation conducted by SecurityMetrics’ Forensic Investigators, an organization had a fairly sophisticated security and IT system. However, two incorrectly written firewall rules (amongst 300 pages of firewall rules, with about 100 rules on every page) essentially negated the whole firewall, leaving the entire network exposed. It was through this vulnerability that the attacker accessed their network and stole sensitive data.
To properly configure a firewall you need to restrict and control the flow of traffic as much as possible, specifically around the cardholder data environment.
Depending on how complex your environment is, you might require many firewalls to ensure all systems are separated correctly. The more controls you have, the less chance an attacker has at getting through unprotected Internet connections.
Access Control Lists (ACLs) help the firewall decide what it permits and denies into and out of your network. Firewall rules typically allow you to whitelist, blacklist, or block certain websites or IP addresses.
When no ACLs have been configured, everything is allowed into or out of the network. Rules are what give firewalls their security power, which is why they must be constantly maintained and updated to remain effective.
Remember, your firewall is your first line of defense, so you should dedicate time to make sure it’s set up correctly and functioning properly.
FIVE BASIC FIREWALL CONFIGURATION BEST PRACTICES
- SET SECURITY: Set security settings for each switch port, particularly if using segmentation
- ESTABLISH RULES: Update firewall rules if your applications and/or systems don’t have proper security hardening in place (e.g., out-of-date software, default accounts and passwords)
- INBOUND/OUTBOUND RULES: Decide what traffic comes in and out of your network
- USE VPNS: If using remote access, set up virtual private networks (VPNs)
- ADD/CLOSE SWITCH PORTS: Segment different networks with switch ports (e.g., Internet, office, CDE)
INBOUND FIREWALL RULES
If there’s strong business justification for allowing connections from outside, configure these connections properly. If not, the most secure option is turning off all remote access.
If you need to use remote access, you’ll need to set up a VPN. A VPN is a protected tunnel or pipe between an office computer and another computer connecting in through the Internet and should require a username, password and secret code (e.g., multi-factor authentication) unique to the remote computer.
OUTBOUND FIREWALL RULES
It may be tempting to allow everything out of your systems. But, allowing your computers to go anywhere will greatly increase the chances of malicious software infection.
If you haven’t already, now is a good time to think about the different roles or job functions that computers are used for. For instance, receptionists may need to access company email and websites. They probably don’t need Facebook, Twitter, Gmail, or anything else. You can whitelist these computers so that employees can only go to the websites you want them to go to.
On the other hand, employees may need the Internet for research purposes, so they need more open access. You can blacklist these computers so that they can go anywhere except to certain websites you don’t want them to visit. For example, they probably don’t need to use Facebook or YouTube.
You may also have some computers, such as one’s connecting to your CDE, which never needs Internet access. Block these computers from having any access to the Internet.
Merchants often setup large flat networks, where everything inside the network can connect to everything else. They may have one firewall at the edge of their network, but that’s it. Flat networks make securing your card data extremely difficult because if an attacker gets inside of the network, they have access to everything.
Further, initial intrusion in many of 2018’s investigated data breaches began in areas of the merchant’s network that shouldn’t have given the attacker access to the CDE. For example, since the merchant’s network was configured as a “flat network” (i.e., the entire network is protected only by a perimeter firewall, with no internal segmentation) it was not difficult for the attacker to migrate from the point of entry (e.g., employee laptop or work station) to the card data or other sensitive systems.
Firewalls can be used to implement segmentation within an organization’s network. When merchants create a secure payment zone firewalled off from the rest of the day-to-day business traffic, they can better ensure their CDE only communicates with known and trusted sources. This limits the size of the CDE and potentially lowers scope.
For example, you install and configure a multi-interface firewall at the edge of your network. From there, you create one interface on the firewall dedicated just to the systems that store, process, or transmit cardholder data. If that interface doesn’t allow any other traffic in or out of any other zones, this is proper network segmentation.
Yes, segmentation is not necessarily required to be compliant with PCI DSS 3.2.1. However, if you’re looking for one of the easiest ways to reduce cost, effort, and time spent on getting in-scope systems compliant, you may want to consider segmentation.
Segmentation can be extremely tricky, especially for those without a technical security background. Consider having a security professional double check all your segmentation work.
TEST AND MONITOR CONFIGURATION
As stated earlier, network firewalls aren’t a plug-and-forget technology. No matter the size of your environment, things change over time. Firewall rules will need to be revised over the course of a few months. That’s why PCI DSS requirements state organizations must review firewall and router rule sets regularly (e.g., at least every six months). While forcing you to ensure there are no security weaknesses, it also gives you the chance to update your firewall strategy.
FIREWALL REVIEW DATA
We asked over 350 individuals responsible for IT security and compliance decisions about how often firewall rules are reviewed by a security professional and/or third party; these are the results:
TESTING YOUR NETWORK
You need to test the effectiveness of your firewall rules. For example, you need to scan for rogue wireless access points. Rogue wireless access points can allow attackers unauthorized access to secure networks, giving them the access to attack your network remotely. Consequently you need to scan for rogue wireless access points, particularly if they are attached to your non-guest network. This helps you to identify which access points need to be changed.
Use vulnerability scans and penetration tests to find weaknesses in your network. Vulnerability scans are great weekly, monthly, or quarterly insight into your network security, while penetration tests are a more thorough way to deeply examine network security.
A vulnerability scan is an automated, high-level test that looks for and reports potential vulnerabilities. All external IPs and domains exposed in the CDE should be scanned by a PCI Approved Scanning Vendor (ASV) at least quarterly.
Typically, internal and external vulnerability scans generate an extensive list/report of vulnerabilities found and references for further research on the vulnerability. Some even offer directions on how to fix the problem.
Despite what many businesses believe, scanning is not enough. You can’t just scan and sit on the report. Act quickly on any vulnerabilities discovered to ensure security holes are patched and then re-scan to validate that the vulnerabilities have been successfully addressed.
If you are a service provider and you use segmentation, perform a penetration test on segmentation controls at least every six months and after any changes.
Although not required for all organizations or every SAQ types (except required for SAQ A-EP, B-IP, C, and D), organizations may find it helpful to request a penetration test to measure their business security. Helping you find security weaknesses, penetration testers analyze network environments, identify potential vulnerabilities, and attempt to exploit those vulnerabilities (or coding errors) just like a hacker would.
The time it takes to conduct a penetration test varies based on network size, network complexity, and the individual penetration test staff members assigned. A small environment can be completed in a few days, but a large environment can take several weeks. Typically, penetration test reports contain a detailed description of attacks used, testing methodologies, and suggestions for remediation.
FIREWALL LOG MANAGEMENT
Log management also plays a vital role in monitoring firewall security (and is yet another PCI DSS requirement). Set up logging so you have real-time alerts and backtracking to discover what occurred during a problem. Logs keep track of both normal and potentially damaging user actions happening against a firewall and help prevent, detect, and minimize the impact of a data breach. If event log software is configured correctly, administrators can be alerted if firewall logs indicate an attack.
BUSINESSES SHOULD REVIEW THEIR LOGS DAILY TO SEARCH FOR ERRORS, ANOMALIES, OR SUSPICIOUS ACTIVITY THAT DEVIATE FROM THE NORM.
To take advantage of log management, look at your security strategy and make sure these steps are taken care of:
- Decide how and when to generate logs (refer to Requirement 10.2).
- Secure your stored logs so they aren’t maliciously altered by cybercriminals or accidentally altered by well-intentioned employees.
- Assign an employee you trust to review
- Set up a team to review suspicious alerts.
- Spend time to create rules for alert generation (don’t just rely on a template).
- Store logs for at least one year, with three months readily available.
- Frequently check log collection to identify necessary adjustments.
Nearly all firewalls have very limited logging space. It’s important to set up a logging server somewhere in the office and configure the firewall logs to go to that server. Software on the logging server can monitor logs from the firewall, as well as from all other systems, and send an email or text alert if it detects you’re under attack.
LOG MANAGEMENT TOOLS
Given the large amount of log data generated by systems, it’s virtually impossible to manually analyze logs beyond one or two systems, especially reviewing logs all day. Log monitoring software takes care of that task by using rules to automate log review and only alert on events that might reveal problems.
You likely need Security Information and Event Management (SIEM) tools to sift through logs and drill down into problems. In the past, SIEM systems were only utilized in big companies, but smaller companies now realize system monitoring can help identify attacks.
It’s helpful to have a third party who specializes in log monitoring to interpret events because with each new operating system update, there is often change. If you really do have a problem, you can initiate your incident response plan (IRP).
Also, remember that in order to correlate events over multiple systems you must synchronize system times. All systems should get their system time from one or two internal time servers which in turn receive time
from a trusted external source.
Firewall documentation helps your team comprehend what has been done, what still needs to be done, and where the problems are in your environment. Ultimately, it keeps your security efforts organized and makes next year’s job easier. After all, updating already existing documentation is much easier than starting from scratch.
You’ll likely spend some time documenting your PCI firewall compliance process and what you’ve completed.
Make sure documentation is regularly updated, especially if processes and/or rules change.
Here are some of the most important documentation pieces to consider:
- Description of groups, roles, and responsibilities: By documenting who is involved in the firewall process, you ensure those assigned are aware of their responsibilities.
- Business justification for allowed services, protocols, and ports: Compromise often occurs in areas that are unused, unpatched, and unmonitored. Ensure your firewall only allows the minimum amount of connections required for your business to operate. If you need any ports or services open for your business to function, the PCI DSS wants to know why, and how you’re going to protect against those open areas (particularly if they’re insecure services or protocols).
- Network and cardholder data flow diagrams: As the PCI DSS states, “Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems.” Without an accurate view into how your network is set up, you could overlook devices that need to be part of your firewall rule set. Network and cardholder data flow diagrams help identify the location of all network devices and how card data flows through each piece of the network. While analyzing these diagrams, you should be able to study exactly what areas must be protected, and the unnecessary services, protocols, and ports to disable.
NETWORK AND CARDHOLDER DATA FLOW DIAGRAMS
Accurate cardholder data flow diagrams are vital for firewall documentation because they show how your systems are interacting with card data. Systems in your network that store, process, or transmit card data need to be properly secured and separated from other systems on your network.
Create a diagram that shows how cardholder data enters your network, the systems it touches as it flows through your network, and any point it may leave your network (e.g., sent to a payment processor). You’ll want to maintain a diagram for each card flow that exists. Some businesses will have just one flow, but you might also have an additional flow if your website processes payment cards.
Then you can overlay the card flows onto the systems in the network environment, and diagram and understand which systems store, process, or transmit cardholder data. You can examine your actual network and decide how it fits into your card flow diagram by asking yourself:
- How is my network constructed?
- Is there one firewall at the edge of my card-processing environment?
- Is my network segmented internally?
- Does my environment have a multi-interface firewall?
- Do I have multiple firewalls?
Make necessary adjustments to your firewall rules so that your organization’s firewall(s) is properly set-up.
Large environments typically have firewalls in place, at least at the perimeter of the network. Care needs to be taken to select firewalls that support the necessary configuration options to protect critical systems and provide segmentation between the CDE and other internal and external networks.
Smaller merchants sometimes struggle to understand firewalls, and may not have the necessary in-house expertise to configure and manage them correctly and securely. If this is the case, a PCI-validated third party service provider should be contracted to provide assistance, rather than simply deploying a default configuration and hoping for the best.
It may seem obvious, but leave as few holes as possible in your firewall. Rules should be as specific as possible for your environment. Spend the time to identify specific destinations; don’t just allow all access to the Internet.
Along the same line, if you have third parties that remotely support your environment, limit that inbound access to specific sources.
Firewalls are a first line of defense, and attention needs to be given to the logs and alerts they generate. Often, the volume of log data can be overwhelming, so merchants turn them off or discard them altogether. It’s important (and required) to review firewall logs daily, in order to identify patterns and activity that indicate attempts to breach security. There are many good software packages available to help merchants deal with the volume of log data and to more easily pick out the important data that requires you to take action.
For Requirement 1, remember three things:
- Strict firewall rules.
- Pay attention to what logs tell you.
- Review firewall configurations frequently, adjust as necessary, and document everything.
Security Analyst CISSP | CISA | QSA
THINGS YOU WILL NEED TO HAVE:
- Limited traffic into Card Data Environment to that which is necessary (1.2.1a)
- “Deny All” rule for all other inbound and outbound traffic (1.2.1b)
- Stateful Inspection/Dynamic Packet Filtering (1.3.6)
- Documented business justification for each port or protocol allowed through the firewall
- An automated audit log tracking all security related events for all system components
- An inventory of authorized wireless access points with listed business justifications (11.1.1)
THINGS YOU WILL NEED TO DO:
- Position firewall to prohibit direct inbound and outbound traffic from Cardholder Data Environment (1.3, 1.3.3)
- Create secure zone for any card data storage, must be separate from DMZ (demilitarized zone)
- Outbound connections from Cardholder Data Environment must be explicitly authorized (1.3.5)
- Document all firewall policies and procedures (1.2.1.a, 1.2.1.b, 1.2.3, 1.3, 1.3.3, 1.3.5, 1.3.6)
- Have a process in place to review the logs and security events at least daily, in addition to any reviews of system components as defined by the business for risk management strategy or other policies (10.6.1.b and 10.6.2.b)
- Have a process in place to respond to anomalies or exceptions (10.6.3.b)
- Keep all audit log records for at least one year and keep the last three months’ logs readily available for analysis (10.7.b-10.7.c)
- Run internal vulnerability scans on a quarterly basis using a qualified internal resource or qualified external third party (organizational independence must exist) and re-scan all scans until “high-risk” (as defined in the risk ranking requirement 6.1) vulnerabilities are resolved (11.2.1.a-c)
- Run quarterly external vulnerability scans (requires ASV) and re-scan until all scans obtain a passing status (no vulnerability scores over 4.0) (11.2.2.a-c)
- If wireless scanning is used to identify wireless access points, the scan must be run at least quarterly (11.1.c)
THINGS YOU MAY NEED TO DO:
- Install a firewall between wireless networks and Card Data Environment (wireless only) (1.2.3)
- Install a web application firewall on public-facing applications (6.6)
- If network segmentation exists, penetration-testing procedures must confirm segmentation is operational and isolates all out-of-scope systems from systems in the cardholder data environment (11.3.4.a)
To ensure your firewall does what it’s supposed to, consult with a security professional, such as a PCI DSS Qualified Security Assessor (QSA). You’ll want to discuss what firewall types you need to use and which firewall’s to purchase. This will prevent common mistakes and ensure everything is set up correctly. Make sure to take time to properly configure and periodically review your firewall rules/configuration.
Installing, updating, and maintaining your firewall can be difficult. Some organizations use managed firewall services to help them with complex firewall rules and firewall management.
We help customers close security and compliance gaps to avoid data breaches. Our forensic, penetration testing, and audit teams identify best security practices and simplify compliance mandates (PCI DSS, HIPAA, HITRUST, GDPR). As an Approved Scanning Vendor, Qualified Security Assessor, Certified Forensic Investigator, we have tested over 1 million systems for security.