PCI DSS Wireless: To be or NOT to be.
I have seen numerous disparities as to the interpretation of the applicability of the wireless controls, within PCI DSS, e.g:
Many PCI DSS assessments appear to take the shortcut in regards to the consideration of the applicability of wireless controls, using the fact that the business being assessed does not 'officially' employ wireless technologies. This is far from being in the interest of the business, being that privileged users or malicious individuals may employ such devices:
Surely the applicability of these controls should be clear but this issue has been a hot topic of debate, within the Payment Card Industry Qualified Security Assessor (PCI QSA) community, for a long while:
Where does this leave the assessed entity, who has the previous PCI QSA mark their quarterly wireless checks as N/A and the next year's QSA be able to fail the same entity for not having carried out the quarterly wireless checks?
Which QSA is right?
Dependent on how the QSA has read the PCI DSS, both options are correct!!!!
How can this be, I hear you scream?
The simple reason is due to the fact that the PCI DSS contradicts itself:
Okay, so if wireless technology is not used, the requirements and testing could be regarded as N/A or optional. Correct?
Well, not if you read the specific controls guidance:
1.2.3. "The known (or unknown) implementation and exploitation of wireless technology within a network is a common path for malicious individuals to gain access to the network and cardholder data".
2.1.1. " If wireless networks are not implemented with sufficient security configurations (including changing default settings), wireless sniffers can eavesdrop on the traffic, easily capture data and passwords, and easily enter and attack the network".
4.1.1. " Malicious users use free and widely available tools to eavesdrop on wireless communications".
9.1.3. " Without security over access to wireless components and devices, malicious users could use an organization’s unattended wireless devices to access network resources, or even connect their own devices to the wireless network to gain unauthorized access".
11.1. " Implementation and/or exploitation of wireless technology within a network are some of the most common paths for malicious users to gain access to the network and cardholder data. If a wireless device or network is installed without a company’s knowledge, it can allow an attacker to easily and “invisibly” enter the network. Unauthorized wireless devices may be hidden within or attached to a computer or other system component, or be attached directly to a network port or network device, such as a switch or router. Any such unauthorized device could result in an unauthorized access point into the environment".
All of the specific controls guidance indicate that rogue devices could be attached to the network and systems, by malicious individuals, to steal cardholder data. Such wireless devices are not implemented by the business to store, process or transmit cardholder data, as per page 11, so would be marked as N/A. Consequently, no testing for wireless rogue devices would be needed or carried out.
Surely, any business that is processing large volumes of cardholder data would want to include the testing for rogue wireless devices, both from privileged users (yes, unbelievably, this does happen) or malicious attackers. In the event of a PCI DSS compliant business being breached, through the use of a rogue wireless device, would they still have a leg to stand on?
Perhaps, you think that this style of attack is not a THING! Think again:
If you have previously marked the wireless controls as N/A, I would encourage you to think again and I hope that when the PCI Security Standards Council re-write the PCI DSS, that the release of v4.0 will at long last provide the clarity on whether the testing for wireless devices is in scope, or not.
Don't get me wrong, I enjoyed almost 5 years working as a QSA to help businesses to understand the complexities of the PCI DSS and to successfully implement in order for them to achieve compliance, and to be less of a target to an attacker.
PCI DSS is not perfect but it does go some way to ensuring that a business' payment card operations are more secure. I would just like to see some consistency and a suite of controls that reduce the interpretation factor.
For example, Application Programmable Interfaces (APIs), in scope or not in regards to 6.5.1 to 6.5.6?
With all this uncertainty, as a business, do you understand the risks of accepting N/A marked controls when carrying out due diligence on your 3rd parties, or even when providing your compliance to your Acquirer or Customers?