PCI DSS version 3.0 changes help organizations make payment security business-as-usual

On January 1, 2014, PCI DSS 3.0 goes into effect. If you haven’t started the transition yet, don’t worry; you have until January 1, 2015 to move to the new standard. However, don’t wait too long to start planning and executing. While many of the changes in the PCI DSS 3.0 requirements are clarifications, there are several new requirements that could take you some time to address. An overarching theme of 3.0 is the evolution of security compliance to a day-to-day practice, instead of a once-a-year event that happens just before an audit. You’ll find that many of the new and expanded testing and auditing requirements directly support this goal. To get to the details, here are some of the significant new requirements, guidance on why they were added, and why they might be a challenge to meet.

Requirement
Why Added
What’s Challenging
2.4
Maintain an inventory of system components that are in scope for PCI DSS.
Enable an organization to define the scope of their environment for implementing PCI DSS controls.
While configuration management database (CMDB) adoption and implementations are increasing in the large enterprise space, most mid-market and smaller companies don’t have the resources to acquire, implement and maintain a complex solution. They may need to implement a CMDB or something similar to maintain an asset inventory.
 
5.1.2
For systems not commonly affected by malicious software, perform periodic evaluations to identify and evaluate evolving malware threats.
Identify emerging security vulnerabilities in systems that are not commonly targeted or affected by malware, such as mainframes and mid-range computers.
An organization will need to ensure they have agreement with their QSA on what are “not commonly affected” systems. After that, keeping track of emerging vulnerabilities will be challenging and costly for organizations that do not have extensive security expertise in-house or via partners.
 
9.9*
Protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution.
Keep criminals from stealing cardholder data by stealing and/or manipulating card-reading devices and terminals.
Many organizations want to give consumers more access to POS devices (e.g., self-checkout at the grocery store) to improve the customer experience (e.g., faster checkout) which in turn increases the need for security solutions (people, processes, technology) to support these improved customer experiences.
 
11.3*
Implement an industry-accepted methodology for penetration testing.
Enables organizations to gain a better understanding of their potential exposure and develop a strategy to defend against attacks.
The "industry-accepted methodology" requirement makes this a challenging requirement for organizations that don’t have expertise in-house or currently work with a penetration-testing partner that doesn’t take an industry-standard approach.
In addition, organizations will need to treat penetration testing as a lifecycle management event vs. a one-and-done process. As the organization evolves (e.g., offers new services), the testing methodology and processes need to be updated and maintained and the security solutions extended to cover them.
 
12.9*
Service providers acknowledge in writing that they are responsible for the security of cardholder data the service provider possesses or otherwise stores, processes, or transmits on behalf of the customer.
Promotes a consistent level of understanding between service providers and their customers about their applicable PCI DSS responsibilities.
While many large and established service providers are already providing this information, organizations working with service providers that don’t provide it might have a challenge convincing them to deliver it in writing.
 

In future blog articles, we’ll discuss these and other PCI DSS 3.0 changes in more detail and offer suggestions for overcoming potential challenges. For complete documentation on all the requirements, visit the PCI Security Standards Council website. For information on how Alert Logic helps organizations comply with PCI DSS regulations, visit the PCI DSS Compliance section of our website. * These requirements are best practices until June 30, 2015, after which they become requirements.