The recent TJX Companies Inc. data breach refocused attention on credit card security, retailers and the Payment Card Industry Data Security Standard (PCI DSS).
PCI DSS is to the credit card industry what Sarbanes-Oxley (SOX) has been to publicly held companies. It's pushing them to comply with the PCI Security Standards Council guidelines, the most recent of which was drafted in September 2006. It forces card issuers and processors to invest in the necessary compliance technology and training or face crippling consequences. Those who don't can be heavily fined or barred from issuing or accepting cards from any council members. And, because the council consists of a consortium of five powerful card companies -- Visa, MasterCard, American Express, Discover and JCB -- not complying can effectively ban a bank from issuing cards or a merchant from accepting them.
PCI DSS is not groundbreaking; it is simply a set of information security standards no different than those at any large bank or publicly held corporation. But it has molded security throughout the credit card industry lifecycle, from how banks issue cards to how retailers accept them.
During the TJX breach, hackers stole an undetermined number of credit card accounts, some of which dated back to 2003; as a result, dozens of banks reported incidents of fraud from the compromised cards. Also, because TJX had stored old account information instead of deleting it, the company violated a PCI requirement, which mandates that a company remove data it no longer needs.
In total, there are twelve PCI DSS-required controls. They cover access management, network security, incident response, network monitoring and testing and information security policies. PCI DSS critics claim, in some cases, that it's too restrictive; it interferes with how companies set up firewalls and antivirus software, for example, and is too vague in other areas like incident response and network monitoring.
Additionally, these twelve controls are grouped together under six PCI DSS "control objectives." They include:
- Build and maintain a secure network -- Ensure firewalls are installed and that changes to rules are adequately logged. Web servers that must access the Internet should be in a DMZ. Database servers holding customer account information should be inside the company's network, protected by a firewall. Note: For the most part, these requirements are already part of the networking staff's routine job responsibilities.
- Protect cardholder data -- Stored account numbers must be encrypted or truncated, and customer data must be disposed of when no longer needed. This was the fatal mistake in the TJX case. Encryption over public networks for data in motion should be done using SSL.
- Maintain a vulnerability management program -- This control covers a wide range of requirements. It requires antivirus software on all servers and workstations, and recommends everyone follow guidelines from the Open Web Application Security Project (OWASP) for developing Web applications.
- Implement strong access control measures -- Restrict access to systems with account numbers and ensure user accounts are audited to remove outdated or malicious accounts. Stored passwords should also be encrypted.
- Regularly monitor and test networks --Require regular vulnerability scans, reviews of server logs and the installation of intrusion detection or prevention systems (IDS and IPS).
- Maintain an information security policy -- Draft an information security policy that covers access control, network and physical security, and application and system development. It's important to keep the policy updated as systems and needs change, and to make sure it's distributed to system users.
The standard also requires that PCI compliance be certified by two separate outside consultancies. And with that in mind, numerous consultants now offer PCI compliance services.
Vendors are also placed in one of four risk categories. These risk categories are based on a company's annual credit card transaction volume. Those processing more than six million transactions a year per card plan are classified as level 1; companies processing less than six million but over 150,000 transactions are classified as level 2. Vendors processing 20,000 transactions are classified as level 3 and vendors processing less than 20,000 transactions are classified as level 4.
While this may sound overwhelming, there are some best practices that can ease the PCI compliance burden and actually mesh with a company's existing information security program.
To start, use the two keys for PCI compliance: Remote vulnerability scans and the assessment completions. Remote vulnerability scans should be conducted on a quarterly basis, cover all Internet connections to and from the company, including dedicated ones, like those for Web and email servers. The scans must also be conducted by a PCI Security Standards Council-certified approved scanning vendor (ASV). The assessments must be conducted annually by a qualified security assessor (QSA), which like its ASV counterpart, must be certified by the council. It is important to note that level 1 vendors are also subjected to a site visit in addition to the annual assessment.
When choosing a QSA and ASV for a compliance program, check if they have the technical experience and expertise in the six control areas. A QSA should be able to audit for the 12 controls, while an ASV should have a track record of conducting vulnerability assessments.
There are a lot of major players in the approved list of QSAs and ASVs: Foundstone, Symantec, Cybertrust, LUHRQ, Ernest and Young and KPMG are some common ASVs; QSAs include Symantec, ISS, Remington, and Neohapsis.
To stay compliant, keep complete records of how the required controls are set up, maintained and changed. Internal IT auditors should also use the PCI standard as a point of reference in regular audits to ensure the company remains compliant. It's also a good idea to hold employee training sessions for those who handle credit card data in compliance procedures.
While PCI compliance seems like another IT security headache, most of it is based in established security procedures and policies. And, with a lineup of well-known consultants, compliance can be integrated into a company's existing security program.
About the author:
Joel Dubin, CISSP, is an independent computer security consultant based in Chicago. He is a Microsoft MVP, specializing in Web and application security, and the author of The Little Black Book of Computer Security. As an Ask the Expert panelist, he answers questions on identity management and access control.
