PCI Update: Focus on Third-Party Risks

PCI-DSS Version 3.0 Stresses Service Provider Security
PCI Update: Focus on Third-Party Risks
Troy Leach and Bob Russo

Version 3.0 of the PCI Data Security Standard goes into effect Jan. 1, 2014, so organizations need to shore up their compliance programs, say Troy Leach and Bob Russo of the PCI Security Standards Council.

"Next year is really a market implementation year, so we encourage everyone to review and become familiar with the new standards before their required assessments are due," says Russo, general manager of the council, in an interview with Information Security Media Group [transcript below].

Among the new requirements of version 3.0 are steps to mitigate payment card risks posed by third parties, such as cloud providers and payment processors.

The new version also stresses that businesses and organizations that accept and/or process cards are responsible for ensuring the third parties they rely on for outsourced solutions and services use appropriate security measures, says Leach, the council's chief technology officer.

"Many of the breaches have involved the integrity of the third parties," Leach says. "Organizations need to help those types of entities understand their PCI responsibilities."

Contract Requirements

Another new requirement included in the update to PCI-DSS calls for contracts between businesses, retailers and other entities that accept card payments and third parties that specifically outline card security obligations, Leach says. "Organizations must have a written agreement with the service provider to ensure they understand their obligations to secure data," he says.

Businesses, merchants, banking institutions and others responsible for complying with the PCI DSS and the PCI Application Data Security Standard have until January 2015, when enforcement of the updated requirements begins, to shore up their compliance programs, Russo says.

"There's a full year before the previous version is retired, so this gives companies time to familiarize themselves with the new requirements and make any kind of adjustments to their programs based on their business environments and whatever their security strategies are," he says.

During this interview, Russo and Leach discuss:

  • Critical requirements added in version 3.0;
  • PCI's impact on mobile payments;
  • New requirements for qualified security assessors.

For more information, see also, PCI Updates Address Retail Breaches.

Russo brings more than 25 years of high-tech business management, operations and security experience to his role as the general manager of the PCI Security Standards Council. He guides the organization's efforts to improve data security standards for merchants, banks and other key stakeholders involved in the global payment card transaction process. He works with representatives from American Express, Discover Financial, JCB, MasterCard Worldwide and Visa International to drive awareness and adoption of the PCI-DSS.

In his role as lead security standards architect for the PCI Security Standards Council, Leach has developed and implemented a comprehensive quality assurance program to promote consistency within the council's QSA, ASV, PA-DSS and PED programs. Before joining the council, Leach led the incident-response program at American Express, where he reviewed more than 300 cases of account data compromises. Over the past 18 years, he has held positions in systems administration, network engineering, IT management, security assessment and forensic analytics.

Changes in Version 3.0

TRACY KITTEN: What would you say are some of the biggest changes that are being made to version 3.0 based on feedback that you've gathered?

BOB RUSSO: The few areas that we were tweaking according to the input at our community meetings, for example, was PCI-DSS requirement 8.5.1 which was added to ensure that the service providers with access to customer environments are using a unique authentication credential, such as a password or pass-phrase for each particular customer. This is specifically to address scenarios where the vendor supports multiple merchants, and the compromise of credentials from one customer results in the compromise of all the customers that are on the same device, which we've seen happen over the years. The feedback we received indicated that there was confusion as to really who this applies to. We added language to clarify that this is for service providers with remote-access customers on premise.

Another area that we saw was in reference to volatile memory. We initially proposed a new PCI-DSS requirement to address memory-scraping, but due to the input that we received on this, we reference it now in 6.5 and we incorporated the stuff into PADSS specifically, to the training for developers and secure development lifecycle guidance.

Another hot topic in the update is PCI-DSS requirement 9.9 regarding point-of-sale security. We got input that we need to clarify which devices this applies to. We added language to indicate this applies to devices that capture payment card data via direct physical interaction with the card to make sure that it's not being tampered with or somebody is substituting a device. ...

Updates to Retail Networks, POS

KITTEN: When we spoke in August, we talked about a number of changes, including those related to the retail network and point-of-sale security issues that you just talked about. These issues are hot right now because we've had so many malware attacks that have compromised card data and other sensitive PII. Are there any new updates to share here beyond what you've already talked about that relate to what merchants might expect?

RUSSO: You've reported a lot of challenges with skimming and compromises happening at the point of sale, so I don't have to tell you how important securing these devices is. In response to a lot of these challenges, as I said earlier, we added a new requirement to the DSS, 9.9, [which] applies to card-reading devices that are used in card-present transactions. That's to say either a card swiped or dipped at the point-of-sale, not to the entire POS system. We talked a lot about version 3.0, PCI-DSS emphasizing education and awareness, and that's really the focus of this particular requirement, helping to build awareness among frontline employees. ... A lot of this information is carried in skimming documents that we have on our website as well, but [it's] incorporating this so that every one of the employees knows, as an example, [about] keeping inventory of the devices that you have in the store and conducting periodic inspections for tampering.

For example, the addition of card skimmers to devices is pretty easily detectable if you've got a picture of the device. Another example would be checking stickers or physical markings on the device, and the frequency of these inspections certainly can vary and is basically decided by each one of the merchants. Most importantly, educate those frontline people to notice any kind of suspicious behavior. ... You want to know how to report suspicious behavior, who to report it to and to have a process for them to follow to be escalated so that this stuff can be investigated.

Updates to Third Parties

KITTEN: I'm going to go back to something that you talked about earlier and that's the updates that include new requirements for service providers with remote access and the need for unique authentication credentials for each customer. This particular update also requires the implementation of penetration testing. Can you give a little more background about that?

TROY LEACH: The changes you note are a couple of the key updates that we have version 3.0. As Bob pointed out, based on the feedback we received from the industry and what we're seeing in terms of compromises, there's growing dependency on third parties and business process, with forensic data showing that approximately 90 percent of compromises over the past few years have involved integrity of that third-party relationship as part of a breach. One example of service provider requirements is the PCI-DSS requirement 8.5.1 that requires service providers use a different authentication credential for each of their customers, and that helps to avoid the potential compromise of multiple customers using one set of credentials. This change is part of our focus on improving the security across the payment chain by helping those types of entities better understand the PCI responsibilities, even if they're not part of the merchant of record.

You'll also note that in this new version of the standard, we have penetration-testing updates. Pen-testing has always been required, but this is an area that we received a lot of feedback on requesting more clarity or guidance on how to perform pen-tests. We've also expanded 11.3 to include more information about what type of methodology you should use and added a requirement to validate segmentation as adequate. We've seen many breaches over the past few years where an entity made some assumptions about limiting their scope for protecting card holder data but never tested the legitimacy of those network boundaries. This new requirement is going to ask for demonstrative evidence to show that there's a clear demarcation for what should be considered part of their cardholder data environment.

Concerns Among Processors, Merchants

KITTEN: This is the first update to the PCI Data Security Standard as well as the Payment Application Data Security Standard since 2010. Are there concerns among processors, merchants and banking institutions about complying or conforming with these updates?

RUSSO: There are significant changes with version 3.0 that really will impact organizations' security programs ... and we hope [will] make for stronger payment card security in their organizations. But we find typically [that] the majority of organizations are already doing most of these things, and, if not, that's part of the design of the standards to update the lifecycle. We put the standard out, but it doesn't become effective until 2014, and then there's a full year before the previous version is retired, so this gives companies time to familiarize themselves with the new requirements and make any kind of adjustments to their programs based on their business environments and whatever their security strategies are. Based on the feedback we've gotten so far, generally organizations are pretty pleased with the updates. They realize some of them are going to require more effort than others, but the changes are coming as a response to security challenges that are out there.

Security vs. Compliance

KITTEN: How has the way organizations viewed PCI compliance changed in the last three years? Do you see organizations focusing more on security as they should rather than mere compliance?

RUSSO: We've come a long way from where we started in 2006. By and large, organizations recognize the importance and the value of PCI-DSS in providing a strong baseline for supporting their payment card data security, but we're still seeing challenges when it comes to maintaining PCI-DSS between the assessments, and that's what these changes are primarily designed to help drive. Payment security is every-day business practices or business as usual, and we think providing more education, greater flexibility and building awareness with both internal parties and external business partners are the key components of this.

Data on Third Parties

KITTEN: The new guidelines expand compliance to include third parties, as you've noted earlier. What kind of data should organizations be collecting from these external systems to show compliance?

LEACH: We've always talked about security as a shared responsibility, and in this version of the standard, we focused on how to educate third parties and the role that they play in protecting payment card data. The changes introduced in requirement 12 are focused on helping merchant and service providers both understand what their responsibilities are when it comes to PCI-DSS. For example, 12.8.2 requires organizations to have a written agreement that includes an acknowledgement of the service provider, what responsibilities they have for securing card holder data, and that service provider's process for storing that information and what they have to expect as a customer of that relationship. We actually have a special interest group that's made up of merchants, service providers and other security professionals that are devoted to the topic of third-party security insurance. In fact, many of the updates that we made were incorporated from their project and we'll be putting out additional guidance on that particular topic in early 2014.

Mobile Challenges

KITTEN: What about mobile malware or other mobile security challenges surrounding BYOD? Does version 3.0 address mobile issues?

LEACH: PCI-DSS applies to mobile devices if they're used as part of the cardholder data environments; for example, if they're used for payment acceptance. The fact is that many consumer mobile devices simply can't provide the level of security needed to adequately protect payment card data. In other words, they can't create a trusted environment equivalent to a PCI-DSS compliant environment. We're working with others in the industry, including standards bodies, vendors, banks and processors, but we're unwilling to lower the bar for security by writing the standard to meet the current security status of consumer mobile devices. We're very encouraged by the progress we're seeing in the past two years in the means of how to secure consumer-grade devices, but if we wrote a security standard now for mobile with the expected level of trust and integrity for a financial transaction ... no consumer device would be able to meet it.

Rather, we've created best practices and guidance that have already been released. We're seeing a movement to improve security in the next generation of consumer devices, which we hope will ultimately lead to a level of trust that the industry has been accustomed to when it comes to payment card security.

To finish answering your question, the consumer side of mobile - for example, the NFCs, the e-wallets and consumer-side use of mobile - falls outside the council's focus area, along with the corporate enterprise issues around bring-your-own-device processes. But we do partner with other standards bodies that focus on those areas to see whether the same technology can be a dual-purpose of securing mobile acceptance as well.

Card Security Concerns

KITTEN: What are your greatest concerns as they relate to card security in the coming months and years?

LEACH: One of my concerns is organizations becoming too technology-focused and assuming that one silver bullet layered over the environment will satisfy all of the organization's security needs. With so many new ways to accept payments - we just talked about mobile - and some of the complexity that comes inherently with that, organizations should recognize that attack surfaces become larger unless they identify ways to limit where and how the cardholder data is accessible.

Another area of concern is the growing dependency on third parties. We've already seen service providers and aggregation of card holder data as a primary target for criminals. As we continue to leverage technologies like the cloud and expand e-commerce and mobile environments, the attack surface is only going to increase.

Looking to the future, we must recognize that the organizations that are being attacked and the organized crime rings that are attacking them have a very good understanding of how payment card transactions work, and they will continue to explore new ways to compromise those environments and those systems, especially in the unattended space, such as ATMs, fuel dispensers and other types of systems like that. Changes made to both the PCI-DSS and PADSS will encourage organizations to promote training and education for both the internal development teams as well as third-party relationships and their responsibility to protect their customers which end up being the merchant of record.

U.S. EMV Migration

KITTEN: Is the migration to EMV in the U.S. stirring up new concerns or worries about an uptick in card-not-present fraud globally?

LEACH: That certainly has been a hot topic of conversation. In fact, we just had several presentations at our community meetings on that particular topic. There's a concern as we migrate to chip cards in the United States. The industry is being very diligent in investigating ways to minimize both the exposure of cardholder data and EMV transactions and how to secure card-not-present.

Also, as history has shown in other regions, we can expect a spike in compromises in the face-to-face environment as the window of opportunity closes pre-migration. As we move to EMV, there are multi-channel retailers that need to be very considerate of the entire payment infrastructure and not just the brick and mortar for EMV face-to-face and transactions, but also realize that there's a need to protect and be responsible for e-commerce environments and other card-not-present environments as well.

Educating Organizations on Threats

KITTEN: You've touched on this just a bit, but I would like to elaborate here. What about anticipated upticks in skimming attacks and other mag-stripe compromises which may result from a network breach? How are you educating organizations about the industry's anticipation that we can see these threats increase during the months between now and when the full EMV roll-out in the U.S. takes place?

LEACH: Education is a key theme for us, both within the standard and other activities. We're encouraging merchants to continue to build a strong card transaction security program using the PCI standards, which collectively offers the best protection of cardholder data across all payment channels. As part of that, we do have best practices on skimming prevention which address some of these issues; best practices for ATMs, which also has a broad applicability to other types of point-of-sale systems; and also information supplements on how to do penetration testing and prevention of network breaches. This boils down to both the education that's within the standard itself and the requirements of due diligence, as well as providing additional guidance to the industry for particular types of payment acceptance.

QSA Program

KITTEN: I'd like to talk about the QSA program. An emphasis has been placed on physical device security. What will the QSA need to focus on differently for physical security?

LEACH: The testing procedures require that the QSA examine documented policies and procedures to verify they include things like maintaining a list of devices, periodically inspecting devices to look for tampering or substitution; training the personnel to be aware of the suspicious behavior and to report tampering or substitution of those devices and be aware of these common-sense attacks that may take place. It also includes examining the list of devices as well as reviewing the training material and interviewing the personnel to ensure that they're aware of the policies and have undergone the appropriate types of training we mentioned.

KITTEN: There has been a lot of discussion that also has revolved around moving toward a more business-as-usual monitoring standard or practice to ensure ongoing compliance and ongoing security. How can QSAs get involved to help customers achieve this?

RUSSO: As we've said, helping organizations make payment security part of their everyday business practice is really the driving force behind the updates. As we said earlier, we've seen vast improvements in organizations understanding and adopting the DSS since the standard was first introduced. Changes made to a company's environment or ... they merge with another company - these things ultimately result in them not maintaining their security controls to the same level as they were initially validated to.

As business partners, the QSAs really play an important role in helping ensure that organizations are doing what they need to do - not just to meet the assessment, but to be secure. We encourage all the QSAs and merchant organizations both to take advantage of the navigating PCI-DSS guidance that was added into the standard as that extra column so that they're on the same page about the intent of what the requirement is and, more importantly, what the security goal is.

Version 3.0 Timeline

KITTEN: Before we close, are there any final thoughts about the update that you would like our audience to know about?

RUSSO: Let me just give everybody a quick reminder on what the timeline is. Version 3.0 is available now but will not become effective until Jan. 1, 2014. Next year is really a market implementation year, so we encourage everyone to review and become familiar with the new standards before their required assessments are due. But certainly don't wait until the last minute; the sooner an organization can review it and plan for all the necessary changes, the better position they're going to be in when it comes to their first assessment with version 3.0.

Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing bankinfosecurity.com, you agree to our use of cookies.