VeriFone VeriShield PCI Assessment...

Verifone VeriShield Total Protect Technical Assessment

White Paper

Prepared for:

March 18, 2015

Dan Fritsche, CISSP, QSA (P2PE), PA-QSA (P2PE) [email protected]

Table of Contents EXECUTIVE SUMMARY................................................................................................................................................................ 3

OVERVIEW ......................................................................................................................................................................................... 3 SUMMARY FINDINGS ............................................................................................................................................................................ 6

PCI DSS VALIDATION REDUCTION ............................................................................................................................................... 7

CONTROL REDUCTION FOR MERCHANTS ................................................................................................................................................ 10 DEPLOYMENT SCENARIOS .................................................................................................................................................................... 10 SUMMARY PCI DSS APPLICABLE CONTROL REDUCTION ............................................................................................................................ 13 DETAILED PCI DSS CONTROL REDUCTION .............................................................................................................................................. 14

TECHNICAL ASSESSMENT .......................................................................................................................................................... 14

SCOPE OF ASSESSMENT....................................................................................................................................................................... 14 VERISHIELD TOTAL PROTECT ENCRYPTION ASSESSMENT ............................................................................................................................ 17 VALIDATION OF DECRYPTION AT VERISHIELD DECRYPTION (“VSD”) ............................................................................................................ 18 KEY LOADING AND DISTRIBUTION ......................................................................................................................................................... 22

APPENDIX A: PCI DSS CONTROL REDUCTION RISK MAPPINGS .................................................................................................. 31

DETAILED PCI DSS CONTROL REDUCTION .............................................................................................................................................. 31

© 2007 Coalfire Systems, Inc. of 120

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 provide an update to the Verifone VTP PCI DSS 3.0 whitepaper reflecting the current standards. Coalfire conducted an independent technical assessment of the VeriShield Total Protect (VTP), secured by RSA security solution in 2013. During that timeframe, Coalfire conducted assessment activities including technical testing, an architectural assessment, industry analysis, a compliance validation and peer review. The Whitepaper with PCI DSS 2.0 standards was released in September 2013. This paper reflects the revised whitepaper addressing Verifone VTP and how it aligns to current PCI-DSS v3.0 standards.

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 how many PCI DSS requirements need to be validated when properly deployed. This reduction will be based on evaluating the risk of each of the PCI DSS 3.0 requirements and how the VTP security solution applies to each control within the context of the current PCI P2PE standards released in July 2013. 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.

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

Copyright 2015, Coalfire Systems Inc. Page | 3

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 applicable control 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 applicable control 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.

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.

The assessment focuses on how the VTP security solution can be leveraged in the context of PCI DSS v3.0 and the current PCI P2PE standards released in July 2013. The assessment also focuses on the new Derived Symmetric Key mode functionality.


This paper leverages the testing performed for the 2013 VTP assessment and provides an update to the 2013 VTP whitepaper to reflect the current PCI DSS 3.0 standards.

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 number of PCI DSS requirements a merchant is still responsible for validating.

In July 2013, 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.

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 applicable 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 Procedures: Encryption, Decryption, and Key Management within Secure Cryptographic Devices Version 1.1.1” published by the PCI SSC in July 2013, 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.

• 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 control 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 a very clear and dramatic reduction in the number of requirements that require PCI DSS 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 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 applicable PCI DSS controls 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 control applicability. 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 July 2013 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.

https://www.pcisecuritystandards.org/security_standards/documents.php

These documents, along with the PCI DSS 3.0 are the reference points used for all comments and conclusions in this assessment. Additionally, PCI has updated some relevant FAQ’s:


Frequently Asked Questions (FAQs) For Point-to-Point Encryption (P2PE) The below FAQ from April 2012 could be referenced for information about how a merchant may receive scope reduction through use of validated P2PE solution.

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 card-present 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 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 from April 2012:

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.

FAQs that were released in July 2014 provide additional and timely clarifications to the application of the P2PE Solution Requirements and Testing Procedures. The FAQ below provides clarifications on the physical security of the POI devices.

Are POI devices required to be physically secured (e.g. bolted to a counter-top or tethered with a cable) in the merchant environment? How does this requirement apply to handheld/wireless POI devices?

A. The intent of this requirement is for the solution provider to provide instructions in the PIM about how to physically secure the POI device – for example, if the device has a cable connection or a fixed bracket, the PIM should describe how to use these features. The merchant should be able to use these instructions to secure devices as appropriate for their environment. Whether the merchant applies the physical security instructions will depend on the type of environment the device is being used in, and does not impact the P2PE solution assessment.

If a POI device is not intended to be secured in one place – for example, it is a handheld or wireless device – the solution provider is expected to provide merchants with instructions for how to implement process controls to protect the device. Examples of process controls could include storing the device in an area inaccessible to the public when the device is not in use, assigning responsibility to specific personnel for supervising use of the device, and so on. Again, the solution provider’s responsibility is to provide this information in the PIM so the merchant is aware of best practices. The actual methods implemented by merchants to secure POI devices may vary according to the needs of the particular merchant.

July 2014 - What is acceptable evidence concerning P2PE compliance for a third-party entity that underwent a P2PE assessment for services they offer on behalf of P2PE solution providers, such that the third-party can


provide that evidence to subsequent P2PE solution providers who use those same services?

A. This topic will be addressed in P2PE v2.0. In the interim and for P2PE v1.1.1 assessments, a third-party who is providing services on behalf of P2PE solution providers can provide a statement to solution providers pursuing a P2PE assessment based on a prior P2PE assessment of the third-party entity. Note that this FAQ applies only to services governed under P2PE Domains 1, 5, or 6 (including Annexes A and B) such as POI device management, decryption environment related functions, Key Injection Facility (KIF) services, Certification Authority (CA), or Registration Authority (RA).

The date the P2PE statement is signed for the third-party’s P2PE assessment (whether assessed as part of a full P2PE solution or in isolation) must be less than one year before the date of any subsequent solutions provider’s P2PE assessment completion date (i.e., the statement described herein is only valid for one year).

This statement, as stated above, must be prepared by the QSA (P2PE) who assessed the third party. The statement must be signed and dated by both the third-party and the QSA (P2PE), and must attest to the fact that the third-party entity is compliant with all applicable P2PE requirements. The statement must also contain [at a minimum] the following information, as applicable to the third-party. Note that the statement is not required to contain any sensitive information.

• Provide a summary of services being offered by the third party. • Provide information per the following bullets, which reference sections and tables present in the Solution

P-ROV Template v1.1.1. Please refer to that document as applicable o Provide administrative information regarding the third-party and the QSA (P2PE) using Section

1.1 as a reference. o Provide information requested in Sections 1.2 and 1.3 regarding the date and timeframe of the

assessment, as well as the version of the P2PE Standard utilized. o Provide information requested in Section 2.4 regarding the P2PE decryption environment(s). o Provide all information requested in Section 3.5 regarding key management. o Provide the information requested in Table 1.1 and 1.2 in Domain 1 regarding the POI devices

used. Exclude information regarding payment applications as they are not relevant to third-party P2PE services applicable to this attestation.

o Provide all information requested in Table 1.3 and 1.4 in Domain 1 regarding SCDs used to generate, load, or encrypt cryptographic keys. Examples include HSMs, key injection/loading devices (KLDs) and other devices that generate or load keys.

o Provide all information requested in Table 5.1 and 5.2 in Domain 5 regarding HSM’s used in the decryption environment.

o Provide all information requested in Table 5.3 in Domain 5 regarding Host Systems used in the decryption environment (HW/Hybrid ONLY).

o Provide all information requested in Table 6.1 and 6.2 (Domain 6), as well as Tables 6A.1 (Domain 6, Annex A) and 6B.1 (Domain 6, Annex B) regarding cryptographic key types and their associated hardware devices.

• List each high-level P2PE requirement assessed and indicate whether the requirement was assessed in full (i.e., inclusive of all its sub-requirements), partially, or deemed not applicable. Provide a justification for all applicable requirements only tested partially or deemed not applicable. “Not Applicable” in this context infers the requirement may apply but was deemed not applicable via the assessment process and the review of relevant information. For example, applicable in this context would not refer to Domain 2 requirements that govern POI-resident payment applications. An example of requirements later deemed not applicable via the course of the assessment would be a KIF facility that doesn’t utilize DUKPT keys.

• Include an explicit confirmation attesting to the fact the third-party entity’s prior P2PE assessment includes all services, processes, and systems appropriate to the services the third party offers to P2PE solution providers. At any time during the one-year period of the statement’s validity, if any services,


processes, or systems were changed or added, the third-party must document any additions or changes and provide that documentation to applicable current and potential P2PE solution providers.

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 applicable control reduction programs

Clarification of Control Reduction Clearly, PCI DSS control reduction cannot remove a merchant from the requirement to be compliant. PCI DSS control 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 control 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 of compromise. Reducing PCI DSS control applicability for payment card data does not mean the PCI DSS controls are not justified to protect the merchants other information assets.

Control Reduction 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 the PCI DSS controls that are applicable. 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 applicable 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 DSS control reduction 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. • 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 – 3rd 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 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:

https://www.pcisecuritystandards.org/documents/which_applications_eligible_for_pa-dss_validation.pdf


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.

Summary PCI DSS Control Reduction 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 Control Reduction

PCI DSS Area

Major Impact Moderate Impact Minor/No Impact

Requirement 1 X

Requirement 2 X

Requirement 3 X

Requirement 4 X

Requirement 5 X

Requirement 6 X

Requirement 7 X

Requirement 8 X

Requirement 9 X

Requirement 10 X

Requirement 11 X

Requirement 12 X

Legend:

• Major – A significant number of controls are either no longer applicable or there is 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

• Minor – Either all controls are applicable or most IT assets still require the controls


Detailed PCI DSS Control Reduction A table in Appendix A was created as a general guideline for determining the PCI-DSS control applicability within a merchant environment utilizing the VTP solution. This risk-based guidance indicates Coalfire’s recommended reduction of applicable PCI-DSS controls for Merchants that have compliantly implemented the VTP solution. Scroll down to Appendix A to review the detailed PCI DSS risk guidance.

Technical Assessment

Scope of Assessment Verifone VeriShield Total Protect was assessed for compliance relative to current PCI DSS 3.0 standards and PCI P2PE 1.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 Description FPE Format Preserving Encryption HSM Hardware Security Module KIF Key Injection Facility PAYware Connect Verifone Payment Gateway, with integrated VSD TRSM Tamper Resistant Security Module SRED Secure Reading and Exchange of Data VCL VeriShield Crypto Library VKM VeriShield Key Management VMB VeriShield Merchant Boarding VMC VeriShield Monitoring & Compliance VSD VeriShield Decryption Service


VTP VeriShield Total Protect

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); • 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.


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 347247137165329=1103101331063? Full Track Encryption at MX 925 347247442085329=5503101713901?

Table 2: VISA Track Data vs. Encrypted Track Data VISA Test Card – Source Serial Sniffer


Full Original Track Data %B4916870291537109^SEMTEK/TEST VISA CARD ^11051015218100 00024021000? ;4916870291537109=11051015218102402100?

Full Track Encryption at VX 820 %B4916873076827109^SEMTEK/TEST VISA CARD ^55051011160605 77648588628? ;4916873076827109=55051019572262175128?

Table 3: MasterCard Track Data vs. Encrypted Track Data MasterCard Test Card – Source USB Sniffer Full Original Track Data %B5587442275354896^SEMTEK/TEST CARD MC ^1101101000100000000000690000000?

;5587442275354896=11011010001006900000? Full Track Encryption at MX 915 %B5587447007624896^SEMTEK/TEST CARD MC ^5501101155439894003235598825650?

;5587447007624896=55011015845422563496?

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.

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


Figure 6: Ethernet Capture Example

Figure 7: VSD Decrypt Form Example


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.


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 0th 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.


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


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


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


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 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 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.


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 the applicability of PCI DSS controls. VTP can be used to achieve a full PCI P2PE listing by service providers to achieve maximum PCI DSS validation 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.


Contact information: Coalfire: www.coalfire.com Phone: 877-224-8077 Email: [email protected] Verifone: www.verifone.com Phone: 800-837-4366

Legal Disclaimer:

Coalfire is solely responsible for the contents of this document as of the date of publication. The contents of this document are subject to change at any time based on revisions to the applicable regulations and standards (HIPAA, PCI-DSS et.al). Consequently, any forward-looking statements are not predictions and are subject to change without notice. While Coalfire has endeavored to ensure that the information contained in this document has been obtained from reliable sources, there may be regulatory, compliance, or other reasons that prevent us from doing so. Coalfire reserves the right to revise any or all of this document to reflect an accurate representation of the content relative to the current technology landscape. In order to maintain contextual accuracy of this document, all references to this document must explicitly reference the entirety of the document inclusive of the title and publication date; Neither party will publish a press release referring to the other party or excerpting highlights from the document without prior written approval of the other party. If you have questions with regard to any legal or compliance matters referenced herein you should consult legal counsel, your security advisor and/or your relevant standard authority.


Appendix A: PCI DSS Control Reduction Risk Mappings

Detailed PCI DSS Control Reduction 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 Procedures: The PCI-DSS requirement testing procedure as outlined in the PCI-DSS v3.0.

Control Reduction Risk Value: This is the associated risk value (1-4) associated with each PCI-DSS testing procedure. The value indicates whether or not the applicability of a PCI-DSS requirement can be reduced or eliminated. They are as follows:

1. Properly implemented, the VTP solution will completely render the requirement not applicable for a merchant’s PCI-DSS assessment.

2. Properly implemented, the VTP solution can significantly reduce or eliminate the applicability of the requirement from f 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 applicable 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 separately.

Merchant Documentation: Mapped against the PCI-DSS ROC Reporting Instructions v3.0, the documentation a Merchant is responsible for maintaining if a requirement is deemed in-scope for their PCI-DSS assessment. Requirements with a Control Reduction Risk value of 1 will not have any associated documentation expectations.

Justification: The Coalfire justification for the reduction or elimination of applicable controls for each PCI-DSS requirement when the VTP solution is properly implemented.


PCI-DSS v3.0 Testing Procedure Control Reduction Risk Value

Merchant Documentation

Justification

1.1 Inspect the firewall and router configuration standards and other documentation specified below and verify that standards are complete and implemented as follows:

1.1.1.a Examine documented procedures to verify there is a formal process for testing and approval of all:

• Network connections, and

• Changes to firewall and router configurations.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network. Formal process for network components testing and approval requirements would not be applicable.

1.1.1.b For a sample of network connections, interview responsible personnel and examine records to verify that network connections were approved and tested.


1.1.1.c Identify a sample of actual changes made to firewall and router configurations, compare to the change records, and interview responsible personnel to verify the changes were approved and tested.


1.1.2.a Examine diagram(s) and observe network configurations to verify that a current network diagram exists and that it documents all connections to the cardholder data environment, including any wireless networks.

4 Network Diagram Even with the significant reduction of applicable controls the VTP solution obtains, Coalfire feels that merchants should still diagram the network flow of the retail locations where VTP will be utilized.

1.1.2.b Interview responsible personnel to verify that the diagram is kept current.

4 Network Diagram Even with the significant reduction of applicable controls the VTP solution obtains, Coalfire feels that merchants should still diagram the network flow of the retail locations where VTP will be utilized.




Justification

1.1.3.a Examine data flow diagram and interview personnel to verify the diagram:

• Shows all cardholder data flows across systems and networks.

• Is kept current and updated as needed upon changes to the environment.

4 Data Flow 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.

1.1.4.a Examine the firewall configuration standards and verify that they include requirements for a firewall at each Internet connection and between any DMZ and the internal network zone.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network. The firewall configuration standards testing requirements would not be applicable.

1.1.4.b Verify that the current network diagram is consistent with the firewall configuration standards.

4 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.

1.1.4.c Observe network configurations to verify that a firewall is in place at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone, per the documented configuration standards and network diagrams.


1.1.5.a Verify that firewall and router configuration standards include a description of groups, roles, and responsibilities for management of network components.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network. The firewall and router configuration standards testing requirements would not be applicable.

1.1.5.b Interview personnel responsible for management of network components to confirm that roles and responsibilities are assigned as documented.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network.

1.1.6.a Verify that firewall and router configuration standards include a documented list of all services, protocols and ports, including business justification for each—for example, hypertext transfer

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network. The firewall and router configuration




Justification

protocol (HTTP) and Secure Sockets Layer (SSL), Secure Shell (SSH), and Virtual Private Network (VPN) protocols.

standards testing requirements would not be applicable.

1.1.6.b Identify insecure services, protocols, and ports allowed; and verify that security features are documented for each service.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network. There is no cardholder data storage in a merchant environment and as such the insecure services, protocols and ports review requirements would not be applicable.

1.1.6.c Examine firewall and router configurations to verify that the documented security features are implemented for each insecure service, protocol, and port.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network. There is no cardholder data storage in a merchant environment and as such the insecure services, protocols and ports review requirements would not be applicable.

1.1.7.a Verify that firewall and router configuration standards require review of firewall and router rule sets at least every six months.


1.1.7.b Examine documentation relating to rule set reviews and interview responsible personnel to verify that the rule sets are reviewed at least every six months.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network. The firewall review documentation requirements would not be applicable.

1.2 Examine firewall and router configurations and perform the following to verify that connections are restricted between untrusted networks and system components in the cardholder data environment:




Justification

1.2.1.a Examine firewall and router configuration standards to verify that they identify inbound and outbound traffic necessary for the cardholder data environment.


1.2.1.b Examine firewall and router configurations to verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment.


1.2.1.c Examine firewall and router configurations to 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.


1.2.2.a Examine router configuration files to verify they are secured from unauthorized access.


1.2.2.b Examine router configurations to verify they are synchronized—for example, the running (or active) configuration matches the start-up configuration (used when machines are booted).into the cardholder data environment.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network. The router configurations testing requirements would not be applicable.

1.2.3.a Examine firewall and router configurations to verify that there are perimeter firewalls installed between all wireless networks and the cardholder data environment.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network. The firewall and router configurations testing requirements would not be applicable.




Justification

1.2.3.b Verify that the firewalls deny or, if traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and the cardholder data environment.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation 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—and perform the following to determine that there is no direct access between the Internet and system components in the internal cardholder network segment:

1.3.1 Examine firewall and router configurations to verify that a DMZ is implemented to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation 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.

1.3.2 Examine firewall and router configurations to verify that inbound Internet traffic is limited to IP addresses within the DMZ.


1.3.3 Examine firewall and router configurations to verify direct connections inbound or outbound are not allowed for traffic between the Internet and the cardholder data environment.


1.3.4 Examine firewall and router configurations to verify that anti-spoofing measures are implemented, for example internal addresses cannot pass from the Internet into the DMZ.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network. The firewall and router configurations




Justification

testing requirements would not be applicable.

1.3.5 Examine firewall and router configurations to verify that outbound traffic from the cardholder data environment to the Internet is explicitly authorized.


1.3.6 Examine firewall and router configurations to 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 solution will remove the PCI DSS validation requirements for the merchant’s host network. However, Coalfire still recommends against direct unrestricted inbound Internet access to the POIs.

1.3.7 Examine firewall and router configurations to verify that system components that store cardholder data are on an internal network zone, segregated from the DMZ and other untrusted networks.


1.3.8.a Examine firewall and router configurations to verify that methods are in place to prevent the disclosure of private IP addresses and routing information from internal networks to the Internet.


1.3.8.b Interview personnel and examine documentation to verify that any disclosure of private IP addresses and routing information to external entities is authorized.





Justification

1.4 Install personal firewall software on any mobile and/or employee-owned devices that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the network. Firewall configurations include:

• Specific configuration settings are defined for personal firewall software. • Personal firewall software is actively running. • Personal firewall software is not alterable by users of mobile and/or employee-owned devices.

1.4.a Examine policies and configuration standards to verify:

• Personal firewall software is required for all mobile and/or employee-owned devices that connect to the Internet (for example, laptops used by employees) when outside the network, and which are also used to access the network.

• Specific configuration settings are defined for personal firewall software.

• Personal firewall software is configured to actively run.

• Personal firewall software is configured to not be alterable by users of mobile and/or employee-owned devices.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network. With no access to cardholder data, mobile and/or employee owned computers personal firewall software requirement will be not applicable.

1.4.b Inspect a sample of mobile and/or employee-owned devices to verify that:

• Personal firewall software is installed and configured per the organization’s specific configuration settings.

• Personal firewall software is actively running.

• Personal firewall software is not alterable by users of mobile and/or employee- owned devices.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network. With no access to cardholder data, mobile and/or employee owned computers personal firewall software requirement will be not applicable.

1.5 Ensure that security policies and operational procedures for managing firewalls are documented, in use, and known to all affected parties.




Justification

1.5 Examine documentation and interview personnel to verify that security policies and operational procedures for managing firewalls are:

• Documented, • In use, and • Known to all affected parties.

3 Network Diagram Network Configuration Standards Data Flow Diagram

Even with the significant reduction of applicable controls the VTP solution obtains, Coalfire feels that merchants should still maintain the data flow, network flow diagrams of the retail locations where VTP will be utilized.

2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.

2.1.a Choose a sample of system components, and attempt to log on (with system administrator help) to the devices and applications using default vendor-supplied accounts and passwords, to verify that ALL default passwords (including those on operating systems, software that provides security services, application and system accounts, POS terminals, and Simple Network Management Protocol (SNMP) community strings) have been changed. (Use vendor manuals and sources on the Internet to find vendor-supplied accounts/passwords.)

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices).

2.1.b For the sample of system components, verify that all unnecessary default accounts (including accounts used by operating systems, security software, applications, systems, POS terminals, SNMP, etc.) are removed or disabled.


2.1.c Interview personnel and examine supporting documentation to verify that:

• All vendor defaults (including default passwords on operating systems, software providing security services, application and system accounts, POS terminals, Simple Network Management Protocol (SNMP) community strings, etc.) are changed before a system is installed on the network.





Justification

• Unnecessary default accounts (including accounts used by operating systems, security software, applications, systems, POS terminals, SNMP, etc.) are removed or disabled before a system is installed on the network.

2.1.1 For wireless environments connected to the cardholder data environment or transmitting cardholder data, change ALL wireless vendor defaults at installation, including but not limited to default wireless encryption keys, passwords, and SNMP community strings.

2.1.1.a Interview responsible personnel and examine supporting documentation to verify that:

• Encryption keys were changed from default at installation

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network. Wireless device components would transmit cardholder data in encrypted format with merchant having no knowledge of decryption keys.

2.1.1.b Interview personnel and examine policies and procedures to verify:

• Default SNMP community strings are required to be changed upon installation.

• Default passwords/phrases on access points are required to be changed upon installation.


2.1.1.c Examine vendor documentation and login to wireless devices, with system administrator help, to verify:


2.1.1.d Examine vendor documentation and observe wireless configuration settings to verify firmware on wireless devices is updated to support strong encryption for:

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network. Vendor documentation specific to




Justification

• Authentication over wireless networks • Transmission over wireless networks

wireless configuration settings would not be applicable.

2.1.1.e Examine vendor documentation and observe wireless configuration settings to verify other security-related wireless vendor defaults were changed, if applicable.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network. Vendor documentation specific to wireless configuration settings would not be applicable.

2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.

Sources of industry-accepted system hardening standards may include, but are not limited to:

• Center for Internet Security (CIS) • International Organization for Standardization (ISO) • SysAdmin Audit Network Security (SANS) Institute

National Institute of Standards Technology (NIST)

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.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). PCI requirements testing the configuration standards for various system components would not be applicable.

2.2.b Examine policies and interview personnel to verify that system configuration standards are updated as new vulnerability issues are identified, as defined in Requirement 6.1.





Justification

2.2.c Examine policies and interview personnel to verify that system configuration standards are applied when new systems are configured and verified as being in place before a system is installed on the network.


2.2.d Verify that system configuration standards include the following procedures for all types of system components:

• Changing of all vendor- supplied defaults and elimination of unnecessary default accounts

• Implementing only one primary function per server to prevent functions that require different security levels from co-existing on the same server

• Enabling only necessary services, protocols, daemons, etc., as required for the function of the system

• Implementing additional security features for any required services, protocols or daemons that are considered to be insecure

• Configuring system security parameters to prevent misuse

• Removing all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers


2.2.1.a Select a sample of system components and inspect the system configurations to verify that only one primary function is implemented per server.





Justification

2.2.1.b If virtualization technologies are used, inspect the system configurations to verify that only one primary function is implemented per virtual system component or device

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). With no access to cardholder data, there will be no applicable requirements for virtualization technologies.

2.2.2.a Select a sample of system components and inspect enabled system services, daemons, and protocols to verify that only necessary services or protocols are enabled.


2.2.2.b Identify any enabled insecure services, daemons, or protocols and interview personnel to verify they are justified per documented configuration standards.


2.2.3 Inspect configuration settings to verify that security features are documented and implemented for all insecure services, daemons, or protocols.


2.2.4.a Interview system administrators and/or security managers to verify that they have knowledge of common security parameter settings for system components.


2.2.4.b Examine the system configuration standards to verify that common security parameter settings are included.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). PCI requirements testing the




Justification

configuration standards for various system components would not be applicable.

2.2.4.c Select a sample of system components and inspect the common security parameters to verify that they are set appropriately and in accordance with the configuration standards.


2.2.5.a Select a sample of system components and inspect the configurations to verify that all unnecessary functionality (for example, scripts, drivers, features, subsystems, file systems, etc.) is removed.


2.2.5.b. Examine the documentation and security parameters to verify enabled functions are documented and support secure configuration.


2.2.5.c. Examine the documentation and security parameters to verify that only documented functionality is present on the sampled system components.


2.3 Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access.




Justification

2.3.a Observe an administrator log on to each system and examine system configurations 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 insecure remote-login commands are not available for non-console access


2.3.c Observe an administrator log on to each system to verify that administrator access to any web-based management interfaces is encrypted with strong cryptography.


2.3.d Examine vendor documentation and interview personnel to verify that strong cryptography for the technology in use is implemented according to industry best practices and/or vendor recommendations.


2.4 Maintain an inventory of system components that are in scope for PCI DSS.

2.4.a Examine system inventory to verify that a list of hardware and software components is maintained and includes a description of function/use for each.

4 POI Device Inventory Maintaining POI device inventory will still apply to the merchant environment.

2.4.b Interview personnel to verify the documented inventory is kept current.

4 POI Device Inventory Maintaining POI device inventory will still apply to the merchant environment.

2.5 Ensure that security policies and operational procedures for managing vendor defaults and other security parameters are documented, in use, and known to all affected parties.




Justification

2.5 Examine documentation and interview personnel to verify that security policies and operational procedures for managing vendor defaults and other security parameters are:


1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network. PCI requirements testing the configuration standards for various system components would not be applicable.

2.6 Shared hosting providers must protect each entity’s hosted environment and cardholder data. These providers must meet specific requirements as detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers.

2.6 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 Keep cardholder data storage to a minimum by implementing data-retention and disposal policies, procedures and processes that include at least the following for all CHD storage:

• Limiting data storage amount and retention time to that which is required for legal, regulatory, and business requirements.

• Processes for secure deletion of data when no longer needed. • Specific retention requirements for cardholder data. • A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention.

3.1.a Examine the data- retention and disposal policies, procedures and processes to verify they include at least the following:

• 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.




Justification

• Secure deletion of cardholder data when no longer needed for legal, regulatory, or business reasons

• Coverage for all storage of cardholder data

• A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements.

3.1.b Interview personnel to verify that:

• All locations of stored cardholder data are included in the data-retention and disposal processes.

• Either a quarterly automatic or manual process is in place to identify and securely delete stored cardholder data.

• The quarterly automatic or manual process is performed for all locations of cardholder data.



3.1.c For a sample of system components that store cardholder data:

• Examine files and system records to verify that the data stored does not exceed the requirements defined in the data-retention policy.

• Observe the deletion mechanism to verify data is deleted securely.



3.2 Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process.

3.2.a For issuers and/or companies that support issuing services and store sensitive authentication data, review policies and interview personnel to verify there is a documented business justification for the storage of sensitive authentication data.

1 Not Applicable Not applicable for merchants.




Justification

3.2.b For issuers and/or companies that support issuing services and store sensitive authentication data, examine data stores and system configurations to verify that the sensitive authentication data is secured.

1 Not Applicable Not applicable for merchants.

3.2.c For all other entities, if sensitive authentication data is received, review policies and procedures, and examine system configurations to verify the data is not retained after authorization.

1 Not Applicable Sensitive authentication data will not be stored within or outside of hardware POI devices.

3.2.d For all other entities, if sensitive authentication data is received, review procedures and examine the processes for securely deleting the data to verify that the data is unrecoverable.


3.2.1 Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data.

3.2.1 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 after authorization:

• Incoming transaction data • All logs (for example, transaction,

history, debugging, error) • History files • Trace files • Several database schemas • Database contents





Justification

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 four- digit card verification code or value printed on the front of the card or the signature panel (CVV2, CVC2, CID, CAV2 data) is not stored after authorization:




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.

3.2.3 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 after authorization:




3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see the full PAN.

3.3.a Examine written policies and procedures for masking the display of PANs to verify:

• A list of roles that need access to displays of full PAN is documented, together with a legitimate business need for each role to have such access.

• PAN must be masked when displayed such that only personnel with a legitimate business need can see the full PAN.






Justification

• All other roles not specifically authorized to see the full PAN must only see masked PANs.

3.3.b Examine system configurations to verify that full PAN is only displayed for users/roles with a documented business need, and that PAN is masked for all other requests.



3.3.c Examine displays of PAN (for example, on screen, on paper receipts) to verify that PANs are masked when displaying cardholder data, and that only those with a legitimate business need are able to see full PAN.



3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:

• One-way hashes based on strong cryptography, (hash must be of the entire PAN). • Truncation (hashing cannot be used to replace the truncated segment of PAN). • Index tokens and pads (pads must be securely stored).

Strong cryptography with associated key-management processes and procedures.

3.4.a Examine documentation about the system used to protect the PAN, including the vendor, type of system/process, and the encryption algorithms (if applicable) to 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

key- management processes and procedures

1 Not Applicable PAN will be rendered unreadable at swipe on POI devices. Merchants will have no responsibility for secure storage of cardholder data within their environments.




Justification

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 rendered unreadable.


3.4.d Examine a sample of audit logs to confirm that the PAN is rendered unreadable or removed from the logs.


3.4.1.a If disk encryption is used, inspect the configuration and observe the authentication process to verify that logical access to encrypted file systems is implemented via a mechanism that is separate from the native operating system’s authentication mechanism (for example, not using local user account databases or general network login credentials).


3.4.1.b Observe processes and interview personnel to verify that cryptographic keys are stored securely (for example, stored on removable media that is adequately protected with strong access controls).


3.4.1.c Examine the configurations and observe the processes to verify that cardholder data on removable media is encrypted wherever stored.

Note: If disk encryption is not used to encrypt removable media, the data stored





Justification

on this media will need to be rendered unreadable through some other method.

3.5 Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse:

3.5 Examine key-management policies and procedures to verify processes are specified to protect keys used for encryption of cardholder data against disclosure and misuse and include at least the following:

• Access to keys is restricted to the fewest number of custodians necessary.

• Key-encrypting keys are at least as strong as the data- encrypting keys they protect.

• Key-encrypting keys are stored separately from data- encrypting keys.

• Keys are stored securely 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.

3.5.1 Examine user access lists to verify that access to keys is restricted to the fewest number of custodians necessary.


3.5.2 Store secret and private keys used to encrypt/decrypt cardholder data in one (or more) of the following forms at all times:

• Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key.

• Within a secure cryptographic device (such as a host security module (HSM) or PTS-approved point-of- interaction device). • As at least two full-length key components or key shares, in accordance with an industry-accepted method




Justification

3.5.2.a Examine documented procedures to verify that cryptographic keys used to encrypt/decrypt cardholder data must only exist in one (or more) of the following forms at all times.

• Encrypted with a key- encrypting key that is at least as strong as the data- encrypting key, and that is stored separately from the data-encrypting key.

• Within a secure cryptographic device (such as a host security module (HSM) or PTS-approved point-of-interaction device).

• As key components or key shares, in accordance with an industry-accepted method.

1 Not Applicable. If the VTP solution has been implemented correctly, Merchants will have no key management responsibilities within their environment. As such, the key-management procedures documentation is not applicable.

3.5.2.b Examine system configurations and key storage locations to verify that cryptographic keys used to encrypt/decrypt cardholder data exist in one, (or more), of the following form at all times.

• Encrypted with a key- encrypting key. • Within a secure cryptographic device

(such as a host security module (HSM) or PTS-approved point-of-interaction device).

• As key components or key shares, in accordance with an industry-accepted method.


3.5.2.c Wherever key- encrypting keys are used, examine system configurations and key storage locations to verify:

• Key-encrypting keys are at least as strong as the data- encrypting keys they protect.

• Key-encrypting keys are stored separately from data- encrypting keys.





Justification

3.5.3 Examine key storage locations and observe processes to verify that keys are stored in the fewest possible locations.


3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data, including the following:

3.6.a Additional Procedure for service providers: If the service provider shares keys with their customers for transmission or storage of cardholder data, examine the documentation that the service provider provides to their customers to verify that it includes guidance on how to securely transmit, store, and update customers’ keys, in accordance with Requirements 3.6.1 through 3.6.8 below.


3.6.1.a Verify that key- management procedures specify how to generate strong keys.


3.6.1.b Observe the method for generating keys to verify that strong keys are generated.


3.6.2.a Verify that key- management procedures specify how to securely distribute keys.





Justification

3.6.2.b Observe the method for distributing keys to verify that keys are distributed securely.


3.6.3.a Verify that key-management procedures specify how to securely store keys.


3.6.3.b Observe the method for storing keys to verify that keys are stored securely.


3.6.4.a Verify that key- management procedures include a defined cryptoperiod for each key type in use and define a process for key changes at the end of the defined cryptoperiod(s).


3.6.4.b Interview personnel to verify that keys are changed at the end of the defined cryptoperiod(s).


3.6.5.a Verify that key- management procedures specify processes for the following:

• The retirement or replacement of keys when the integrity of the key has been weakened.

• The replacement of known or suspected compromised keys.





Justification

• Any keys retained after retiring or replacing are not used for encryption operations.

3.6.5.b Interview personnel to verify the following processes are implemented:

• Keys are retired or replaced as necessary when the integrity of the key has been weakened, including when someone with knowledge of the key leaves the company.

• Keys are replaced if known or suspected to be compromised.

• Any keys retained after retiring or replacing are not used for encryption operations.


3.6.6.a Verify that manual clear- text key-management procedures specify processes for the use of the following:

• Split knowledge of keys, such that key components are under the control of at least two people who only have knowledge of their own key components; AND

• Dual control of keys, such that at least two people are required to perform any key- management operations and no one person has access to the authentication materials (for example, passwords or keys) of another.


3.6.6 b Interview personnel and/or observe processes to verify that manual clear-text keys are managed with:

• Split knowledge, AND • Dual control


3.6.7.a Verify that key-management procedures specify processes to prevent 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. As such, the key-management




Justification

procedures documentation is not applicable.

3.6.7.b Interview personnel and/or observe process to verify that unauthorized substitution of keys is prevented.


3.6.8.a Verify that key- management procedures specify processes for 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. As such, key-management procedures documentation is not applicable.

3.6.8.b Observe documentation or other evidence showing that key custodians have acknowledged (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. As such, key-management procedures documentation is not applicable.

3.7 Ensure that security policies and operational procedures for protecting stored cardholder data are documented, in use, and known to all affected parties.

3.7 Examine documentation and interview personnel to verify that security policies and operational procedures for protecting stored cardholder data are:

• Documented, • In use, and • Known to all affected parties



4.1 Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including the following:

• Only trusted keys and certificates are accepted. • The protocol in use only supports secure versions or configurations. • The encryption strength is appropriate for the encryption methodology in use.




Justification

4.1.a Identify all locations where cardholder data is transmitted or received over open, public networks.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network. Cardholder data is encrypted at POI device with no key responsibilities with merchant. Cardholder data transmission requirements will not be applicable for this environment.

4.1.b Review documented policies and procedures to verify processes are specified for the following:

• For acceptance of only trusted keys and/or certificates.

• For the protocol in use to only support secure versions and configurations (that insecure versions or configurations are not supported).

• For implementation of proper encryption strength per the encryption methodology in use.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network. Cardholder data is encrypted at POI device with no key responsibilities with merchant. Cardholder data transmission requirements will not be applicable for this environment. Transmission requirements will not be applicable.

4.1.c Select and observe a sample of inbound and outbound transmissions as they occur to verify that all cardholder data is encrypted with strong cryptography during transit.


4.1.d Examine keys and certificates to verify that only trusted keys and/or certificates are accepted.





Justification

4.1.e Examine system configurations to verify that the protocol is implemented to use only secure configurations and does not support insecure versions or configurations.


4.1.f Examine system configurations to verify that the proper encryption strength is implemented for the encryption methodology in use. (Check vendor recommendations/best practices.)


4.1.g For SSL/TLS implementations, examine system configurations to verify that SSL/TLS is enabled whenever cardholder data is transmitted or received.


4.1.1 Identify all wireless networks transmitting cardholder data or connected to the cardholder data environment. Examine documented standards and compare to system configuration settings to verify the following for all wireless networks identified:

• Industry best practices (for example, IEEE 802.11i) are used to implement strong encryption for authentication and transmission.

• Weak encryption (for example, WEP, SSL version





Justification

• 2.0 or older) is not used as a security control for authentication or transmission.

4.2 Never send unprotected PANs by end-user messaging technologies.

4.2.a If end-user messaging technologies are used to send cardholder data, observe processes for sending PAN and examine a sample of outbound transmissions as they occur to verify that PAN is rendered unreadable or secured with strong cryptography whenever it is sent via end-user messaging technologies.


4.2.b Review written policies to verify the existence of a policy stating that unprotected PANs are not to be sent via end-user messaging technologies.

2 Acceptable Usage Policies Merchants will not have any access to cardholder data within their environment; however, employees will still have access to the physical credit card in retail environments. As such, a policy prohibiting the emailing of unprotected PAN is still appropriate for most retail environments.

4.3 Ensure that security policies and operational procedures for encrypting transmissions of cardholder data are documented, in use, and known to all affected parties.

4.3 Examine documentation and interview personnel to verify that security policies and operational procedures for encrypting transmissions of cardholder data are:


2 Acceptable Usage Policies Merchants will not have any access to cardholder data within their environment; however, employees will still have access to the physical credit card in retail environments. As such, a policy prohibiting the emailing of unprotected PAN is still appropriate for most retail environments.

5.1 Deploy anti-virus software on all systems commonly affected by malicious software.




Justification

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 anti-virus technology exists.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all server components located on the merchant’s host network. Anti-virus and anti-malware requirements will not be applicable.

5.1.1 Review vendor documentation and examine anti- virus configurations to verify that anti-virus programs; • Detect all known types of malicious

software, • Remove all known types of malicious

software, and • Protect against all known types of

malicious software.


5.1.2 Interview personnel to verify that evolving malware threats are monitored and evaluated for systems not currently considered to be commonly affected by malicious software, in order to confirm whether such systems continue to not require anti-virus software.


5.2 Ensure that all anti-virus mechanisms are maintained as follows:

• Are kept current. • Perform periodic scans. • Generate audit logs which are retained per PCI DSS Requirement 10.7.

5.2.a Examine policies and procedures to verify that anti- virus software and definitions are required to be kept up-to-date.


5.2.b Examine anti-virus configurations, including the master installation of the software

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all server components located on the merchant’s host network.




Justification

Anti-virus and anti-malware requirements will not be applicable.

5.2.c Examine a sample of system components, including all operating system types commonly affected by malicious software, to verify that:

• The anti-virus software and definitions are current.

• Periodic scans are performed.


5.2.d Examine anti-virus configurations, including the master installation of the software and a sample of system components, to verify that:

• Anti-virus software log generation is enabled, and

• Logs are retained in accordance with PCI DSS Requirement 10.7.


5.3 Ensure that anti-virus mechanisms are actively running and cannot be disabled or altered by users, unless specifically authorized by management on a case-by-case basis for a limited time period.

5.3.a Examine anti-virus configurations, including the master installation of the software and a sample of system components, to verify the anti- virus software is actively running.


5.3.b Examine anti-virus configurations, including the master installation of the software and a sample of system components, to verify that the anti-virus software cannot be disabled or altered by users.


5.3.c Interview responsible personnel and observe processes to verify that anti-virus software cannot be disabled or altered by users, unless specifically authorized by

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all server components located on




Justification

management on a case-by-case basis for a limited time period.

the merchant’s host network. Anti-virus and anti-malware requirements will not be applicable.

5.4 Ensure that security policies and operational procedures for protecting systems against malware are documented, in use, and known to all affected parties.

5.4 Examine documentation and interview personnel to verify that security policies and operational procedures for protecting systems against malware are:



6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.

6.1.a Examine policies and procedures to verify that processes are defined for the following:

• To identify new security vulnerabilities. • To assign a risk ranking to

vulnerabilities that includes identification of all “high risk” and “critical” vulnerabilities.

• To include using reputable outside sources for security vulnerability `information.

2 Vulnerability Alerting Procedures

Even with the significant reduction of applicable controls the VTP solution obtains, Coalfire feels that merchants should still document the POI devices and payment system’s vulnerability alerting processes.

6.1.b Interview responsible personnel and observe processes to verify that:

• New security vulnerabilities are identified.

• A risk ranking is assigned to vulnerabilities that includes identification of all “high” risk and “critical” vulnerabilities.

• Processes to identify new security vulnerabilities include using reputable outside sources for security vulnerability information.

2 Vulnerability Alerting Procedures

Even with the significant reduction of applicable controls the VTP solution obtains, Coalfire feels that merchants should still document the POI devices and payment system’s vulnerability alerting processes.




Justification

6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.

6.2.a Examine policies and procedures related to security- patch installation to verify processes are defined for:

• Installation of applicable critical vendor-supplied security patches within one month of release.

• Installation of all applicable vendor-supplied security patches within an appropriate time frame (for example, within three months).

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Patch management procedures for various system components will not be applicable.

6.2.b For a sample of system components and related software

• Identify the sample of system components and related software selected for this testing procedure.

• For each item in the sample, describe how the list of security patches installed on each system was compared to the most recent vendor security-patch list to verify that:

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Patch management procedures for various system components will not be applicable.

6.3 Develop internal and external software applications (including web-based administrative access to applications) securely, as follows:

• In accordance with PCI DSS (for example, secure authentication and logging). • Based on industry standards and/or best practices.

Incorporate information security throughout the software development life cycle.

6.3.a Examine written software- development processes to verify that the processes are based on industry standards and/or best practices.

1 Not Applicable This control will be not applicable for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE.

6.3.b Examine written software development processes to verify that information security is included throughout the life cycle.

1 Not Applicable This control should not apply for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE. As such, software development processes




Justification

documentation will not be applicable.

6.3.c Examine written software development processes to verify that software applications are developed in accordance with PCI DSS.

1 Not Applicable This control should not apply for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE. As such, software development processes documentation will not be applicable.

6.3.d Interview software developers to verify that written software development processes are implemented.


6.3.1 Examine written software- development procedures and interview responsible personnel to verify that pre-production and/or custom application accounts, user IDs and/or passwords are removed before an application goes into production or is released to customers.


6.3.2 Review custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes) to include at least the following:

• Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code review techniques and secure coding practices.

• Code reviews ensure code is developed according to secure coding guidelines. • Appropriate corrections are implemented prior to release.

Code review results are reviewed and approved by management prior to release.

6.3.2.a Examine written software development procedures and interview responsible personnel to verify 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





Justification

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.

6.3.2.b Select a sample of recent custom application changes and verify that custom application code is reviewed according to 6.3.2.a, above.


6.4 Follow change control processes and procedures for all changes to system components. The processes must include the following:

6.4 Examine policies and procedures to verify the following are defined:

• Development/test environments are separate from production environments with access control in place to enforce separation.

• 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.

• Change control procedures related to implementing security patches and software modifications are documented.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Change control processes and procedures for various system components will not be applicable.

6.4.1.a Examine network documentation and network device configurations to verify that the development/test environments are separate from the production environment(s).

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on




Justification

the merchant’s host network (outside of the POI devices).

6.4.1.b Examine access controls settings to verify that access controls are in place to enforce separation between the development/test environments and the production environment(s).


6.4.2 Observe processes and interview personnel assigned to development/test environments and personnel assigned to production environments to verify that separation of duties is in place between development/test environments and the production environment.


6.4.3.a Observe testing processes and interview personnel to verify procedures are in place to ensure production data (live PANs) are not used for testing or development.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Merchants will have no access to cardholder data (PANs) within their environment.

6.4.3.b Examine a sample of test data to verify production data (live PANs) is not used for testing or development.


6.4.4.a Observe testing processes and interview personnel to verify test data and accounts are removed before a production system becomes active.





Justification

6.4.4.b Examine a sample of data and accounts from production systems recently installed or updated to verify test data and accounts are removed before the system becomes active.


6.4.5.a Examine documented change-control procedures related to implementing security patches and software modifications and verify procedures are defined for:

• Documentation of impact. • Documented change approval by

authorized parties. • Functionality testing to verify that the

change does not adversely impact the security of the system.

• Back-out procedures.

2 Change control procedures POI devices

Change control procedures should not apply for all of the merchant environment; however, Coalfire recommends change control processes be used for tracking POI devices within the environment. Change management processes for other systems would be not applicable.

6.4.5.b For a sample of system components, interview responsible personnel to determine recent changes/security patches. Trace those changes back to related change control documentation. For each change examined, perform the following:

For each item in the sample, identify the sample of changes and the related change control documentation selected for this testing procedure (through 6.4.5.4)



6.4.5.1 Verify that documentation of impact is included in the change control documentation for each sampled change.






Justification

6.4.5.2 Verify that documented approval by authorized parties is present for each sampled change.



6.4.5.3.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.



6.4.5.3.b For custom code changes, verify that all updates are tested for compliance with PCI DSS Requirement 6.5 before being deployed into production.


6.4.5.4 Verify that back-out procedures are prepared for each sampled change.



6.5 Address common coding vulnerabilities in software-development processes as follows:

• Train developers in secure coding techniques, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory.

Develop applications based on secure coding guidelines.

6.5.a Examine software development policies and procedures to verify that training in secure coding techniques is

1 Not Applicable This control should not apply for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE. As such, software




Justification

required for developers, based on industry best practices and guidance.

development processes documentation will not be applicable.

6.5.b Interview a sample of developers to verify that they are knowledgeable in secure coding techniques.


6.5.c Examine records of training to verify that software developers received training on secure coding techniques, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory.


6.5.d. Verify that processes are in place to protect applications from, at a minimum, the following vulnerabilities:


6.5.1 Examine software- development policies and procedures and interview responsible personnel to verify that injection flaws are addressed by coding techniques that include:

• Validating input to verify user data cannot modify meaning of commands and queries.

• Utilizing parameterized queries.

1 Not Applicable This control will be not applicable for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE. As such, software development procedures and secure coding documentation will not be applicable.

6.5.2 Examine software- development policies and procedures and interview

For the interviews at 6.5.d, summarize the relevant interview details that confirm processes are in place, consistent with the software development documentation at 6.5.d, to ensure that buffer overflows are addressed by coding techniques that include:

1 Not Applicable This control should not apply for merchants utilizing the VTP solution as there will be no self-developed payment applications within the CDE. As such, software development procedures and secure coding documentation will not be applicable.




Justification

6.5.3 Examine software- development policies and procedures and interview responsible personnel to verify that insecure cryptographic storage is addressed by coding techniques that:

• Prevent cryptographic flaws. • Use strong cryptographic algorithms

and keys.


6.5.4 Examine software- development policies and procedures and interview responsible personnel to verify that insecure communications are addressed by coding techniques that properly authenticate and encrypt all sensitive communications.


6.5.5 Examine-software development policies and procedures and interview responsible personnel to verify that improper error handling is addressed by coding techniques that do not leak information via error messages (for example, by returning generic rather than specific error details).


6.5.6 Examine software- development policies and procedures and interview responsible personnel to verify that coding techniques address any “high risk” vulnerabilities that could affect the application, as identified in PCI DSS Requirement 6.1.


6.5.7 Examine software- development policies and procedures and interview responsible personnel to verify that cross-site scripting (XSS) is addressed by coding techniques that include:

• Validating all parameters before inclusion.

• Utilizing context-sensitive escaping.





Justification

6.5.8 Examine software- development policies and procedures and interview responsible personnel to verify that improper access control— such as insecure direct object references, failure to restrict URL access, and directory traversal—is addressed by coding technique that include:

• Proper authentication of users. • Sanitizing input. • Not exposing internal object references

to users. • User interfaces that do not permit

access to unauthorized functions.


6.5.9 Examine software development policies and procedures and interview responsible personnel to verify that cross-site request forgery (CSRF) is addressed by coding techniques that ensure applications do not rely on authorization credentials and tokens automatically submitted by browsers.


6.5.10 Examine software development policies and procedures and interview responsible personnel to verify that broken authentication and session management are addressed via coding techniques that commonly include:

• Flagging session tokens (for example cookies) as “secure.”

• Not exposing session IDs in the URL. • Incorporating appropriate time-outs

and rotation of session IDs after a successful login.


6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:

• Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes.

Note: This assessment is not the same as the vulnerability scans performed for Requirement 11.2.




Justification

Installing an automated technical solution that detects and prevents web-based attacks (for example, a web- application firewall) in front of public-facing web applications, to continually check all traffic.

6.6 For public-facing web applications, ensure that either one of the following methods is in place as follows:

• Examine documented processes, interview personnel, and examine records of application security assessments to 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, at a minimum, all

vulnerabilities in Requirement 6.5 are included in the assessment.

− That all vulnerabilities are corrected. − That the application is re-evaluated

after the corrections.

• Examine the system configuration settings and interview responsible personnel to verify that an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) is in place as follows: − Is situated in front of public-facing

web applications to detect and prevent web-based attacks.

− Is actively running and up-to-date as applicable.

− Is generating audit logs. − Is configured to either block web-

based attacks, or generate an alert.

1 Not Applicable This control will not be applicable for merchants utilizing the VTP solution as VTP solution is not a web application requiring application security assessments or automated technical solution to detect and prevent web-based attacks. Public-facing web applications are not in scope for this paper.

6.7 Ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties.




Justification

6.7 Examine documentation and interview personnel to verify that security policies and operational procedures for developing and maintaining secure systems and applications are:


1 Not Applicable Security policies and operational procedures documentation for maintaining secure systems and applications would not be applicable.

7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access.

7.1.a Examine written policy for access control, and verify that the policy incorporates 7.1.1 through 7.1.4 as follows:

• Defining access needs and privilege assignments for each role.

• Restriction of access to privileged user IDs to least privileges necessary to perform job responsibilities.

• Assignment of access based on individual personnel’s job classification and function.

• Documented approval (electronically or in writing) by authorized parties for all access, including listing of specific privileges approved.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Access control policies will not be applicable for the merchant environment.

7.1.1 Select a sample of roles and verify access needs for each role are defined and include:

• System components and data resources that each role needs to access for their job function.

• Identification of privilege necessary for each role to perform their job function.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Access control restriction requirements would not be applicable.

7.1.2.a Interview personnel responsible for assigning access to verify that access to privileged user IDs is:

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on




Justification

• Assigned only to roles that specifically require such privileged access.

• Restricted to least privileges necessary to perform job responsibilities.

the merchant’s host network (outside of the POI devices). Access control restriction requirements would not be applicable.

7.1.2.b Select a sample of user IDs with privileged access and interview responsible management personnel to verify that privileges assigned are:

• Necessary for that individual’s job function.

• Restricted to least privileges necessary to perform job responsibilities.


7.1.3 Select a sample of user IDs and interview responsible management personnel to verify that privileges assigned are based on that individual’s job classification and function.


7.1.4 Select a sample of user IDs and compare with documented approvals to verify that:

• Documented approval exists for the assigned privileges.

• The approval was by authorized parties.

• That specified privileges match the roles assigned to the individual.


7.2 Examine system settings and vendor documentation to verify that an access control system is implemented as follows:




Justification

7.2.1 Confirm that access control systems are in place on all system components.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Access control system implementation requirements would not be applicable.

7.2.2 Confirm that access control systems are configured to enforce privileges assigned to individuals based on job classification and function.


7.2.3 Confirm that the access control systems have a default “deny-all” setting.


7.3 Ensure that security policies and operational procedures for restricting access to cardholder data are documented, in use, and known to all affected parties.

7.3 Examine documentation and interview personnel to verify that security policies and operational procedures for restricting access to cardholder data are:


1 Not Applicable Merchant will have no access to cardholder data, security policies and operational procedures documentation for restricting access to cardholder data would not be applicable.

8.1 Define and implement policies and procedures to ensure proper user identification management for non-consumer users and administrators on all system components as follows:

8.1.a Review procedures and confirm they define processes for each of the items below at 8.1.1 through 8.1.8.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for




Justification

all system components located on the merchant’s host network (outside of the POI devices). User identification management procedures for merchant environments would not be applicable.

8.1.1 Interview administrative personnel to confirm that all users are assigned a unique ID for access to system components or cardholder data.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). User identification management procedures for merchant environments would not be applicable.

8.1.2 For a sample of privileged user IDs and general user IDs, examine associated authorizations and observe system settings to verify each user ID and privileged user ID has been implemented with only the privileges specified on the documented approval.


8.1.3.a Select a sample of users terminated in the past six months, and review current user access lists—for both local and remote access—to verify that their IDs have been deactivated or removed from the access lists.


8.1.3.b Verify all physical authentication methods—such as, smart cards, tokens, etc.— have been returned or deactivated.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). User identification management




Justification

procedures for merchant environments would not be applicable.

8.1.4 Observe user accounts to verify that any inactive accounts over 90 days old are either removed or disabled.


8.1.5.a Interview personnel and observe processes for managing accounts used by vendors to access, support, or maintain system components to verify that accounts used by vendors for remote access are:

• Disabled when not in use. • Enabled only when needed by the

vendor, and disabled when not in use.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Vendor remote access management procedures will not be applicable.

8.1.5.b Interview personnel and observe processes to verify that vendor remote access accounts are monitored while being used.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Vendor remote access management procedures will not be applicable.

8.1.6.a For a sample of system components, inspect system configuration settings to verify that authentication parameters are set to require that user accounts be locked out after not more than six invalid logon attempts.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Authentication parameter settings for various system components will not be applicable.




Justification

8.1.6.b Additional procedure for service providers: Review internal processes and customer/user documentation, and observe implemented processes to verify that non- consumer user accounts are temporarily locked-out after not more than six invalid access attempts.

1 Not Applicable Not applicable in merchant environments.

8.1.7 For a sample of system components, 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.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Authentication parameter settings for various system components will not be applicable.

8.1.8 For a sample of system components, inspect system configuration settings to verify that system/session idle time out features have been set to 15 minutes or less.


8.2 In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users:

• Something you know, such as a password or passphrase. • Something you have, such as a token device or smart card.

Something you are, such as a biometric.

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:

• Examine documentation describing the authentication method(s) used.

1 Not Applicable Merchants will not have access to cardholder data. As such, user authentication management requirements will not be applicable.

8.2.1.a Examine vendor documentation and system configuration settings to verify that passwords are protected with strong

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network




Justification

cryptography during transmission and storage.

(outside of the POI devices). User-authentication password protection requirements will not be applicable.

8.2.1.b For a sample of system components, examine password files to verify that passwords are unreadable during storage.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). User-authentication password protection requirements will not be applicable.

8.2.1.c For a sample of system components, examine data transmissions to verify that passwords are unreadable during transmission.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). User-authentication password protection requirements will not be applicable.

8.2.1.d Additional procedure for service providers: Observe password files to verify that customer passwords are unreadable during storage.


8.2.1.e Additional procedure for service providers: Observe data transmissions to verify that customer passwords are unreadable during transmission.


8.2.2 Examine authentication procedures for modifying authentication credentials and observe security personnel to verify that, if a user requests a reset of an authentication credential by phone, e-mail, web, or other non-face-to-face method, the user’s identity is verified before the authentication credential is modified.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Authentication procedures for users will not be applicable.

8.2.3.a For a sample of system components, inspect system configuration settings to verify that user password

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for




Justification

parameters are set to require at least the following strength/complexity:

• Require a minimum length of at least seven characters.

• Contain both numeric and alphabetic characters.

all system components located on the merchant’s host network (outside of the POI devices). Password parameter settings for various system components will not be applicable.

8.2.3.b Additional procedure for service providers: Review internal processes and customer/user documentation to verify that non-consumer user passwords are required to meet at least the following strength/complexity:

• Require a minimum length of at least seven characters.

• Contain both numeric and alphabetic characters.


8.2.4.a For a sample of system components, inspect system configuration settings to verify that user password parameters are set to require users to change passwords at least every 90 days.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Password parameter settings for various system components will not be applicable.

8.2.4.b Additional procedure for service providers: Review internal processes and customer/user documentation to verify that:

• Non-consumer user passwords are required to change periodically; and

• Non-consumer users are given guidance as to when, and under what circumstances, passwords must change.


8.2.5.a For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require





Justification

that new passwords cannot be the same as the four previously used passwords.

Password parameter settings for various system components will not be applicable.

8.2.5.b Additional Procedure for service providers, review internal processes and customer/user documentation to verify that new non- consumer user passwords cannot be the same as the previous four passwords.


8.2.6 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.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Password parameter settings for various system components will not be applicable.

8.3 Incorporate two-factor authentication for remote network access originating from outside the network, by personnel (including users and administrators) and all third parties, (including vendor access for support or maintenance).

8.3.a Examine system configurations for remote access servers and systems to verify two-factor authentication is required for:

• All remote access by personnel. • All third-party/vendor remote

access (including access to applications and system components for support or maintenance purposes).

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Two-factor authentication for remote network access will not be applicable.

8.3.b Observe a sample of personnel (for example, users and administrators) connecting remotely to the network and verify that at least two of the three authentication methods are used.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Two-factor authentication for remote network access will not be applicable.

8.4 Document and communicate authentication procedures and policies to all users including:

• Guidance on selecting strong authentication credentials.




Justification

• Guidance for how users should protect their authentication credentials. • Instructions not to reuse previously used passwords.

Instructions to change passwords if there is any suspicion the password could be compromised.

8.4.a Examine procedures and interview personnel to verify that authentication procedures and policies are distributed to all users.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Authentication procedures and policies requirements will not be applicable.

8.4.b Review authentication procedures and policies that are distributed to users and verify they include:

• Guidance on selecting strong authentication credentials.

• Guidance for how users should protect their authentication credentials.

• Instructions for users not to reuse previously used passwords.

• Instructions to change passwords if there is any suspicion the password could be compromised.


8.4.c Interview a sample of users to verify that they are familiar with authentication procedures and policies.


8.5 Do not use group, shared, or generic IDs, passwords, or other authentication methods as follows:

• Generic user IDs are disabled or removed. • Shared user IDs do not exist for system administration and other critical functions. • Shared and generic user IDs are not used to administer any system components.




Justification

8.5.a For a sample of system components, examine user ID lists to verify the following.

• Generic user IDs 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.


8.5.b Examine authentication policies/procedures to verify that use of group and shared IDs and/or passwords or other authentication methods are explicitly prohibited.


8.5.c Interview system administrators to verify that group and shared IDs and/or passwords or other authentication methods are not distributed, even if requested.


8.5.1 Additional requirement for service providers: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer.

8.5.1 Additional requirement for service providers:

Examine authentication policies and procedures and interview personnel to verify that different authentication are used for access to each customer.





Justification

8.6.a Examine authentication policies and procedures to verify that procedures for using authentication mechanisms such as physical security tokens, smart cards, and certificates are defined and include:

• Authentication mechanisms are assigned to an individual account and not shared among multiple accounts.

• Physical and/or logical controls are defined to ensure only the intended account can use that mechanism to gain access.


8.6.b Interview security personnel to verify authentication mechanisms are assigned to an account and not shared among multiple accounts.


8.6.c Examine system configuration settings and/or physical controls, as applicable, to verify that controls are implemented to ensure only the intended account can use that mechanism to gain access.


8.7.a Review database and application configuration settings and verify that all users are authenticated prior to access.

1 Not Applicable There will be no cardholder data repositories when the VTP solution is implemented properly.

8.7.b Examine database and application configuration settings to verify 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).


8.7.c Examine database access control settings and database application configuration settings to verify that user





Justification

direct access to or queries of databases are restricted to database administrators.

8.7.d Examine database access control settings, database application configuration settings, 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).


8.8 Examine documentation interview personnel to verify that security policies and operational procedures for identification and authentication are:


1 Not Applicable Merchant will have no access to cardholder data, security policies and operational procedures documentation for identification and authentication would not be applicable.

9.1 Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment. 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 they are “locked” to prevent unauthorized use.

2 Physical Security Policy Appropriate physical controls to ensure that the POI devices cannot be physically altered, perimeter devices are properly protected should be in place. Physical controls also apply to protection of paper media containing cardholder data.

9.1.1.a Verify that video cameras and/or access control mechanisms are in place to monitor the entry/exit points to sensitive areas.

1 Not Applicable This control requirement will be not applicable since there won't be any "sensitive" areas in the merchant




Justification

environment outside of the POI terminals.

9.1.1.b Verify that video cameras and/or access control mechanisms are protected from tampering or disabling.

1 Not Applicable This control requirement will be not applicable since there won't be any "sensitive" areas in the merchant environment outside of the POI terminals.

9.1.1.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 will be not applicable since there won't be any "sensitive" areas in the merchant environment outside of the POI terminals

9.1.2 Interview responsible personnel and observe locations of publicly accessible network jacks to verify that physical and/or logical controls are in place to restrict access to publicly accessible network jacks.

2 Physical Security Policy Appropriate physical controls to ensure that the POI devices cannot be physically altered, perimeter devices are properly protected should be in place. Physical controls also apply to protection of paper media containing cardholder data.

9.1.3 Verify that physical access to wireless access points, gateways, handheld devices, networking/communications hardware, and telecommunication lines is appropriately restricted.


9.2 Develop procedures to easily distinguish between onsite personnel and visitors, to include:

• Identifying new onsite personnel or visitors (for example, assigning badges). • Changes to access requirements.

Revoking or terminating onsite personnel and expired visitor identification (such as ID badges).

9.2.a Review documented processes to verify that procedures are defined for identifying and distinguishing between onsite personnel and visitors.

Verify procedures include the following:

2 Physical Security Policy

Cardholder data will not be accessible within the merchant environment; therefore, the applicability of this requirement can be greatly reduced; however, controls should ensure that unauthorized visitors cannot




Justification

• Identifying new onsite personnel or visitors (for example, assigning badges),

• Changing access requirements, and • Revoking terminated onsite personnel

and expired visitor identification (such as ID badges)

access perimeter systems or POI devices.

9.2.b Observe processes for identifying and distinguishing between onsite personnel and visitors to verify that:

• Visitors are clearly identified, 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 applicability of this requirement can be greatly reduced; however, controls should ensure that unauthorized visitors cannot access perimeter systems or POI devices.

9.2.c Verify that access to the identification process (such as a badge system) is limited to authorized personnel.


9.2.d Examine identification methods (such as ID badges) in use to verify that they clearly identify visitors and it is easy to distinguish between onsite personnel and visitors.


9.3 Control physical access for onsite personnel to the sensitive areas as follows:

• Access must be authorized and based on individual job function. • Access is revoked immediately upon termination, and all physical access mechanisms, such as keys, access cards, etc.,

are returned or disabled.

9.3.a For a sample of onsite personnel with physical access to the CDE, interview


Cardholder data will not be accessible within the merchant environment; therefore, the applicability of this requirement




Justification

responsible personnel and observe access control lists to verify that:

• Access to the CDE is authorized. • Access is required for the

individual’s job function.

can be greatly reduced; however, controls should ensure that unauthorized users cannot access perimeter systems or POI devices.

9.3.b Observe personnel access the CDE to verify that all personnel are authorized before being granted access.


Cardholder data will not be accessible within the merchant environment; therefore, the applicability of this requirement can be greatly reduced; however, controls should ensure that unauthorized users cannot access perimeter systems or POI devices.

9.3.c Select a sample of recently terminated employees and review access control lists to verify the personnel do not have physical access to the CDE.


Cardholder data will not be accessible within the merchant environment; therefore, the applicability of this requirement can be greatly reduced; however, controls should ensure that unauthorized users cannot access perimeter systems or POI devices.

9.4 Verify that visitor authorization and access controls are in place as follows:

9.4.1.a Observe procedures and interview personnel to verify that visitors must be authorized before they are granted access to, and escorted at all times within, areas where cardholder data is processed or maintained.


9.4.1.b Observe the use of visitor badges or other identification to verify that a physical token badge does not permit unescorted access to physical areas where cardholder data is processed or maintained.





Justification

9.4.2.a Observe people within the facility to verify the use of visitor badges or other identification, and that visitors are easily distinguishable from onsite personnel.


9.4.2.b Verify that visitor badges or other identification expire.


9.4.3 Observe visitors leaving the facility to verify visitors are asked to surrender their badge or other identification upon departure or expiration.


9.4.4.a Verify that a visitor log is in use to record physical access to the facility as well as computer rooms and data centers where cardholder data is stored or transmitted.


9.4.4.b Verify that the log contains: • The visitor’s name, • The firm represented, and • The onsite personnel authorizing

physical access.

2 Physical Security Policy Cardholder data will not be accessible within the merchant environment; therefore, the applicability of this requirement can be greatly reduced; however, controls should ensure that unauthorized visitors cannot




Justification

access perimeter systems or POI devices.

9.4.4.c Verify that the log is retained for at least three months.


9.5 Physically secure all media.

9.5 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).


Data Retention and Storage Policies (if applicable)


9.5.1.a Observe the storage location’s physical security to confirm that backup media storage is secure.




9.5.1.b Verify that the storage location security is reviewed at least annually.




9.6 Maintain strict control over the internal or external distribution of any kind of media, including the following:

9.6 Verify that a policy exists to control distribution of media, and that the policy covers all distributed media including that distributed to individuals.






Justification

9.6.1 Verify that all media is classified so the sensitivity of the data can be determined.



9.6.2.a Interview personnel and examine records to verify that all media sent outside the facility is logged and sent via secured courier or other delivery method that can be tracked.



9.6.2.b Select a recent sample of several days of offsite tracking logs for all media, and verify tracking details are documented.



9.6.3 Select a recent sample of several days of offsite tracking logs for all media. From examination of the logs and interviews with responsible personnel, verify proper management authorization is obtained whenever media is moved from a secured area (including when media is distributed to individuals).



9.7 Maintain strict control over the storage and accessibility of media.

9.7 Obtain and examine the policy for controlling storage and maintenance of all media and verify that the policy requires periodic media inventories.



9.7.1 Review media inventory logs to verify that logs are maintained and media inventories are performed at least annually.


If the merchant has any paper based processes associated with this payment channel then this requirement will still apply to their environment. Otherwise,




Justification

this requirement can be considered not applicable.

9.8 Destroy media when it is no longer needed for business or legal reasons as follows:

9.8 Examine the periodic media destruction policy and verify that it covers all media and defines requirements for the following: • Hard-copy materials must be crosscut

shredded, incinerated, or pulped such that there is reasonable assurance the hard-copy materials cannot be reconstructed.

• Storage containers used for materials that are to be destroyed must be secured.

• Cardholder data on electronic media must be rendered unrecoverable via a secure wipe program (in accordance with industry-accepted standards for secure deletion), or by physically destroying the media.



9.8.1.a Interview personnel and examine procedures to verify that hard-copy materials are crosscut shredded, incinerated, or pulped such that there is reasonable assurance the hard-copy materials cannot be reconstructed.



9.8.1.b Examine storage containers used for materials that contain information to be destroyed to verify that the containers are secured.



9.8.2 Verify that cardholder data on electronic media is rendered unrecoverable via a secure wipe program in accordance with industry-accepted standards for secure deletion, or otherwise physically destroying the media).

1 Not Applicable There will be no electronic instances of cardholder data storage within the merchant environment.




Justification

9.9 Protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution. Note: These requirements apply to card-reading devices used in card-present transactions (that is, card swipe or dip) at the point of sale. This requirement is not intended to apply to manual key-entry components such as computer keyboards and POS keypads. Note: Requirement 9.9 is a best practice until June 30, 2015, after which it becomes a requirement.

9.9 Examine documented policies and procedures to verify they include: • Maintaining a list of devices • Periodically inspecting devices to look

for tampering or substitution • Training personnel to be aware of

suspicious behavior and to report tampering or substitution of devices.

4 Device Protection policies and procedures

This requirement is fully in-scope for the merchant’s PCI-DSS assessment.

9.9.1 Maintain an up-to-date list of devices. The list should include the following: • Make, model of device. • Location of device (for example, the address of the site or facility where the device is located). • Device serial number or other method of unique identification.

9.9.1.a Examine the list of devices to verify it includes: • Make, model of device • Location of device (for example, the

address of the site or facility where the device is located)

• Device serial number or other method of unique identification.



9.9.1.b Select a sample of devices from the list and observe device locations to verify that the list is accurate and up to date.



9.9.1.c Interview personnel to verify the list of devices is updated when devices are added, relocated, decommissioned, etc.



9.9.2 Periodically inspect device surfaces to detect tampering (for example, addition of card skimmers to devices), or substitution (for example, by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device).

9.9.2.a Examine documented procedures to verify processes are defined to include the following: • Procedures for inspecting devices • Frequency of inspections.



9.9.2.b Interview responsible personnel and observe inspection processes to verify: • Personnel are aware of procedures for

inspecting devices.






Justification

• All devices are periodically inspected for evidence of tampering and substitution.

9.9.3 Provide training for personnel to be aware of attempted tampering or replacement of devices. Training should include the following: • Verify the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them

access to modify or troubleshoot devices. • Do not install, replace, or return devices without verification. • Be aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open

devices). Report suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).

9.9.3.a Review training materials for personnel at point-of-sale locations to verify they include training in the following: • Verifying the identity of any third-

party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices

• Not to install, replace, or return devices without verification

• Being aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices)

• Reporting suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).



9.9.3.b Interview a sample of personnel at point-of-sale locations to verify they have received training and are aware of the procedures for the following: • Verifying the identity of any third-

party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices

• Not to install, replace, or return devices without verification

• Being aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices)

• Reporting suspicious behavior and indications of device tampering or substitution to appropriate personnel






Justification

(for example, to a manager or security officer).

9.10 Ensure that security policies and operational procedures for restricting physical access to cardholder data are documented, in use, and known to all affected parties.

9.10 Examine documentation and interview personnel to verify that security policies and operational procedures for restricting physical access to cardholder data are: • Documented, • In use, and • Known to all affected parties.



Device Protection policies and procedures


10.1 Implement audit trails to link all access to system components to each individual user.

10.1 Verify, through observation and interviewing the system administrator, that: • Audit trails are enabled and active for

system components. • Access to system components is linked

to individual users.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Merchant has no access to cardholder data, thus implementation of audit trails requirements would not be applicable.

10.2 Through interviews of responsible personnel, observation of audit logs, and examination of audit log settings, perform the following: 10.2.1 Verify all individual access to cardholder data is logged.

1 Not Applicable. Merchant access to cardholder will not be possible with the proper implementation of the VTP solution.

10.2.2 Verify all actions taken by any individual with root or administrative privileges are logged.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Merchant has no access to cardholder data, thus implementation of audit trails




Justification

requirements would not be applicable.

10.2.3 Verify access to all audit trails is logged.


10.2.4 Verify invalid logical access attempts are logged.


10.2.5.a Verify use of identification and authentication mechanisms is logged.


10.2.5.b Verify all elevation of privileges is logged.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Merchant has no access to cardholder data, thus implementation of audit trails




Justification

requirements would not be applicable.

10.2.5.c Verify all changes, additions, or deletions to any account with root or administrative privileges are logged.


10.2.6 Verify the following are logged: • Initialization of audit logs • Stopping or pausing of audit logs.


10.2.7 Verify creation and deletion of system level objects are logged.


10.3 Record at least the following audit trail entries for all system components for each event:

10.3.1 Verify user identification is included in log entries.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Merchant has no access to




Justification

cardholder data, thus implementation of audit trails requirements would not be applicable.

10.3.2 Verify type of event is included in log entries.


10.3.3 Verify date and time stamp is included in log entries.


10.3.4 Verify success or failure indication is included in log entries.


10.3.5 Verify origination of event is included in log entries.





Justification

Merchant has no access to cardholder data, thus implementation of audit trails requirements would not be applicable.

10.3.6 Verify identity or name of affected data, system component, or resources is included in log entries.


10.4 Examine configuration standards and processes to verify that time-synchronization technology is implemented and kept current per PCI DSS Requirements 6.1 and 6.2.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Time-synchronization standards and requirements would not be applicable.

10.4.1.a Examine the process for acquiring, distributing and storing the correct time within the organization to verify that: • Only the designated central time

server(s) receives time signals from external sources, and time signals from external sources are based on International Atomic Time or UTC.

• Where there is more than one designated time server, the time servers peer with one another to keep accurate time,

• Systems receive time information only from designated central time server(s).





Justification

10.4.1.b Observe the time-related system-parameter settings for a sample of system components to verify: • Only the designated central time

server(s) receives time signals from external sources, and time signals from external sources are based on International Atomic Time or UTC.

• Where there is more than one designated time server, the designated central time server(s) peer with one another to keep accurate time.

• Systems receive time only from designated central time server(s).


10.4.2.a Examine system configurations and time-synchronization settings to verify that access to time data is restricted to only personnel with a business need to access time data.


10.4.2.b Examine system configurations, time synchronization settings and logs, and processes to verify that any changes to time settings on critical systems are logged, monitored, and reviewed.


10.4.3 Examine systems configurations to verify that the time server(s) accept time updates from specific, industry-accepted 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).


10.5 Secure audit trails so they cannot be altered.




Justification

10.5 Interview system administrators and examine system configurations and permissions to verify that audit trails are secured so that they cannot be altered as follows

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Merchant has no access to cardholder data, thus implementation of audit trails along with security of audit trail requirements would not be applicable.

10.5.1 Only individuals who have a job-related need can view audit trail files.


10.5.2 Current audit trail files are protected from unauthorized modifications via access control mechanisms, physical segregation, and/or network segregation.


10.5.3 Current audit trail files are promptly backed up to a centralized log server or media that is difficult to alter.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Merchant has no access to cardholder data, thus




Justification

implementation of audit trails along with security of audit trail requirements would not be applicable.

10.5.4 Logs for external-facing technologies (for example, wireless, firewalls, DNS, mail) are written onto a secure, centralized, internal log server or media.


10.5.5 Examine system settings, monitored files, and results from monitoring activities to verify the use of file-integrity monitoring or change-detection software on logs.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). File-integrity monitoring or change-detection requirements will not be applicable.

10.6 Review logs and security events for all system components to identify anomalies or suspicious activity. Perform the following: 10.6.1.a Examine security policies and procedures to verify that procedures are defined for reviewing the following at least daily, either manually or via log tools: • All security events • Logs of all system components that

store, process, or transmit CHD and/or SAD, or that could impact the security of CHD and/or SAD

• Logs of all critical system components • Logs of all servers and system

components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.)

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Merchant has no access to cardholder data, thus procedures related to implementation of audit trails and security events would not be applicable.




Justification

10.6.1.b Observe processes and interview personnel to verify that the following are reviewed at least daily: • All security events • Logs of all system components that

store, process, or transmit CHD and/or SAD, or that could impact the security of CHD and/or SAD

• Logs of all critical system components • Logs of all servers and system

components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.).

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Merchant has no access to cardholder data, thus procedures related to implementation of audit trails and security events would not be applicable.

10.6.2 Review logs of all other system components periodically based on the organization’s policies and risk management strategy, as determined by the organization’s annual risk assessment. 10.6.2.a Examine security policies and procedures to verify that procedures are defined for reviewing logs of all other system components periodically—either manually or via log tools—based on the organization’s policies and risk management strategy.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Merchant has no access to cardholder data, thus procedures related to logging and security events would not be applicable.

10.6.2.b Examine the organization’s risk-assessment documentation and interview personnel to verify that reviews are performed in accordance with organization’s policies and risk management strategy.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Merchant has no access to cardholder data, thus procedures related to logging and security events would not be applicable.

10.6.3 Follow up exceptions and anomalies identified during the review process.

10.6.3.a Examine security policies and procedures to verify that procedures are defined for following up on exceptions and anomalies identified during the review process.





Justification

Security policies and procedures for log review processes will not be applicable.

10.6.3.b Observe processes and interview personnel to verify that follow-up to exceptions and anomalies is performed.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Security policies and procedures for log review processes will not be applicable.

10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from backup).

10.7.a Examine security policies and procedures to verify that they define the following: • Audit log retention policies • Procedures for retaining audit logs for

at least one year, with a minimum of three months immediately available online.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network (outside of the POI devices). Audit log retention policies and procedures will not be applicable.

10.7.b Interview personnel and examine audit logs to verify that audit logs are available for at least one year.


10.7.c Interview personnel and observe processes to verify that at least the last three months’ logs can be immediately restored for analysis.


10.8 Ensure that security policies and operational procedures for monitoring all access to network resources and cardholder data are documented, in use, and known to all affected parties.




Justification

10.8 Examine documentation interview personnel to verify that security policies and operational procedures for monitoring all access to network resources and cardholder data are: • Documented, • In use, and • Known to all affected parties.

1 Not Applicable Merchant will have no access to cardholder data, thus security policies and operational procedures for monitoring all access to network resources and cardholder data would not be applicable.

11.1 Implement processes to test for the presence of wireless access points (802.11), and detect and identify all authorized and unauthorized wireless access points on a quarterly basis. Note: Methods that may be used in the process include but are not limited to wireless network scans, physical/logical inspections of system components and infrastructure, network access control (NAC), or wireless IDS/IPS. Whichever methods are used, they must be sufficient to detect and identify both authorized and unauthorized devices.

11.1.a Examine policies and procedures to verify processes are defined for detection and identification of both authorized and unauthorized wireless access points on a quarterly basis.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network. Policies and procedures for wireless access point detection and identification will not be applicable.

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

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network. Policies and procedures for wireless access point detection and identification will not be in applicable.

11.1.c Examine output from recent wireless scans to verify that: • Authorized and unauthorized wireless

access points are identified, and • The scan is performed at least

quarterly for all system components and facilities.





Justification

11.1.d If automated monitoring is utilized (for example, wireless IDS/IPS, NAC, etc.), verify the configuration will generate alerts to notify personnel.


11.1.1 Examine documented records to verify that an inventory of authorized wireless access points is maintained and a business justification is documented for all authorized wireless access points.


11.1.2.a Examine the organization’s incident response plan (Requirement 12.10) to verify it defines and requires a response in the event that an unauthorized wireless access point is detected.


11.1.2.b Interview responsible personnel and/or inspect recent wireless scans and related responses to verify action is taken when unauthorized wireless access points are found.


11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).Verify that internal and external vulnerability scans are performed as follows:

11.2.1 Perform quarterly internal vulnerability scans, and rescans as needed, until all “high-risk” vulnerabilities (as identified in Requirement 6.1) are resolved. Scans must be performed by qualified personnel.




Justification

11.2.1.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.

11.2.1.b Review the scan reports and verify that the scan process includes rescans until all “high-risk” vulnerabilities as defined in PCI DSS Requirement 6.1 are resolved.



11.2.1.c Interview personnel to verify 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).



11.2.2.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.




Justification

11.2.2.b Review the results of each quarterly scan and rescan to verify that the ASV Program Guide requirements for a passing scan have been met (for example, no vulnerabilities rated 4.0 or higher by the CVSS, and no automatic failures).



11.2.2.c Review the scan reports to verify that the scans were completed by a PCI SSC Approved Scanning Vendor (ASV).



11.2.3.a Inspect and correlate 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.

11.2.3.b Review scan reports and verify that the scan process includes rescans until:

• For external scans, no vulnerabilities exist that are scored 4.0 or higher by the CVSS.

• For internal scans, all “high-risk” vulnerabilities as defined in PCI DSS Requirement 6.1 are resolved.






Justification

11.2.3.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).



11.3 Penetration Testing

Note: The update to Requirement 11.3 is a best practice until June 30, 2015, after which it becomes a requirement. PCI DSS v2.0 requirements for penetration testing must be followed until v3.0 is in place.

11.3 Examine penetration-testing methodology and interview responsible personnel to verify a methodology is implemented that includes the following: • Is based on industry-accepted

penetration testing approaches (for example, NIST SP800-115)

• Includes coverage for the entire CDE perimeter and critical systems

• Testing from both inside and outside the network

• Includes testing to validate any segmentation and scope-reduction controls

• Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5

• Defines network-layer penetration tests to include components that support network functions as well as operating systems

• Includes review and consideration of threats and vulnerabilities experienced in the last 12 months

• Specifies retention of penetration testing results and remediation activities results.


As such, there are no applicable penetration testing requirements.




Justification

11.3.1.a Examine the scope of work and results from the most recent external penetration test to verify that penetration testing is performed as follows:

• Per the defined methodology • At least annually • After any significant changes to

the environment.



11.3.1.b 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).



11.3.2.a Examine the scope of work and results from the most recent internal penetration test to verify that penetration testing is performed at least annually and after any significant changes to the environment.

• Per the defined methodology • At least annually • After any significant changes to the

environment



11.3.2.b 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).






Justification

11.3.3 Examine penetration testing results to verify that noted exploitable vulnerabilities were corrected and that repeated testing confirmed the vulnerability was corrected.



11.3.4 If segmentation is used to isolate the CDE from other networks, perform penetration tests at least annually and after any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective, and isolate all out-of-scope systems from in-scope systems.

11.3.4.a Examine segmentation controls and review penetration-testing methodology to verify that penetration-testing procedures are defined to test all segmentation methods to confirm they are operational and effective, and isolate all out-of-scope systems from in-scope systems.



11.3.4.b Examine the results from the most recent penetration test to verify that penetration testing to verify segmentation controls: • Is performed at least annually and

after any changes to segmentation controls/methods.

• Covers all segmentation controls/methods in use.

• Verifies that segmentation methods are operational and effective, and isolate all out-of-scope systems from in-scope systems.



11.4 Use intrusion-detection systems and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment, and alert personnel to suspected compromises. Keep all intrusion-detection and prevention engines, baselines, and signatures up-to-date.

11.4.a Examine system configurations and network diagrams to verify that techniques (such as intrusion-detection systems and/or intrusion-prevention systems) are in place to monitor all traffic: • At the perimeter of the cardholder

data environment

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network. Intrusion-detection and/or intrusion prevention




Justification

• At critical points in the cardholder data environment.

requirements will be not applicable.

11.4.b Examine system configurations and interview responsible personnel to confirm intrusion-detection and/or intrusion-prevention techniques alert personnel of suspected compromises.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network. Intrusion-detection and/or intrusion prevention requirements will be not applicable.

11.4.c Examine IDS/IPS configurations and vendor documentation to verify intrusion-detection and/or intrusion-prevention techniques are configured, maintained, and updated per vendor instructions to ensure optimal protection.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network. Intrusion-detection and/or intrusion prevention requirements will be not applicable.

11.5 Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.

11.5.a Verify the use of file-integrity 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 • Additional critical files determined by

entity (for example, through risk assessment or other means).


11.5.b Verify the mechanism is configured to alert personnel to unauthorized modification of critical files, and to perform critical file comparisons at least weekly.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for all system components located on the merchant’s host network




Justification

(outside of the POI devices). File-integrity monitoring or change-detection requirements will not be applicable.

11.5.1 Interview personnel to verify that all alerts are investigated and resolved.


11.6 Ensure that security policies and operational procedures for security monitoring and testing are documented, in use, and known to all affected parties.

11.6 Examine documentation interview personnel to verify that security policies and operational procedures for security monitoring and testing are:


1 Not Applicable Merchant will have no access to cardholder data, thus security policies and operational procedures for security monitoring and testing would not be applicable.

12.1 Establish, publish, maintain, and disseminate a security policy.

12.1 Examine the information security policy and verify that the policy is published and disseminated to all relevant personnel (including vendors and business partners).

4 Information Security Policy


12.1.1 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.



12.2.a Verify that an annual risk-assessment process is documented that identifies assets, threats, vulnerabilities, and results in a formal risk assessment.


Annual Risk Assessment


12.2.b Review risk-assessment documentation to verify that the risk-assessment process is performed at least annually and upon significant changes to the environment.


Annual Risk Assessment





Justification

12.3 Examine the usage policies for critical technologies and interview responsible personnel to verify the following policies are implemented and followed:

12.3.1 Verify that the usage policies include processes for 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.

12.3.2 Verify that the usage policies include processes for all technology use to be authenticated with user ID and password or other authentication item (for example, token).


12.3.3 Verify that the usage policies define a list of all devices and personnel authorized to use the devices.


12.3.4 Verify that the usage policies define a method to accurately and readily determine owner, contact information, and purpose (for example, labeling, coding, and/or inventorying of devices).


12.3.5 Verify that the usage policies require acceptable uses for the technology.


12.3.6 Verify that the usage policies require acceptable network locations for the technology.


12.3.7 Verify that the usage policies require a list of company-approved products.


12.3.8.a Verify that the usage policies require automatic disconnect of sessions for remote-access technologies after a specific period of inactivity.


12.3.8.b Examine configurations for remote access technologies to verify that remote access sessions will be automatically disconnected after a specific period of inactivity.





Justification

12.3.9 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.


12.3.10.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.

1 Not Applicable Cardholder data will not be accessible within the merchant environment.

12.3.10.b For personnel with proper authorization, verify that usage policies require the protection of cardholder data in accordance with PCI DSS Requirements.

1 Not Applicable Cardholder data will not be accessible within the merchant environment.

12.4.a Verify that information security policies clearly define information security responsibilities for all personnel.



12.4.b Interview a sample of responsible personnel to verify they understand the security policies.

4 Incident Response Plan (IRP)


12.5 Examine information security policies and procedures to verify: • The formal assignment of information

security to a Chief Security Officer or other security-knowledgeable member of management.

• The following information security responsibilities are specifically and formally assigned:



12.5.1 Verify that responsibility for establishing, documenting and distributing security policies and procedures is formally assigned.






Justification

12.5.2 Verify that responsibility for monitoring and analyzing security alerts and distributing information to appropriate information security and business unit management personnel is formally assigned.



12.5.3 Verify that responsibility for establishing, documenting, and distributing security incident response and escalation procedures is formally assigned.



12.5.4 Verify that responsibility for administering (adding, deleting, and modifying) user account and authentication management is formally assigned.



12.5.5 Verify that responsibility for monitoring and controlling all access to data is formally assigned.



12.6.a Review the security awareness program to verify it provides awareness to all personnel about the importance of cardholder data security.


Security Awareness Policy/Program


12.6.b Examine security awareness program procedures and documentation and perform the following:

4 Security Awareness Policy/Program


12.6.1.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).



12.6.1.b Verify that personnel attend awareness training upon hire and at least annually.



12.6.1.c Interview a sample of personnel to verify they have completed awareness training and are aware of the importance of cardholder data security.






Justification

12.6.2 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.



12.7 Inquire with Human Resource department management and verify that background checks are conducted (within the constraints of local laws) prior to hire on potential personnel who will have access to cardholder data or the cardholder data environment.



12.8 Through observation, review of policies and procedures, and review of supporting documentation, verify that processes are implemented to manage service providers with whom cardholder data is shared, or that could affect the security of cardholder data (for example, backup tape storage facilities, managed service providers such as web-hosting companies or security service providers, those that receive data for fraud modeling purposes, etc.), as follows:

12.8.1 Verify that a list of service providers is maintained.



12.8.2 Observe written agreements and confirm they include an acknowledgement by service providers that they are responsible for the security of cardholder data the service providers possess or otherwise store, process or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.



12.8.3 Verify that policies and procedures are documented and implemented including proper due diligence prior to engaging any service provider.



12.8.4 Verify that the entity maintains a program to monitor its service providers’ PCI DSS compliance status at least annually.






Justification

12.8.5 Verify the entity maintains information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.



12.9 Additional testing procedure for service providers: Review service provider’s policies and procedures and observe written agreement templates to confirm the service provider acknowledges in writing to customers that the service provider will maintain all applicable PCI DSS requirements to the extent the service provider handles, has access to, or otherwise stores, processes or transmits the customer’s cardholder data or sensitive authentication data, or manages the customer's cardholder data environment on behalf of a customer.


12.10 Examine the incident response plan and related procedures to verify entity is prepared to respond immediately to a system breach by performing the following:

12.10.1.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 backup 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 for all critical system components

• Reference or inclusion of incident response procedures from the payment brands.



12.10.1.b Interview personnel and review documentation from a sample of previously reported incidents or alerts to verify that the documented incident response plan and procedures were followed.






Justification

12.10.2 Verify that the plan is tested at least annually.



12.10.3 Verify through observation, review of policies, and interviews of responsible personnel 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.



12.10.4 Verify through observation, review of policies, and interviews of responsible personnel that staff with responsibilities for security breach response are periodically trained.



12.10.5 Verify through observation and review of processes that monitoring and responding to alerts from security monitoring systems, including detection of unauthorized wireless access points, are covered in the incident response plan.



12.10.6 Verify through observation, review of policies, and interviews of responsible personnel that there is a process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments.




VeriFone VeriShield PCI Assessment...

Documents

Transcript of VeriFone VeriShield PCI Assessment...