This discussion item came up during recertification training last week. It caused a lot of debate from the QSAs in the room with no final decision on who held the correct point of view.
The PCI SSC, participating organizations and the card brands have stated that MPLS (aka, Multiprotocol Label Switching) is a private network, meaning that cardholder data transmitted over an MPLS network does not have to be encrypted. What was debated was the correctness of that decision. Where I come down on this issue is that MPLS on its face is not necessarily as private as one might think.
Unlike previous telecommunication solutions such as frame relay and ATM, MPLS is Internet Protocol (IP) aware. By definition, “When packets enter a MPLS-based network, Label Edge Routers (LERs) give them a label (identifier). These labels not only contain information based on the routing table entry (i.e., destination, bandwidth, delay, and other metrics), but also refer to the IP header field (source IP address), Layer 4 socket number information, and differentiated service. Once this classification is complete and mapped, different packets are assigned to corresponding Labeled Switch Paths (LSPs), where Label Switch Routers (LSRs) place outgoing labels on the packets.” The key here is that MPLS uses IP header information in order to properly route traffic. In essence, MPLS is no different from layer 3 IP switching/routing using VLANs on obviously a much larger scale.
Since MPLS is protocol aware, it allows carriers such as AT&T, Verizon, BT and the like to automatically reroute packets to avoid network congestion, outages and other issues that may affect network performance. Not only can the carriers reroute packets on their own networks, but they can also reroute packets onto other carrier’s MPLS networks if necessary. And best of all, this occurs automatically based on how your MPLS network is defined.
Carriers will point to IEEE 802.1q for securing MPLS networks. 802.1q is the definition for the tagging of VLAN traffic to separate traffic on the same VLAN. While in theory the standard does keep the traffic separated even on the same VLAN, it also can be intercepted with the right tools. So, security is in the eye of the beholder.
Contracts for MPLS service typically include clauses that indicate that the MPLS network will be private, meaning that one customer cannot get to another customer’s network and visa versa. But here is a potential glitch. If a carrier reroutes your MPLS traffic to another carrier’s MPLS network for any reason, there is likely no guarantee that your traffic will remain private.
So now that I have described what MPLS is and how it operates, what impact does or can it have on an organization’s PCI compliance? Well, it depends.
The primary point is that an organization’s network traffic is in the clear on an MPLS network, meaning that the carrier and anyone else that has access to the organization’s network can read packets on the MPLS network. Based on the architecture of MPLS, there are potential risks that the carrier could misconfigure the MPLS network and cause packets to cross to a path. While this sort of mistake is typically noticeable and rare, it has been known to happened, so it is not totally out of the realm of possibility. In addition, IP spoofing and similar attacks can be used to penetrate the 802.1q protocol, so it is not an absolute assurance that your traffic will stay secure over the carrier’s network.
Carriers operate multiple customer MPLS networks using large layer 3 switches and many VLANs. Traffic from multiple customers may be aggregated on a single VLAN or over their own individual VLAN. Regardless, VLAN access controls need to be understood and properly managed and maintained just like on your own network. Under MPLS, your carrier is just putting you into one or more VLANs to move your data from location to location. Under network segmentation rules, there needs to be proper controls in place to ensure that VLANs and access to them a truly separated. Remember, it is not just your data streams; it is many customers data streams being managed and separated. Under MPLS, I would argue that the carrier’s controls in this area should also be assessed for PCI compliance as well as the customer’s because the carrier’s network is just and extension of the customer’s.
Since the carrier is just an extension of the customer’s network, the carrier needs to be made aware of PCI or other sensitive network traffic so that they can take appropriate measures to ensure the security of the data stream. This may include having the carrier commit to ensuring the security of the data stream by segregating it from other customers’ traffic and not rerouting it to another carrier’s network. If the carrier is aware of PCI data traffic, the carrier is also responsible for complying with PCI DSS requirements to ensure that traffic maintains its privacy and security.
In response to the risks presented by MPLS, a lot of organizations just encrypt their network traffic. However, encryption defeats the point of MPLS because once the data stream is encrypted, MPLS can no longer have access to the IP headers. There is currently an IEEE working group that is developing a new encryption standard that will make IP packet headers readable while encrypting the packet’s payload, thus allowing MPLS to still route packets without having access to the data contained in those packets. When this new encryption standard will be released is anyone’s guess, but there is impetuous to get it agreed to quickly so that MPLS can be better secured.
The bottom line is that MPLS may or may not be private. It all depends on how the carrier implements it. As a customer, I would recommend that you discuss your network security and privacy requirements in detail with your carrier so that they can accommodate your requirements and understand their potential obligations. Do not just accept their assurances that MPLS is private. In the end, if the carrier cannot ensure the security and privacy of your data, then MPLS is likely not your networking solution.
The PCI SSC has issued and FAQ on this topic. To quote the Council:
Is MPLS / X.25 / ISDN / <insert your technology here> considered a private or public network for the purposes of PCI DSS Requirement 4.1?
The intent of PCI DSS Requirement 4.1 is to prevent cardholder data from being intercepted and/or diverted while in transit over a public or shared network. In order to establish whether a particular network should be considered private or public, the QSA would need to review the specific network provider and configuration details and determine whether the network could expose data to the Internet or other untrusted networks.
For example, the network may be configured to share IP addresses among multiple entities, and expose an entity’s traffic to the Internet through an edge router or other shared device with an Internet port. In this example, the network should be considered as being public or untrusted. In order to be considered “private”, the network in question must not be exposed to the Internet or any other public or untrusted network.
If the network is maintained by a third party service provider, the QSA should also review the service documentation to see if it includes data privacy provisions.
If the QSA cannot gain assurance that the privacy of data is maintained while in transit over the network from end-to-end, they should consider the network to be public for the purposes of Requirement 4.1