PCI Compliance with Meraki
The PCI Standard
The Payment Card Industry Data Security Standard is a worldwide information security standard assembled by the Payment Card Industry Security Standards Council (PCI SSC). The standard was created to help organizations that process card payments prevent credit card fraud through enhanced security measures. The standard applies to all organizations which hold, process, or pass cardholder information from any card branded with the logo of one of the card brands.
The PCI DSS v3.2 standard describes clear requirements for building compliant wireless LANs. Meraki’s secure wireless solutions offer a simple, cost-effective means of achieving PCI compliance. Meraki’s integrated mapping, logging, and rogue AP detection tools eliminate the need to build a solution from component parts. In addition, centralized control of geographically distributed networks makes it easy to implement the same PCI-compliant architecture across large numbers of retail locations.
Meraki is certified as a PCS DSS v3.2 Level 1 Service Provider (the most rigorous audit level). You can learn more about Meraki's own PCI DSS compliance at https://meraki.cisco.com/trust#pci .
Network Segmentation and PCI Compliance
PCI audits can be expensive and time-consuming, especially when the audit scope includes your entire network infrastructure. PCI DSS security requirements apply to all system components, where “system components” are defined as “any network component, server, or application that possesses cardholder data or sensitive authentication data. Network components include but are not limited to firewalls, switches, routers, wireless access point, network appliances, and other security appliances.
Meraki’s cloud hosted WLAN controller is out of band, meaning that wireless traffic (including cardholder data) does not flow through Meraki’s cloud-hosted controller or any other Meraki infrastructure not behind your firewall. Meraki’s datacenters are SAS 70 type II certified, feature robust physical and cyber security protection, and are regularly audited by third parties. While Meraki’s datacenters are considered out of scope for any WLAN networks PCI audit, Meraki has taken the additional step to obtain PCI certification for our datacenters. Meraki datacenters have passed the Level 1 PCI audit, the most rigorous level for PCI compliance.
One way that the scope of a PCI audit can be reduced is through network segmentation. Network segmentation, or isolation of the cardholder data environment (CDE), from the remainder of the corporate network is not a PCI DSS requirement. However, it is recommended as a means of reducing the scope and cost of a PCI DSS assessment as well as a means of reducing general risk to the organization. If your wireless network is not being used to transmit sensitive cardholder data, then the wireless network can potentially be segmented from the CDE, removing the wireless network from the scope of a PCI audit. There are two ways to achieve this segmentation; locating the WLAN on a completely separate wired network infrastructure that is not connected to the CDE, and using firewall segmentation.
Wireless Network Not Connected to CDE
Segmentation can be achieved by locating the wireless network on a completely separate, parallel wired network that is not connected to the CDE at all. The access points cannot be connected to any switches, routers or other wired infrastructure that is connected even peripherally to the CDE. In addition, the wireless network must have its own Internet connection (ie. it cannot share a modem or firewall with the CDE network).
Firewall-Segmented Wireless Network Connected to CDE
If the wireless LAN is connected to the CDE, it can still be segmented from the CDE if it is separated from the CDE with a firewall according to the following PCI-DSS requirement:
1.2.3 Install perimeter firewalls between any wireless networks and the CDE, and configure these firewalls to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the CDE.
Meraki’s built-in firewall (LAN Isolation) can be used to effectively deny any wireless traffic into the local LAN or CDE. To provide complete segmentation of the wireless LAN from the CDE, LAN isolation must be turned on for all SSIDs.
A simple flow chart documenting how a network administrator can ensure that their Meraki wireless network is compliant with these requirements is included in Appendix A. In addition, an example of how to configure a segmented network in Dashboard is included in Appendix B.
VLANs and Network Segmentation
Virtual local area networks (VLANs) cannot be relied upon for network segmentation (eg. having the CDE on one VLAN and the WLAN on separate VLANs) and will not necessarily take the wireless out of the PCI DSS scope. Hackers can potentially hop across VLANs using known techniques if adequate access controls between VLANs are not put in place.
PCI Compliance for a Non-Segmented Meraki Wireless LAN
The following table lists the PCI requirements that are applicable to wireless networks that are part of the CDE (ie. are not segmented from the CDE and/or are transmitting sensitive cardholder data) and how a Meraki wireless LAN can be used to satisfy each requirement:
| PCI Requirement | Meraki Meets | How Meraki Helps |
| 1.2.3 Install perimeter firewalls between any wireless networks and the CDE, and configure these firewalls to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the CDE. | Yes | This requirement is considered a best practice even for non-segmented networks to limit traffic from the wireless network into the CDE to only that required for business purposes from authorized users and devices. Meraki’s built-in firewall (LAN Isolation) and Identity Policy Manager (IPM) can be used to effectively deny or control any wireless traffic into the local LAN or the Internet. LAN isolation should be used for guest SSIDs and IPM custom firewall rules should be used for other SSIDs to limit access to the LAN to business-necessary traffic only. |
| 2.1.1 For wireless environments connected to the CDE or transmitting cardholder data, change wireless vendor defaults, including but not limited to default wireless encryption keys, passwords, and SNMP community strings. Ensure wireless device security settings are enabled for strong encryption technology for authentication and transmission. | Yes | Meraki does not ship with default keys that need to be changed. Meraki supports the latest strong security standards and makes it easy to ensure they are setup correctly. |
| 4.1.1 Ensure wireless networks transmitting cardholder data or connected to the CDE, use industry best practices (for example, IEEE 802.11i) to implement strong encryption for authentication and transmission. | Yes | Meraki supports the strongest encryption standards, including WPA2-PSK, and WPA2-Enterprise (802.11i) with AES encryption. |
| 6.1 Ensure that all system components and software are protected from known vulnerabilities by having the latest vendor-supplied security patches installed. Install critical security patches within one month of release. | Yes | Meraki can automatically install the latest firmware on APs via the cloud. |
| 7.2 Establish an access control system for systems components with multiple users that restricts access based on a user’s need to know, and is set to "deny all" unless specifically allowed. | Yes | Meraki provides full, readonly, and lobby ambassador roles. Access can be further restricted to a specific wireless network within an organization. |
| 9.1.3 Restrict physical access to wireless access points, gateways, and handheld devices. | Yes | Meraki enterprise access points feature have 3 different physical security mechanisms, including padlock and security screw, that restrict physical access. Meraki APs can also be placed in the plenum to make them more secure. |
| 10.5.4 Write logs for externalfacing technologies onto a log server on the internal LAN…verify that logs for external-facing technologies are offloaded or copied onto a secure centralized internal log server media. | Yes | Meraki network logs are automatically stored in a centralized environment and backed up in geographically redundant data centers. |
| 10.6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion-detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers. | Yes | Meraki provides centralized monitoring and logging of all wireless access attempts in a detailed event log. |
| 11.1 Test for the presence of wireless access points by using a wireless analyzer at least quarterly or deploying a wireless IDS/IPS to identify all wireless devices in use. | Yes | Meraki includes IDS, also known as rogue AP detection, which reduces the need for manual scans. |
| 12.3 Develop usage policies for critical employee-facing technologies (for example, remote – access technologies, wireless technologies...) to define proper use of these technologies for all employees and contractors. | Yes | Implementer’s responsibility |
| 12.9.5 Include alerts from intrusion detection, intrusion-prevention, and file-integrity monitoring systems. | Yes | Meraki’s wireless intrusion detection system generates automatic alerts to warn of potential security threats. |
A simple flow chart documenting how a network administrator can ensure that their Meraki wireless network is compliant with these requirements is included in Appendix A. In addition, an example configuration of a PCI-compliant network configuration for a Meraki network that is part of the CDE is contained in Appendix C.
Additional details on the PCI requirements can be found by downloading the standard here.
Meraki PCI Report Tool
An administrator can check network settings against PCI DSS v2.0 and 3.0 WLAN requirements using the PCI Report page under the Monitor tab in an MR access point network. The results will indicate a pass/fail for each WLAN PCI requirement, with details on why. In the case of a failure, guidance is provided on what network settings need to be changed to get into compliance. The report can be printed and filed away or given to a security auditor. PCI DSS version 3.1 and 3.2 included minor changes to the 3.0 standard.
PCI Compliance Documentation
For PCI DSS documentation such as System and Organization Controls (SOC2) or Attestation of Compliance (AOC), access to the latest versions of these documents can be requested through the Cisco Trust Portal. Other relevant documentation such as the Consensus Assessment Initiative Questionnaire (CAIQ) or ISO compliances may also be available through this portal.
For questions on missing or outdated documentation, please open a Support case with Cisco Meraki Support, referencing the details of specific documentation required.
Summary
The PCI DSS v3.2 standard describes clear requirements for building compliant wireless LANs. Meraki’s secure wireless solutions offer a simple, cost-effective means of achieving PCI compliance. Meraki’s integrated mapping, logging, and rogue AP detection tools eliminate the need to build a solution from component parts. In addition, centralized control of geographically distributed networks makes it easy to implement the same PCI-compliant architecture across large numbers of retail locations. You can learn more about Meraki solutions for retail at http://www.meraki.com.
Additional notes
Access points running older firmware
There is a known issue with Dashboard and Legacy AP that are running older firmware and the PCI reporting function. Networks with AP that cannot run r27.x or r28.x firmware, but are running the latest available firmware for their platform, i.e. MR32/ 26.8.3, will seemingly fail a PCI report. Meraki is working on getting the reporting functionality updated to accurately reflect the software patch compliance of an AP that is running the latest firmware available for it.
Please note that the issue is cosmetic only and does not indicate a true out-of-compliance for the network(s) if, the only failure is 6.2 out-of-date software.