Privacy Advisor

The Impact of New Payment Card Industry Standards on Business

Companies will have a year to implement Version 3.0

November 26, 2013

By Rebecca N. Shwayri

Version 3.0 of the Payment Card Industry Data Security Standard (PCI-DSS) has been released by the PCI Security Standards Council. The security requirements are intended to strengthen the security of cardholder data and encourage the adoption of uniform data security standards within the payment card industry. PCI-DSS applies to all entities that are involved in payment card processing. This includes merchants, processors, acquirers, issuers and service providers as well as entities that store, process and transmit cardholder data.

Version 3.0 contains new technical requirements that businesses within the payment card industry should comply with. Version 3.0 goes into effect on January 1. However, companies have until December 31 to make the transition from Version 2.0 to Version 3.0. The most notable change is that 3.0 takes a more holistic approach toward data security and encourages the integration of this security into standard business protocols.

This article will examine the new technical data security requirements of Version 3.0., including the 12 requirements of PCI-DSS compliance, the technical differences between versions and 3.0’s integration of data security into standard business protocol. Finally, it will examine an area in which 3.0 could be updated in the future.

Requirements of PCI-DSS

PCI-DSS contains 12 principles that companies should follow in ensuring the security of cardholder data. These principles are:

  • Install and maintain a firewall to protect cardholder data
  • Do not use vendor-supplied passwords
  • Protect cardholder data
  • Encrypt cardholder data that is transmitted across public networks
  • Ensure that systems are protected against malware and viruses
  • Maintain secure systems and applications
  • Restrict those who can access cardholder data
  • Authenticate those who access system components
  • Restrict physical access to data
  • Monitor access to network resources
  • Test security systems and processes
  • Maintain a policy that addresses information security

These 12 requirements should be considered a minimum baseline standard that a company should follow. Noncompliance could lead to fines by the payment card brands in the event of a data breach. In addition, noncompliance could lead to class-action data security suits. Even though compliance with PCI-DSS is important, there have been instances in which a company that is PCI-DSS-compliant has been subject to a data breach. In other words, compliance with the standards is not an absolute guarantee of security.  

Version 3.0 New Technical Requirements

While PCI-DSS contains general principles that companies handling payment card data should follow, the sub-requirements for each section are particularly detailed. Version 3.0 imposes a number of new technical requirements that were not included in 2.0. These technical requirements are broad-ranging and include recommendations for strengthening password security, limitations on physical access, implementing a methodology for penetration testing and informing cardholders regarding the entity's responsibility for the security of payment card data.

  • Requirement 5.1.2 requires periodic evaluations of those systems that are not typically impacted by malicious software to determine whether those systems still do not need antivirus software.
  • Requirement 8.2.3 requires that passwords meet a minimum length of seven characters and contain numeric and alphabet characters.
  • Requirement 8.5.1 states that a service provider that has remote access to a customer's premises must utilize a unique authentication credential for each customer. This helps to mitigate any security compromise that might arise to multiple customers as a result of a hacker obtaining security information for one customer.  
  • Requirement 8.6 states that there must be the assignment of certain authentication mechanisms. For example, authentication mechanisms like security tokens, smart cards or certificates must be assigned to an individual account rather than shared among multiple accounts.
  • Requirement 9.3 provides that physical access to critical areas should be controlled. Access should be based on an individual’s job function and should be revoked upon termination.
  • Requirement 9.9 is intended to protect devices that capture payment card data from intrusion. Requirement 9.9 recommends testing procedures to ensure that devices are periodically inspected for tampering and intrusion.
  • Requirements 11.3 and 11.4 provide for the implementation of a methodology for penetration assessment. The assessment should be based on industry-accepted penetration-testing approaches and should include coverage for all critical systems. All traffic should be monitored at the perimeter of cardholder data and at critical points within the data environment. A proactive approach to unauthorized activity detection is necessary to ensure that attacks do not go undetected.
  • Finally, Requirement 12.9 provides that service providers should acknowledge in writing to customers that they are responsible for the security of cardholder data held by the provider.

Improving Business-as-Usual Practices

While Version 3.0 imposes new technical requirements, the biggest changes aim to make PCI-DSS compliance part of a company's business-as-usual practice. To accomplish this objective, 3.0 recommends taking several different steps to incorporate security into business practices.

First, 3.0 recommends ensuring that failures in security are remediated as soon as possible. Responding to a security failure would include identifying the cause of the failure, addressing any security issues that arose during the failure, implementing practices to prevent the failure from occurring in the future and providing enhanced monitoring.

Second, 3.0 recommends reviewing the impact of a new change on the security environment. For example, if a new system is implemented or if there is a change in network configurations, then it is important to determine the impact of this change on the entity's PCI-DSS compliance.

Third, any changes to an entity's organizational structure—such as a merger, for example—should result in a review of the impact of this change on PCI-DSS compliance.

Fourth, a company should periodically conduct assessments to ensure that the company continues to comply with PCI-DSS requirements and that personnel are following appropriate security protocols.

Finally, a company should review its hardware and software technology on an annual basis to verify that these technologies are supported by the entity's vendor and continue to meet PCI-DSS security requirements.

Conclusion

Version 3.0 takes a more holistic approach towards payment card security compared to Version 2.0. Companies that handle payment card data would do well to examine the new requirements and transition to these new requirements in a seamless manner. The likelihood is that a number of these requirements are already utilized by companies processing payment card information. To the extent that a company processing payment card information is not following Version 3.0, the entity should work to become compliant as soon as possible in order to deter possible future cyber-attacks. While Version 3.0 endeavors to take a more comprehensive approach to payment card security, there are potential gaps in 3.0 that will need to be addressed by the PCI Security Standards Council in the future. Cyber criminals are targeting mobile devices in an attempt to gain sensitive financial information, and Version 3.0 leaves a gap as to their security. Companies endeavoring to secure sensitive financial information should work to protect the security of this information when it is transmitted on mobile devices.

Rebecca N. Shwayri is a business litigator and information technology lawyer.

Read more by Rebecca Shwayri:
The Risks Associated with Financial Institutions’ Use of Social Media
The SEC’s Cybersecurity Guidelines: A Potential Game-Changer for How Companies Disclose Risks of Cybersecurity Breaches