Wireless networks and non-Windows based platforms affected

By Susan Lyon

The Payment Card Industry (PCI) Security Standards Council posted Version 1.2 of the PCI Data Security Standards (PCI DSS) on October 1. The major credit card companies require compliance with the PCI DSS rules via contracts with merchants and their vendors that accept and process credit cards. The new rules come out as many retailers still struggle to comply with Version 1.1. As several of the changes clarify or even ease former obligations, Version 1.2 will help, in some ways, with that compliance.

A few of the changes, however, may add to those struggles. Significant changes include heightened security requirements for wireless networks and expanded requirements to deploy anti-virus software beyond Windows-based platforms, including systems like UNIX. Merchants and vendors subject to PCI DSS rules should note these changes.

Significant changes

Significant changes in Version 1.2 of the PCI DSS that may impact your business include:

• Heightened protections for wireless networks transmitting cardholder data, "or connected to cardholder data environments," including requirements to:

          o Verify compliance with industry best practices (e.g., IEEE 802.11i) to strongly encrypt authentication and transmission of cardholder data
          o Cease use of WEP (Wired Equivalent Protocol), an algorithm used to secure wireless networks. Security experts generally consider WEP to be a less secure method for protecting wireless data than other methods, such as WPA.
          o Version 1.2 sets deadlines to stop use of WEP at the following future dates:  
                + No new use of WEP can be put in place after March 31, 2009.
                + All use of WEP must cease after June 30, 2010.
          o Cost of conversion from WEP to WPA can be quite costly for many companies.

• Extended need to deploy anti-virus software to all platforms. The former rule was understood to apply only to Windows-based systems. The new rule applies to any systems, including UNIX. The new rule also states that anti-virus software must guard against all known types of malicious software.

• Make mandatory the protection of public-facing web applications by either (1) reviewing and patching vulnerabilities, or (2) installing web-application firewalls. Version 1.1 had initially described these options simply as a best practice, giving until June 30, 2008 before becoming a rule. So technically, the compliance date had already passed, but issuance of Version 1.2 serves as a good reminder of this requirement.

• Added requirement to render passwords unreadable both in storage and in transmission. The prior rule only required passwords to be unreadable in transmission.

Other changes of note include:

• Increased responsibilities to create documents of certain processes. Such additional documentation includes: a diagram of the network showing cardholder data flows; documents to verify placement of firewall and router rule sets; log reports of audit trail histories; and forms for attestation of compliance for onsite assessments to be completed and signed by merchants/service providers and Qualified Security Assessors (QSAs).

• Specified list of critical employee-facing technologies needing review. That list includes: "remote access technologies, wireless technologies, removable electronic media, email usage, Internet usage, laptops, and personal digital assistants."

Clarifications/Relaxed Requirements
Many of the changes simply clarify rules, however, a few changes allowed for more flexibility, including:

• Relaxed firewall and router rules set review frequency to every six months. Formerly, reviews were set to quarterly.

• Replaced prescriptive requirement to use WPA (Wi-Fi Protected Access) or WPA2 (an advanced protocol that fully implements the 802.11i standard) to update firmware in a wireless environment. The new standard no longer mandates a specific type of technology. Instead, it provides more flexibility by simply requiring "strong encryption" technology.

• Clarified that internal and external penetration testing does not require use of a QSA or Approved Scanning Vendor (ASV). Penetration testing involves testing the vulnerability of a system by simulating an attack. Such testing can be done internally or using a regular third-party vendor. Individuals doing the testing, however, must be qualified and independent. If internal resources are used rather than external vendors, those individuals should be organizationally separate from those managing the tested system.

• Removed requirement to disable broadcast of SSID (Service Set Identifier, the name of a wireless network that gets displayed as a choice for users to connect to). Previously, it was thought that disabling broadcast of SSIDs would help secure networks. The current approach takes into account the fact that SSIDs cannot truly be secured. Despite disabling broadcast of SSIDs available for connection, once users actually connect to a network, networks display SSID in the clear.

Action items for your business

• Determine, if you use wireless networks, whether to transmit cardholder data or in connection with systems that do. If you do, review your security standards to ensure compliance with IEEE 802.11i. Put in place a plan to eliminate implementation of new use of WEP after March 31, 2009 and cease any ongoing use of WEP after June 30, 2010. As this can be a costly undertaking for many companies, be sure those in your organization who set technology budgets plan appropriately for this.

• Assess whether you use any non-Windows based platforms. If so, explore procurement of the many new anti-virus solutions for non-Windows based platforms. Prioritize roll-out to systems core to processing card holder data or in close connection to such central systems. Also, consider more vulnerable systems like personal computers.

• Review your processes for protecting public-facing web applications. First consider a process for regular review and patching of application vulnerabilities. If patching of applications is not feasible, consider as an alternative the installation of web-application firewalls. Addressing application vulnerabilities is generally considered to be a better security practice. Web-application firewalls, however, can be a good stop-gap solution until vulnerabilities can be addressed or if patching applications is not practical, for example, where older applications are soon to be replaced.

As Katherine Race Brin, attorney with the Federal Trade Commission‘s Division of Privacy and Identity Protection, noted at a recent data security workshop, data security compliance is an "ongoing process." As part of that process, you should regularly review your payment card security practices. At minimum, think about taking the actions described above. This is a good time, however, to consider whether you are due for a more thorough review. You may find the relaxed or clarified requirements help you realize significant savings. On the other hand, your review may reveal new obligations and risks which you will now need to find budget to solve. Whether you think you have achieved PCI compliance or continue to strive to get there, the release of this latest version of the PCI DSS should prompt you to revisit your current practices.

Susan Lyon, of counsel in Perkins Coie's Privacy & Security practice, provides practical advice to a broad range of multinational companies on privacy, data security, online safety and Internet laws. Her practice also includes regulatory compliance counseling, litigation, and legislative policy. Prior to Perkins, Ms. Lyon was in-house privacy counsel for Microsoft Corp. and Dell Inc. Ms. Lyon's updates on privacy and data security law can be found at the Perkins' Internet law blog, www.digestiblelaw.com. You can email her at slyon@perkinscoie.comThis e-mail address is being protected from spam bots, you need JavaScript enabled to view it or find her on Facebook.