Clarifying, Somewhat, The PCI Wireless Security Standards

GuestView Columnist David Taylor is the Founder of the PCI Knowledge Base and former E-Commerce and Security analyst with Gartner.

The Wireless Special Interest Group of the PCI SSC has just issued a set of guidelines to help companies ensure that their wireless networks are secure and effectively segmented to limit the potential for damage to the cardholder data environment if a portion of the wireless network should be compromised.

(Related story: our coverage of the new PCI wireless guideline document itself.) Given that such a compromise resulted in the TJX breach and many others, the document provides some very worthwhile guidance. OK. So it’s a good document. What’s the point of writing about an implementation guideline beyond telling people to read it? Actually, there are three points that I think are worth making relative to wireless security, based on our PCI best practices research:

  • A wireless IDS/IPS is still not mandated
    One of the technical controls that was introduced with PCI DSS 1.2 is the wireless IDS/IPS. It’s listed as an option, with the other option being to manually carry a laptop around corporate and stores running wireless networks on a quarterly (or more frequent) basis and see whether any networks appear that the security person (if any) does not recognize.

    Although it's certainly understandable that, for SMEs, the cost of a wireless IDS/IPS can be prohibitive, this is the sort of technology that should be mandatory for larger (i.e., Level 1 and 2) companies. That is not only because of the time and effort that it saves, but also because it can be extremely difficult to spot “rogue” or malicious networks in dense urban areas, shopping malls and large multi-company facilities.

    Beyond the analytics provided by such automated tools, it is also necessary for the company to maintain accurate device inventories and implement a thorough remediation process. But the point here is that the labor intense the wireless network detection process is, the less often it’s going to be performed, and the less value it’s going to deliver in terms of early breach detection.

  • Separating “Rogue” from “Malicious” WLANs
    One of the aspects of wireless security that I wish this implementation guideline covered in more detail is the detection of rogue wireless networks, especially at the store level. An increasingly common hack is for criminals to find live, open network plugs in the backend of retail stores and plug in small, discreet wireless access points, which can allow them to bypass some network segmentation controls, and remotely gather information.

    Whether in this document or another document, it would be a very useful guideline to help IT managers and even store managers know what to look for physically as well as technically. Although PCI QSAs are very experienced in looking for these hacks, many self-assessors rely heavily on simple network scans and do not do a physical inventory of all network access points at all stores to see what’s plugged into them.

    In addition, it is very rare for the results of the wireless network scans to be compared with an accurate store-level IT device inventory, because most are out of date or do not reflect the myriad different wireless network pilots, implemented by multiple local and regional vendors as well as corporate.

    The result is that a store manager or IT manager from corporate or a regional office may not be able to tell whether a new wireless network was installed by a legitimate vendor or was installed surreptitiously. Since most store or regional IT managers are reluctant to simply unplug a device (due to the risk of messing up a business application), malicious wireless network devices may be left in place for weeks or months at a time.

  • To Sample, or Not to Sample
    Finally, I rarely quarrel with the language in documents because it’s usually possible to discern the intent, even when the words may be confusing.

    But I think the issue of sampling store-level security as part of the PCI compliance assessment is important enough to bring up a quote from this document: “An organization may not choose to select a sample of sites for compliance. Organizations must ensure that they scan all sites quarterly to comply with the standard. The organization’s responsibility is to ensure that the CDE is compliant at all times. With that said, during a PCI DSS assessment, the organization or its assessor may choose to validate compliance with requirement 11.1 by selecting a sample of all locations.”

    This reads like the committee started to “get tough” on sampling, then decided to back off. But it does make sense. The point here is that a merchant cannot decide, before the fact, that it will only make some of its stores PCI compliant. All stores have to be made to be compliant. However, when it comes to validation of compliance, you can select a sample of stores for the test.

    Store level sampling is one area where we continue to hear “horror stories” – from both sides. Some assessors, to win business with low-cost bids, are still significantly under-sampling or they let the merchants pick the stores to be sampled. Some merchants, doing their own self-assessments, are selecting “known good” stores, rather than doing any kind of random or quota-type sampling.

    Given that the merchants bear the risk and liability, all of this may be perfectly reasonable. But it’s not the point of a sampling process that is designed to show “representative” results. The point here is that merchants have come a long way in some areas, but wireless security at the store level is still a “laggard” compared to other aspects of PCI compliance.

  • The Bottom Line
    There is a lot of activity in the wireless sector, especially with mobile payment starting to come online. I’m personally very interested in hearing about the wireless and mobile security issues and projects because we’re finding many examples that are not addressed explicitly by the PCI standards and companies are wondering if their projects are “safe” or whether they will have to make changes with the next version of PCI DSS comes out in the Fall of 2010. For more on this topic, please visit the PCI Knowledge Base, if you want to view our research. If you want to have a personal discussion about PCI and wireless or mobile payment issues, just send me an E-Mail at [email protected].