Requirement 11.1 of the PCI DSS requires scanning for rogue wireless access points. The risk identified here is that some miscreant will connect a rogue wireless access point to your environment, then sit in their car outside and sniff information with the goal of intercepting passwords and other sensitive information so he/she can steal cardholder data. This is an understandable view, don’t get me wrong, but it’s a limited view. The control is there to mitigate the risk of any miscreant doing it, as an internal or external risk, as it is far easier for a member of staff to gain access to the office environment and plug a rogue device in than an external third party.
The requirement is as follows:
“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.”
The methods above are slightly expanded from the methods enumerated in PCI DSS v1.2 and provide a bit more flexibility to merchants and service providers. In July 2009, the PCI SSC released an Information Supplement on PCI DSS Wireless Guidance prepared by the Wireless Special Interest Group. As that is a document just over 30 pages, I'll try to keep this short and sweet. If you're interested that document is available here: https://www.pcisecuritystandards.org/pdfs/PCI_DSS_Wireless_Guidelines.pdf
I'm going to go through the testing procedures for this requirement one by one for completion. However, only 11.1.b requires any real activity!
11.1.a Verify that the entity has a documented process to detect and identify wireless access points on a quarterly basis.
This is simply about incorporating the Wireless Scanning requirements in an appropriate policy (such as a Security Testing Policy). A quarterly process that identifies the controls to be implemented should be documented, and the required evidence and control forms referenced. The adequacy of the process is assessed in 11.1.b.
“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 (for example, by USB, etc.)
Wireless devices attached to a network port or network device”
If you use wireless devices, these should all be documented as part of the asset inventory. A simple process to validate the status of devices on the inventory against the active devices provides a good basis for control. Also look to the wireless systems implemented to provide you with additional functionality to manage PCI DSS requirements.
Network ports should be activated for required use only and a check of LAN and switch ports should be performed to verify only required devices are connected. E.g. if you have 10 servers and a firewall, you should probably have 11 cables going into your switch. While I know this is horribly difficult to monitor in many server rooms that are a cabling nightmare, tidy cabling can be a separate goal in itself and will not to be further discussed here!
Network Access Control can provide a simple solution to the issue, although with a heftier price tag. Any investment should be decided based on the requirements of the business rather than solely on compliance requirements. Technology alone does not solve the problem; it must be configured and maintained.
Regular system users should not be permitted to install Plug'N'Play devices to their systems. Role Based Access Control is already required within the PCI DSS requirements and this is something that is fairly easy to lock down in most environments (usually via group policy). Only devices that require and have authorised wireless access should have wireless configuration system services available.
On top of the normal physical security controls associated with a data centre or networking cabinet, racks should be locked and an eyes-on review should verify whether additional hardware has been introduced.
In terms of using tools an option which only requires configuration and some training is the use of the nmap scanner with the -O switch to identify wireless access points. The traditional use of WiFi analysers such as NetStumbler or Kismet will also assist you in establishing the wireless baseline of surrounding areas. Once the baseline is established, monitoring can be based on any identified changes.
The requirement does not specify all of the above need to be implemented. This is here to provide a flavour of the measures available to demonstrate compliance. The controls that are implemented must be effective; simply walking around once a quarter with a wireless scanner without direction does not provide adequate control. It is important to note the requirement calls for a methodology.
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.
If the environment is split over many sites or locations, the processes must be sufficient to cover the locations included within the scope of compliance, not just the sampled locations. If a third party hosting company is used as a Service Provider someone must be responsible for the controls at this location.
11.1.d If automated monitoring is utilized (for example, wireless IDS/IPS, NAC, etc.), verify the configuration will generate alerts to personnel.
If you are using a Wireless IPS (WIPS), configure the settings to email or otherwise alert the appropriate security personnel if rogue access points are introduced to the environment.
11.1.e Verify the organization’s incident response plan (Requirement 12.9) includes a response in the event unauthorized wireless devices are detected.
The whole process is broken if the people that you rely on to implement the controls do not know what to do in the case of exceptions. It is important for these controls to filter into the incident response framework. Incident response should include a provision for the processes to be followed for alerts about possible use of rogue devices, and invocation procedures if the presence of a rogue device is confirmed.