PCI Vulnerability Scans – Part II: PCI and Wireless

In my  previous PCI blog post we discussed risk level of vulnerabilities for PCI. In this blog post I will go over wireless requirements and how to detect rogue APs.

11.1 Test for the presence of wireless access points and detect unauthorized wireless access points on a quarterly basis.
Note: Methods that may be used in the process include but are not limited to wireless network scans, physical/logical inspections of system components and infrastructure, network access control (NAC), or wireless IDS/IPS. Whichever methods are used, they must be sufficient to detect and identify any unauthorized devices.

11.1.a Verify that the entity has a documented process to detect and identify wireless access points on a quarterly basis.

11.1.b Verify that the methodology is adequate to detect and identify any unauthorized wireless access points, including at least the following:

_ WLAN cards inserted into system components

_ Portable wireless devices connected to system components

(e.g., by USB, etc.)

_ Wireless devices attached to a network port or network device

11.1.c Verify that the documented process to identify unauthorized wireless access points is performed at least quarterly for all system components and facilities.

11.1.d If automated monitoring is utilized (e.g., wireless IDS/IPS, NAC), verify the configuration will generate alerts to personnel.

11.1.e Verify the organizationʼs incident response plan (Requirement 12.9) includes a response in the event unauthorized wireless devices are detected.

PCI wants you to detect rogue access points. However there is a flaw here. PCI doesn’t require you to monitor your network for rogue access points. It just want you detect them quarterly…

Well, what if attacker deploy an AP after you run your quarterly scan? You will be vulnerable lots of networking attack for a 3 more months and you will think you’re secure since you have PCI certification… This is another example of why you should not think you are secure just because you have a certification…

Anyway, let’s return our subject. So we need to determine rogue AP quarterly. Himm. Let’s see. We can do this by scanning all wireless APs and comparing the BSSIDs (mac address) of the APs that have same SSID with our APs. If we see any AP that has our SSID but not in our asset, that AP is a rogue AP.

A. Windows

Go to Start, type powershell, on the blue screen of power shell run these two following commands:

Netsh wlan show networks mode=bssid -> To get all BSSIDs

Netsh wlan show networks mode=ssid-> To get all SSIDs


KisMAC is a free, open source wireless stumbling and security tool for Mac OS

You can download it at http://kismac-ng.org/

After you run the KisMAC, click Start Scan in the bottom right corner.

C. Linux

Kismet is an 802.11 wireless network detector, sniffer, and intrusion detection system. Kismet will work with any wireless card which supports raw monitoring

mode, and can sniff 802.11b, 802.11a, 802.11g, and 802.11n traffic (devices and drivers permitting).

Linux users can download Kismet at http://www.kismetwireless.net

Note: Please read the full manual, but for the quick starters, here is the bare minimal instruction to operate Kismet:

• Download Kismet from http://www.kismetwireless.net/download.shtml

• Run “./configure”. Pay attention to the output! If Kismet cannot find all the  headers and libraries it needs, major functionality may be missing. Most notably, compiling Kismet yourself will require the development packages and headers, usually called foo-dev or foo-devel.

• Make sure that all the functionality you need was enabled properly in configure. Almost all users will need pcap and libnl support for proper operation.

• Compile Kismet with “make”.

• Install Kismet with either “make install” or “make suidinstall”.

Note: you must read the “suid” installation and security” section of the Readme or your system may be insecure.

• If you have installed Kismet as suid-root, add your user to the “kismet” group

• Run “kismet”. If you did not install Kismet with suid-root support, you need to start it as root in nearly all situations. This is not recommended as it is

less secure than privsep mode, where packet processing is segregated  from admin rights.

• When prompted to start the Kismet server, choose “Yes”.

• When prompted to add a capture interface, add your wireless interface. In nearly all cases, Kismet will autodetect the device type and supported

channels. If it does not, you will have to manually define the capture type   (as explained later in this README).

• Logs will be stored in the directory created when you started using Kismet, unless it changed via the “logprefix” config file or “–log-prefix” startup option.

• READ THE REST OF THIS README. Kismet has a lot of features and a lot of configuration options. To get the most out of it, you must read all of

the documentation.


With these tools you can get all SSIDs and BSSIDs on your area (It is good idea to capture packets in different areas of your buildings so that you have better chance to detect any existed rogue APs.


Update: I have received couple of e-mail about PCI scope on wireless. Here is what PCI says about it:

If wireless technology is used to store, process, or transmit cardholder data (for example, point-of-sale transactions, “line-busting”), or if a wireless
local area network (WLAN) is connected to, or part of, the cardholder data environment (for example, not clearly separated by a firewall), the PCI
DSS requirements and testing procedures for wireless environments apply and must be performed (for example, Requirements 1.2.3, 2.1.1, and
4.1.1). Before wireless technology is implemented, an entity should carefully evaluate the need for the technology against the risk. Consider
deploying wireless technology only for non-sensitive data transmission.”

I believe it is pretty straight forward.  If there is no separation of wired/wireless networks with a firewall on your cardholder data environment you cannot think wireless network is out of your scope…

One thought on “PCI Vulnerability Scans – Part II: PCI and Wireless

  1. Pingback: Information Security Blog » PCI Vulnerability Scans – Part I : Severity Levels (Risk Rankings)

Leave a Reply

Your email address will not be published. Required fields are marked *