PCI and Wireless Technologies

While using wireless technologies in a PCI environment can be tricky, it is possible to configure it appropriately and obtain compliance (keeping in mind that misconfigured wireless networks are still a popular target for attackers to gain initial access and then springboard into the CDE).In this post, we’ll explore how to appropriately configure and maintain wireless technologies to achieve and maintain PCI compliance.

Wireless networks typically conjure up thoughts of Wi-Fi, access points, and SSIDs (Service Set Identifiers). But it’s more than that. Wireless technologies also include Bluetooth, ZigBee, NFC (near field communication), cellular (3G, 4G, and 5G), RFID (radio frequency identification), microwave, Z-Wave, and satellite, just to name a few. Wireless also includes any wireless-enabled devices connected to the CDE (a wireless card in a laptop, a wireless extender, etc.) It’s very seldom that an assessed environment only has wired technologies (and it’s even possible an environment can have only wireless technologies). Even if you are not using wireless to transmit cardholder data, you’ll still have a PCI burden. We’ll talk about that more later.  

If the assessed entity uses wireless technologies to store, process, or transmit cardholder data, the wireless technology is in scope. That’s pretty easy to identify. However, the technology is also in scope if it is connected to the CDE and not segmented (see my recent blog post regarding segmentation). That’s a little tougher to identify. These connected-to technologies are often overlooked during an assessment.

For in-scope wireless technologies, the following requirements apply (requirement numbers are from PCI DSS v4.0):

• 1.2.3 – Maintain an up-to-date network diagram that depicts wireless networks. This includes diagrams that show NSC (network security control) placement between fully out-of-scope wireless networks and in-scope infrastructure.

• 1.3.3 – Install NSCs between ALL wireless networks and the CDE (regardless of whether the wireless network is a CDE). If you previously attested under version 3.2.1 of the DSS, take note of the update to this requirement.  This is where the network diagram of out-of-scope wireless networks comes in handy. The NSC can only permit wireless traffic into the CDE that has an authorized business justification. (Note: Be sure your pen test includes these segmentation controls [Req. 11.4.5].)
• 2.3.1 – Change all vendor defaults. This requirement includes passwords on WAPs (wireless access points), but it also includes default wireless encryption keys (fixed pre-shared keys), SNMP default community strings, etc.
• 2.3.2 – Change wireless encryption keys a) when personnel with key management responsibilities change roles or separate from the company or b) if the key is compromised or suspected of having been compromised. Be sure to use long complex keys at all times (the longer the better!).
• 4.2.1 and 4.2.1.2 – Use industry best practices to implement strong cryptography (currently WPA2-AES or WPA3 at a minimum). Do not permit fallback to an insecure protocol or lower encryption level.
• 6.3.1 and 6.3.3 – Monitor wireless access points for vulnerabilities and update their firmware in a timely manner.
• 9.2.3 – Restrict physical access to WAPs. This might include placing the WAP behind a badge reader in a secure room, in a secure cage on the ceiling secured to something more than a false ceiling, etc. This does not include disguising it as a camera or just placing it freely in a high ceiling.
• 10.2 – Ensure WAPs and other wireless infrastructure are included in all logging implementations and meet the PCI DSS requirements in requirement 10.
• 11.2.x – Maintain an inventory of all authorized WAPs. Run a wireless analyzer at least quarterly to detect all WAPs. Compare to the inventory to ensure they are known authorized devices. Research and respond 24×7 to unknown or newly discovered devices (as outlined in your incident response plan). Be sure to cross-reference authorized devices to your network diagram in Req. 1.2.3. Note that an automated solution is not required but is highly recommended. Also, note that the PCI DSS requires quarterly inspections at a minimum. Let’s be hone, quarterly is a long time. An attacker could easily place an unauthorized WAP for a week or two and remove it and you would be none the wiser. From a risk perspective, automation or weekly inspections are recommended.
• 12.2.1 – All management-approved wireless technologies must be addressed in the acceptable use policy. The policy needs to define what wireless technologies are permitted and how they can be used.
• 12.10.1, 12.10.3, and 12.10.5 – Be sure your incident response program is documented, is staffed appropriately to respond 24×7, and includes a proper response for unauthorized wireless device detection.

If you have wireless and it’s not in scope, you still have some requirements to consider. Requirements 1.2.3, 1.3.3, 11.2.x, 12.10.1. 12.10.3. And 12.10.5 cannot be marked NA (not applicable) even if the policy forbids the use of wireless technologies. Testing will be required for each of these requirements as it relates to wireless. Whether approved or forbidden as a technology, segmenting the wireless technology, detecting unauthorized connectivity and responding appropriately are all requirements of the PCI DSS.  

By following industry best practices for the initial configuration and fulfilling these requirements for on-going management, assessed entities can use wireless networking in a PCI-compliant environment.  Contact GuidePoint for assistance in configuring and securing wireless infrastructure, scoping your wireless network from a PCI perspective, or assessing your PCI environment.