If your business accepts credit card payments, then the way you handle that data is governed by Payment Card Industry Data Security Storage Standards (PCI DSS), not as a matter of law, but as part of your contract with the credit card companies whose cards you accept. Depending on how much you follow such things, you may or may not know that those rules changed Oct. 1, when the Payment Card Industry Data Security Standards Council issued PCI DSS 1.2.
Most of the changes are relatively minor, and intended to clarify points of misunderstanding contained in PCI DSS 1.1, which has been in effect since 2006, according to Bob Russo, the Council’s general manager. “People call us every day and ask, ‘Do security rules apply to routers?’ or to ask what we mean by ‘a regular basis,’” he says. The current changes are mostly intended to clarify this kind of confusion and remove redundancies, Russo says, but, he adds, "We did draw some lines in the sand."
Crossing those lines is a bad idea, with consequences including stiff financial penalties and increased transaction fees. Rather than take the risk it, it makes sense to learn about the new rules and the changes your company might need to make to comply with them. There’s no room to list them all here, so to get a complete picture we recommend reviewing both the new standards, and a summary of the changes on the Council’s website. Meantime, here are the items most likely to affect your business.
- WEP is disallowed. Wireless networks that contain or transmit cardholder data must be protected by encryption, and wired equivalent privacy (WEP) is no longer acceptable according to Requirement 4.1.1. It must be replaced with Wi-Fi protected access (WPA). “Over the years, WEP has been proven to be not as good as originally thought,” Russo says, and indeed the Internet offers many articles and videos that purportedly explain how to break WEP encryption in 10 minutes or less. “In the new standards, we said we don’t want to see any new WEP implementations after March 31, and existing implementations to be phased out by June 30, 2010,” Russo says.
- All systems “commonly affected” by malware must run anti-malware software. “It’s two changes in one,” notes Anton Chuvakin, director of PCI compliance solutions for Qualys, a software-as-a-service provider of security and compliance software and services. “The previous requirement was to use anti-virus software; now you have to have anti-spyware as well, and you have to extend it to all systems.” Those running the Linux operating system, for instance, might previously have skipped this step because few, if any, viruses or other threats are directed at Linux. The Council won’t specify exactly which systems are considered “commonly affected” by malware, except to say that most mainframes and some Unix-based server operating systems are probably exempted. But, it notes, the world of malware changes quickly and compliance with Requirement 6.2 means staying vigilant about the possibility of malware threats.
- Application firewalls are mandatory for Web applications. This was a recommended best practice until the Council made it part of Requirement 6.6 this past June. “Every Web facing application either has to go through a code review -- which is impractical for most small companies -- or install a Web application firewall,” Russo says. “You want to eliminate back doors and those sorts of things.” [A “back door” is secret access to software that bypasses passwords and other protections.]
- Logs must be saved for a year. Servers, computers, and other devices, as well as some applications, retain an internal log of all their activities. (For more on logs see this IncTechnology article.) Requirement 10.7 now requires companies to retain those logs for at least a year, and keep the most recent three months immediately available (archived online or available for quick backup from disk). PCI DSS 1.1 instructed companies to retain logs, but did not specify how long, Russo says.
- New-user passwords must be changed. It’s hard to believe anyone would be foolish enough to leave the factory-installed password on a router, server, or personal computer that processes cardholder information, but apparently, some companies are. Requirement 8.5 now makes that a violation of PCI DSS, and also requires that passwords include both letters and numbers.
Things to come
Before you get too attached to PCI DSS 1.2, keep in mind that yet another, newer version of the requirements will be arriving one day. During a recent conference on the PCI standards, representatives of the Council and industry representatives discussed items currently under review for future versions of PCI DSS. “They plan to work on addressing cardholder data after it's been collected but before it gets authorized,” says Amer Deeba, vice president of product marketing at Qualys. A second area, he says, has to do with the rapid growth of virtualization and the challenges of securing virtual machines. The third area, is internal transmission of cardholder data, for instance to employees who have no need to know them.
“There’s a huge desire in the credit card payment industry to address internal traffic,” he says. “PCI DSS 1.2 is still mostly focused on parameter threats.”