The Payment Card Industry Security Standards Council (PCI SSC) released version 3.1 of the Payment Card Industry Data Security Standard (PCI DSS) in April 2015. To help you make sense of the new standard, Solutions II is sharing a series of blogs throughout 2015 created by Tenable Network Security that focus on each of the twelve requirements. We’ll provide tips and pointers and clarity around “what’s new,” ultimately giving you a better understanding of the PCI DSS. The goal is for your organization to achieve a sustainable security posture that adheres to new and existing requirements and demonstrates continuous (business-as-usual) compliance.
The PCI Security Standards Council (SSC) went to great lengths to enhance the PCI DSS in version 3 by adding an informational section called Guidance. You should always reference this section to determine the context of a requirement and to understand how the PCI SSC interprets the spirit or intent of the requirement. Understanding the intent of the requirement is critical to not only assure that you are meeting the requirement, but even more so to determine viable alternatives or compensating controls to address the requirement.
This primary subject of this article is an explanation of the sub-requirements, clarifications, and enhancements under Requirement 1 which focuses on the implementation of firewalls and routers to secure your network.
This installment of “Committing to the 12-Step Program for PCI DSS” is the first of two articles that will focus on the major goal to “Build and Maintain a Secure Network and Systems.” Building and maintaining a secure network is tied to PCI DSS Requirement 1: “Install and maintain a firewall configuration to protect cardholder data.”[Note: A future article will focus on building and maintaining secure systems by focusing on PCI DSS Requirement 2: “Do not use vendor-supplied defaults for system passwords and other security parameters.”]
Since we are on the topic of building and maintaining a secure network, it seems appropriate to also spend some time discussing network segmentation as well. Let’s start with a brief overview of network security and segmentation to better understand the goals of network security for the payment card industry.
The Evolution of Network Security
A long time ago (the early ‘90s) personal computers were pretty much confined to the desktop and didn’t connect to each other. There were networks of course but they were mostly confined to the government and higher education for “research” projects and information sharing. The benefits of information and resource sharing made the use of network within companies and organizations more appealing, and the popularity of the Internet and web browsing (thanks Mozilla!) made the whole thing really take off.
Basic network security involves protecting your internal network from the external, untrusted Internet but at the same time providing a secure means of communication between other entities over the Internet and your own internal networks.
This basic paradox – the desire to provide open and free (and immediate) sharing of information while at the same time limiting or preventing access to said information is what drives the entire information security industry.
As networks started to emerge within organizations, and as these organizations started attaching to the Internet, there emerged a basic architecture design that came to be known as the “three-tier architecture.” The three tiers are basically 1) untrusted (e.g. the Internet), 2) semi-trusted (e.g. a DMZ), and 3) trusted (e.g. your internal network). Each tier would be logically and physically separated by network devices like routers and particularly firewalls that would control traffic flow into and out of your trusted network. The most common use of this architecture was in deploying e-Commerce applications.
In many ways, the Payment Card Industry Data Security Standard (PCI DSS), first published in 2004, reflects this 3-tier, e-Commerce architecture in its detailed requirements, particularly in Requirement 1. The supposition was that the primary “untrusted” network is the Internet, and the primary “trusted” network would be the internal or production network for most companies. Transaction information, customer sales records, inventories, etc., would all be maintained in databases that are required to be available only on the internal, trusted network, but would also be accessed and updated by consumers through ecommerce applications.
A Word About Network Segmentation
The PCI DSS also initially assumed that the entire network of the entity being assessed would be in scope because most networks back then were completely “flat” – meaning every system and network segment was logically reachable from anywhere else within the network (e.g. if you can reach it you can hack it).
To limit the scope of PCI compliance assessments, the PCI DSS provided the allowance for entities to demonstrate that their systems involved in payment card processing were logically and physically separated from other parts of the internal network through network segmentation.
This was a great idea because creating additional layers of segmentation would in theory make it more difficult for attackers to reach the cardholder data where it was being processed or stored. Unfortunately, the community latched on to the notion of segmentation being a great way to greatly reduce the “hassle” or “burden” of following all these silly security requirements found in the PCI DSS.
Let’s be clear about one thing: Network segmentation (beyond the 3-tier architecture model) is NOT a requirement for meeting PCI compliance requirements. It is a means to help isolate critical systems within a more tightly controlled area of your network, and thus making it harder for attackers to steal payment card data and commit fraud.
Most companies attempt some sort of network segmentation for a variety of good and bad reasons. What is often misunderstood though is that if you are creating a trusted network (the goal of network segmentation) within your corporate network you are declaring that your corporate network is untrusted – and therefore all aspects of Requirement 1 become applicable to your internal trusted/untrusted network segments in addition to your external network connections such as the Internet. That is, you need to implement a firewall(s) among your internal network segments, limit the ports/services that are allowed to communicate through the firewall, regularly review the firewall rules, monitor, log, and alert for security events, and so forth.[Note: Other PCI DSS requirements become applicable as well when you invoke internal network segmentation. For example, sending cardholder data over internal networks does not ordinarily require an encrypted transmission method, but if you are transmitting the data over “untrusted” portions of your internal network then Requirement 4 does apply (keyword == “untrusted”).]
Keeping all of this in mind, let’s take a look at how PCI DSS v3.0/3.1 requires you to build and maintain a secure network.
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
When you want to protect one area from another, you put a wall between them. In networking, the way you do this is by implementing a firewall. There is an implied ‘inside’ and ‘outside’ which can also be referred to as internal/external or simply trusted/untrusted. So, the first requirement in the PCI DSS states that you must implement the basic network protection of a firewall. The PCI DSS provides the rationale for this requirement:
“All systems must be protected from unauthorized access from untrusted networks, whether entering the system via the Internet as e-commerce, employee Internet access through desktop browsers, employee e-mail access, dedicated connections such as business-to-business connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.”
That part about “seemingly insignificant paths… can provide unprotected pathways…” is key. The vast majority of breaches that have plagued the payment card industry have been caused by the exploitation of one or more of these “insignificant paths” – some much larger than others. The proper implementation of firewalls and network devices to prohibit this type of access is vital to the protection of any sensitive data you need to protect, but none more so than payment card data.
1.1 Establish and implement firewall and router configuration standards that include the following:
If you haven’t figured it out yet, security starts with a written plan for how you are going to accomplish the goals of your (written) security policy. For 1.1, this means you have to have documented standards for your network devices. The requirement still includes “routers,” but to be honest, I haven’t seen a router in a corporate environment in years – it’s mostly switches or multi-purpose network devices these days. But I suppose there are still small routers used in retail locations, so the term has not been changed. The clarification that was added in PCI DSS v3.0/3.1 is to state that these configuration standards not only have to be documented, but implemented.
1.1.1 A formal process for approving and testing all network connections and changes to the firewall and router configurations
There’s nothing much new here. When the requirement says “formal process” what they really mean is that the process is written down and followed and that a record is kept of all connections and changes that are made.
This is vital information to have when conducting an assessment of whether an entity is actually keeping track of their network connections. You start with the configuration standard which says, “we only allow x, y, and z type of network traffic through the firewall.” Then you compare actual firewall rules to the configuration standard plus whatever change records exist that document what services are allowed.
1.1.2 Current network diagram that identifies all connections between the cardholder data environment and other networks, including any wireless networks
There was clarification added to this sub-requirement that actually spells out what needs to be included in the network diagram, namely all connections between the cardholder data environment and other networks (visually demonstrating network segmentation) as well as the location and connections to any wireless networks.
1.1.3 Current diagram that shows all cardholder data flows across systems and networks
It’s hard to tell how any PCI compliance assessment was ever completed without a clear understanding of all cardholder data flows, but this new sub-requirement finally makes what should be considered a necessity to be a requirement. It is important to note that there is more to this process than simply authorization and settlement flows. There are numerous post-settlement activities that need to be documented, as well as making sure all payment methods are accounted for (POS, phone orders, fax, email, e-commerce).
Understanding and documenting the data flow is a great way to discover unintended storage of cardholder data and helps to reduce data leakage or bleeding and the likelihood of compromise.
1.1.4 Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone
No change to this requirement.
Keep in mind that the concept of a DMZ is much more logical than physical these days, and multiple network segments are typically created and managed from one network device. The most common implementation these days is virtualized networks or (VLANs). Even with VLANs there must be a logical flow through a firewall component (virtual or physical) that creates the enforcement of access controls and preserves the trusted/untrusted separation of networks.
1.1.5 Description of groups, roles, and responsibilities for management of network components
No changes here.
1.1.6 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.
There was a clarification added to this requirement in terms of spelling out SNMP v1 and v2. Also, since this requirement mentions the Secure Sockets Layer (SSL) as an example of services allowed it is good to reiterate that the PCI DSS follows the National Institute of Standards and Technology (NIST) guidance for robust cryptographic systems as set forth in a series of Special Publications. In particular, NIST SP 800-52: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations (Revision 1) which prohibits the use of TLS 1.0, SSL 2.0, and SSL 3.0 to protect Federal information because of the reliance on cryptographic algorithms that are not approved. PCI DSS is basically following this guidance and is prohibiting the use of any version of SSL and “early TLS” after a grace period which terminates on June 30, 2016.
1.1.7 Requirement to review firewall and router rule sets at least every six months
No changes here.
Keep in mind that all of 1.1.x requires documentation first, and then an assessor would verify that the configuration standards are followed through a variety of exercises including sampling, interviews, observation, and examination of actual configurations compared to what is expected from the documentation.
1.2 Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment.
No changes here.
But remember that untrusted networks are any networks (including corporate and production networks) that are outside of your declared cardholder data environment.
1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic.
No changes here.
Don’t underestimate the importance of restricting outbound traffic. Some recent breaches involving malware attacks were successful in part because of the attackers’ ability to send the traffic out of the compromised network without detection.
1.2.2 Secure and synchronize router configuration files.
There is added clarification for this requirement that the intent of securing router configuration files is to prevent unauthorized access (and tampering).
1.2.3 Install perimeter firewalls between all wireless networks and the cardholder data environment, and configure these firewalls to deny or, if traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and the cardholder data environment.
This requirement has added language to clarify that the intent of the requirement is to restrict access to/from the wireless network and the cardholder data environment. Authorized traffic is allowed and must adhere to all PCI DSS controls.
The key here is to identify and allow only that traffic that is necessary for conducting business.
1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment
No changes here.
Remember that this requirement is a reflection of the 3-tier architecture model and there is an implied “two hops” required (meaning there is an intermediary network such as a DMZ) for any traffic between the Internet (or untrusted network) and the cardholder data environment.
1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports
No changes here.
This requirement specifies the need for a logical DMZ to prevent any direct communications between public, untrusted networks and the cardholder data environment.
1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ
No changes here.
1.3.3 Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment
No changes here.
1.3.4 Implement anti-spoofing measures to detect and block forged source IP addresses from entering the network
The wording was changed to this sub-requirement to explicitly state that the security goal is to prevent network traffic from being allowed through the firewall due to spoofing internal addresses. Some early firewalls could be fooled in this manner because the source IP would be checked and determined to be a valid internal address but the actual source of the network traffic was not verified (e.g. internal addresses can’t come from the Internet). For segmented networks, this is a little trickier to satisfy as the firewall needs to be able to distinguish between the trusted “internal” addresses and any other “untrusted” addresses.
1.3.5 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet
No changes here.
But remember, this is how so many of the malware attacks were successful in exfiltrating the compromised cardholder data out of the compromised retailers’ networks.
1.3.6 Implement stateful inspection, also known as dynamic packet filtering. (That is, only “established” connections are allowed into the network.)
No changes here.
1.3.7 Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks
No changes here.
1.3.8 Do not disclose private IP addresses and routing information to unauthorized parties
No changes here. The detailed requirements found in 1.3.x spells out the most common or known attacks against firewalls and specifies that these attacks should not be possible for gaining access to your cardholder data network.
1.4 Install personal firewall software on any mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), which are used to access the organization’s network
Minor changes were made to this requirement to align the language of the requirement itself and the testing procedure.
This is the final requirement in this first section of the PCI DSS, and requires personal firewall software to be enabled on mobile devices and laptops. If you would allow me a short nitpick: Yes, the word “firewall” appears in the requirement, and this is the firewall section, but in-practice the verification of this requirement generally is the responsibility of desktop or domain administrators whereas evaluation of all of the other firewall and router rules is the responsibility of network administrators. So, this requirement should really be part of the next section, Requirement 2.