The first step, as is with most parts of PCI, is to document! 1.1.2 was referenced in Chapter 4, “Building and Maintaining a Secure Network,” but it has applicability here specifically for wireless networks. Any wireless networks that are permissible in your environment should be documented in the network diagram you present to assessors. As an example, let's say that the only wireless permitted in your environment is a vendor wireless network that only has limited Internet access. Your network should already have a firewall between the unsecured wireless network and the corporate network. That action alone helps you meet most of PCI DSS. Even though it is not connected to any card processing networks, nor does it process cards itself, placing it on the diagram helps to illustrate that you have your ducks in a row.

Requirement 1.2.3 mandates that firewalls be installed between any in-scope networks and the wireless network. This is pretty self explanatory, but the part that can trip companies up is defining what is acceptable as a firewall. Because PCI DSS uses the word “perimeter” to describe the kind of firewalls you should use, many Qualified Security Assessors (QSAs) interpret that to mean a stateful inspection firewall like what you see in Requirement 1.3.6. Some QSAs might consider stateless packet filtering firewalls as a way to meet this requirement. With the flexibility that Reflexive Access Lists (RACLs) afford you as a stateful inspection access list, consider deploying those instead of new hardware. Watch your resource management, as any time you add filtering like this to your switches or routers, you will be adding both overhead and memory usage. Routers and switches at or near capacity should be upgraded before considering this type of deployment. The main point here is to put some kind of enforcement point between the wireless network and the wired network – preferably a stand-alone firewall – with the wireless network being on the untrusted side of the device.

Zooming to Requirement 12, we have more documentation-related items to address. Requirement 12.3 now includes wireless technologies. Remember, this is a policy document. If you set a company policy, your internal assessment group should conduct periodic reviews to ensure that the policies are being followed. Your QSA is not required to dig that deep, but a corporate policy that has not followed leads to a breach could prevent you from receiving safe harbor protection under the various card brand operating rules or applicable state or federal laws. The policies for Requirement 12.3 should address all the following before deploying wireless in your environment:

Most companies that deploy this type of technology can address the wireless components as part of their broader policy covering Requirement 12.3.

Next in Requirement 12 is 12.9.3, now expanded to include an incident response plan specifically for unauthorized wireless APs. If you follow PCI DSS to the letter, the possibility of activating this clause in your incident response plan may seem remote. It is. We'll get into that more later in the “Testing for Unauthorized Wireless: Requirement 11.1” section of this chapter.

By now, you are probably wondering when we will get to those fancy encryption requirements! It goes without saying, but building a secure environment where you operate any technology starts with documentation. Part of your wireless usage and deployment standards should include select elements from Requirements 2 and 4.

Wireless encryption technologies have come a long way in the last several years. Just 10 years ago, the only options for wireless encryption were using WEP or tunneling encryption inside your wireless connection such as a VPN or Secure Socket Layer (SSL) connection. Now, there are a multitude of options for both encryption and authentication. As of PCI DSS 1.2, WEP is no longer permitted as an acceptable protection technology. By the time you read this, no new installations using WEP may be deployed, and all existing ones must be upgraded by June 30, 2010.

Security professionals are quick to point out that WEP is simply encrypting packet payloads, and with additional protection like tunneled encryption and endpoint firewall technologies, it could still be a secure way to deploy wireless. Unfortunately for PCI DSS compliance, WEP is not allowed.

Requirement 2.1.1 lists five items that QSAs must check for to validate compliance. Your wireless installation should (at a minimum)

This dovetails nicely into Requirement 4.1.1 that simply reiterates that industry best practices should be used for encryption and authentication of wireless devices. This requirement overlaps with Requirement 2.1.1 somewhat but still should be viewed separately.

What constitutes an industry best practice for wireless security? For Wi-Fi installations, WPA or WPA2 should be deployed. WPA is increasingly coming under attack due to its reliance on WEP to function. WPA was designed as an interim fix to WEP until the 802.11i standard was finalized (also known as WPA2) and has recently demonstrated vulnerability to dictionary and “chopchop” like attacks due to its reliance on WEP. Details of these attacks can readily be found via your favorite search engine. New installations using Wi-Fi should absolutely use WPA2 with some form of unique authentication, sometimes called WPA2 “Enterprise.” Don't use shared keys (sometimes called WPA2 “Personal”). They are a pain to deal with and, for large installations, virtually impossible to maintain according to PCI DSS.

For other wireless technologies such as satellite, cellular, or microwave, encrypt transmissions with Triple-DES (3DES) or the Advanced Encryption Standard (AES) stream ciphers (or an industry-accepted algorithm of equivalent or better strength). Don't rely on the cost of communication interception equipment to secure these increasingly popular forms of communication. Such reliance is both risky and could lead to a false sense of security, further putting your company at risk.

Requirement 9.1.3 mandates physical protection for wireless devices. APs should be kept under lock and key, behind badged access doors, or in some cases, it should be protected with a cage. The intent of this requirement is to prevent an unauthorized user from tampering with the device. Don't rely on a 12-foot ceiling to protect the APs deployed on or above it. Ladders are readily available here in the 21st century. For that reason, don't rely on other physical hiding techniques, such as making your AP look like a smoke detector, to secure your hardware.

Wireless gets a quick mention in the dreaded logging requirement for PCI DSS. Be sure to include wireless logs from your AP in your centralized logging solution. Different vendors have different ways of communicating logging data but most can dump data via syslog(). Piggybacking on the same infrastructure that collects logs from routers and switches should be trivial to accomplish.

When it comes to wireless, there is no requirement more debated than 11.1. Security and compliance may not be farther apart anywhere else in the standard than they are right here. On one side, merchants are equipping district managers with basic wireless tools and making sure they hit each of their stores at least once a quarter. These merchants rarely are able to be compliant with the standard all year long as invariably stores are missed and equipment fails. Managers don't understand why they have to do it, and every merchant has at least one maverick out there that would opt to buzz the tower instead of respecting the controller's wishes.

On the other end of the spectrum, you have wireless defense vendors who tell their prospects that they cannot comply with PCI DSS unless they buy and deploy their wireless intrusion detection system (IDS) or intrusion prevention system (IPS) solution. One author knows he has ruined a few sales people's quarters by giving merchants alternatives to deploying wireless IPS. Early deployments were often costly, and retailers of any substantial size face mounting costs in deploying the technology in each store. A $2000 cash outlay for one location is easy to swallow, but that same outlay for a thousand locations suddenly becomes significant.

Then, in extremely rare cases, merchants have sophisticated enough network equipment to positively identify every device plugged into their network with automatic quarantine capabilities when devices that should not be active are plugged in. The number of ways you can attack this particular requirement are numerous, and the effective security of these solutions varies greatly.

The authors would like all those wireless IDS and IPS vendors to cover their ears for the duration of this paragraph. Just skip the rest of this paragraph, and go to the next one. Neither author wants to see this show up in a marketing slick, seriously. For the rest of you, the wireless vendors really do have your best interests in mind when they are pushing their products as a method to meet this requirement. One vendor in particular has a great analogy about scanning each store once per quarter (as the requirement states). It's equivalent of turning your firewall on for 1 day each quarter, then assuming nobody would want to come in and attack you until you turn it on for that 1 day next quarter. This analogy is fitting because it helps put things into context. It's also a great illustration on the difference between compliance and security.

Compliance with Requirement 11.1 means that at a minimum, you must scan each location with a wireless analyzer each quarter to identify all wireless devices. Should an unauthorized one show up in the scan, it should be traced down and efforts made to ensure that it is not affecting the security of the cardholder network. Alternatively, you can use a Wireless IDS or IPS to identify these devices in real-time, and in some cases, take action against them to prevent them from functioning on the network. Requirement 11.1.b mandates that if you do choose to use a Wireless IDS or IPS, it can generate alerts when unauthorized devices are detected, and should that event occur, 11.1.c ties into Requirement 12.9.3 discussed above (the incident response plan).

If you are using a wireless POS system for your stores, do yourself a favor and deploy an AP that has IDS and IPS functionality out of the box. Then, enable them and ensure that they can meet Requirement 11.1.b. If your plans include wireless POS, you should do everything you can to defend those devices. Make no mistake; if you deploy it, the attackers will come.

WEP has been proven to be a very weak encryption technique to secure a wireless connection. The article, “Breaking 104-bit WEP in less than 60 seconds” (http://eprint.iacr.org/2007/120.pdf), discusses how easy it is to break WEP. In a nutshell, there is a 3-byte vector called an initialization vector (IV). The IV is prepended onto packets based on a preshared key that all clients who need to authenticate must know. For most WEP hacks, you will probably only need tools like Kismet and the aircrack-ng suite. These tools can be downloaded freely from the Internet.

Ashley's Archery Adventures aims to revolutionize hunting through archery. Ashley started her business last year and has seen steady growth as adults and kids alike take on the challenge of archery. Ashley's business is built on a small 50-acre plot of land just outside of several large suburbs. Luckily, she was close enough to those suburbs to get high-speed Internet access for her office and POS devices.

Ashley spends much of her time out in the field (literally) and has set up several small covered areas where her customers can enjoy water and packed lunches in between archery stations. Because Ashley found herself away from her desk quite often, she put a small Wi-Fi antenna on a modest 100-foot tower by the main office so that she could use her laptop. She took the appropriate precautions to secure her network and used a long preshared key that she changed every quarter.

One day while at the main office, she noticed some strange pop-up windows appearing on her computer and suffered intermittent network blackouts. She installed antivirus and set her automatic patch update to run weekly, so she thought that maybe it was one of her software programs automatically updating itself. If that was not the case, she thought maybe the weather caused her wireless network to go on the fritz. She made a mental note of it and went on with her day. That evening, she noticed that the problem seemed to go away and things were back to normal. Two months later, she learned that she had been compromised.

Ashley was a victim of a common attack against laptops with Wi-Fi cards called the Evil Twin. Ashley frequently visited her local coffee shop on the weekends and used their Wi-Fi connection from her laptop. When the owner of the coffee shop added free Wi-Fi for his customers, he dropped a basic wireless router with default settings on a separate broadband connection for his customers. He didn't want to mess with security settings for his customers and get involved with fixing esoteric problems with each patron's laptop. Default settings seemed to avoid those problems. He also didn't want one of his users to potentially use so much of the Wi-Fi network that his store network was at, or beyond, capacity. This solution worked well for him and his customers.

When Ashley's laptop was acting funny 2 weeks prior, an attacker was cycling through commonly used default SSIDs and got her laptop to associate with his attack machine. Because he provided a stronger signal than the one Ashley was using at the time, her laptop automatically associated with his machine, and he was able to launch an endpoint attack against it. Ashley's laptop had not yet downloaded and installed a patch that fixed a remote vulnerability in the operating system, allowing the attacker to exploit the vulnerability and gain control of her machine. From there, he installed a rootkit and was able to gain access to other machines on the network, including her POS devices. He was also able to grab the Wi-Fi key and casually observe and participate in the network at will.

One of the dangers of wireless networking is the devices that use it. One author has enjoyed watching overly confident security professionals boast about the security of their Wi-Fi networks, only to have a savvy consultant attack a laptop directly (instead of trying to break the network encryption) to gain access. Sometimes computers try to out think their users and do things they “believe” are in the best interest of their users. One of those things is to choose the strongest wireless signal to get the best possible Internet connection.

You can combat this by never “remembering” the networks that you connect to, requiring users to specifically choose each network in which they want to participate.

After learning her lesson, Ashley quickly cleaned up her breach and was able to refocus on her business. She kept her wireless network intact, but she added additional protection with a host-based firewall for her laptop and then removed all stored profiles except for her office Wi-Fi. Her device is the only authorized device on the network at this time, but part of her improvement plan for this year is to put small POS terminals in some of the covered areas. She plans to offer more products for sale like cold beverages and food or snack items. Each covered area would have a PC to keep track of inventory or allow employees to send quick notes via instant messages or e-mail.

Ashley has budgeted a small amount of money to purchase both the hardware for the expansion plan and to build a small back-office network to maintain these devices. She wanted to provide network services to the devices to back them up daily and put important files on a network file server for all machines to use. Being as these machines would be somewhat exposed to the elements, she knew that equipment failure was a much bigger possibility than if those devices were kept in a climate-controlled office environment.

She purchases and deploys a Microsoft Windows 2003 Server and sets up her new employees in Active Directory with usernames and passwords. Each machine must log into the domain, and her “Rent-an-IT-Guy” sets up some basic network shares and permissions for each user. After he finished setting everything up, he left a small easy-to-follow guide for Ashley should she need to make minor changes.

Now Ashley must decide how she wants these machines to connect to the wireless network. It's impractical to go change Wi-Fi keys on these devices by hand every quarter, so she wants to find an automated solution or replace shared keys all together. What should she do?

Ashley has two choices. The first is to have her “Rent-an-IT-Guy” write a script that will change the Wi-Fi keys automatically on each PC in the field. This gives Ashley the advantage of keeping her existing setup that she is familiar with, but allowing the machines to easily change their keys while avoiding the headache of visiting each terminal and typing in the complex key by hand.

Ashley's second choice is to upgrade her Wi-Fi router to one that will support an enterprise authentication scheme with 802.11i or WPA2. From there, she can add an agent into each field computer's installation that requires users to authenticate with the network first with their existing username and password. This username and password could be part of their Active Directory credentials and would only require setting up a RADIUS server on the domain controller to enable this functionality.

Before security purists jump down the authors' throats, yes, we do realize that a single username and password that accesses all resources may add additional risk of compromise. That said, in this instance, the risk is relatively low provided that each user receives training on how to create good passwords or pass phrases, and they are changed regularly. Alternatively, Ashley could deploy an inexpensive token-based solution to provide a second factor of authentication that would effectively remove this weakness.

James's Junker Jubilee, a car rental facility that rents run down automobiles for a fraction of the cost of a traditional rental company, recently went through a PCI assessment. Upon arriving at their corporate headquarters, the assessors were placed into a conference room for the duration of the assessment. When it came time to ask about wireless technologies, Sally, a risk manager, proudly stated that wireless technologies were prohibited at James's and that employees found using these technologies were reprimanded with penalties up to termination.

The lead assessor casually looked over in the corner of the conference room where the audio/visual (A/V) equipment was stored and pointed out a blue device with two antennas on it. It oddly enough had a label on it that proclaimed “Property of IT, DO NOT REMOVE.” When the lead assessor examined it closer, it was an AP from a well-known supplier and was plugged into the Ethernet port in the wall. The assessor had an older model in his house, so he was sure he was looking at an AP and not something related to the A/V features of the conference room. Sally looked at the device and said, “Well, that showed up last month and we just assumed it belonged to IT and didn't touch it. The CIO has a lot of political power at James's, and most employees have learned not to cross him.”

It turns out, a hacker posing as a flower deliveryman gained access to the facility around Valentine's Day that year and placed the curiously labeled device in the conference room. He had been poking around the network ever since and had stolen both customer data and intellectual property. Because he had used several techniques to hide the device, the basic wireless sweeps that the company was performing did not pick up that device. To the wireless analyzer, it appeared to be coming from the community laptop at the front desk that was used to enter and print visitor badges.

Had James's used a Wireless IDS or IPS to bolster his security instead of relying on his quarterly wireless analysis as part of Requirement 11.1, chances are he would have had a much better chance of catching the hacker in the act and shutting down the connection before the breach of data could occur.