News, Education and Events Decoding Digital Payments & Fraud

News, Education and Events Decoding Digital Payments & Fraud

CNP Series Report – PCI Part 2: Card-Not-Present vs. Card-Present Requirements

By Jeff Man, Security Strategist and Evangelist, Tenable Network Security, exclusively for PCI Part 2: Card-Not-Present vs. Card-Present Requirements When the PCI Security Standards Council (PCI SSC) published version 3.0 of the Payment Card Industry Data Security Standard (PCI DSS) in November 2013, there were several changes the organization felt were significant enough to warrant a grace period.  That reprieve came to an end June 30, 2015, when those changes morphed from “best practice” to “requirement.” There are five new requirements found in PCI DSS v3.0/3.1 that went into effect on this date. The first article in this series focused on the new penetration testing methodology requirement (11.3). This week will focus on two requirements that, together, apply to all merchants subject to PCI compliance. There are two new requirements in PCI DSS Version 3.0/3.1 aimed at specific audiences. The first—6.5.10, “Broken authentication and session management”—is for merchants engaged in card-not-present payment acceptance, primarily through the use of e-commerce servers. In contrast, 9.9, “Protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution,” is focused on the physical security of payment acceptance devices used for card-present merchants. Of course, many merchants offer multiple payment acceptance methods, so adherence to both of these new requirements would be required, in those cases. Broken Authentication & Session Management PCI Part 2: Card-Not-Present vs. Card-Present Requirements PCI DSS Requirement 6.5 says entities must produce secure software by [hide for=”!logged”]requiring secure coding training that focuses on how to avoid the most common mistakes or vulnerabilities that show up in code. Those common mistakes are listed in the Open Web Application Security Project’s (OWASP) Ten Most Critical Web Application Security Risks , which was updated in 2013 prior to the initial release of PCI DSS Version 3.0. The sub-requirements 6.5.1- 6.5.10 simply reflect the current “OWASP Top Ten” as of the date of publication of the DSS. At the time of a company’s PCI compliance validation, the entity is required to include the current “top ten” list of coding vulnerabilities in its training. The requirement to protect against broken authentication and session management actually was included in a previous release of the OWASP Top Ten published in 2010. However, it was not published until after the release of PCI DSS Version 2.0 so it was not explicitly included as a requirement until Version 3.0 was released in November 2013 (Timing is everything). The risks associated with broken authentication and session management include attackers stealing login credentials, taking over actual sessions, impersonating users and other techniques that result in a session being hijacked and used to commit theft or fraud. It is important to note that although this area of focus made the OWASP Top Ten in 2010, it actually climbed into a higher spot in 2013. This type of exploit was gaining popularity, so OWASP believed it was important to give it more attention. This new requirement applies to all Level 1 merchants and all service providers (whether they self-assess or not) if they engage in or support any form of Web-based application related to payment acceptance and processing. Smaller merchants that rely on the self-assessment process for validating PCI compliance are only subject to this requirement if they are completing SAQ A-EP “ Partially Outsourced E-commerce Merchants Using a Third-Party Website for Payment Processing ” or if they complete SAQ D-Merchants “ All Other Eligible SAQ Merchants .” Physical Security of Payment Acceptance Devices PCI Part 2: Card-Not-Present vs. Card-Present Requirements There has been a fair amount of discussion in blogs and articles about the new PCI DSS 9.9 requirement to “protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution.” Interestingly, most of these discussions characterize this new requirement as a response to the targeted malware attacks perpetrated against POS systems over the past three years. In actuality, the addition is a result of the introduction of the Point-to-Point Encryption (P2PE) Standard. When the PCI Council released its initial draft of the P2PE Hardware Solution standards, it stated that protecting the encryption keys (key management) that were embedded into payment acceptance devices was paramount to the security of the transmission of the payment authorization data. The protection required was two-fold: from a network perspective, the keys had to be embedded into modules (chips) that would be unreachable and thus resistant to hacker attack, malware, or any other form of electronic compromise. But because these devices would be distributed to geographically dispersed retail locations, there was also a need to address the physical security of the devices. The P2PE HW Standard called for detailed physical security procedures to be in-place at retail locations such as keeping an inventory of all payment acceptance systems, maintaining chain-of-custody, never leaving spare devices unattended or unsecured, and periodically inspecting deployed devices for evidence of tampering of the device or connecting wires, or modifications such as skimming devices. The only problem was that these early P2PE standards were written for vendors that would be developing the systems and not the end users—merchants. The problem was addressed with the introduction of 9.9 and its subordinate requirements 9.9.1 through 9.9.3. Card-present merchants are now required to protect payment acceptance devices by requiring documented policies and procedures that include:
  • Maintaining a list or inventory of devices (9.9.1)
  • Periodic inspection of the device to look for tampering (9.9.2), and
  • Training for personnel (e.g. store employees and clerks) to make sure they know how to look for evidence of tampering, but also to be familiar with maintenance procedures by support vendors (to prevent social engineering of the devices)
The 9.9 requirement is actually the most prolific of the new requirements in terms of how often it shows up in the various self-assessment questionnaires:
SAQs subject to PCI DSS 9.9

Scope of the SAQ

SAQ B Merchants with Only Imprint Machines or Only Standalone, Dial-out Terminals – No Electronic Cardholder Data Storage
SAQ B-IP Merchants with Standalone, IP-Connected PTS Point-of-Interaction (POI) Terminals – No Electronic Cardholder Data Storage
SAQ C Merchants with Payment Application Systems Connected to the Internet – No Electronic Cardholder Data Storage
SAQ D-Merch All other SAQ-Eligible Merchants
SAQ D-SP SAQ-Eligible Service Providers
SAQ P2PE-HW Merchants using Hardware Payment Terminals in a PCI SSC-Listed P2PE Solution Only – No Electronic Cardholder Data Storage
The PCI Council wants to migrate as many merchants as possible to more secure payment solutions such as P2PE. It greatly reduces the footprint of cardholder data in a merchant’s network and it all but eliminates data “leakage” or storage in unintended locations. This should always be the focus of implementing new technologies rather than attempting to “limit scope” or “ease the burden” of having to comply with a set of security standards such as PCI. Focus on the security of the data that you are trying to protect and you will meet your compliance requirements. PCI is not a burden; properly implemented it is a solid framework for building an appropriate data security program for your business. Read PCI Part 1: New Penetration Testing Requirements Read PCI Part 3: Third-Party Crashers


  • Share this Article:

Daniel Leibovitch