VeriFone VeriShield Total Protect Technical Assessment White Paper

Transcription

1 VeriFone VeriShield Total Protect Technical Assessment White Paper Prepared for: September 4 th, 2013 Dan Fritsche, CISSP, QSA (P2PE), PA-QSA (P2PE) [email protected]

2 Table of Contents EXECUTIVE SUMMARY... 3 OVERVIEW... 3 SUMMARY FINDINGS... 6 PCI DSS VALIDATION REDUCTION... 8 SCOPE REDUCTION FOR MERCHANTS DEPLOYMENT SCENARIOS SUMMARY PCI DSS SCOPE REDUCTION DETAILED PCI DSS SCOPE REDUCTION TECHNICAL ASSESSMENT SCOPE OF ASSESSMENT VERISHIELD TOTAL PROTECT ENCRYPTION ASSESSMENT VALIDATION OF DECRYPTION AT VERISHIELD DECRYPTION ( VSD ) KEY LOADING AND DISTRIBUTION APPENDIX A: PCI DSS SCOPE REDUCTION RISK MAPPINGS DETAILED PCI DSS SCOPE REDUCTION Coalfire Systems, Inc. Page 2

3 Executive Summary Overview VeriFone engaged Coalfire Systems Inc. (Coalfire), as a respected Payment Card Industry (PCI) Qualified Security Assessor Point to Point Encryption (QSA P2PE) company, to conduct an independent technical assessment of the VeriShield Total Protect (VTP), secured by RSA security solution. Coalfire conducted assessment activities including technical testing, an architectural assessment, industry analysis, a compliance validation and peer review. In this paper, Coalfire will describe how the VeriShield Total Protect security solution can nearly eliminate the current risk of payment card data compromise within a merchant s retail environment and can dramatically reduce the scope of PCI DSS validation when properly deployed. This scope reduction will be based on evaluating the risk of each of the PCI DSS 2.0 requirements and how the VTP security solution applies to each control within the context of the current PCI P2PE standards released in VTP is a component of a P2PE solution program and as such, not eligible to obtain a PCI P2PE validated solution listing on its own. VTP can be used by service providers to provide a P2PE validated solution to their merchants; however, there are P2PE requirements that are not addressed. These include requirements such as the implementation of physical security controls in accordance with the PIM (P2PE Instruction Manual) that will be the responsibility of the service provider. NOTE: VeriShield Total Protect (VTP) is the latest version and name for VeriShield Protect (VSP) and includes all VSP functionality plus additional encryption methods and tokenization. VSP will be referenced in many places for clarification purposes, but the focus of this assessment is on the most recent features VTP offers. About VeriShield Total Protect VeriShield Total Protect is a comprehensive, modular and flexible solution designed to provide merchants with strong encryption of payment card data from the point of capture to the point of decryption at their gateway, payment processor, or acquirer. VTP includes everything from VeriShield Protect (VSP) and now includes Format Preserving Encryption (FPE) using a symmetric derived key management system along with RSA encryption and tokenization to merchants. The VTP security solution includes these VSP components: 1. Capture Point Encryption The VeriShield Crypto Library (VCL) component is deployed within the VeriFone Tamper Resistant Security Module (TRSM). The TRSM is considered part of the payment device s operating system from a security perspective. Regardless of the payment origin: magnetic stripe, manual entry, tapped via NFC phone or contactless card, or EMV chip, this component encrypts payment card data at the point of capture. 2. Service provider Interface Decryption The VeriShield Decryption Service (VSD) is the end point of the encrypted transaction that resides at the merchant processor, PCI DSS compliant service provider, or at the merchant s switch (depending on merchant requirements). No sensitive cardholder data is stored during the decryption process Coalfire Systems, Inc. Page 3

4 3. VTP Front End and Web Service The single point of integration for all service requests made by external integration hosts. 4. VeriFone Merchant Boarding (VMB) This web-based user interface provides the ability to board merchant/store locations as well as delete merchant/store/device locations. In addition, this tool provides features to do key creation and import services through an interface with the HSM, and device configuration creation services. No sensitive cardholder data is stored in VTP, so none is available in the VMB user interface. A user is also not able to view key data that is stored in a HSM through this interface. 5. Device Monitoring The VeriShield Monitoring and Compliance console (VMC) is a centralized monitoring and reporting platform that provides web-based visibility into transaction health and encryption for each POI device, and as such, is implemented as a centralized management server. No sensitive cardholder data is stored in VTP, so none is available in the VMC user interface. 6. Key Management Platform The VeriShield Key Management (VKM) component is an optional integrated component that provides the full key management lifecycle for the solution including synchronization, remote management of BIN tables and device settings such as eparms. VeriShield Total Protect provides an additional software component to assist in HSM operations: 1. HSM Utility -- Enables key custodians to manage HSM resident keys and retrieve key components. This enables the merchant to utilize the derived key functionality. The VeriShield Total Protect security solution is focused on reducing the risk of a merchant data breach while supporting processing requirements and minimizing the operational impact to existing systems and environments. Our assessment reviewed both current and planned deployment scenarios. This assessment included the above components in PCI compliant testing labs and focused on the new VTP components and the symmetric derived key management system. Audience This assessment report has four target audiences: 1. Merchants: This audience is evaluating the VeriFone VeriShield Total Protect security solution for deployment in their payment card environment. Merchants will be able to clearly understand what benefits they can receive from using VTP in their environment, including risk and scope reduction. 2. Acquirers and Service Providers: This audience is evaluating the VeriFone VeriShield Total Protect security solution for deployment in their service provider environment. Acquirers and service providers can use this assessment to evaluate how VTP can enable them to offer a P2PE solution leading to specific scope reduction for merchants, and even to help them to achieve a PCI P2PE validated listing. 3. QSA s and the Internal Audit Community: This audience may be evaluating the VeriFone VeriShield Total Protect security solution to determine the impact of P2PE on PCI DSS compliance in general on behalf of their merchant Coalfire Systems, Inc. Page 4

5 4. VeriFone and Partners: The final target audience is the product and engineering teams of VeriFone and its technology partners. The purpose of including this audience is to provide an independent evaluation of their solution and help them identify any areas for improvement. Assessment Scope The scope of our assessment focused on the critical elements that validate the security and effectiveness of the security solution. Coalfire incorporated in-depth analysis of compliance fundamentals that are essential for evaluation by merchants, service providers and the QSA community. In addition, Coalfire utilized reviews and feedback obtained from members of the PCI community; however, the opinions and findings within this evaluation are solely those of Coalfire and do not represent any assessment findings, or opinions, from any other parties. This assessment is not a replication of the previous 2010 VSP assessment and whitepaper, but rather an update focusing on how the VTP security solution can be understood and leveraged in the context of PCI DSS v2.0 and the current PCI P2PE standards released in This assessment will specifically focus on the new Derived Symmetric Key Mode functionality. Methodology Coalfire has implemented industry best practices in our assessment and testing methodologies. Standard validation methods were used throughout the assessment. Coalfire conducted technical lab testing in both the Coalfire Labs located in Louisville, Colorado and the VeriFone labs in San Diego, CA. This included complete POS installation, integration, transaction testing, device assessment, encryption evaluation and forensic analysis. A previous validation assessment was performed in 2010 for some VTP components; that work was not reproduced, but instead it was leveraged and should be referred to for an understanding of Classic Key Mode functionality. Merchant PCI DSS Compliance Scope Even the best encryption technologies do not completely eliminate the scope of PCI DSS compliance validation, as some in the industry have claimed. In fact, if a merchant is accepting a payment card, the entirety of the PCI DSS always applies to them. However, a properly implemented, and thoroughly evaluated, encryption solution can satisfy a significant portion of the PCI DSS controls; thereby significantly reducing the scope of what PCI DSS requirements a merchant is still responsible for validating. In 2012, the PCI SSC released an official P2PE standard detailing what controls must be in place for a service provider to become listed using a given data security solution. This program works best for level 4 merchants. For encryption solutions not listed with the PCI SSC (which would include most level one merchant solutions), the Council has stated that the acquirer or payment brand should be consulted to determine how an encryption solution can be used. This assessment can be used by a service provider using the VTP security solution to pursue a PCI P2PE validated listing or to interact directly with an acquirer or payment brand to understand what reduction of applicable controls is acceptable Coalfire Systems, Inc. Page 5

6 To that end, a risk evaluation for each control is included to justify a corresponding reduction of applicability, based on the PCI P2PE standards. Coalfire has reviewed each deployment scenario to assess its impact on the cardholder data environment that would be considered in scope for PCI DSS validation. We have leveraged our experience as a veteran QSA(P2PE)/PA-QSA(P2PE) firm in applying technologies such as network segmentation, tokenization, and various encryption solutions to provide guidance on appropriate PCI DSS reduction of applicable controls. Technical Security Assessment The flexible and modular solution design of VeriShield Total Protect presented Coalfire with at least three core deployment architectures and a number of merchant integration and configuration options. Our assessment covered core deployment architecture and all available configuration options. The assessment included testing a comprehensive set of administrative, technical and physical controls. This included the definition of control roles and responsibilities between the merchant and connected entities. Applicable compliance control requirement adherence from the PCI DSS, PCI PA-DSS, PCI P2PE and PCI PTS were validated within the scope of our security assessment. Where control gaps or vulnerabilities were identified, remediation guidance was communicated to responsible parties and follow-up testing was performed to validate gap closure. Coalfire evaluated and tested the complete VeriShield Total Protect security solution within the context of the applicable controls in the 6 domains as described in Solution Requirements and Testing s: Encryption, Decryption, and Key Management within Secure Cryptographic Devices Version 1.1 published by the PCI SSC in April 2012, as well as other related documents including updates to the standard. The evaluation included verification of encryption methods, key length, algorithms, key management methods, and physical and logical protection. Security and Risk Profile The greatest value of P2PE solutions for merchants is the reduction in risk of payment card data compromise. Using our extensive experience with threat analysis, computer forensics, data breach investigations and security incident response we validated the critical aspects of risk mitigation that the VeriShield Total Protect security solution can provide for merchants. Summary Findings The following are important highlights of Coalfire s technical evaluation: A properly deployed VeriShield Total Protect security solution can provide significant risk reduction of data compromise and is one of the most effective data security controls available to merchants today. VeriShield Crypto Library meets encryption best practices and standards for cryptographic algorithms and key strength. VCL format-preserving methods meet industry standards and VISA best practices guidance. The format-preserving VeriShield Crypto Library provides successful integration with existing payment applications, POS systems and back-office servers Coalfire Systems, Inc. Page 6

7 A payment application or POS system not running on the POI, and that is not PA-DSS validated can be taken out of PA-DSS scope if all payment data is captured through the VeriShield Total Protect security solution and the system is cleansed of all legacy card data. A merchant should have ownership rights to the decryption keys, but not have access to, or possession of these keys to achieve the greatest PCI DSS reduction of applicable controls. A merchant can dramatically reduce the PCI DSS controls they are responsible for validating in their retail and corporate environments if all electronic card data is captured in a VeriShield Total Protect TRSM and the merchant is not capable of decrypting captured data and decryption keys do not exist within their environment. VMC provides effective compliance and security auditing for the merchants and their QSAs. Compliance reporting over time is easily evidenced for assessors through VMC. The VeriShield Total Protect security solution integrates securely with PC-based POS systems or cash registers without exposing card data, encryption keys or authentication data to these platforms. The derived key management processes of the VeriShield Total Protect security solution remove most of the challenges of key management for the merchant that are present in many other P2PE technologies. Specific benefits of this method include unique keys per device per card, automated key management functions, increased key strength, and streamlined integration to HSM devices. A VeriFone PTS validated terminal should be the only point in a merchant retail environment that captures card data through any supported input method: swipe, manual, EMV or contactless. To achieve the greatest PCI DSS scope reduction, Coalfire and VeriFone recommend the use of a PTS 2.x with SRED or 3.x with SRED device. VCL will run on any of these devices. The tested version of VeriShield Total Protect security solution encrypts more types of cards than previous versions, thus increasing the encryption rate while still providing BIN exclusion ranges and maintaining integration value with existing POS systems. Assessor Comments Our assessment scope put a significant focus on validating the PCI DSS compliance control reduction impact of the VeriShield Total Protect security solution. The VeriShield Total Protect security solution can nearly eliminate risk of payment card data compromise for a merchant s retail environment. There can be very clear and dramatic reduction of the PCI DSS scope of validation with a properly deployed solution. However, ignoring the PCI DSS and security best practices, even if they are out of scope for PCI DSS compliance validation, can introduce many other security or business continuity risks to the merchant. Security and business risk mitigation should be any merchant s goal and focus for selecting security controls. The VeriShield Total Protect security solution can benefit merchants by helping reduce the cost of PCI DSS compliance validation and allow them to invest more of those resources into business risk mitigating controls. With the current PCI P2PE standard, merchants have an increased expectation for vendors and service providers to offer a more secure environment utilizing the latest encryption technologies. The VeriShield 2013 Coalfire Systems, Inc. Page 7

8 Total Protect security solution leverages a longstanding experience and commitment to provide cutting edge encryption technology to merchants and service providers. The VeriShield Total Protect security solution can be used by service providers and acquirers seeking to provide merchants with a secure encryption solution that will reduce their risk and the applicability of several PCI DSS controls. PCI DSS Validation Reduction The Payment Card Industry has developed the PCI Data Security Standard (DSS) to mitigate the risk of compromise to a specific data set. The standard is focused only to the system components that are within scope of PCI. For all system components, all PCI DSS controls apply. The PCI DSS is based on industry security best practices but is not focused on the overall information security of merchants. To reduce PCI DSS compliance scope you must reduce the potential security risk and access to payment card data. The PCI Security Standards Council has incorporated scope reduction guidance within the PCI DSS framework and through FAQ guidance on specific technologies or architecture. Scope reduction has most commonly been addressed through the implementation of network segmentation where systems and environments that process, store or transmit card data are isolated from other non-payment environments. This approach is not focused on reducing the applicability of any specific DSS control to a merchant s environment but rather reducing the validation expectations of the environment that the DSS controls apply to. As most of the DSS controls are designed to manage risk to card data from specific threat scenarios, it is therefore possible to reduce their applicability by securing the card data in the merchant environment, so that the threat scenarios are no longer a viable risk. By strongly encrypting card data at the point of capture in a secure and restricted device, where no ability to decrypt the card data exists, you can effectively isolate the majority of the merchant s environment from scope. If specific deployment scenarios are adhered to, the merchant environment can be treated as an untrusted environment similar to a public network when using strong transmission encryption. In 2012 the PCI Security Standards Council released 2 P2PE documents. The first was for a hardware/hardware solution, the second for a hardware/hybrid solution. For the purposes of this paper, the former will be the focus of all interpretations and comments. This standard can be found at PCI s document library, under the P2PE section, along with supporting documentation. These documents, along with the PCI DSS 2.0 are the reference points used for all comments and conclusions in this assessment. Additionally, PCI has updated some relevant FAQ s: FAQ of the Month - UPDATED Is encrypted cardholder data in scope for PCI DSS? 2013 Coalfire Systems, Inc. Page 8

9 August, 2012: This FAQ has been updated to reflect the evolving security landscape surrounding the use of encrypted payment card data, and to eliminate inconsistencies in how the scope of PCI DSS is determined with respect to the presence of encrypted data. With the release of the PCI Point-to-Point Encryption (P2PE) Program, the Council is providing additional guidance on the security of encrypted cardholder data through this updated FAQ, as well as two additional FAQs: "Are third-party storage providers storing only encrypted cardholder data in scope for PCI DSS?" and "Are merchants using Council-listed P2PE solutions out of scope for PCI DSS?" These FAQs are intended to clarify that storage of encrypted data without access to the decryption keys does not automatically result in the data, or the merchant, being out of scope. Encryption of cardholder data with strong cryptography is an acceptable method of rendering the data unreadable in order to meet PCI DSS Requirement 3.4. Because encrypted data can be decrypted with the right cryptographic key, encrypted cardholder data remains in scope for PCI DSS. Generally, the encrypted data is the responsibility of the entity (that is, the corporation, organization or business being reviewed) that controls and/or has access to the encrypted data and the decryption keys. It is possible that encrypted data may be deemed out of scope for a particular entity if, and only if, it is validated that the entity in possession of the encrypted data does not have the ability to decrypt it. This means the entity does not have decryption keys anywhere in their environment, and that none of the entity's systems, processes or personnel have access to the environment where decryption keys are located, nor do they have the ability to retrieve them. Furthermore, all applicable PCI DSS requirements apply if any of the following conditions are met: Encrypted cardholder data is stored on a system or media that also contains the decryption key, Encrypted data is stored in the same environment as the decryption key, Encrypted data is accessible to an entity that also has access to the decryption key. For information about how a merchant may receive scope reduction through use of a validated P2PE solution, please see the FAQ: "Are merchants using Council-listed P2PE solutions out of scope for PCI DSS?" This FAQ reference states: Are merchants using Council-listed P2PE solutions out of scope for PCI DSS? A. No. While use of a validated, listed P2PE solution can help to reduce the scope of a merchant s cardholder data environment, it does not remove the need for PCI DSS in the merchant environment. The merchant environment remains in scope for PCI DSS because cardholder data is always present within the merchant environment. For example, in a cardpresent environment, merchants have physical access to the payment cards in order to complete a transaction, and may also have paper reports or receipts with cardholder data. As another example, in card-not-present environments (such as mail-order or telephone-order), payment 2013 Coalfire Systems, Inc. Page 9

10 card details are provided via other channels that need to be evaluated and protected according to PCI DSS. Only Council-listed P2PE solutions are recognized as meeting the requirements necessary for merchants to reduce the scope of their cardholder data environment through use of a P2PE solution. Merchants using encryption solutions that are not included on the Council s List of Validated P2PE Solutions should consult with their acquirer or payment brand about use of these solutions. Another important FAQ: Can merchants use P2PE solutions not listed on the Council s website for PCI DSS scope reduction? A. Only Council-listed solutions are recognized as meeting the requirements necessary for merchants to reduce the scope of their cardholder data environment (CDE) through use of a P2PE solution. In addition to using a validated, Council-listed P2PE solution, merchants wishing to reduce the scope of their CDE must meet certain characteristics, as documented in the Merchants Using P2PE Solutions section of the P2PE Standard. SAQ-eligible merchants can review the P2PE-HW SAQ on our website for eligibility criteria and applicable PCI DSS requirements. Merchants using encryption solutions that are not included on PCI SSC s list of Validated P2PE Solutions should consult with their acquirer or the payment brands about the use of these solutions. Based on this guidance, one of the intentions for this assessment is to provide guidance for Merchants wishing to use the VeriFone VeriShield Total Protect Solution to be able to easily demonstrate to their acquirer or payment brands how the solution addresses various PCI DSS controls. In addition to this formal guidance from the Council, Coalfire has also utilized the following to formulate our guidance on PCI DSS reduction of applicable controls for P2PE: Dialogue with Council members regarding P2PE to understand their current position and future intent Reference and review of the FAQ released by the Council Dialogue with respected QSA s from other QSA companies in the industry Coalfire s experience in implementing other PCI DSS scope reduction programs Clarification of Compliance Clearly, PCI DSS scope reduction cannot remove a merchant from the requirement to be compliant. PCI DSS scope reduction does not eliminate a merchant s responsibility to validate compliance to their Acquirer as PCI DSS always applies to merchants who accept card data. Traditional PCI DSS scope reduction is only focused on addressing the applicability of specific controls to a merchant s environment based on isolation of data, systems and networks from security risks to payment card data. PCI DSS scope reduction s biggest payoff for merchants is the opportunity to eliminate the cost of control deployment for the sole purpose of meeting compliance obligations. The second major benefit is the reduction of cost and effort to validate PCI DSS compliance of the merchant environment. Many merchants have sensitive data assets other than payment card data in their environment that have a risk 2013 Coalfire Systems, Inc. Page 10

11 of compromise. Reducing PCI DSS scope for payment card data does not mean the PCI DSS controls are not justified to protect the merchants other information assets Coalfire Systems, Inc. Page 11

12 for Merchants Each merchant s environment is different. Differences in card data capture processes or deployment decisions could easily impact a merchant s ability to achieve maximum reduction of applicable controls. Coalfire has presented the most common deployment scenario for a merchant implementing VeriShield Total Protect to reduce PCI DSS scope. Additionally, we have identified important deployment constraints that are critical to adhere to for maximum reduction of controls. A number of deployment scenarios offered with the VeriShield Total Protect solution were assessed by Coalfire. All scenarios have a positive impact that reduces the number of PCI DSS controls for the merchant; however, there are significant differences if a merchant chooses a deployment scenario where they host decryption services or key management within their environment. Coalfire can support any merchant or QSA inquiry regarding the impact to PCI DSS controls from other deployment scenarios. Deployment Scenarios The VeriShield Total Protect solution is designed with flexible component architecture and distributed communication methods that can facilitate a number of deployment scenarios. Deployment scenarios can include deployments where both end points of the encryption/decryption process are under merchant control or outsourcing of the decryption endpoint to a service provider. The merchant may have a number of service provider options available to them that range from VeriFone, Network Aggregators (TNS) or Processor/Acquirers. Coalfire has defined two general deployment scenarios for the purpose of PCI scope assessment in this white paper. Regardless of the deployment scenario a number of deployment assumptions are required to achieve the full PCI DSS reduction of applicable controls for retail environments identified later in this white paper. The following assumptions are: Transaction locations only capture payment card data within the VeriShield Total Protect payment device. Payment applications and registers disable or procedurally restrict card swipe or card entry outside of the VeriShield Total Protect payment device. Only format preserving data is provided back to any payment application, register or downstream system No decryption capabilities of card data encrypted with VeriShield Total Protect are accessible to the merchant. The merchant does not possess or have access to decryption keys in their retail or corporate environments. All decryption services are contracted with a compliant service provider that has been assessed by a QSA to deliver the VeriShield Total Protect Decryption Services. Chargeback and other customer support and payment research processes do not include or require access to the full primary account number Coalfire Systems, Inc. Page 12

13 Public facing web applications for e-commerce or other payment transactional systems not using the VeriShield Total Protect solution must be addressed with your QSA to determine PCI DSS requirements. There are two versions of the derived key management system available unique key per device and shared key. 1. Unique Key per Device this derived key method creates a separate device derivation key (DDK) unique to each payment device so that card data is encrypted differently on every device the device derivation keys are derived from a unique master derivation key (MDK). 2. Shared Key this derived key method shares the device derivation key (DDK) across a set of payment devices so that card data is encrypted the same on each device in the set the device derivation key is derived from a unique master derivation key(mdk). This paper is focused solely on the use of the unique key per device derived key management system. Scenario #1 - VeriFone Hosted Decryption Service Deployment In this first scenario, a merchant deploys the VeriShield Total Protect payment device as the only capture end point in their retail environment and subscribes with VeriFone directly for decryption services. Figure 1: VeriFone Decryption Diagram This scenario is based on a merchant s selection of a VeriShield Total Protect payment device that is deployed in the retail environment that replaces any other platforms for card data capture. When card data is swiped or keyed into the VeriShield Total Protect solution, the VCL component encrypts the card data and sends it to a processing end-point where the decryption services reside. VeriFone manages the decryption service in a PCI DSS compliant environment. Scenario #2 3 rd Party Service Provider Decryption Service Deployment The second scenario is basically the same from a merchant s perspective, except for using a third party other than VeriFone for decryption. As with the previous scenario, a merchant deploys the VeriShield Total Protect terminal as the only capture end point in their retail environment and then subscribes with 2013 Coalfire Systems, Inc. Page 13

14 a processor/acquirer/service provider for decryption services. Coalfire has labeled this as the Outsourced Decryption deployment scenario. Figure 2: Outsourced Decryption Diagram The outsourced decryption scenario is based on a merchant s selection of a VeriShield Total Protect payment device that is deployed in the retail environment that replaces any other platforms for card data capture. When card data is swiped or keyed into the VeriShield Total Protect solution, the VCL component encrypts the card data and sends it to a processing end-point where the decryption services reside. The decryption service could be hosted by a gateway service provider or processor/acquirer. This end-point service provider would deploy and manage the decryption service in a PCI DSS compliant environment. Merchant PA-DSS Requirement Reduction Merchants who have payment applications that are currently not validated to the PCI Payment Application Data Security Standard (PA-DSS) are now required to only use applications which are validated to the PA-DSS 1.2 or higher standard. Not doing so introduces a significant risk, especially if a breach were to occur. While there are now a large number of options for validated Payment Applications, un-validated versions are still in use and affordable quality solutions are often limited in some industries. If a merchant follows either deployment scenario presented above, where they integrate the VeriShield Total Protect terminal with their payment application and no longer capture card data in the payment application, they can remove the requirement to use a PA-DSS validated application. Merchants must effectively purge any legacy card data from the existing applications and restrict any card capture whether through card swipe or key entry. The application would only prompt the VeriShield Total Protect solution for tender and pass transaction information. The payment application would never receive payment card data in return. The application then would no longer store, process or transmit cardholder data, which would effectively remove the application from PA-DSS eligibility based on PCI s Applications Eligible for PA-DSS Validation: 2013 Coalfire Systems, Inc. Page 14

15 This document states: For the purposes of PA-DSS, a payment application eligible for review and listing by the PCI SSC is defined as an application that: a) stores, processes, or transmits cardholder data as part of authorization or settlement; and b) is sold, distributed, or licensed to third parties 2013 Coalfire Systems, Inc. Page 15

16 Summary PCI DSS The following summary chart provides a quick view of the impact to PCI DSS control requirements for a merchant s retail environment assuming the VTP solution has been properly implemented. Merchant environments or payment processes can differ and it is important to work with your QSA and acquirer to validate appropriate PCI DSS control reduction before making any assumptions on scope reduction. If a merchant has deployed the VTP solution in their environment it is assumed that it is the only payment channel within the merchant s retail and corporate environments. Paper based processes discussed within the justifications below would be in support of the VTP payment channel only. All recommended risk reductions are based on the assumption that a QSA has fully validated that the VTP solution has been properly implemented in the merchant s environment. Summary Chart of Merchant PCI DSS PCI DSS Area Major Impact Moderate Impact Minor/No Impact Section 1 Section 2 Section 3 Section 4 Section 5 Section 6 Section 7 Section 8 X X X X X X X X Section 9 X Section 10 Section 11 X X Legend: Section 12 X Major A significant number of controls are either removed from scope or a reduction in the number of IT assets requiring the controls Moderate A reduced number of controls are required and a significant reduction in the number of IT assets requiring the controls 2013 Coalfire Systems, Inc. Page 16

17 Minor Either no controls are removed from scope or minor impact to the scope of IT assets requiring the controls Detailed PCI DSS A table in Appendix A was created as a general guideline for determining the PCI-DSS scope within a merchant environment utilizing the VTP solution. This risk-based guidance indicates Coalfire s recommended PCI-DSS scope reduction for Merchants that have compliantly implemented the VTP solution. Scroll down to Appendix A to review the detailed PCI DSS risk guidance Coalfire Systems, Inc. Page 17

18 Technical Assessment Scope of Assessment VeriFone VeriShield Total Protect was assessed for compliance relative to current PCI DSS 2.0 standards and PCI P2PE 1.1. The assessment testing focused on the following functional areas: 1. Verification of Point-to-Point Encryption from the point of encryption to the point of decryption a. Point-of-Encryption included VeriFone MX 915, MX 925 and VX820 Terminal Card Entry Devices with Tamper Resistant Security Module ( TRSM ) b. Point-of-Decryption was a VeriShield Decryption Service ( VSD ) Test System hosted by VeriFone. 2. Use of robust key management a. Direct Testing of key management via command cards b. Review of remote key management via VKM web interface c. Direct testing of key management via VCL API integration 3. Key-length and Cryptographic Standards 4. Alternate account or transaction identifier for recurring payments a. Note: recurring payment processing is not part of the VeriShield Total Protect system due to increased vulnerability of storing data b. VeriShield Total Protect is a transaction pipeline system c. Non-storage of any transaction data was verified by disk forensics 5. PCI DSS reduction of applicable controls Note: Coalfire s assessment concentrated on functional aspects of VeriFone VeriShield Total Protect, where tamper resistance is addressed by the PTS certification of the VeriFone terminal itself. Glossary Acronym FPE HSM KIF PAYware Connect TRSM SRED VCL VKM VMB VMC VSD VTP Description Format Preserving Encryption Hardware Security Module Key Injection Facility VeriFone Payment Gateway, with integrated VSD Tamper Resistant Security Module Secure Reading and Exchange of Data VeriShield Crypto Library VeriShield Key Management VeriShield Merchant Boarding VeriShield Monitoring & Compliance VeriShield Decryption Service VeriShield Total Protect Copyright 2013, Coalfire Systems Inc. Page 18

19 Figure 1: Test Lab Configuration Diagram The diagram below illustrates configuration used to test VeriShield Total Protect system. All encryption takes place at the VeriFone MX or VX device. Decryption takes place at the VeriShield Decryption Service. Status and alerts are centrally managed by the VeriShield Monitoring & Compliance console. Assessment Environment The VeriFone VeriShield Total Protect system was installed in Coalfire s Lab for the duration of the testing. A VeriFone VX 820 device was serially connected to a Coalfire provided Windows 7 machine. A VeriFone MX 915 devices was connected via USB and an MX 925 was connected via Ethernet; both to another Windows 7 machine. The Windows 7 machine hosted VeriFone s Form Agent application. Form agent simulates the logical POS interface to the VX and MX terminals, thus emulating a merchant s environment. The assessment included: Running payment card transactions using four test cards (American Express, Discover, Visa and MasterCard); Copyright 2013, Coalfire Systems Inc. Page 19

20 Monitoring interfaces for transmitted card data over a serial connection, USB and Ethernet. All transmitted card data was encrypted when leaving the VX or MX devices. Scanning the disk for unencrypted Track and PAN data both manually and using automated forensics tools. No card data was found on disk either encrypted or decrypted. The test equipment and software consisted of: 1. Serial Port Sniffer to monitor card data transferred from the VX 820 to the Form Agent application on the Windows machine; 2. USB Sniffer to monitor card data transferred from the MX 915 to the Form Agent application on the Windows machine; 3. Wireshark Ethernet port sniffer to monitor card data transferred from the MX 925 to the Form Agent application on the Windows machine; 4. Wireshark Ethernet port sniffer to monitor traffic from Windows machine to VSD hosted by VeriFone; 5. Magnetic card reader to verify Track 1 and Track 2 of test cards; 6. Remote access to VSD hosted by VeriFone to provide a feedback loop from the VSD to verify that the decrypted Track 1 and Track 2 data matched the unencrypted Track 1 and Track 2 data; 7. FTKCapture to create Disk Imaging application to capture the disk image of the Windows machines. Assessment testing used credit card transactions from four test cards (MasterCard, American Express, Discover, and Visa) and; scanning the system and database tables for Track 2 and unencrypted PAN data both manually and using automated forensics tools. Copyright 2013, Coalfire Systems Inc. Page 20

21 Figure 2: Test Configuration and Data Flow Diagram The diagram below illustrates the system as set up in the Coalfire labs. This dataflow diagram illustrates all test flows of cardholder data and the location of capture tools for analyzing data flows. VeriShield Total Protect Encryption Assessment The following charts show the results of the intercepted traffic from the MX and VX devices and the Windows machines. Note: The original full Track data was gathered independently using a magnetic card swipe device. Shown below are single specific examples, multiple examples were collected over the course of testing, across the 3 VeriFone devices, key rotation and via different methods including Serial sniffing, USB sniffing and Ethernet sniffing methods. Table 1: AMEX Track 2 Data vs. Encrypted Track 2 Data AMEX Test Card Source Ethernet Sniffer Full Original Track Data = ? Copyright 2013, Coalfire Systems Inc. Page 21

22 Full Track Encryption at MX = ? Table 2: VISA Track Data vs. Encrypted Track Data VISA Test Card Source Serial Sniffer Full Original Track Data %B ^SEMTEK/TEST VISA CARD ^ ? ; = ? Full Track Encryption at VX 820 %B ^SEMTEK/TEST VISA CARD ^ ? ; = ? Table 3: MasterCard Track Data vs. Encrypted Track Data MasterCard Test Card Source USB Sniffer Full Original Track Data %B ^SEMTEK/TEST CARD MC ^ ? ; = ? Full Track Encryption at MX 915 %B ^SEMTEK/TEST CARD MC ^ ? ; = ? These results demonstrate the encryption that is performed by the VeriShield Total Protect VCL on the device and all output is encrypted before any attached system, such as a POS, has received the data. The encrypted PANs pass the Luhn (mod 10) test. Error State and Out-of-Band Encryption The VeriShield Total Protect solution is configured to securely encrypt the greatest number of transactions possible at the point of swipe while managing a number of out-of-range and error conditions. Encryption rules have been enhanced in VTP. There are two transactional scenarios where encryption would not occur: 1. Expiration Out-of-Range If a card is swiped with an expiration date beyond 2054 the encryption function will not be executed. 2. BIN exclusion table A table to define BIN ranges to not encrypt is available. This can be used for fleet card and other gift or reward card type programs and no valid Card-branded ranges should ever be included. Specific encryption rules that will be encrypted include: Cards that do not pass the Luhn check (Mod 10). Cards that have expired. Cards where Track 1 PAN and Track 2 PAN does not match. Validation of Decryption at VeriShield Decryption ( VSD ) The following results were obtained using VeriFone s FormAgent PC test tool. FormAgent simulated a POS transaction prompting the MX and VX devices to accept the input of a card for a magnetic swipe transaction and also demonstrated the results of what was received. This data could then be used to send the encrypted data to the remote VSD server hosted by VeriFone. This feedback loop allowed a look into the Point-to-Point Encryption process. The process for verifying the Encryption was as follows: 1. Encrypted Track 1 or Track 2 data from the MX or VX device was captured by the serial, USB or Ethernet sniffer. Form agent also displayed the same encrypted data. Copyright 2013, Coalfire Systems Inc. Page 22

23 2. The captured Track 1 or Track 2 data was entered into the VSD by a remote connection and using a web browser and running the DecryptV04 API. 3. The VSD sent the decrypted Track 2 or Track 1 data back to the Coalfire monitoring workstation. Since the clear text track data was known, a comparison could be made between the Track 2 or Track 1 data sent by VSD and the known Track 2 or Track 1 data. The capture of data at serial, USB and Ethernet interfaces demonstrates that data flowing from the MX and VX devices is encrypted. The format of the encrypted data is valid. Any application, computer, network equipment, or transmission media cannot compromise card holder data since the card data is encrypted at the MX or VX device with VeriShield Total Protect. The following are a few examples of Form agent output, sniffer outputs and the VSD decryption responses: Figure 3: Form Agent Example Figure 4: Serial Capture Example Figure 5: USB Capture Example Copyright 2013, Coalfire Systems Inc. Page 23

24 Figure 6: Ethernet Capture Example Figure 7: VSD Decrypt Form Example Copyright 2013, Coalfire Systems Inc. Page 24

25 Figure 8: VSD Decrypt Result Example Disk Analysis The technical assessment included a forensic examination of the Windows workstation hard disk drive as well as the VSD hard disks. The process for examining the disk was as follows: 1. A complete workstation disk image and VSD server image was captured by FTK Image application on an external USB-hard drive; 2. The captured disk images were verified using a hashing algorithm; and 3. EnCase was used to search the disk images for all test card PANs and Tracks. There was no PAN or track data on any disk. The disk forensic analysis demonstrates that storage of any track data, encrypted or in the clear, is not taking place. The POS system does not handle any cardholder data, nor does it ever have access to it. The VSD servers are actually in scope under a service provider PCI DSS ROC, but images were taken to validate encrypted storage and to compare encrypted values throughout the entire process. The VeriShield Total Protect solution integrates securely with PC based POS or cash registers without exposing card data, encryption keys or authentication data to these platforms. WAN Traffic Assessment A Wireshark Ethernet port sniffer was used to monitor traffic from test POS machine to the VSD Servers. In a production scenario, traffic from the POS is encrypted using SSL. While not required, this encryption adds an additional layer of security at the transport layer. Copyright 2013, Coalfire Systems Inc. Page 25

26 Key Loading and Distribution With derived key only one key is loaded into the device; the MDK (Master Derivation Key). Once loaded the MDK is used to generate the DDK (Device Derivation Key) within the device. Once the DDK s are created, the MDK is securely deleted. There are two ways to load the MDK into the VeriFone devices: 1. Master Key Component Cards The HSM utility is used to create the files which are used to burn the Master Component cards for a specific KEK. The KEK is entered into the HSM utility and it creates the files that are used to burn the Master Component Cards. The Master Component Card swipes at the device cause VCL to fetch the wrapped MDK from the vcl_settings file and to unwrap it with the KEK that is derived from the data on the Master Component cards. Once the MDK has been successfully injected into the device, VCL uses it and other info to generate 90 DDKs. Then the MDK is deleted. VCL points to the 0 th DDK. 2. VeriShield Remote Key (VRK) A VRK Payload is created that will enable the device to unwrap the MDK that is wrapped in the Remote KEK. Once VCL has injected the MDK the process is the same as above. Copyright 2013, Coalfire Systems Inc. Page 26

27 Updating Keys There are three ways to advance the DDK within the VeriFone devices: 1. VCL Direct Interface A merchant can integrate directly to VCL to do the Advance DDK command. A merchant Point of Sale (POS) system will enable this feature so that the key can be advanced by direct interface from the POS. Once the advance DDK command is received, VCL will advance the DDK index to the next available DDK. The old DDK is deleted. VCL will create a command response which, when received by VSD, causes VSD to increment the DDK index portion of the derivation data for the virtual device that represents that physical device in the VSD database. No key data is exchanged. If no virtual device exists yet, one is created. Figure 9: Advance DDK - Key Management using VCL Direct Interface Copyright 2013, Coalfire Systems Inc. Page 27

28 2. VKM VeriShield Key Management The user may use VKM (VeriShield Key Management) to create Advance DDK jobs for selected devices. Once the device has fetched the job package via kmailman, VCL will advance the DDK index to the next available DDK. The old DDK is deleted. VCL will return status (via kmailman) back to the VKM service which will communicate to VSD. This causes VSD to increment the DDK index portion of the derivation data for the virtual device that represents that physical device in the VSD database. No key data is exchanged. There is no key data in the job package. Note that the user may create the job for already existing devices only. Figure 10: Advance DDK - Key Management using VKM Copyright 2013, Coalfire Systems Inc. Page 28

29 3. Command Cards VMB is used to generate a file that is used to burn a merchant specific Advance DDK command card. When the Advance DDK command card is swiped at a device, VCL will advance the DDK index to the next available DDK. The old DDK is deleted. VCL creates a command response which, when received by VSD, causes VSD to increment the DDK index portion of the derivation data for the virtual device that represents that physical device in the VSD database. No key data is exchanged. There is no key data on the Advance DDK command card. If no virtual device exists yet, one is created. Figure 11: Advance DDK - Key Management using Command Card Copyright 2013, Coalfire Systems Inc. Page 29

30 Key Management via Command Cards, VKM, and VCL Direct Interface The Command Card method is primarily used to load keys to a device during a pilot or proof of concept. Command cards are not used for production key management procedures, other than rare cases where some service providers choose to use them to advance the DDK from one key to the next. VKM requires either TCP/IP connectivity or a mechanism to push a file to the PIN pad device. Most merchants choose to use the VCL Direct Interface method of key management so they don t have to manage the creation and distribution of command cards, thus creating the most favorable operational environment for managing the changing of encryption keys. Command cards were necessary for our test system, but it replicates the use of how a KIF (Key Injection Facility) combines keys from the HSM into the device. A Command Card has a magnetic stripe card that contains an encrypted string of information used to load the necessary keys on the PIN pad device. There are five different types of command cards (or integration methods): 1. RegiStart: This enables encryption and all transactions are then encrypted based on the current DDK. 2. Stop Command Card: Used to turn encryption off. 3. Registart SRED: This is identical as the regular RegiStart, except that once this is run, encryption cannot be turned off. The Stop command card was tested after use of this card and it failed. 4. Advance DDK: This is used to move from one DDK to the next. This is the one item that can be done via a command card or via VKM in production, although most service providers to not use the command card option. 5. Update Settings: This is used to update a configuration parameter in VCL or to update a BIN exclusion file. There are also master key cards: Master Key Component Cards: Two cards are used, replicating the two components of that a KIF receives. These two values are XORed and used to inject the MDK from the vcl_settings file. 90 DDK s are generated at this point and the MDK is then deleted. VCL Direct Interface and Key Management A merchant POS vendor will work with the merchant to build the interface to VCL for the Registart command. After the integration is complete, the RegiStart command can be triggered at the POS and VCL will set the encryption state to ON. VCL creates a command response containing derivation data and the encryption on state which, when received by VSD, causes VSD to apply the derivation data and encryption state to the virtual device that represents that physical device in the VSD database. No key data is exchanged. There is no key data in the RegiStart command. If no virtual device exists yet, one is created. This command card will fail at the device if the device is in SRED mode and the command response will contain the failure info. A merchant POS vendor will work with the merchant to build the interface to VCL for the Registart SRED command. When the RegiStart SRED command is triggered at the POS, VCL will set the encryption state to ON and SRED mode to enabled. VCL creates a command response containing derivation data, the encryption on state, and SRED on state which, when received by VSD, causes VSD to apply the derivation data, encryption stat, and SRED on mode to the virtual device that represents that physical device in the VSD database. No key data is exchanged. There is no key data in the RegiStart SRED command. If no virtual device exists yet, one is created. A merchant POS vendor will work with the merchant to build the interface to VCL for the Stop command. When the Stop command is triggered at the POS, VCL will set the encryption state to OFF. VCL creates a command response Copyright 2013, Coalfire Systems Inc. Page 30

31 containing the encryption off state which, when received by VSD, causes VSD to apply the encryption state to the virtual device that represents that physical device in the VSD database. No key data is exchanged. There is no key data in the Stop command. If no virtual device exists yet, one is created but it will have no derivation data at all. This command will fail at the device if the device is in SRED mode and the command response will contain the failure info. A merchant POS vendor will work with the merchant to build the interface to VCL for the Advance DDK command. When the Advance DDK command is triggered at the POS, VCL will advance the DDK index to the very next value. VCL creates a command response containing the new derivation data, when received by VSD, causes VSD to apply the new derivation data to the virtual device that represents that physical device in the VSD database. No key data is exchanged. There is no key data in the Advance DDK command. If no virtual device exists yet, one is created. This command will fail at the device if the device is on the last DDK and the command response will contain the failure info. VKM and Key Management The user may use VKM (VeriShield Key Management) to create RegiStart jobs for selected devices. Once the device has fetched the job package via kmailman, VCL will set the encryption state to ON. VCL will return status (via kmailman) back to the VKM service which will communicate to VSD. VCL will return encryption status and derivation data (via kmailman) back to the VKM service which will communicate to VSD. This causes VSD to apply the derivation data and encryption state to the virtual device that represents that physical device in the VSD database. No key data is exchanged. There is no key data in the job that is created by VKM. There is no key data in the response that is returned by VCL. This job will fail at the device if the device is in SRED mode and VKM will receive the failure info. The user may use VKM (VeriShield Key Management) to create RegiStart SRED jobs for selected devices. Once the device has fetched the job package via kmailman, VCL will set the encryption state to ON and SRED mode to enabled. VCL will return encryption and SRED status and derivation data (via kmailman) back to the VKM service which will communicate to VSD. This causes VSD to apply the derivation data, SRED state, and encryption state to the virtual device that represents that physical device in the VSD database. No key data is exchanged. There is no key data in the job that is created by VKM. There is no key data in the response that is returned by VCL. The user may use VKM (VeriShield Key Management) to create Stop jobs for selected devices. Once the device has fetched the job package via kmailman, VCL will set the encryption state to OFF. VCL will return status (via kmailman) back to the VKM service which will communicate to VSD. VCL will return encryption status and derivation data (via kmailman) back to the VKM service which will communicate to VSD. This causes VSD to apply the derivation data and encryption state to the virtual device that represents that physical device in the VSD database. No key data is exchanged. There is no key data in the job that is created by VKM. There is no key data in the response that is returned by VCL. This job will fail at the device if the device is in SRED mode and VKM will receive the failure info. The user may use VKM (VeriShield Key Management) to create Advance DDK jobs for selected devices. Once the device has fetched the job package via kmailman, VCL will advance the DDK index to the very next value. VCL will Copyright 2013, Coalfire Systems Inc. Page 31

32 return status (via kmailman) back to the VKM service which will communicate to VSD. This causes VSD to apply the new derivation data to the virtual device that represents that physical device in the VSD database. No key data is exchanged. There is no key data in the job that is created by VKM. There is no key data in the response that is returned by VCL. This job will fail at the device if the device is on the last DDK and VKM will receive the failure info. Command Cards and Key Management: VMB is used to generate a file that is used to burn a merchant specific RegiStart command card. When the RegiStart command card is swiped at a device, VCL will set the encryption state to ON. VCL creates a command response containing derivation data and the encryption ON state which, when received by VSD, causes VSD to apply the derivation data and encryption state to the virtual device that represents that physical device in the VSD database. No key data is exchanged. There is no key data on the RegiStart command card. If no virtual device exists yet, one is created. This command card will fail at the device if the device is in SRED mode and the command response will contain the failure info. VMB is used to generate a file that is used to burn a merchant specific RegiStart SRED command card. When the RegiStart SRED command card is swiped at a device, VCL will set the encryption state to ON and SRED mode to enabled. VCL creates a command response containing derivation data, the encryption ON state, and SRED ON state which, when received by VSD, causes VSD to apply the derivation data, encryption state, and SRED ON mode to the virtual device that represents that physical device in the VSD database. No key data is exchanged. There is no key data on the RegiStart SRED command card. If no virtual device exists yet, one is created. VMB is used to generate a file that is used to burn a merchant specific Stop command card. When the Stop command card is swiped at a device, VCL will set the encryption state to OFF. VCL creates a command response containing the encryption OFF state which, when received by VSD, causes VSD to apply the encryption state to the virtual device that represents that physical device in the VSD database. No key data is exchanged. There is no key data on the Stop command card. If no virtual device exists yet, one is created but it will have no derivation data at all. This command card will fail at the device if the device is in SRED mode and the command response will contain the failure info. Copyright 2013, Coalfire Systems Inc. Page 32

33 SRED Information Here are some guidelines for how SRED mode works: SRED is specific to Derived Unique Key Mode Encryption may NOT be stopped on a Derived Unique Key encrypting device that is in SRED mode. Once in SRED mode, a Derived Unique Key encrypting device may NOT be taken out of SRED mode. Encryption may ONLY be stopped on a Derived Unique Key encrypting device that is NOT in SRED mode. A new command card may be created that will start encryption and place the Derived Unique Key encrypting device in SRED mode. A new VKM job may be selected that will start encryption and place the Derived Unique Key encrypting device in SRED mode. Specific to derived key mode: Derived Shared Key encrypting devices may NOT be placed in SRED mode. Start SRED command cards may NOT be made for Classic Mode devices. A Start SRED job may NOT be assigned to a Classic Mode device. During testing, each of the devices was placed into each mode using the command cards. Encryption was turned back on after the regular encryption mode was enabled and then put into the SRED encryption mode. The encrypted values were observed to be the same, validating that the same DDK was in use regardless of mode. SRED mode is simply a one way version of the encryption enablement on a device. Advance DDK was also used and new encrypted values were observed. Swiping of track 1 and track 2, as well as manual entry of PAN and expiration date was done on each of the devices to ensure no method of entry was ever output from the device in clear text. Use of VKM VKM is intended for use by service providers to enable key advancement remotely, as well as manage other basic administrative functions. Access to VKM is structured based upon users, groups, and access rights. Service Providers need to follow all standard PCI DSS practices in allowing access and use of VKM in support of their merchants. Merchants using VTP should not have access to VKM in order to maintain the maximum reduction of applicable controls. Summary VTP is a robust P2PE solution that, if implemented correctly, can be used by merchants and service providers to dramatically reduce both risk and scope for PCI DSS controls. VTP can be used to achieve a full PCI P2PE listing by service providers to achieve maximum scope reduction to provide to merchants, and it can also be used in a non-listed manner to achieve dramatic reduction of applicable controls as detailed above. Service Providers should follow all guidance on how to use VTP properly and fully secure their back end decryption processes to PCI DSS standards. Merchants can use VTP and this document to demonstrate how the technology works and enable QSA s or other interested parties to be able to evaluate their proper implementation of VTP into their environment. Copyright 2013, Coalfire Systems Inc. Page 33

34 Appendix A: PCI DSS Risk Mappings Detailed PCI DSS The information contained in the table in Appendix A was created as a general guideline for determining the PCI-DSS scope within a merchant environment utilizing the VTP solution. This risk-based guidance indicates Coalfire s recommended PCI-DSS reduction of applicable controls for merchants that have properly implemented the VTP solution. Merchants should work with their QSA and acquirer to validate proper implementation and appropriate PCI DSS control reduction before making any assumptions on scope reduction. It s important to note that the risk reduction values and their associated mapping to PCI DSS requirements below are intended to address the applicability of each PCI testing procedure. The risk values are not intended as a recommendation from Coalfire or VeriFone to remove existing security systems and controls from a merchant environment. Merchant s need to be aware of the principle of defense in depth; even though many of the requirements in the table below are designated as Not Applicable for the purposes of obtaining a PCI DSS validation, the associated security system and processes are still needed to meet industry best practices and protect the merchant s environment as a whole. The information within the table is broken into the following columns: PCI-DSS Testing s: The PCI-DSS requirement testing procedure as outlined in the PCI-DSS v2.0. : This is the associated risk value (1-4) associated with each PCI-DSS testing procedure. The value indicates whether or not the scope for a PCI-DSS requirement can be reduced or eliminated. They are as follows: 1. Properly implemented, the VTP solution will completely eliminate the requirement from the scope of a merchant s PCI-DSS assessment. 2. Properly implemented, the VTP solution can significantly reduce or eliminate the requirement from the scope of a merchant s PCI-DSS assessment. Depending on the merchant s cardholder data environment, some validation from the QSA may be required. 3. Properly implemented, the VTP solution may reduce the testing associated with this requirement; however, the control will need to be validated by the merchant s QSA. 4. This requirement is fully in-scope for the merchant s PCI-DSS assessment. Note: The risk rankings associated with each PCI DSS requirement relate to the VTP payment channel only. If the merchant maintains other payment channels and processes they will need to be evaluated for scope separately. : Mapped against the PCI-DSS ROC Reporting Instructions v2.0, the documentation a Merchant is responsible for maintaining if a requirement is deemed in-scope for their PCI-DSS assessment. Requirements with a Risk value of 1 will not have any associated documentation expectations. : The Coalfire justification for the reduction or elimination of applicable controls for each PCI-DSS requirement when the VTP solution is properly implemented. Copyright 2013, Coalfire Systems Inc. Page 34

35 1.1 Obtain and inspect the firewall and router configuration standards and other documentation specified below to verify that standards are complete. Complete the following: Verify that there is a formal process for testing and approval of all network connections and changes to firewall and router configurations a Verify that a current network diagram (for example, one that shows cardholder data flows over the network) exists and that it documents all connections to cardholder data, including any wireless networks b Verify that the diagram is kept current a Verify that firewall configuration standards include requirements for a firewall at each Internet connection and between any DMZ and the internal network zone b Verify that the current network diagram is consistent with the firewall configuration standards. requirements for the merchant s host network. 3 Network Diagram Even with the significant reduction of applicable controls the VTP solution obtains, Coalfire feels that merchants should still diagram the data flow of the retail locations where VTP will be utilized. 3 Network Diagram Even with the significant reduction of applicable controls the VTP solution obtains, Coalfire feels that merchants should still diagram the data flow of the retail locations where VTP will be utilized. requirements for the merchant s host network. 3 Network Diagram Coalfire feels that a network diagram is still appropriate for the merchant environment; however, it will not need to be compared to network configuration standards. Copyright 2013, Coalfire Systems Inc. Page 35

36 1.1.4 Verify that firewall and router configuration standards include a description of groups, roles, and responsibilities for logical management of network components a Verify that firewall and router configuration standards include a documented list of services, protocols and ports necessary for business for example, hypertext transfer protocol (HTTP) and Secure Sockets Layer (SSL), Secure Shell (SSH), and Virtual Private Network (VPN) protocols b Identify insecure services, protocols, and ports allowed; and verify they are necessary and that security features are documented and implemented by examining firewall and router configuration standards and settings for each service a Verify that firewall and router configuration standards require review of firewall and router rule sets at least every six months b Obtain and examine documentation to verify that the rule sets are reviewed at least every six months. requirements for the merchant s host network. requirements for the merchant s host network. requirements for the merchant s host network. requirements for the merchant s host network. requirements for the merchant s host network. Copyright 2013, Coalfire Systems Inc. Page 36

37 1.2 Examine firewall and router configurations to verify that connections are restricted between untrusted networks and system components in the cardholder data environment, as follows: a Verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment, and that the restrictions are documented b Verify that all other inbound and outbound traffic is specifically denied, for example by using an explicit deny all or an implicit deny after allow statement Verify that router configuration files are secure and synchronized for example, running configuration files (used for normal running of the routers) and start-up configuration files (used when machines are rebooted), have the same, secure configurations. requirements for the merchant s host network. requirements for the merchant s host network. requirements for the merchant s host network. Copyright 2013, Coalfire Systems Inc. Page 37

38 1.2.3 Verify that there are perimeter firewalls installed between any wireless networks and systems that store cardholder data, and that these firewalls deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment. requirements for the merchant s host network. There will be no cardholder data storage on the Merchant s network. 1.3 Examine firewall and router configurations including but not limited to the choke router at the Internet, the DMZ router and firewall, the DMZ cardholder segment, the perimeter router, and the internal cardholder network segment to determine that there is no direct access between the Internet and system components in the internal cardholder network segment, as detailed below Verify that a DMZ is implemented to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports Verify that inbound Internet traffic is limited to IP addresses within the DMZ. requirements for the merchant s host network. There is no cardholder data storage in a merchant environment and as such the DMZ network layer would not be applicable. requirements for the merchant s host network. There is no cardholder data storage in a merchant environment and as such the DMZ network layer would not be Copyright 2013, Coalfire Systems Inc. Page 38

39 applicable Verify direct connections inbound or outbound are not allowed for traffic between the Internet and the cardholder data environment. 2 Network Diagram Network Configuration Standards When implemented properly, the VTP requirements for the merchant s host network. However, Coalfire still recommends against direct unrestricted inbound Internet access to the POIs Verify that internal addresses cannot pass from the Internet into the DMZ Verify that outbound traffic from the cardholder data environment to the Internet is explicitly authorized requirements for the merchant s host network. requirements for the merchant s host network Verify that the firewall performs stateful inspection (dynamic packet filtering). (Only established connections should be allowed in, and only if they are associated with a previously established session.) 2 Network Diagram Network Configuration Standards When implemented properly, the VTP requirements for the merchant s host network. However, Coalfire still recommends against direct unrestricted inbound Internet access to the POIs Verify that system components that store cardholder data are on an internal network zone, segregated from the DMZ and other untrusted networks a Verify that methods are in place to prevent the disclosure of private IP addresses and routing information from internal requirements for the merchant s host network. There is no cardholder data storage in a merchant environment and as such the DMZ network layer would not be applicable. requirements for the merchant s host network. Copyright 2013, Coalfire Systems Inc. Page 39

40 networks to the Internet b Verify that any disclosure of private IP addresses and routing information to external entities is authorized. 1.4.a Verify that mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), and which are used to access the organization s network, have personal firewall software installed and active. 1.4.b Verify that the personal firewall software is configured by the organization to specific standards and is not alterable by users of mobile and/or employee-owned computers. 2.1 Choose a sample of system components, and attempt to log on (with system administrator help) to the devices using default vendor-supplied accounts and passwords, to verify that default accounts and passwords have been changed. (Use vendor manuals and sources on the Internet to find vendorsupplied requirements for the merchant s host network. requirements for the merchant s host network. With no access to cardholder data, mobile and/or employee owned computers can be considered out of scope for PCI DSS. requirements for the merchant s host network. With no access to cardholder data, mobile and/or employee owned computers can be considered out of scope for PCI DSS. Copyright 2013, Coalfire Systems Inc. Page 40

41 accounts/passwords.) Verify the following regarding vendor default settings for wireless environments: a Verify encryption keys were changed from default at installation, and are changed anytime anyone with knowledge of the keys leaves the company or changes positions b Verify default SNMP community strings on wireless devices were changed c Verify default passwords/passphrases on access points were changed d Verify firmware on wireless devices is updated to support strong encryption for authentication and transmission over wireless networks e Verify other security-related wireless vendor defaults were requirements for the merchant s host network. requirements for the merchant s host network. requirements for the merchant s host network. requirements for the merchant s host network. requirements for the merchant s host Copyright 2013, Coalfire Systems Inc. Page 41

42 changed, if applicable. network. 2.2.a Examine the organization s system configuration standards for all types of system components and verify the system configuration standards are consistent with industry-accepted hardening standards. 2.2.b Verify that system configuration standards are updated as new vulnerability issues are identified, as defined in Requirement c Verify that system configuration standards are applied when new systems are configured. 2.2.d Verify that system configuration standards include each item below ( ) a For a sample of system components, verify that only one primary function is implemented per server. Copyright 2013, Coalfire Systems Inc. Page 42

43 2.2.1.b If virtualization technologies are used, verify that only one primary function is implemented per virtual system component or device a For a sample of system components, inspect enabled system services, daemons, and protocols. Verify that only necessary services or protocols are enabled b Identify any enabled insecure services, daemons, or protocols. Verify they are justified and that security features are documented and implemented a Interview system administrators and/or security managers to verify that they have knowledge of common security parameter settings for system components b Verify that common security parameter settings are included in the system configuration standards c For a sample of system components, verify that common security parameters are set appropriately. Copyright 2013, Coalfire Systems Inc. Page 43

44 2.2.4.a For a sample of system components, verify that all unnecessary functionality (for example, scripts, drivers, features, subsystems, file systems, etc.) is removed b. Verify enabled functions are documented and support secure configuration c. Verify that only documented functionality is present on the sampled system components. 2.3 For a sample of system components, verify that non-console administrative access is encrypted by performing the following: 2.3.a Observe an administrator log on to each system to verify that a strong encryption method is invoked before the administrator s password is requested. 2.3.b Review services and parameter files on systems to determine that Telnet and other remote login commands are not available for use internally. Copyright 2013, Coalfire Systems Inc. Page 44

45 2.3.c Verify that administrator access to the web-based management interfaces is encrypted with strong cryptography. 2.4 Perform testing procedures A.1.1 through A.1.4 detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers for PCI DSS assessments of shared hosting providers, to verify that shared hosting providers protect their entities (merchants and service providers) hosted environment and data. 1 Not Applicable Not Applicable for merchants. 3.1 Obtain and examine the policies, procedures and processes for data retention and disposal, and perform the following: a Verify that policies and procedures are implemented and include legal, regulatory, and business requirements for data retention, including specific requirements for retention of cardholder data (for example, cardholder data needs to be held for X period for Y business reasons). 3 Data Retention and Storage Policies (if applicable) If the merchant has any paper based processes associated with this payment channel then this requirement will still apply to their environment. Otherwise, this requirement can be considered not applicable. Copyright 2013, Coalfire Systems Inc. Page 45

46 3.1.1.b Verify that policies and procedures include provisions for secure disposal of data when no longer needed for legal, regulatory, or business reasons, including disposal of cardholder data c Verify that policies and procedures include coverage for all storage of cardholder data d Verify that policies and procedures include at least one of the following: * A programmatic process (automatic or manual) to remove, at least quarterly, stored cardholder data that exceeds requirements defined in the data retention policy * Requirements for a review, conducted at least quarterly, to verify that stored cardholder data does not exceed requirements defined in the data retention policy e For a sample of system components that store cardholder data, verify that the data stored does not exceed the requirements defined in the data retention policy. 3 Data Retention and Storage Policies (if applicable) 3 Data Retention and Storage Policies (if applicable) 3 Data Retention and Storage Policies (if applicable) 3 Data Retention and Storage Policies (if applicable) If the merchant has any paper based processes associated with this payment channel then this requirement will still apply to their environment. Otherwise, this requirement can be considered not applicable. If the merchant has any paper based processes associated with this payment channel then this requirement will still apply to their environment. Otherwise, this requirement can be considered not applicable. If the merchant has any paper based processes associated with this payment channel then this requirement will still apply to their environment. Otherwise, this requirement can be considered not applicable. If the merchant has any paper based processes associated with this payment channel then this requirement will still apply to their environment. Otherwise, this requirement can be considered not applicable. Copyright 2013, Coalfire Systems Inc. Page 46

47 3.2.a For issuers and/or companies that support issuing services and store sensitive authentication data, verify there is a business justification for the storage of sensitive authentication data, and that the data is secured. 3.2.b For all other entities, if sensitive authentication data is received and deleted, obtain and review the processes for securely deleting the data to verify that the data is unrecoverable. 1 Not Applicable Not applicable for merchants. 1 Not Applicable Sensitive authentication data will not be stored within or outside of hardware POI devices. 3.2.c For each item of sensitive authentication data below, perform the following steps: For a sample of system components, examine data sources, including but not limited to the following, and verify that the full contents of any track from the magnetic stripe on the back of card or equivalent data on a chip are not stored under any circumstance: * Incoming transaction data * All logs (for example, transaction, history, debugging, error) * History files * Trace files * Several database schemas * Database contents 1 Not Applicable Sensitive authentication data will not be stored within or outside of hardware POI devices. Copyright 2013, Coalfire Systems Inc. Page 47

48 3.2.2 For a sample of system components, examine data sources, including but not limited to the following, and verify that the three-digit or fourdigit card verification code or value printed on the front of the card or the signature panel (CVV2, CVC2, CID, CAV2 data) is not stored under any circumstance: * Incoming transaction data * All logs (for example, transaction, history, debugging, error) * History files * Trace files * Several database schemas * Database contents 3 Data Retention and Storage Policies (if applicable) If the merchant has any paper based processes associated with its payment channel that includes card validation codes then this requirement will still apply to documents. Otherwise, this requirement can be considered not applicable. Sensitive authentication data will not be stored within or outside of hardware POI devices For a sample of system components, examine data sources, including but not limited to the following and verify that PINs and encrypted PIN blocks are not stored under any circumstance: * Incoming transaction data * All logs (for example, transaction, history, debugging, error) * History files * Trace files * Several database schemas * Database contents 1 Not Applicable Sensitive authentication data will not be stored within or outside of hardware POI devices. Copyright 2013, Coalfire Systems Inc. Page 48

49 3.3 Obtain and examine written policies and examine displays of PAN (for example, on screen, on paper receipts) to verify that primary account numbers (PANs) are masked when displaying cardholder data, except for those with a legitimate business need to see full PAN. 3 Data Retention and Storage Policies (if applicable) If the merchant has any paper based processes associated with this payment channel then this requirement will still apply to their environment. Otherwise, this requirement can be considered not applicable. 3.4.a Obtain and examine documentation about the system used to protect the PAN, including the vendor, type of system/process, and the encryption algorithms (if applicable). Verify that the PAN is rendered unreadable using any of the following methods: * One-way hashes based on strong cryptography * Truncation * Index tokens and pads, with the pads being securely stored * Strong cryptography, with associated keymanagement processes and procedures 3.4.b Examine several tables or files from a sample of data repositories to verify the PAN is rendered unreadable (that is, not stored in plain-text). 3.4.c Examine a sample of removable media (for example, back-up tapes) to confirm that the PAN is 1 Not Applicable PAN will be rendered unreadable at swipe on POI devices. Merchants will have no responsibility for cardholder data within their environments. 1 Not Applicable PAN will be rendered unreadable at swipe on POI devices. Merchants will have no responsibility for cardholder data within their environments. 1 Not Applicable PAN will be rendered unreadable at swipe on POI devices. Merchants will have no responsibility for cardholder data within their environments. Copyright 2013, Coalfire Systems Inc. Page 49

50 rendered unreadable. 3.4.d Examine a sample of audit logs to confirm that the PAN is rendered unreadable or removed from the logs a If disk encryption is used, verify that logical access to encrypted file systems is implemented via a mechanism that is separate from the native operating systems mechanism (for example, not using local user account databases) b Verify that cryptographic keys are stored securely (for example, stored on removable media that is adequately protected with strong access controls) c Verify that cardholder data on removable media is encrypted wherever stored. 1 Not Applicable PAN will be rendered unreadable at swipe on POI devices. Merchants will have no responsibility for cardholder data within their environments. 1 Not Applicable PAN will be rendered unreadable at swipe on POI devices. Merchants will have no responsibility for cardholder data within their environments. 1 Not Applicable PAN will be rendered unreadable at swipe on POI devices. Merchants will have no responsibility for cardholder data within their environments. 1 Not Applicable PAN will be rendered unreadable at swipe on POI devices. Merchants will have no responsibility for cardholder data within their environments. Note: If disk encryption is not used to encrypt removable media, the data stored on this media will need to be rendered unreadable through some other method. Copyright 2013, Coalfire Systems Inc. Page 50

51 3.5 Verify processes to protect keys used for encryption of cardholder data against disclosure and misuse by performing the following: Examine user access lists to verify that access to keys is restricted to the fewest number of custodians necessary. 1 Not Applicable. If the VTP solution has been implemented correctly, Merchants will have no key management responsibilities within their environment a Examine system configuration files to verify that keys are stored in encrypted format and that key-encrypting keys are stored separately from data-encrypting keys b Identify key storage locations to verify that keys are stored in the fewest possible locations and forms 1 Not Applicable. If the VTP solution has been implemented correctly, Merchants will have no key management responsibilities within their environment. 1 Not Applicable. If the VTP solution has been implemented correctly, Merchants will have no key management responsibilities within their environment. 3.6.a Verify the existence of key-management procedures for keys used for encryption of cardholder data. 1 Not Applicable. If the VTP solution has been implemented correctly, Merchants will have no key management responsibilities within their environment. Copyright 2013, Coalfire Systems Inc. Page 51

52 3.6.b For service providers only: If the service provider shares keys with their customers for transmission or storage of cardholder data, verify that the service provider provides documentation to customers that includes guidance on how to securely transmit, store and update customer s keys, in accordance with Requirements through below. 1 Not Applicable. Not applicable for merchants. 3.6.c Examine the keymanagement procedures and perform the following: Verify that keymanagement procedures are implemented to require the generation of strong keys. 1 Not Applicable. If the VTP solution has been implemented correctly, Merchants will have no key management responsibilities within their environment Verify that keymanagement procedures are implemented to require secure key distribution. 1 Not Applicable. If the VTP solution has been implemented correctly, Merchants will have no key management responsibilities within their environment Verify that keymanagement procedures are implemented to require secure key storage. 1 Not Applicable. If the VTP solution has been implemented correctly, Merchants will have no key management responsibilities within their environment Verify that keymanagement procedures are implemented to require periodic key changes at the end of the defined 1 Not Applicable. If the VTP solution has been implemented correctly, Merchants will have no key management responsibilities within their environment. Copyright 2013, Coalfire Systems Inc. Page 52

53 cryptoperiod a Verify that keymanagement procedures are implemented to require the retirement of keys when the integrity of the key has been weakened b Verify that the keymanagement procedures are implemented to require the replacement of known or suspected compromised keys c If retired or replaced cryptographic keys are retained, verify that these keys are not used for encryption operations. 1 Not Applicable. If the VTP solution has been implemented correctly, Merchants will have no key management responsibilities within their environment. 1 Not Applicable. If the VTP solution has been implemented correctly, Merchants will have no key management responsibilities within their environment. 1 Not Applicable. If the VTP solution has been implemented correctly, Merchants will have no key management responsibilities within their environment Verify that manual clear-text key-management procedures require split knowledge and dual control of keys. 1 Not Applicable. If the VTP solution has been implemented correctly, Merchants will have no key management responsibilities within their environment Verify that keymanagement procedures are implemented to require the prevention of unauthorized substitution of keys. 1 Not Applicable. If the VTP solution has been implemented correctly, Merchants will have no key management responsibilities within their environment. Copyright 2013, Coalfire Systems Inc. Page 53

54 3.6.8 Verify that keymanagement procedures are implemented to require key custodians to acknowledge (in writing or electronically) that they understand and accept their key-custodian responsibilities. 1 Not Applicable. If the VTP solution has been implemented correctly, Merchants will have no key management responsibilities within their environment. 4.1 Verify the use of security protocols wherever cardholder data is transmitted or received over open, public networks. Verify that strong cryptography is used during data transmission, as follows: 4.1.a Select a sample of transactions as they are received and observe transactions as they occur to verify that cardholder data is encrypted during transit. 4.1.b Verify that only trusted keys and/or certificates are accepted. 4.1.c Verify that the protocol is implemented to use only secure configurations, and does not support insecure versions or configurations. 4.1.d Verify that the proper encryption strength is implemented for the encryption methodology in use. (Check vendor requirements for the merchant s host network. requirements for the merchant s host network. requirements for the merchant s host network. requirements for the merchant s host network. Copyright 2013, Coalfire Systems Inc. Page 54

55 recommendations/best practices.) 4.1.e For SSL/TLS implementations: * Verify that HTTPS appears as a part of the browser Universal Record Locator (URL). * Verify that no cardholder data is required when HTTPS does not appear in the URL For wireless networks transmitting cardholder data or connected to the cardholder data environment, verify that industry best practices (for example, IEEE i) are used to implement strong encryption for authentication and transmission. 4.2.a Verify that PAN is rendered unreadable or secured with strong cryptography whenever it is sent via end-user messaging technologies. 4.2.b Verify the existence of a policy stating that unprotected PANs are not to be sent via end-user messaging technologies. requirements for the merchant s host network. requirements for the merchant s host network. requirements for the merchant s host network. 2 Acceptable Usage Policies Merchants will not have any access to cardholder data within their environment; however, employees will still have access to the physcial credit card in retail environments. As such, a policy prohibiting the ing of unprotected PAN is still appropriate for most retail environments. Copyright 2013, Coalfire Systems Inc. Page 55

56 5.1 For a sample of system components including all operating system types commonly affected by malicious software, verify that anti-virus software is deployed if applicable antivirus technology exists 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). requirements for all server components. Anti-virus and anti-malware requirements will not be applicable. requirements for all server components. Anti-virus and anti-malware requirements will not be applicable. 5.2 Verify that all anti-virus software is current, actively running, and generating logs by performing the following: 5.2.a Obtain and examine the policy and verify that it requires updating of antivirus software and definitions. 5.2.b Verify that the master installation of the software is enabled for automatic updates and periodic scans. 5.2.c For a sample of system components including all operating system types commonly affected by malicious software, verify that requirements for all server components. Anti-virus and anti-malware requirements will not be applicable. requirements for all server components. Anti-virus and anti-malware requirements will not be applicable. requirements for all server components. Anti-virus and anti-malware requirements will not be applicable. Copyright 2013, Coalfire Systems Inc. Page 56

57 automatic updates and periodic scans are enabled. 5.2.d For a sample of system components, verify that anti-virus software log generation is enabled and that such logs are retained in accordance with PCI DSS Requirement a For a sample of system components and related software, compare the list of security patches installed on each system to the most recent vendor security patch list, to verify that current vendor patches are installed. 6.1.b Examine policies related to security patch installation to verify they require installation of all critical new security patches within one month. requirements for all server components. Anti-virus and anti-malware requirements will not be applicable. 6.2.a Interview responsible personnel to verify that processes are implemented to identify new security vulnerabilities, and that a risk ranking is assigned to such vulnerabilities. (At minimum, the most critical, highest risk vulnerabilities should be ranked as High. Copyright 2013, Coalfire Systems Inc. Page 57

58 6.2.b Verify that processes to identify new security vulnerabilities include using outside sources for security vulnerability information. 6.3.a Obtain and examine written software development processes to verify that the processes are based on industry standards and/or best practices. 6.3.b Examine written software development processes to verify that information security is included throughout the life cycle. 6.3.c Examine written software development processes to verify that software applications are developed in accordance with PCI DSS. 6.3.d From an examination of written software development processes, and interviews of software developers, verify that: Custom application accounts, user IDs and/or passwords are removed before system goes into production or is released to customers. 1 Not Applicable This control will be out of scope for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE. 1 Not Applicable This control will be out of scope for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE. 1 Not Applicable This control will be out of scope for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE. 1 Not Applicable This control will be out of scope for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE. 1 Not Applicable This control will be out of scope for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE. Copyright 2013, Coalfire Systems Inc. Page 58

59 6.3.2.a Obtain and review policies to confirm that all custom application code changes must be reviewed (using either manual or automated processes) as follows: * Code changes are reviewed by individuals other than the originating code author, and by individuals who are knowledgeable in code review techniques and secure coding practices. * Code reviews ensure code is developed according to secure coding guidelines (see PCI DSS Requirement 6.5). * Appropriate corrections are implemented prior to release. * Code review results are reviewed and approved by management prior to release b Select a sample of recent custom application changes and verify that custom application code is reviewed according to a, above. 1 Not Applicable This control will be out of scope for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE. 1 Not Applicable This control will be out of scope for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE. 6.4 From an examination of change control processes, interviews with system and network administrators, and examination of relevant data (network configuration documentation, production and test data, etc.), verify the following: Copyright 2013, Coalfire Systems Inc. Page 59

60 6.4.1 The development/test environments are separate from the production environment, with access control in place to enforce the separation There is a separation of duties between personnel assigned to the development/test environments and those assigned to the production environment Production data (live PANs) are not used for testing or development Test data and accounts are removed before a production system becomes active a Verify that changecontrol procedures related to implementing security patches and software modifications are documented and require items below. Merchants will have no access to cardholder data (PANs) within their environment. Copyright 2013, Coalfire Systems Inc. Page 60

61 6.4.5.b For a sample of system components and recent changes/security patches, trace those changes back to related change control documentation. For each change examined, perform the following: Verify that documentation of impact is included in the change control documentation for each sampled change Verify that documented approval by authorized parties is present for each sampled change a For each sampled change, verify that functionality testing is performed to verify that the change does not adversely impact the security of the system b For custom code changes, verify that all updates are tested for compliance with PCI DSS Requirement 6.5 before being deployed into production. This control will be out of scope for merchants utilizing the VTP solution as there will be no self-developed payment Copyright 2013, Coalfire Systems Inc. Page 61

62 applications within the CDE Verify that back-out procedures are prepared for each sampled change. 6.5.a Obtain and review software development processes. Verify that processes require training in secure coding techniques for developers, based on industry best practices and guidance. 6.5.b Interview a sample of developers and obtain evidence that they are knowledgeable in secure coding techniques. 1 Not Applicable This control will be out of scope for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE. 1 Not Applicable This control will be out of scope for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE. 6.5.c. Verify that processes are in place to ensure that applications are not vulnerable to, at a minimum, the following: Injection flaws, particularly SQL injection. (Validate input to verify user data cannot modify meaning of commands and queries, utilize parameterized queries, etc.) 1 Not Applicable This control will be out of scope for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE. Copyright 2013, Coalfire Systems Inc. Page 62

63 6.5.2 Buffer overflow (Validate buffer boundaries and truncate input strings.) 1 Not Applicable This control will be out of scope for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE Insecure cryptographic storage (Prevent cryptographic flaws) 1 Not Applicable This control will be out of scope for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE Insecure communications (Properly encrypt all authenticated and sensitive communications) Improper error handling (Do not leak information via error messages) 1 Not Applicable This control will be out of scope for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE. 1 Not Applicable This control will be out of scope for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE All High vulnerabilities as identified in PCI DSS Requirement Cross-site scripting (XSS) (Validate all parameters before inclusion, utilize contextsensitive escaping, etc.) Improper Access Control, such as insecure direct object references, failure to restrict URL access, and directory traversal (Properly authenticate users and sanitize input. Do not expose internal object references to users.) 1 Not Applicable This control will be out of scope for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE. 1 Not Applicable This control will be out of scope for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE. 1 Not Applicable This control will be out of scope for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE. Copyright 2013, Coalfire Systems Inc. Page 63

64 6.5.9 Cross-site request forgery (CSRF). (Do not reply on authorization credentials and tokens automatically submitted by browsers.) 6.6 For public-facing web applications, ensure that either one of the following methods are in place as follows: * Verify that public-facing web applications are reviewed (using either manual or automated vulnerability security assessment tools or methods), as follows: - At least annually - After any changes - By an organization that specializes in application security - That all vulnerabilities are corrected - That the application is reevaluated after the corrections * Verify that a webapplication firewall is in place in front of publicfacing web applications to detect and prevent webbased attacks. 1 Not Applicable This control will be out of scope for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE. 1 Not Applicable This control will be out of scope for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE. Note: An organization that specializes in application security can be either a third-party company or an internal organization, as long as the reviewers specialize in application security and can Copyright 2013, Coalfire Systems Inc. Page 64

65 demonstrate independence from the development team. 7.1 Obtain and examine written policy for data control, and verify that the policy incorporates the following: Confirm that access rights for privileged user IDs are restricted to least privileges necessary to perform job responsibilities. Copyright 2013, Coalfire Systems Inc. Page 65

66 7.1.2 Confirm that privileges are assigned to individuals based on job classification and function (also called role-based access control or RBAC) Confirm that documented approval by authorized parties is required (in writing or electronically) for all access, and that it must specify required privileges Confirm that access controls are implemented via an automated access control system. 7.2 Examine system settings and vendor documentation to verify that an access control system is implemented as follows: Confirm that access control systems are in place on all system components Confirm that access control systems are configured to enforce privileges assigned to individuals based on job classification and function. Copyright 2013, Coalfire Systems Inc. Page 66

67 7.2.3 Confirm that the access control systems have a default deny-all setting. 8.1 Verify that all users are assigned a unique ID for access to system components or cardholder data. 8.2 To verify that users are authenticated using unique ID and additional authentication (for example, a password) for access to the cardholder data environment, perform the following: * Obtain and examine documentation describing the authentication method(s) used. * For each type of authentication method used and for each type of system component, observe an authentication to verify authentication is functioning consistent with documented authentication method(s). Copyright 2013, Coalfire Systems Inc. Page 67

68 8.3 To verify that two-factor authentication is implemented for all remote network access, observe an employee (for example, an administrator) connecting remotely to the network and verify that two of the three authentication methods are used. 8.4.a For a sample of system components, examine password files to verify that passwords are unreadable during transmission and storage. 8.4.b For service providers only, observe password files to verify that customer passwords are encrypted. 1 Not Applicable for merchants. 8.5 Review procedures and interview personnel to verify that procedures are implemented for user identification and authentication management, by performing the following: Copyright 2013, Coalfire Systems Inc. Page 68

69 8.5.1 Select a sample of user IDs, including both administrators and general users. Verify that each user is authorized to use the system according to policy by performing the following: * Obtain and examine an authorization form for each ID. * Verify that the sampled user IDs are implemented in accordance with the authorization form (including with privileges as specified and all signatures obtained), by tracing information from the authorization form to the system Examine password/authentication procedures and observe security personnel to verify that, if a user requests a password reset by phone, e- mail, web, or other nonface-to-face method, the user s identity is verified before the password is reset Examine password procedures and observe security personnel to verify that first-time passwords for new users, and reset passwords for existing users, are set to a unique value for each user and changed after first use. Copyright 2013, Coalfire Systems Inc. Page 69

70 8.5.4 Select a sample of users terminated in the past six months, and review current user access lists to verify that their IDs have been deactivated or removed Verify that inactive accounts over 90 days old are either removed or disabled a Verify that any accounts used by vendors to access, support and maintain system components are disabled, and enabled only when needed by the vendor b Verify that vendor remote access accounts are monitored while being used Interview the users from a sample of user IDs, to verify that they are familiar with authentication procedures and policies. Copyright 2013, Coalfire Systems Inc. Page 70

71 8.5.8.a For a sample of system components, examine user ID lists to verify the following: * Generic user IDs and accounts are disabled or removed * Shared user IDs for system administration activities and other critical functions do not exist * Shared and generic user IDs are not used to administer any system components b Examine authentication policies/procedures to verify that group and shared passwords or other authentication methods are explicitly prohibited c Interview system administrators to verify that group and shared passwords or other authentication methods are not distributed, even if requested a For a sample of system components, obtain and inspect system configuration settings to verify that user password parameters are set to require users to change passwords at least every 90 days. Copyright 2013, Coalfire Systems Inc. Page 71

72 8.5.9.b For service providers only, review internal processes and customer/user documentation to verify that non-consumer user passwords are required to change periodically and that non-consumer users are given guidance as to when, and under what circumstances, passwords must change a For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require passwords to be at least seven characters long b For service providers only, review internal processes and customer/user documentation to verify that that non-consumer user passwords are required to meet minimum length requirements a For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require passwords to contain both numeric and alphabetic characters. 1 Not Applicable Not applicable in merchant environments. 1 Not Applicable Not applicable in merchant environments. Copyright 2013, Coalfire Systems Inc. Page 72

73 b For service providers only, review internal processes and customer/user documentation to verify that non-consumer user passwords are required to contain both numeric and alphabetic characters a For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require that new passwords cannot be the same as the four previously used passwords b For service providers only, review internal processes and customer/user documentation to verify that new non-consumer user passwords cannot be the same as the previous four passwords a For a sample of system components, obtain and inspect system configuration settings to verify that authentication parameters are set to require that a user s account be locked out after not more than six invalid logon attempts. 1 Not Applicable Not applicable in merchant environments. 1 Not Applicable Not applicable in merchant environments. Copyright 2013, Coalfire Systems Inc. Page 73

74 b For service providers only, review internal processes and customer/user documentation to verify that non-consumer user accounts are temporarily locked-out after not more than six invalid access attempts For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require that once a user account is locked out, it remains locked for a minimum of 30 minutes or until a system administrator resets the account For a sample of system components, obtain and inspect system configuration settings to verify that system/session idle time out features have been set to 15 minutes or less a Review database and application configuration settings and verify that all users are authenticated prior to access. 1 Not Applicable Not applicable in merchant environments. 1 Not Applicable There will be no cardholder data repositories when the VTP solution is implemented properly. Copyright 2013, Coalfire Systems Inc. Page 74

75 b Verify that database and application configuration settings ensure that all user access to, user queries of, and user actions on (for example, move, copy, delete), the database are through programmatic methods only (for example, through stored procedures) c Verify that database and application configuration settings restrict user direct access or queries to databases to database administrators d Review database applications and the related application IDs to verify that application IDs can only be used by the applications (and not by individual users or other processes). 9.1 Verify the existence of physical security controls for each computer room, data center, and other physical areas with systems in the cardholder data environment. * Verify that access is controlled with badge readers or other devices including authorized badges and lock and key. * Observe a system administrator s attempt to log into consoles for randomly selected systems in the cardholder environment and verify that 1 Not Applicable There will be no cardholder data repositories when the VTP solution is implemented properly. 1 Not Applicable There will be no cardholder data repositories when the VTP solution is implemented properly. 1 Not Applicable There will be no cardholder data repositories when the VTP solution is implemented properly. 2 Physical Security Policy Appropriate physical controls to ensure that the POI devices cannot be physically altered, perimeter devices are properly protected and protecting any paper media containing cardholder data are protected should be in place. Copyright 2013, Coalfire Systems Inc. Page 75

76 they are locked to prevent unauthorized use a Verify that video cameras and/or access control mechanisms are in place to monitor the entry/exit points to sensitive areas b Verify that video cameras and/or access control mechanisms are protected from tampering or disabling c Verify that video cameras and/or access control mechanisms are monitored and that data from cameras or other mechanisms is stored for at least three months. 1 Not Applicable This control requirement can be eliminated from scope since there should not be any "sensitive" areas in the merchant environment outside of the POI terminals. 1 Not Applicable This control requirement can be eliminated from scope since there should not be any "sensitive" areas in the merchant environment outside of the POI terminals. 1 Not Applicable This control requirement can be eliminated from scope since there should not be any "sensitive" areas in the merchant environment outside of the POI terminals. Copyright 2013, Coalfire Systems Inc. Page 76

77 9.1.2 Verify by interviewing network administrators and by observation that network jacks are enabled only when needed by authorized onsite personnel. Alternatively, verify that visitors are escorted at all times in areas with active network jacks Verify that physical access to wireless access points, gateways, handheld devices, networking/communication s hardware, and telecommunication lines is appropriately restricted. 9.2.a Review processes and procedures for assigning badges to onsite personnel and visitors, and verify these processes include the following: * Granting new badges, * Changing access requirements, and * Revoking terminated onsite personnel and expired visitor badges 9.2.b Verify that access to the badge system is limited to authorized personnel. 2 Physical Security Policy Appropriate physical controls to ensure that the POI devices cannot be physically altered, perimeter devices are properly protected and protecting any paper media containing cardholder data are protected should be in place. requirements for the merchant s host network. 2 Physical Security Policy Cardholder data will not be accessible within the merchant environment; therefore, the scope of this requirement can be greatly reduced; however, controls should ensure that unauthorized visitors cannot access perimeter systems or POI devices. 2 Physical Security Policy Cardholder data will not be accessible within the merchant environment; therefore, the scope of this requirement can be greatly reduced; however, controls should ensure that unauthorized visitors cannot access perimeter systems or POI devices. Copyright 2013, Coalfire Systems Inc. Page 77

78 9.2.c Examine badges in use to verify that they clearly identify visitors and it is easy to distinguish between onsite personnel and visitors. 2 Physical Security Policy Cardholder data will not be accessible within the merchant environment; therefore, the scope of this requirement can be greatly reduced; however, controls should ensure that unauthorized visitors cannot access perimeter systems or POI devices. 9.3 Verify that visitor controls are in place as follows: Observe the use of visitor ID badges to verify that a visitor ID badge does not permit unescorted access to physical areas that store cardholder data a Observe people within the facility to verify the use of visitor ID badges, and that visitors are easily distinguishable from onsite personnel b Verify that visitor badges expire Observe visitors leaving the facility to verify visitors are asked to surrender their ID badge upon departure or expiration. 9.4.a Verify that a visitor log is in use to record physical access to the facility as well as for computer rooms and data centers where cardholder data is stored or 2 Physical Security Policy Cardholder data will not be accessible within the merchant environment; therefore, the scope of this requirement can be greatly reduced; however, controls should ensure that unauthorized visitors cannot access perimeter systems or POI devices. 2 Physical Security Policy Cardholder data will not be accessible within the merchant environment; therefore, the scope of this requirement can be greatly reduced; however, controls should ensure that unauthorized visitors cannot access perimeter systems or POI devices. 2 Physical Security Policy Cardholder data will not be accessible within the merchant environment; therefore, the scope of this requirement can be greatly reduced; however, controls should ensure that unauthorized visitors cannot access perimeter systems or POI devices. 2 Physical Security Policy Cardholder data will not be accessible within the merchant environment; therefore, the scope of this requirement can be greatly reduced; however, controls should ensure that unauthorized visitors cannot access perimeter systems or POI devices. 2 Physical Security Policy Cardholder data will not be accessible within the merchant environment; therefore, the scope of this requirement can be greatly reduced; however, controls should ensure that unauthorized visitors cannot access perimeter systems or POI devices. Copyright 2013, Coalfire Systems Inc. Page 78

79 transmitted. 9.4.b Verify that the log contains the visitor s name, the firm represented, and the onsite personnel authorizing physical access, and is retained for at least three months. 2 Physical Security Policy Cardholder data will not be accessible within the merchant environment; therefore, the scope of this requirement can be greatly reduced; however, controls should ensure that unauthorized visitors cannot access perimeter systems or POI devices. 9.5.a Observe the storage location s physical security to confirm that backup media storage is secure. 9.5.b Verify that the storage location security is reviewed at least annually. 9.6 Verify that procedures for protecting cardholder data include controls for physically securing all media (including but not limited to computers, removable electronic media, paper receipts, paper reports, and faxes). 9.7 Verify that a policy exists to control distribution of media, and that the policy covers all distributed media including that distributed to individuals. 2 Physical Security Policy Data Retention and Storage Policies (if applicable) 2 Physical Security Policy Data Retention and Storage Policies (if applicable) 2 Data Retention and Storage Policies (if applicable) 2 Data Retention and Storage Policies (if applicable) If the merchant has any paper based processes associated with this payment channel then this requirement will still apply to their environment. Otherwise, this requirement can be considered not applicable. If the merchant has any paper based processes associated with this payment channel then this requirement will still apply to their environment. Otherwise, this requirement can be considered not applicable. If the merchant has any paper based processes associated with this payment channel then this requirement will still apply to their environment. Otherwise, this requirement can be considered not applicable. If the merchant has any paper based processes associated with this payment channel then this requirement will still apply to their environment. Otherwise, this requirement can be considered not applicable. Copyright 2013, Coalfire Systems Inc. Page 79

80 9.7.1 Verify that all media is classified so the sensitivity of the data can be determined Verify that all media sent outside the facility is logged and authorized by management and sent via secured courier or other delivery method that can be tracked. 9.8 Select a recent sample of several days of offsite tracking logs for all media, and verify the presence in the logs of tracking details and proper management authorization. 9.9 Obtain and examine the policy for controlling storage and maintenance of all media and verify that the policy requires periodic media inventories Obtain and review the media inventory log to verify that periodic media inventories are performed at least annually Obtain and examine the periodic media destruction policy and verify that it covers all media, and confirm the following: 2 Data Retention and Storage Policies (if applicable) 2 Data Retention and Storage Policies (if applicable) 2 Data Retention and Storage Policies (if applicable) 2 Data Retention and Storage Policies (if applicable) 2 Data Retention and Storage Policies (if applicable) 2 Data Retention and Storage Policies (if applicable) If the merchant has any paper based processes associated with this payment channel then this requirement will still apply to their environment. Otherwise, this requirement can be considered not applicable. If the merchant has any paper based processes associated with this payment channel then this requirement will still apply to their environment. Otherwise, this requirement can be considered not applicable. If the merchant has any paper based processes associated with this payment channel then this requirement will still apply to their environment. Otherwise, this requirement can be considered not applicable. If the merchant has any paper based processes associated with this payment channel then this requirement will still apply to their environment. Otherwise, this requirement can be considered not applicable. If the merchant has any paper based processes associated with this payment channel then this requirement will still apply to their environment. Otherwise, this requirement can be considered not applicable. If the merchant has any paper based processes associated with this payment channel then this requirement will still apply to their environment. Otherwise, this requirement can be considered not applicable. Copyright 2013, Coalfire Systems Inc. Page 80

81 a Verify that hardcopy materials are crosscut shredded, incinerated, or pulped such that there is reasonable assurance the hard-copy materials cannot be reconstructed b Examine storage containers used for information to be destroyed to verify that the containers are secured. For example, verify that a to-beshredded container has a lock preventing access to its contents. 3 Data Retention and Storage Policies (if applicable) 3 Data Retention and Storage Policies (if applicable) If the merchant has any paper based processes associated with this payment channel then this requirement will still apply to their environment. Otherwise, this requirement can be considered not applicable. If the merchant has any paper based processes associated with this payment channel then this requirement will still apply to their environment. Otherwise, this requirement can be considered not applicable Verify that cardholder data on electronic media is rendered unrecoverable via a secure wipe program in accordance with industryaccepted standards for secure deletion, or otherwise physically destroying the media (for example, degaussing) Verify through observation and interviewing the system administrator, that audit trails are enabled and active for system components. 1 Not Applicable There will be no electronic instances of cardholder data storage within the merchant environment Through interviews, examination of audit logs, and examination of audit log settings, perform the following: Copyright 2013, Coalfire Systems Inc. Page 81

82 Verify all individual access to cardholder data is logged Verify actions taken by any individual with root or administrative privileges are logged. 1 Not Applicable. Merchant access to cardholder will not be possible with the proper implementation of the VTP solution Verify access to all audit trails is logged Verify invalid logical access attempts are logged Verify use of identification and authentication mechanisms is logged Verify initialization of audit logs is logged. Copyright 2013, Coalfire Systems Inc. Page 82

83 Verify creation and deletion of system level objects are logged Through interviews and observation, for each auditable event (from 10.2), perform the following: Verify user identification is included in log entries Verify type of event is included in log entries Verify date and time stamp is included in log entries Verify success or failure indication is included in log entries. Copyright 2013, Coalfire Systems Inc. Page 83

84 Verify origination of event is included in log entries Verify identity or name of affected data, system component, or resources is included in log entries a Verify that timesynchronization technology is implemented and kept current per PCI DSS Requirements 6.1 and b Obtain and review the process for acquiring, distributing and storing the correct time within the organization, and review the time-related systemparameter settings for a sample of system components. Verify the following is included in the process and implemented: a Verify that only designated central time servers receive time signals from external sources, and time signals from external sources are based on International Atomic Time or UTC. Copyright 2013, Coalfire Systems Inc. Page 84

85 b Verify that the designated central time servers peer with each other to keep accurate time, and other internal servers receive time only from the central time servers a Review system configurations and timesynchronization settings to verify that access to time data is restricted to only personnel with a business need to access time data b Review system configurations and time synchronization settings and processes to verify that any changes to time settings on critical systems are logged, monitored, and reviewed Verify that the time servers accept time updates from specific, industryaccepted external sources (to prevent a malicious individual from changing the clock). Optionally, those updates can be encrypted with a symmetric key, and access control lists can be created that specify the IP addresses of client machines that will be provided with the time updates (to prevent unauthorized use of internal time servers). Copyright 2013, Coalfire Systems Inc. Page 85

86 10.5 Interview system administrator and examine permissions to verify that audit trails are secured so that they cannot be altered as follows: Verify that only individuals who have a jobrelated need can view audit trail files Verify that current audit trail files are protected from unauthorized modifications via access control mechanisms, physical segregation, and/or network segregation Verify that current audit trail files are promptly backed up to a centralized log server or media that is difficult to alter Verify that logs for external-facing technologies (for example, wireless, firewalls, DNS, mail) are offloaded or copied onto a secure centralized internal log server or media Verify the use of fileintegrity monitoring or change-detection software for logs by examining system settings and monitored files and results Copyright 2013, Coalfire Systems Inc. Page 86

87 from monitoring activities a Obtain and examine security policies and procedures to verify that they include procedures to review security logs at least daily and that follow-up to exceptions is required b Through observation and interviews, verify that regular log reviews are performed for all system components a Obtain and examine security policies and procedures and verify that they include audit log retention policies and require audit log retention for at least one year b Verify that audit logs are available for at least one year and processes are in place to immediately restore at least the last three months logs for analysis a Verify that the entity has a documented process to detect and identify wireless access points on a quarterly basis. requirements for the merchant s host network. Copyright 2013, Coalfire Systems Inc. Page 87

88 11.1.b Verify that the methodology is adequate to detect and identify any unauthorized wireless access points, including at least the following: * WLAN cards inserted into system components * Portable wireless devices connected to system components (for example, by USB, etc.) * Wireless devices attached to a network port or network device 11.1.c Verify that the documented process to identify unauthorized wireless access points is performed at least quarterly for all system components and facilities d If automated monitoring is utilized (for example, wireless IDS/IPS, NAC, etc.), verify the configuration will generate alerts to personnel e Verify the organization s incident response plan (Requirement 12.9) includes a response in the event unauthorized wireless devices are detected. requirements for the merchant s host network. requirements for the merchant s host network. requirements for the merchant s host network. requirements for the merchant s host network Verify that internal and external vulnerability scans are performed as follows: Copyright 2013, Coalfire Systems Inc. Page 88

89 a Review the scan reports and verify that four quarterly internal scans occurred in the most recent 12-month period. As such, there are no applicable internal vulnerability scanning requirements b Review the scan reports and verify that the scan process includes rescans until passing results are obtained, or all High vulnerabilities as defined in PCI DSS Requirement 6.2 are resolved. As such, there are no applicable internal vulnerability scanning requirements c Validate that the scan was performed by a qualified internal resource(s) or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV). As such, there are no applicable internal vulnerability scanning requirements a Review output from the four most recent quarters of external vulnerability scans and verify that four quarterly scans occurred in the most recent 12-month period. As such, there are no applicable external vulnerability scanning requirements. Copyright 2013, Coalfire Systems Inc. Page 89

90 b Review the results of each quarterly scan to ensure that they satisfy the ASV Program Guide requirements (for example, no vulnerabilities rated higher than a 4.0 by the CVSS and no automatic failures). As such, there are no applicable external vulnerability scanning requirements c Review the scan reports to verify that the scans were completed by an Approved Scanning Vendor (ASV), approved by the PCI SSC. As such, there are no applicable external vulnerability scanning requirements a Inspect change control documentation and scan reports to verify that system components subject to any significant change were scanned. As such, there are no applicable vulnerability scanning requirements b Review scan reports and verify that the scan process includes rescans until: * For external scans, no vulnerabilities exist that are scored greater than a 4.0 by the CVSS, * For internal scans, a passing result is obtained or all High vulnerabilities as defined in PCI DSS Requirement 6.2 are As such, there are no applicable vulnerability scanning requirements. Copyright 2013, Coalfire Systems Inc. Page 90

91 resolved c Validate that the scan was performed by a qualified internal resource(s) or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV). As such, there are no applicable vulnerability scanning requirements a Obtain and examine the results from the most recent penetration test to verify that penetration testing is performed at least annually and after any significant changes to the environment b Verify that noted exploitable vulnerabilities were corrected and testing repeated. As such, there are no applicable penetration testing requirements. As such, there are no applicable penetration testing requirements. Copyright 2013, Coalfire Systems Inc. Page 91

92 11.3.c Verify that the test was performed by a qualified internal resource or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV) Verify that the penetration test includes network-layer penetration tests. These tests should include components that support network functions as well as operating systems Verify that the penetration test includes application-layer penetration tests. The tests should include, at a minimum, the vulnerabilities listed in Requirement a Verify the use of intrusion-detection systems and/or intrusion-prevention systems and that all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment is monitored b Confirm IDS and/or IPS are configured to alert personnel of suspected compromises. As such, there are no applicable penetration testing requirements. As such, there are no applicable penetration testing requirements. As such, there are no applicable penetration testing requirements. requirements for the merchant s host network. requirements for the merchant s host network. Copyright 2013, Coalfire Systems Inc. Page 92

93 11.4.c Examine IDS/IPS configurations and confirm IDS/IPS devices are configured, maintained, and updated per vendor instructions to ensure optimal protection a Verify the use of fileintegrity monitoring tools within the cardholder data environment by observing system settings and monitored files, as well as reviewing results from monitoring activities. Examples of files that should be monitored: * System executables * Application executables * Configuration and parameter files * Centrally stored, historical or archived, log and audit files 11.5.b Verify the tools are configured to alert personnel to unauthorized modification of critical files, and to perform critical file comparisons at least weekly Examine the information security policy and verify that the policy is published and disseminated to all relevant personnel (including vendors and business partners) Verify that the policy addresses all PCI DSS requirements for the merchant s host network. 4 Information Security Policy This requirement is fully in-scope for the merchant s PCI-DSS assessment. 4 Information Security Policy This requirement is fully in-scope for the merchant s PCI-DSS assessment. Copyright 2013, Coalfire Systems Inc. Page 93

94 requirements a Verify that an annual risk assessment process is documented that identifies threats, vulnerabilities, and results in a formal risk assessment. 4 Information Security Policy This requirement is fully in-scope for the merchant s PCI-DSS assessment b Review risk assessment documentation to verify that the risk assessment process is performed at least annually. 4 Information Security Policy Annual Risk Assessment This requirement is fully in-scope for the merchant s PCI-DSS assessment Verify that the information security policy is reviewed at least annually and updated as needed to reflect changes to business objectives or the risk environment Examine the daily operational security procedures. Verify that they are consistent with this specification, and include administrative and technical procedures for each of the requirements. 4 Information Security Policy This requirement is fully in-scope for the merchant s PCI-DSS assessment. 4 Information Security Policy This requirement is fully in-scope for the merchant s PCI-DSS assessment Obtain and examine the usage policies for critical technologies and perform the following: Verify that the usage policies require explicit approval from authorized parties to use the technologies. 4 Acceptable Usage Policies This requirement is fully in-scope for the merchant s PCI-DSS assessment. Copyright 2013, Coalfire Systems Inc. Page 94

95 Verify that the usage policies require that all technology use be authenticated with user ID and password or other authentication item (for example, token) Verify that the usage policies require a list of all devices and personnel authorized to use the devices Verify that the usage policies require labeling of devices with information that can be correlated to owner, contact information and purpose Verify that the usage policies require acceptable uses for the technology Verify that the usage policies require acceptable network locations for the technology Verify that the usage policies require a list of company-approved products Verify that the usage policies require automatic disconnect of sessions for remote-access technologies after a specific period of inactivity. 4 Acceptable Usage Policies This requirement is fully in-scope for the merchant s PCI-DSS assessment. 4 Acceptable Usage Policies This requirement is fully in-scope for the merchant s PCI-DSS assessment. 4 Acceptable Usage Policies This requirement is fully in-scope for the merchant s PCI-DSS assessment. 4 Acceptable Usage Policies This requirement is fully in-scope for the merchant s PCI-DSS assessment. 4 Acceptable Usage Policies This requirement is fully in-scope for the merchant s PCI-DSS assessment. 4 Acceptable Usage Policies This requirement is fully in-scope for the merchant s PCI-DSS assessment. 4 Acceptable Usage Policies This requirement is fully in-scope for the merchant s PCI-DSS assessment. Copyright 2013, Coalfire Systems Inc. Page 95

96 Verify that the usage policies require activation of remote-access technologies used by vendors and business partners only when needed by vendors and business partners, with immediate deactivation after use a Verify that the usage policies prohibit copying, moving, or storing of cardholder data onto local hard drives and removable electronic media when accessing such data via remote-access technologies b For personnel with proper authorization, verify that usage policies require the protection of cardholder data in accordance with PCI DSS Requirements Verify that information security policies clearly define information security responsibilities for all personnel. 4 Acceptable Usage Policies This requirement is fully in-scope for the merchant s PCI-DSS assessment. 1 Not Applicable Cardholder data will not be accessible within the merchant environment. 1 Not Applicable Cardholder data will not be accessible within the merchant environment. 4 Information Security Policy This requirement is fully in-scope for the merchant s PCI-DSS assessment. Copyright 2013, Coalfire Systems Inc. Page 96

97 12.5 Verify the formal assignment of information security to a Chief Security Officer or other securityknowledgeable member of management. 4 Information Security Policy This requirement is fully in-scope for the merchant s PCI-DSS assessment. Obtain and examine information security policies and procedures to verify that the following information security responsibilities are specifically and formally assigned: Verify that responsibility for creating and distributing security policies and procedures is formally assigned Verify that responsibility for monitoring and analyzing security alerts and distributing information to appropriate information security and business unit management personnel is formally assigned Verify that responsibility for creating and distributing security incident response and escalation procedures is formally assigned Verify that responsibility for administering user account and authentication management is formally 4 Information Security Policy This requirement is fully in-scope for the merchant s PCI-DSS assessment. 4 Information Security Policy This requirement is fully in-scope for the merchant s PCI-DSS assessment. 4 Information Security Policy This requirement is fully in-scope for the merchant s PCI-DSS assessment. 4 Information Security Policy This requirement is fully in-scope for the merchant s PCI-DSS assessment. Copyright 2013, Coalfire Systems Inc. Page 97

98 assigned Verify that responsibility for monitoring and controlling all access to data is formally assigned a Verify the existence of a formal security awareness program for all personnel. 4 Information Security Policy This requirement is fully in-scope for the merchant s PCI-DSS assessment. 4 Information Security Policy This requirement is fully in-scope for the merchant s PCI-DSS assessment b Obtain and examine security awareness program procedures and documentation and perform the following: a Verify that the security awareness program provides multiple methods of communicating awareness and educating personnel (for example, posters, letters, memos, web based training, meetings, and promotions) b Verify that personnel attend awareness training upon hire and at least annually Verify that the security awareness program requires personnel to acknowledge, in writing or electronically, at least annually that they have read and understand the information security policy. 4 Security Awareness Policy/Program 4 Security Awareness Policy/Program 4 Security Awareness Policy/Program 4 Security Awareness Policy/Program This requirement is fully in-scope for the merchant s PCI-DSS assessment. This requirement is fully in-scope for the merchant s PCI-DSS assessment. This requirement is fully in-scope for the merchant s PCI-DSS assessment. This requirement is fully in-scope for the merchant s PCI-DSS assessment. Copyright 2013, Coalfire Systems Inc. Page 98

99 12.7 Inquire with Human Resource department management and verify that background checks are conducted (within the constraints of local laws) on potential personnel prior to hire who will have access to cardholder data or the cardholder data environment. 4 Information Security Policy This requirement is fully in-scope for the merchant s PCI-DSS assessment If the entity shares cardholder data with service providers (for example, back-up tape storage facilities, managed service providers such as Web hosting companies or security service providers, or those that receive data for fraud modeling purposes), through observation, review of policies and procedures, and review of supporting documentation, perform the following: Verify that a list of service providers is maintained Verify that the written agreement includes an acknowledgement by the service providers of their responsibility for securing cardholder data. 4 Information Security Policy This requirement is fully in-scope for the merchant s PCI-DSS assessment. 4 Information Security Policy This requirement is fully in-scope for the merchant s PCI-DSS assessment. Copyright 2013, Coalfire Systems Inc. Page 99

100 Verify that policies and procedures are documented and were followed including proper due diligence prior to engaging any service provider Verify that the entity maintains a program to monitor its service providers PCI DSS compliance status at least annually. 4 Information Security Policy This requirement is fully in-scope for the merchant s PCI-DSS assessment. 4 Information Security Policy This requirement is fully in-scope for the merchant s PCI-DSS assessment Obtain and examine the Incident Response Plan and related procedures and perform the following: a Verify that the incident response plan includes: * Roles, responsibilities, and communication strategies in the event of a compromise including notification of the payment brands, at a minimum: * Specific incident response procedures * Business recovery and continuity procedures * Data back-up processes * Analysis of legal requirements for reporting compromises (for example, California Bill 1386 which requires notification of affected consumers in the event of an actual or suspected compromise for any business with California residents in their database) * Coverage and responses 4 Incident Response Plan (IRP) This requirement is fully in-scope for the merchant s PCI-DSS assessment. Copyright 2013, Coalfire Systems Inc. Page 100

101 for all critical system components * Reference or inclusion of incident response procedures from the payment brands b Review documentation from a previously reported incident or alert to verify that the documented incident response plan and procedures were followed Verify that the plan is tested at least annually. 4 Incident Response Plan (IRP) This requirement is fully in-scope for the merchant s PCI-DSS assessment. 4 Incident Response Plan (IRP) This requirement is fully in-scope for the merchant s PCI-DSS assessment. Copyright 2013, Coalfire Systems Inc. Page 101

102 Verify through observation and review of policies, that designated personnel are available for 24/7 incident response and monitoring coverage for any evidence of unauthorized activity, detection of unauthorized wireless access points, critical IDS alerts, and/or reports of unauthorized critical system or content file changes Verify through observation and review of policies that staff with responsibilities for security breach response are periodically trained Verify through observation and review of processes that monitoring and responding to alerts from security systems including detection of unauthorized wireless access points are covered in the Incident Response Plan Verify through observation and review of policies that there is a process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments. 4 Incident Response Plan (IRP) This requirement is fully in-scope for the merchant s PCI-DSS assessment. 4 Incident Response Plan (IRP) This requirement is fully in-scope for the merchant s PCI-DSS assessment. 4 Incident Response Plan (IRP) This requirement is fully in-scope for the merchant s PCI-DSS assessment. 4 Incident Response Plan (IRP) This requirement is fully in-scope for the merchant s PCI-DSS assessment. Copyright 2013, Coalfire Systems Inc. Page 102

103 Copyright 2013, Coalfire Systems Inc. Page 103