There’s a brand new standard of the Payment Card Industry data security standard, which means businesses have a new list of regulations with which to comply in dealing with the security of MasterCard, Visa and other credit card organization payment systems.
The latest standard, PCI 1.2, went into effect Oct. 1, 2008. While the latest version does not introduce any new major requirements, the updates do change some practices such as the sun-setting of implementations of Wired Equivalent Privacy (WEP) wireless security by June 2010. The new standard also:
- Incorporates new and existing best practices
- Provides further scoping and reporting clarification
- Eliminates overlapping sub-requirements and consolidations documentation
- Enhances the Frequently Asked Questions (FAQ) and glossary to facilitate understanding of the security process
See a sample of the top 11 changes.
With this in mind, overall requirements of the PCI data security standard cover the 12 following goals:
| Goals | PCI DSS ver. 1.2 Requirements |
| Build and Maintain a Secure Network |
1. Install and maintain a firewall configuration to protect cardholder data. |
| Protect Cardholder Data | 3. Protect stored cardholder data. 4. Encrypt transmission of cardholder data across open, public networks. |
| Maintain a Vulnerability Management Program | 5. Use and regularly update anti-virus software or programs. 6. Develop and maintain secure systems and applications. |
| Implement Strong Access Control Measures | 7. Restrict access to cardholder data by business need-to-know. 8. Assign a unique ID to each person with computer access. 9 . Restrict physical access to cardholder data. |
| Regularly Monitor and Test Networks | 10. Track and monitor all access to network resources and cardholder data. 11. Regularly test security systems and processes. |
| Maintain an Information Security Policy | 12. Maintain a policy that addresses information security for employees and contractors. |
Because preventing compromise and fraud from occurring is an ongoing challenge, the PCI standards are refreshed every two years. An earlier update came in September 2006, when the PCI standard was updated to version 1.1. The original standard was issued in 2004.
The PCI security standards were created to help organizations that process card payments prevent credit card fraud, hacking and various other security vulnerabilities and threats. To further the adoption of the PCI data security standard, the PCI Security Standards Council (SSC) defines credentials and qualifications for Qualified Security Assessors (QSAs) and Approved Scanning Vendors (ASVs). The PCI SSC also manages a global training and certification program for QSAs and ASVs, and publishes a directory of certified providers on their Web site.
Payment brands (such as MasterCard, Visa, etc.) collectively have adopted PCI data security standard as the requirement for organizations that process, store or transmit payment cardholder data. The PCI SSC is responsible for managing the security standards while each individual payment brand is responsible for managing and enforcing compliance to these standards.
Compliance is mandated by the payment card brands and not by the PCI SSC, but all entities that transmit, process, or store payment card data must be compliant with the PCI data security standard. All merchants, whether small or large, need to comply, though smaller companies have the option to use a self-certification questionnaire. Whether this questionnaire needs to be validated by a QSA depends on the requirements of the card brands in that merchant’s region. For more information, visit PCI Security Standards Council.
Read more to learn how Check Point Software Technologies can help businesses achieve PCI compliance.
| 1.1.6: Clarification - Changed frequency of the firewall and router rule set review from “quarterly” to “at least every six months.”. Added flexibility, based on Participating Organization feedback, so controls can be customized to an organization’s risk management policies. |
| 2.1.1: Clarification - Removed requirement to disable broadcast of SSID. Disabling SSID broadcast does not prevent a malicious user from determining the SSID, as the SSID is broadcast over numerous other messaging/communication channels. |
| 2.1.1: Clarification - Deleted references to specific wireless technologies like WEP. Intended to emphasize using strong encryption technologies for wireless networks, for both authentication and transmission. |
| 4.1.1: Enhancement - Clarified that requirement applies to wireless networks transmitting cardholder data “or connected to cardholder data environments.” Deleted specific requirements and testing procedures for WEP implementations. Added requirement to implement wireless according to industry best practices (e.g., IEEE 802.11i) to implement strong encryption for authentication and transmission. For new wireless implementations, it is prohibited to implement WEP after March 31, 2009. For current wireless implementations, it is prohibited to use WEP after June 30, 2010. Done to emphasize using strong encryption technologies for wireless networks, for both authentication and transmission. |
| 4.2: Clarification - Changed “email” to “end-user messaging technologies” (e-mail, instant messaging, chat). Never send unencrypted PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat). |
| 5.1: Clarification - Requirement applies to all operating systems types commonly affected by malicious software, if applicable anti-virus technology exists. Deploy anti-virus software on all systems affected by malicious software (particularly personal computers and servers). |
| 5.1.1: Clarification - Included viruses, worms, trojans and rootkits as examples of other malicious code that anti-virus software should address. For a sample of system components, verify that all anti-virus programs detect, remove, and protect against all known types of malicious software (for example, viruses, Trojans, worms, spyware, adware, and rootkits). |
| 5.2: Clarification & Enhancement - Ensure that all anti-virus mechanisms are current, actively running, and capable of generating audit logs. Changed “in accordance with company retention policy” to “in accordance with PCI DSS Requirement 10.7.” - (Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from back-up)). |
|
10.2: Clarification - Added to all 10.2 sub requirements wording to ensure events are verified to be “logged.” Implement automated audit trails for all system components for reconstructing these events:
|
|
10.3: Clarification - Added to all 10.3 sub requirements wording to ensure these events are verified to “be included in log entries.” Record at least the following audit trail entries for all system components for each event:
|
| 10.7: Clarification - Changed wording to clarify intent that audit logs must be retained for at least one year, with a minimum of three months immediately available for analysis and provided examples (online, archived or restorable from backup).. |