03
Nov
10

Requirements That Are Never ‘Not Applicable’

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.

Advertisements

11 Responses to “Requirements That Are Never ‘Not Applicable’”


  1. April 28, 2015 at 2:23 PM

    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.

    • April 29, 2015 at 5:04 AM

      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’.

      • 3 Igor
        June 9, 2015 at 5:04 AM

        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”?

      • June 9, 2015 at 5:26 AM

        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.

  2. 5 Karima
    September 20, 2012 at 10:30 AM

    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

    • September 20, 2012 at 9:42 PM

      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.

  3. November 3, 2010 at 7:20 PM

    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.

  4. November 3, 2010 at 11:52 AM

    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?

    • November 3, 2010 at 1:25 PM

      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.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

November 2010
M T W T F S S
« Oct   Dec »
1234567
891011121314
15161718192021
22232425262728
2930  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,862 other followers


%d bloggers like this: