Wireless Scanning Compensating Control

I got a comment regarding my post titled “Wireless Security – Random Thoughts On How To Fix” asking what sorts of compensating controls would address requirement 11.1.  Since I have been looking for a topic, I thought I would address this as well as provide people with an example of how you develop a compensating control.

In order to construct a proper compensating control, you must first answer a couple of basic questions.

  • Define the objective for the original requirement; and
  • Identification of how the compensating control addresses the aforementioned objective.

In order to be able to define the objective for the original requirement, you need to understand the requirement.  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.”  On the face of it the purpose of requirement 11.1 is to ensure that all wireless access points are accounted for at each location using a wireless scanner or WIDS/WIPS, so that any potential rogue access points are identified and therefore can be removed from the network.  But is that the “real” objective of the requirement?  Before you go running off for alternative ways of identifying rogue access points, let us ruminate a bit further about the objective of requirement 11.1.  What is the “real” objective of requirement 11.1?  The real objective is to make sure that rogue access points do not end up on your network and if they do, you can identify and remove them as soon as possible.

Remember the criteria for compensating controls.  Compensating controls must:

  • Meet the intent and rigor of the original PCI DSS requirement;
  • Provide a similar level of defense as the original PCI DSS requirement;
  • Existing PCI DSS requirements CANNOT be considered as compensating controls if they are already required for the item under review;
  • Existing PCI DSS requirements MAY be considered as compensating controls if they are required for another area, but are not required for the item under review; and/or
  • Be “above and beyond” other PCI DSS requirements.

With all of this in mind, what are controls you can put in place to keep rogue wireless access points from being placed on your network in the first place?  The following should not be considered a complete list of controls you can put in place, but it does provide enough controls to create a compensating control for requirement 11.1.

  • Disable all unused switch ports.  If unused switch ports are disabled, the installation of a rogue access point cannot be accomplished by plugging it into an open port on the switch.  This approach is usually not appreciated by network administrators as it requires the re-enabling of a port whenever a device needs to be added at a location.  It can also be disliked by remote facility personnel as it means there can be additional delays in getting another network device on the network.  While this control is referenced in requirement 9.1.2, it is not germane to requirement 11.1, so we can use this control for our compensating control for requirement 11.1.
  • Enable MAC address filtering on the switch ports.  This control will restrict what device can be plugged into an active switch port.  Essentially tying a single device to a single switch port.  As with the first bullet, MAC address filtering creates a network management issue when you want devices added or changed.  So you will be adding to the effort required to change any devices out in the field.  Since MAC address filtering is not required by the PCI DSS, this control will go above and beyond.
  • Monitoring of switch ports and generating alerts whenever a device is unplugged or plugged into a switch port.  Most switches will generate log entries when a device is either unplugged or plugged into a switch port.  Those events should be investigated immediately.  Such events can be the first sign of someone trying to plug in any sort of rogue device from a wireless access point to their own laptop.  Monitoring of this nature is required as part of requirement 10.  However, how you use monitoring to meet requirement 11.1 is not considered part of that requirement, so you can use the information you gather and monitor in requirement 10 to meet your requirement for 11.1.
  • Monitoring the network for any devices that do not respond to SNMP inquiries using your organization’s SNMP private community string.  Again, if a device does not respond to SNMP inquiries using your organization’s SNMP private community string it is either mis-configured or does not belong.  So if you cannot communicate with the device, it needs to be investigated and either fixed or removed.  Monitoring of this sort is not even called out in requirement 10, so I would say that this sort of monitoring would go above and beyond.
  • Disable dynamic host configuration protocol (DHCP).  DHCP is a wonderful service, but it is also a dangerous service.  It is dangerous because it allows any device, whether it belongs on your network or not, to obtain an IP address immediately when it connects to the network.  If any device can obtain an IP address when connected, then it has full connectivity to your network.  By not implementing DHCP, you remove that risk by requiring all devices to be preconfigured for their segment of the network.  Yes, your networking people will likely not appreciate this, but it provides a good security feature.  DHCP is called out as part of requirement 9.1.2, but again, it is not germane to 11.1, so we can use it here for our compensating control.

Because these controls can have a significant impact on your network and computing environment, we need to discuss a few more items.

First, you only need to disable DHCP at your retail locations, not your corporate office.  Typically, an organization has a lot more control over their computing environment at their corporate office, than at their retail locations.  As a result, enabling DCHP at the corporate office is not as risky, but you should still avoid enabling unused switch ports and unused jacks throughout any of your facilities.

If you are going to utilize wireless in any of your organization’s locations, make sure to properly isolate the wireless network from the rest of your network.  Even though you have implemented all of the compensating controls above to secure your network from rouge access points, you still need to ensure a secure wireless networking environment.  If you need wireless for operational purposes, make sure to secure it properly so that it cannot easily be compromised.  Such measures typically include not broadcasting the SSID and using WPA2 Enterprise security.

If you wish to provide wireless access to guests at your corporate office, make sure that their traffic is separated from any other wireless traffic and that they are only granted access to the Internet and no other internal resources.  A lot of organizations today require even guests to authenticate to their wireless as an extra security measure to keep people from using the available bandwidth at will as well as providing a mechanism to have guests acknowledge their responsibilities when using the wireless network.

Once you have the aforementioned information documented, you still have a few more things to cover in your compensating control.  You still need to implement your own feedback loop on these controls to ensure that they are functioning as designed.  Unlike Ron Popiel’s  miracle TV  oven, you cannot just ”set it and forget it” with these controls.  You need to have a plan in place to periodically follow up on all of these controls to ensure that they are functioning as designed.  Typically, that means tracking statistics collected from the monitoring controls.  It also means periodically observing these controls in action to ensure that monitoring is taking place and that ports really are disabled.  This sort of follow up is easily implemented as part of your financial field audit work.

In addition to your own follow up.  Your QSA also has to document what they did to confirm that these controls were in place and functioning as designed.  Their work is going to be similar to your own internal follow up work, but will likely be less extensive than your internal work as long as no exceptions are found.

You should now have a compensating control for requirement 11.1.  But better than that, you should now have a much better understanding of how a compensating control is developed and documented.


8 Responses to “Wireless Scanning Compensating Control”

  1. 1 QSA_Skeptic
    June 24, 2011 at 6:12 AM

    I understand what you’re trying to do in the above, but I don’t think it would cut the mustard if push came to shove. Indeed I’m going to go out on a limb and say that there is no possibility of mitigating controls available for 11.1.

    Interpreting PCI according to “constructive rules” there are four criteria that a “compensating control” must satisfy:
    1. Meet the intent and rigour of the original PCI requirement; and
    2. Provide a similar level of defence as the original requirement (ie, offset the risk that the requirement was designed to defend against); and
    3. Be “above and beyond” other PCI DSS requirements; and
    4. Be commensurate with the additional risk imposed by not adhering to the requirement.

    I’ve restated this because you’ve taken some liberty with your text above by implying that tests are an and/or affair. This is incorrect according to the PCI Glossary of Terms. We have to read precisely what is written, not what we assume it to read. Further, if PCI had wanted the tests applied in any other fashion, they would (or should) have chosen more precise wording (for example, “a control must meet at least one of the following criteria” or some other construction).

    Requirement 11.1 says that you have to test for the presence of wireless access points and detect unauthorised ones on a quarterly basis. The *intent* of the requirement is that you do something very specific (test for the presence of access points), the *rigour* is that it be done regularly (at least quarterly) and that the method used be sufficient to detect and identify unauthorised devices. The objective of the requirement is to create a control that limits the size of the attack surface.

    Thus, here is no “compensating control” that can be designed that will meet the first criterion that isn’t already 11.1 in substance:
    * if your control does not test and detect wireless access points then you fail criterion 1; and
    * if that isn’t done regularly (at least quarterly), or the method cannot detect and identify unauthorised wireless access points you fail criterion 1. 

    If your “compensating control” does do both of these things then it automatically satisfies 11.1, because the methods available for 11.1 “include but [are] not limited to” the methods that are mentioned in the Standard at that requirement. In this case you don’t have a “compensating control” you have a Method that satisfies 11.1.

    It is no doubt possible to design a compensating control to satisfy criteria 2 and 4.

    Criterion 3 is incredibly vague and I’d wager that it has no real meaning.

    Regardless, you’re always going to be tripped up by criterion 1 and I’m not sure that QSAs or acquirers have the right to waive or modify the “test” for the adequacy of compensating controls (save for discretion in interpreting what criterion 3 might actually mean in the context of a mitigating control for a particular requirement).

    The Standard was never designed to be subjected to this kind of analysis. Unfortunately, the structure of the scheme rules, and their incorporation into the merchant contract force you to read the Standard as though it were a set of contractual terms.

  2. 2 DWreck
    June 9, 2010 at 9:58 AM

    I disagree with the majority of this post. Maybe a proper NAC implementation would be a valid compensating control….maybe. The above recommndations do not scale and are subject to too many chances for errors i.e not enough automation.

    • June 11, 2010 at 4:38 AM

      NAC is a great solution, but not one that is affordable for all, let alone implementable for all. And that is just one of the issues with specifying specific solutions, not every solution will address every situation. I have clients large and small where NAC is just not a realistic solution for a variety of valid reasons. If only security were such a cut and dried area, we’d have solved this a long time ago.

  3. February 24, 2010 at 3:54 PM

    Definitely agree with the shortcomings to wireless scanning you detailed and your recommendations for network controls to satisfy the requirement. We’ve recently experienced a marked increase in demand for our product, Locate, which has a rogue access point detection feature to enable administrators to identify, locate, alert, and disable rogue access points on the network in real time. Our customers have relayed to us much of what you outline here, deciding against investing in a point solution, but instead choosing Locate to achieve PCI compliance for requirement 11.1 as a cheaper and more proactive alternative to handheld wireless scanners that also provides additional business value.

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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s


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.


February 2010
« Jan   Mar »

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

Join 1,981 other followers


%d bloggers like this: