Believe it or not, there are two PCI DSS requirements that can never be marked ‘Not Applicable’. According to the PCI SSC, requirements 1.2.3 and 11.1 can never be noted as ‘Not Applicable’.
Requirement 1.2.3 states:
“Install perimeter firewalls between any wireless networks and the cardholder data environment, and configure these firewalls to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment.“
Even if an organization does not have wireless, the PCI SSC has stated that this requirement may never be marked as ‘Not Applicable’. The QSA is required to document the network and describe any wireless the organization has implemented, regardless of whether or not the wireless has any contact with the cardholder data environment.
While this may seem a little over the top, think about why it is included in the PCI DSS. One of the largest breaches that ever occurred was the result of a poorly engineered and operated wireless network. As a result, to prevent future breaches due to wireless networking, the PCI DSS requires that the QSA ensure that any wireless, in or out of scope, is evaluated to determine if it is securely implemented.
When an organization does have wireless networking implemented, the PCI DSS requires that wireless networking to be segregated from the cardholder data environment (CDE) whether the wireless is used to carry cardholder data (CHD) or not. Again, this is in response to the large breach. Wireless is broadcast over public airwaves and an organization cannot be assured that someone is not eavesdropping on that broadcast. However, it is this broadcasting over public airwaves that trip up most organizations. People neglect or forget this fact and do not put in place the appropriate security and controls over wireless networks. As a result, the PCI DSS is trying to ensure that should wireless be compromised, the entire network is not also compromised by default. That then requires that controls such as ACLs and/or firewall rules are put in place to restrict traffic flow between any wireless networks and any other networks.
And even if an organization does not have wireless networking, under this requirement the QSA is required to document what procedures they used to determine that there was no wireless implemented.
As a result, a QSA is not allowed to place a ‘Not Applicable’ for this requirement.
As with requirement 1.2.3, requirement 11.1 was also put in place in response to that large breach as well as a number of other, unrelated breaches. This requirement is also in response to the low cost of wireless networking equipment and the ease with which it can be implemented in a stealthy manner thus providing an attacker with a way into an organization’s network. For reference, requirement 11.1 states:
“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.”
Whether an organization has wireless networking or not, the PCI DSS requires that the organization periodically assess its wireless networking posture to ensure that either wireless is still not present or that if wireless is used, that only the organization’s wireless is present on their network.
For an organization with only one or a few locations, this requirement is not that onerous. However, for a Wal*Mart or Target with thousands of locations, scanning each of those locations on a quarterly basis is daunting. As a result, you get wireless intrusion solutions such as those from Motorola and AirTight to automatically detect unapproved wireless devices. While these solutions meet the requirements of 11.1, they can be expensive and difficult to implement, monitor and manage. There is the alternative of implementing other controls on the network which can also be used to meet this requirement that I have discussed in another blog entry. However, this compensating control has its drawbacks as well.
As with requirement 1.2.3, no organization can mark requirement 11.1 as ‘Not Applicable’ just because they do not have wireless networking implemented.
At the end of the day, the bottom line here is that all organizations are required to ensure that wireless networking is either not present on their network or, if present, it is only their wireless devices and that those wireless devices are appropriately implemented and secured.
PCI Guru 
I realize this blog post is from 2010 and someone above mentions in 2015 that the FAQ was updated, but since then it seems like they also updated the ROC template and similar. Pasting from the 3.2.1 ROC template they now directly use 1.2.3 as a control you could mark N/A:
‘Requirements that are deemed to be not applicable to an environment must be verified as such. Using the example of wireless and an organization that does not use wireless technology in any capacity, an assessor could select “N/A” for Requirements 1.2.3, 2.1.1, and 4.1.1, after the assessor confirms that there are no wireless technologies used in their CDE or that connect to their CDE via assessor testing.’
Just giving a recent update on the topic in case other internet readers come by.
Even though there is a “NA” checkbox available, the Council still tells QSAs that 1.2.3 is NOT to be marked NA.
I didnt mention a checkbox, I quoted the advice for assessors in the current ROC.
The current ROC template text inside the ROC states “[…] an assessor could select “N/A” for Requirements 1.2.3 […]”. I’m not knocking your historical post or the reasoning in it, but I’m just saying the council seem to have updated the published advice inside the ROC.
If they have other current published advice that contradicts the advice inside the current ROC then I would be interested to read it, but I’m just pointing out the current ROC literally gives the example of an assessor being able to mark N/a for 1.2.3 in the ROC.
Where do you see this guidance for 1.2.3 in the ROC? Even the guidance in the PCI DSS does not mention anything about NA. There is only an option of ‘Yes’ or ‘No’ in responding to 1.2.3.b and in the case of a ‘No’ response, the QSA is still required to document what they did to prove that wireless is out of scope.
I also reviewed the FAQs and cannot find any references to guidance you point out. I need specifics as to where you are finding these references.
Okay, I found your reference on page 4 of the PCI DSS. Look at the conditions that statement requires. The assessee MUST have NO WIRELESS anywhere in their environment. That is not by facility, that is corporate wide. No corporate wireless, no wireless anywhere, period! If there is ANY wireless networking in place, they cannot mark 1.2.3 or the others as NA.
The blog doesn’t show me the option to reply to your comment #5 for some reason but yeah in the 3.2.1 Report on Compliance reporting template text, page 4.
I can see that in “an organization that does not use wireless technology in any capacity” that ‘any’ looks pretty strong, but, with apologies for being pedantic, the title of this bog post is “Requirements That Are Never ‘Not Applicable’” and I’m just pointing out that due to changes 1.2.3 isn’t any longer an example of that (for specific assessments that meet the criteria). As in, ‘Never’ doesn’t apply any more for 1.2.3 with the current ROC advice.
I’m not trying to wind you up – I’m thankful that someone is actually having a really good public discussion of 1.2.3 and similar and having a good debate on it. I agree with your stance and reasoning on how it should be completed.
The title of the post was related to a discussion at a QSA call where one of the Council members ran through a list of requirements that were NEVER to be marked as NA. The at a later Community Meeting the Council had a round table that resulted in my follow up post on some additional requirements that during the round table were also identified as not being acceptable to be marked as NA.
I am just passing along what the Council is telling QSAs and their AQM program is assessing QSACs against.
A lot of us have argued that 1.2.3 should be like 3.2.1/3.2.2/3.2.3 and not allow an NA response so that the QSA is required to explain the procedures followed to determine that wireless is not involved.
It appears this is no longer the case for 1.2.3. Right in the FAQ for Q19 it uses 1.2.3 as an example of a requirement you could mark N/A.
Interesting as the Council has still not shared that with the QSAs. I’ll have to submit a question to the Council and get their rationale for this change.
Thank you for pointing this out.
That said, note that it still requires testing of the environment to provide proof that the requirement can be marked ‘Not Applicable’.
Well, there is nothing mystical about being able to tick “N/A” in 1.2.3.
If you look at the reporting instructions in the ROC version 3.1:
1.2.3.a Describe how firewall and router configurations were examined to verify perimeter firewalls are in place between all wireless networks and the cardholder data environment.
=> There is NO perimeter firewall between wireless networks because there is no wireless network!
1.2.3.b Indicate whether traffic between the wireless environment and the cardholder data environment is necessary for business purposes. (yes/no)
=> There is no wireless network!
So, what else than “N/A”?
What we have always been instructed as QSAs to do is to document the procedures we followed to answer 1.2.3.a. So you respond to 1.2.3.a that you reviewed the network diagrams, conducted a facility tour and scanned the facility for 802.11a/b/g/n/ac in the 2.4GHz and 5GHz bands and found no wireless in the facility. I cannot tell you the number of times I have conducted those simple procedures only to find one or more wireless networks in a facility.
The bottom line is that you are not allowed to just blindly accept that there is no wireless in a facility without proving that is the truth.
Hi,
We have a Rogue access point alert system (FortiWifi). Do we have to activate the alerts and reports 24/7
or just quarterly / year as mentioned in PCI req 11.1?
thx
You can do whatever you want as long as you comply with the PCI DSS. I’m not sure how you only generate alerts quarterly, but you must be able to. And if you do, do you really want to follow up on the alerts generated during the quarter? Seems a little late in the game if you let a rogue AP exist for up to three months because you didn’t want to be bothered by alerts. I certainly wouldn’t want to explain that to my boss.
Actually we isolated it onto it’s own dedicated Internet router with a firewall monitoring both inbound and outbound traffic (I’m not a techie at this level so that’s about the extent of my firewall knowledge). This way, we can monitor the activities of anyone using it and since it’s not attached to our internal network, it doesn’t pose too much of a risk.
But yes, I thought this route was counter to security best practices — don’t install stuff you don’t need.
1.2.3 still confuses me when a company does not have (nor want) wireless access points within their establishment. We originally battled with our QSA over this issue and we found it was easier to install a wireless access point and lock it down rather than fight. The QSA had no issue with this solution. So how does installing a wireless access point in an environment that does not need one improve security?
It should not be confusing after reading this post.
If you do not have wireless, how has the QSA ensured that wireless does not exist? That is what the PCI SSC wants QSAs to document here. We didn’t get that explanation until we went through remediation.
For 1.2.3, the PCI SSC wants QSAs to say that they examined the network diagram, interviewed network administrators, observed facilities, reviewed network device configurations, etc. and therefore were able to confirm that wireless is not implemented.
However, you installed a wireless access point and then essentially made it unusable, that is hysterical. What a pointless exercise. Hopefully you have unplugged the AP and found it a new home off of your network.