First Data Transarmor Verifone Edition Technical Assessment White Paper

First Data TransArmor VeriFone Edition Technical Assessment White Paper

Prepared for:

March, 2016

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 ...... 11 DEPLOYMENT SCENARIOS ...... 11 PCI DSS CONTROL REDUCTION SUMMARY ...... 12 SUMMARY CHART OF MERCHANT PCI DSS CONTROL REDUCTION ...... 12 DETAILED PCI DSS CONTROL REDUCTION ...... 13 TECHNICAL ASSESSMENT ...... 13

SCOPE OF ASSESSMENT ...... 13 TRANSARMOR VERIFONE EDITION ENCRYPTION ASSESSMENT ...... 18 KEY LOADING AND DISTRIBUTION ...... 19 APPENDIX A: PCI DSS CONTROL REDUCTION RISK MAPPINGS ...... 25

DETAILED PCI DSS CONTROL REDUCTION ...... 25

Executive Summary

Overview First Data 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 First Data TransArmor VeriFone Edition (TAVE) PCI DSS 3.1 whitepaper reflecting the current standards. Coalfire conducted an independent technical assessment of the TransArmor VeriFone Edition (TAVE), 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 July 2013. This paper reflects the revised whitepaper addressing First Data TAVE and how it aligns to current PCI-DSS v3.1 standards.

In this paper, Coalfire will describe how the TransArmor VeriFone Edition security solution can dramtically reduce the current risk of payment card data compromise within a merchant’s retail environment and can minimize PCI DSS validation when properly deployed. This reduction in validation effort will be based on evaluating the risk of each of the PCI DSS 3.1 requirements and how the TAVE security solution applies to each control within the context of the current PCI P2PE standards released in 2015. The focus of this paper is to clarify how a merchant can benefit from TAVE even though it is not yet a formally listed solution. The conclusions from this paper are provided as guidance to First Data so that they can make a risk based decision for the reduction of a merchant’s scope when properly using TAVE.

About TransArmor VeriFone Edition TransArmor VeriFone Edition 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 in First Data’s secure data center. TAVE combines VeriFone’s encryption methodology, VeriFone Total Protect (VTP) and Format Preserving Encryption (FPE), along with First Data’s TransArmor tokenization technology.

The goals of the TransArmor VeriFone Edition solution are: 1. Reduce the risk of compromise to cardholder data throughout the entire transaction process, from point of entry through authorization and settlement. 2. Minimize the number of applicable controls that merchants must address for compliance to the Payment Card Industry (PCI) Data Security Standard (DSS). 3. Simplify and reduce costs associated for merchants with validation of PCI DSS compliance efforts.

TAVE helps shift the burden of protecting payment card data from the merchant to First Data using the latest encryption and tokenization technologies. This solution:  Combines encryption and tokenization to protect cardholder data at every processing stage.  Maintains all the merchant’s business benefits of storing the payment cardholder data without the associated risk.  Compliments Card Authentication technologies like EMV.

TAVE includes these high level components:

1. Merchant Point of Interaction (POI) – A VeriFone device encrypting cardholder data in hardware as it is collected. 2. First Data Switch – This includes First Data’s Front End Authorization Platform (FEP) and Secure Transaction Management (STM) handler for routing and processing capabilities. This is hosted by First Data in a PCI DSS compliant facility. 3. First Data Decryption and Tokenization – This includes the Hardware Security Module (HSM), VeriShield Decryption Service (VSD) and TransArmor (TA) for tokenization. This is again hosted by First Data in a PCI DSS compliant facility.

This assessment included the above components in PCI compliant testing labs and focused on First Data’s implementation of VeriFone’s VTP encryption methodology, paired with TransArmor tokenization, to provide a secure encryption solution for merchants.

Audience This assessment report has three potential audiences. This report is addressed primarily to the first group, merchants, but can be used by others as well.

1. Merchants: This audience is evaluating the First Data TransArmor VeriFone Edition security solution for deployment in their payment card environment. Merchants will be able to clearly understand what benefits they can receive from using TAVE in their environment, including risk and the reduction of applicable controls. 2. QSAs and the Internal Audit Community: This audience may be evaluating the First Data TransArmor VeriFone Edition security solution to determine the impact on PCI DSS validation on behalf of their merchant. 3. First Data and Partners: The final target audience is the product and engineering teams of First Data 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 reviewed information 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.

Although tokenization is part of the TAVE solution, this assessment focuses solely on how TAVE uses encryption and decryption technologies. The reader should gain an understanding on how TAVE can be leveraged in the context of PCI DSS v3.1 and the current PCI P2PE standards. Tokenization is relevant to

protecting and reducing PCI DSS validation post-authorization for data at rest. For additional information regarding the value of Tokenization, please review the link below: http://www.firstdata.com/downloads/thought-leadership/Value-of-Tokens-WP.pdf

This First Data paper leverages the testing performed for 2013 FD TAVE assessment and provides an update to the 2013 FD TAVE whitepaper to reflect the current PCI DSS 3.1 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 Lab located in Louisville, Colorado and the First Data Lab in Omaha Nebraska. This included interviews, documentation review, transaction testing, encryption evaluation and forensic analysis.

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 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 1.1 standard detailing what controls must be in place for a merchant to have a validated, listed P2PE solution. That P2PE standard was updated to 2.0 in 2015. This program works best for level four 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 will affect their PCI DSS compliance requirements. This assessment can be used by merchants using the TAVE solution to understand what reduction of applicable controls is possible.

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 Coalfire evaluated and tested the complete TransArmor VeriFone Edition 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.

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.

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 TransArmor VeriFone Edition solution can provide for merchants.

Summary Findings The following are highlights of Coalfire’s technical evaluation:

 A properly deployed TransArmor VeriFone Edition solution can provide significant risk reduction of data compromise and is one of the most effective data security controls available to merchants today.  TAVE utilizes VeriFone’s encryption in a secure manner that enables TAVE to provide the key benefits of using encryption to reduce a significant portion of PCI DSS controls remaining for a merchant to manage on a consistent basis.  Minimizing then number of points where data is decrypted and then re-encrypted for another hop, and the number of points where clear text cardholder data exists is a clear security benefit. In deployments of TAVE that go directly from the merchant to the acquirer, there is additional risk reduction because there is no gateway or other middle man that then has unencrypted cardholder data, even for a brief time.  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.  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 at the POI in a TransArmor VeriFone Edition TRSM (Tamper Resistant Security Module), the merchant is not capable of decrypting captured data, and decryption keys do not exist within their environment.  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 First Data recommend the use of a device with PTS 2.x with SRED or 3.x with SRED (Secure Reading and Exchange of Data) enabled.

Assessor Comments Our assessment scope put a significant focus on validating the PCI DSS compliance control reduction impact of the TransArmor VeriFone Edition solution. The TAVE solution can significantly reduce the risk of payment card data compromise for a merchant’s retail environment. There can be very clear and dramatic reduction of PCI DSS validation with a properly deployed solution. However, ignoring the PCI

DSS and security best practices, even if a merchant is out of scope for PCI DSS compliance validation, can introduce many other security or business continuity risks. Security and business risk mitigation should be any merchant’s goal and focus for selecting security controls. The TransArmor VeriFone Edition 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 release of the current PCI P2PE standard, merchants have an increased expectation to receive a more secure environment that utilizes the latest encryption technologies. First Data’s TransArmor VeriFone Edition offering provides such an environment for several different types of merchants in light of a P2PE standard that may not fit every merchant.

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 (SSC) released the P2PE 1.1 standard. In 2015, the PCI SSC updated the standard to 2.0. These standards 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.1 are the reference points used for all comments and conclusions in this assessment. Additionally, PCI has updated some relevant FAQs:

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. https://www.pcisecuritystandards.org/documents/P2PE_v1_1_FAQs_Aug2012.pdf

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 Copyright 2016, Coalfire Systems Inc. Page | 8

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?

https://www.pcisecuritystandards.org/documents/P2PE_Technical_FAQs_1x.pdf

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 First Data TransArmor VeriFone Edition 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 solutions:

 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 QSAs 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 TransArmor VeriFone Edition to reduce PCI DSS controls that are applicable.

Deployment Scenarios The TransArmor VeriFone Edition solution can be used by many different types of merchants. The primary deployment difference will be which POI options a merchant needs.

Regardless of which POI devices are used, there are still several deployment assumptions that are required to achieve the most 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 a VeriFone PTS 3.x with SRED validated payment device.  Payment applications and registers disable or procedurally restrict card swipe or card entry outside of the TransArmor VeriFone Edition payment device.  No decryption capabilities of card data encrypted with TransArmor VeriFone Edition are accessible to the merchant.  The merchant does not possess or have access to decryption keys in their retail or corporate environments.  Chargeback and other customer support and payment research processes do not include or require access to the full primary account number. Most merchants will use First Data’s TransArmor tokenization solution to remove card data from these processes.  Public facing web applications for e-commerce or other payment transactional systems not using the TransArmor VeriFone Edition solution must be addressed with your QSA to determine PCI DSS requirements.

PCI DSS Control Reduction Summary The following summary chart provides a view of the impact to PCI DSS control requirements for a merchant’s retail environment assuming TAVE has been properly implemented. Merchant environments can differ and it is important to work with your QSA to validate appropriate PCI DSS control reduction before making assumptions on scope reduction.

If a merchant has deployed TAVE 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 TAVE payment channel only. All recommended risk reductions are based on the assumption that a QSA has fully validated that TAVE has been properly implemented in the merchant’s environment.

Summary Chart of Merchant PCI DSS Control Reduction PCI DSS Major Control Moderate Control Minor/No Control Area Reduction Reduction Reduction

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 TAVE. This risk-based guidance indicates Coalfire’s recommended reduction of applicable PCI-DSS controls for merchants that have compliantly implemented TAVE. Scroll down to Appendix A to review the detailed PCI DSS risk guidance.

Technical Assessment

Scope of Assessment First Data TransArmor VeriFone Edition was assessed for compliance relative to current PCI DSS 3.1 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 and approval messages returned back to the merchant a. Merchant transactions were simulated using known clear cardholder data b. Encrypted cardholder data was observed through the First Data Front End and STM handlers. c. Point-of-Decryption was a VeriShield Decryption Service (“VSD”) Test System hosted by First Data. d. Return messages were validated to contain no cardholder data. 2. Review of the integration of VTP for: a. Use of robust key management including remote key management via VKM b. Key-length and Cryptographic Standards 3. PCI DSS reduction of applicable controls based on the encryption used at the POI

Figure 1: Network Diagram The diagram below illustrates the network layout used to validate TransArmor VeriFone Edition.

Figure 2: Dataflow Diagram The diagram below illustrates the dataflow reviewed to validate TransArmor VeriFone Edition.

Step (1): Pin Pad applies VSP format preserving encryption.

Step (2): POS Register routes transaction to a Store Controller or Electronic Funds Transfer (EFT) Switch or combination of the two. • The TransArmor Security Packet Field (SP <>) gets appended to the Auth Message Spec in Step 2. • This is a dynamic field; the Encrypted Track/PAN must be extracted from the Auth request and inserted into the SP <>.

NOTE: For Steps 3-8: The transport layer is not encrypted, the TCP/IP protocol is used.

Step (3): (Store Controller to Front End) EFT switch routes Auth request to a First Data (FD) Front End Authorization Platform (FEP). • If SP<> is present, Front End will route the SP <> to the STM Handler for processing. • Card data (Track 1, Track 2, or PAN for manually keyed transactions) or Token • Card data is encrypted with VeriFone format preserving proprietary algorithm; Token is in the clear

Step (4): (Front End to STM Handler) Private card data contained in the encrypted data block is sent to the STM Handler to be decrypted and tokenized. • Front End extracts MID/TID from the Auth Message spec and builds SP message for the STM Handler. • Only the SP<> field is routed to the STM Handler. • The STM Handler interrogates the “Encryption Type” in the SP<> to determine if it is RSA Encrypted transaction or a VSP encrypted transaction. • If RSA Encrypted – follow [Existing Process] and go to step (6) in diagram. • If VSP, go to Step 5A below. • Card data (Track 1, Track 2, or PAN for manually keyed transactions) or Token • Card data is encrypted with VeriFone format preserving proprietary algorithm; Token is in the clear

Step (5A): (STM Handler to VSD) VSD Server receives a decrypt request from the STM Handler. • STM handler will extract data elements from the SP<>. • The decrypted account number and/or magnetic stripe data is returned to the STM Handler. • Card data (Track 1, Track 2, or PAN for manually keyed transactions) or Token • Card data is encrypted with VeriFone format preserving proprietary algorithm; Token is in the clear. Step (5B): (VSD to STM Handler) VSD Server decrypts the card data and sends it back to the STM Handler. • Card data (Track 1, Track 2, or PAN for manually keyed transactions) • Card data is unencrypted Step (6A): (STM Handler to RTS Token Servers) STM Handler sends PAN data to the RTS Server to get tokenized. • PAN or Token (depending upon request performed). • PAN or Token is unencrypted. Step (6B): (RTS Token Servers to STM Handler) RTS Server returns Token or PAN back to STM Handler. • PAN or Token (depending upon request performed). • PAN or Token is unencrypted. Step (7): (STM Handler to Front End) STM Handler routes transaction to Front End Authorization Platform. • PAN or Token (depending upon request performed). • PAN or Token is unencrypted. Step (8): (Front End to Store Controller) Token returned to the merchant in a successful authorization response. • PAN or Token (depending upon request performed). • PAN or Token is unencrypted.

Assessment Environment The First Data TransArmor VeriFone Edition system was installed in First Data’s Lab for the duration of the testing. The STM boxes were running AIX 5.3, the proxy server and VSD application servers were running Windows Server 2008 R2 Enterprise, the VSD Database was running SQL 2008 R2 on Windows Server 2008 R2, and the HSM was Safenet Luna 4.

The assessment included:

 Running payment card transactions using five test scenarios that represent the different ways transactions could occur: o Track 2 with token request - approved o Manual entry with token request - approved o Get PAN request - approved o Track 1 with token request – approved o Declined transaction  Monitoring traffic for transmitted card data over iptrace and analyzing via Wireshark.  Scanning logs and traffic captures for unencrypted Track and PAN data both manually and using automated forensics tools. No card data was found either encrypted or decrypted.

Assessment testing used credit card transactions from three Visa cards, one Discover card, and one Visa PAN.

TransArmor VeriFone Edition Encryption Assessment The following charts show the results of the intercepted traffic from the 5 types of transactions. Note: Shown below are single specific examples, multiple examples were collected over the course of testing.

Table 1: Visa Track 2 Data vs. Encrypted Track 2 Data Visa Test Card - Approved Original Track Data 4012000033330026=16041011000012345678 Track Encryption 4012008992190026=60049981588004757732

Table 2: Discover Manual Input vs. Encrypted PAN Discover PAN - Approved Original PAN 6011000990099818, exp 0416 Encrypted PAN 60046011001583599818

Table 3: VISA Get PAN vs. Encrypted PAN VISA PAN - Approved Original PAN 4012000033330026 Token 8875380764780026

Table 4: Discover Track 2 vs. Encrypted Track Data Discover Test Card – Declined Original Track Data 6221261111117766=160410123456789 Track Encryption 6221262156567766=600490936515360

Table 5: Visa Track 1 vs. Encrypted Track Data Visa Test Card – Approved Original Track Data B4012001386750026^^14121007644204482293072114216 Track Encryption B4012005401770026^^58121008651442176555181090362

These results demonstrate the encryption that is performed by the TransArmor VeriFone Edition VeriShield Crypto Library (VCL) and all output is encrypted before transmission and before getting to First Data. The encrypted PANs pass the Luhn (mod 10) test. Note that the Token does not pass the Luhn test.

Forensic and Wide Area Network (WAN) traffic Analysis The technical assessment included a forensic examination of the logs and the traffic captures. The process included the following:

1. Test transactions were performed, watching the traffic with iptrace; 2. Logs were collected from the transactions ; and 3. Traffic captures were examined in Wireshark for unencrypted PAN or track data; and 4. Log files were searched for unencrypted PAN or track data.

For the traffic captures, there was no PAN or track data found coming out from the simulated POS and into the First Data environment. Once decrypted, no PAN or track data was observed to ever be returned to the merchant/POS. Only tokens, approval codes and other non-sensitive data are returned to the merchant/POS. The logs were reviewed and no evidence of track or PAN data was observed.

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 DDKs are created, the MDK is securely deleted.

First Data uses the following 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 Key Encryption Key (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.

Updating Keys First Data supports 2 ways to advance the DDK within the VeriFone devices:

1. VCL Direct Interface This is the primary method First Data supports. 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 3: Advance DDK - Key Management using VCL Direct Interface

2. Command Cards Also supported is the use of 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 4: Advance DDK - Key Management using Command Card

Key Management via Command Cards, and VCL Direct Interface

VeriShield Remote Key (VRK) requires either TCP/IP connectivity or a mechanism to push a file to the PIN pad device.

There are five different types of integration methods/commands: 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 VRK in production, although most service providers do 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 components: Master Key Component: Two components are used, replicating the two components that a KIF receives. These two values are XORed and used to inject the MDK from the vcl_settings file. 90 DDKs 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.

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.

Summary

TransArmor VeriFone Edition is a robust P2PE solution that, when implemented correctly, can be used by merchants to dramatically reduce both risk and applicability of PCI DSS controls. First Data has integrated VeriFone’s encryption properly and their back end decryption processes reside in a facility that has a current PCI DSS Report on Compliance (ROC) in place. Merchants can use TAVE and this document to demonstrate how the technology works and enable QSAs or other interested parties to evaluate their proper implementation of TransArmor VeriFone Edition into their environment.

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. Consequently, Coalfire is not responsible for any errors or omissions, or for the results obtained from the use of this information. 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 control applicability within a merchant environment utilizing TAVE. This risk-based guidance indicates Coalfire’s recommended PCI-DSS reduction of applicable controls for merchants that have compliantly implemented TAVE. 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.1.

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

1. Properly implemented, TAVE will completely render the requirement not applicable for a merchant’s PCI-DSS assessment. 2. Properly implemented, TAVE can significantly reduce or eliminate applicability of the requirement from the merchant’s PCI-DSS assessment. Depending on the merchant’s cardholder data environment, some validation from the QSA may be required. 3. Properly implemented, TAVE 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 TAVE 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.1 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 TAVE is properly implemented.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

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 1 Not Applicable When implemented properly, procedures to verify there is a formal TAVE will remove the PCI DSS process for testing and approval of all: validation requirements for the • Network connections, and merchant’s host network. Formal process for network components • Changes to firewall and router testing and approval configurations. requirements would not be applicable.

1.1.1.b For a sample of network 1 Not Applicable When implemented properly, connections, interview responsible TAVE will remove the PCI DSS personnel and examine records to verify validation requirements for the that network connections were approved merchant’s host network. Formal and tested. process for network components testing and approval requirements would not be applicable.

1.1.1.c Identify a sample of actual changes 1 Not Applicable When implemented properly, made to firewall and router TAVE will remove the PCI DSS configurations, compare to the change validation requirements for the records, and interview responsible merchant’s host network. Formal personnel to verify the changes were process for network components approved and tested. testing and approval requirements would not be applicable.

1.1.2.a Examine diagram(s) and observe 4 Network Diagram Even with the significant network configurations to verify that a reduction of applicable controls current network diagram exists and that it TAVE obtains, Coalfire feels that documents all connections to the merchants should still diagram cardholder data environment, including the network flow of the retail any wireless networks. locations where TAVE will be utilized.

1.1.2.b Interview responsible personnel to 4 Network Diagram Even with the significant verify that the diagram is kept current. reduction of applicable controls TAVE obtains, Coalfire feels that merchants should still diagram the network flow of the retail

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

locations where TAVE will be utilized.

1.1.3.a Examine data flow diagram and 4 Data Flow Diagram Even with the significant interview personnel to verify the diagram: reduction of applicable controls TAVE obtains, Coalfire feels that  Shows all cardholder data flows across merchants should still diagram systems and networks. the data flow of the retail  Is kept current and updated as needed upon changes to the environment. locations where TAVE will be utilized.

1.1.4.a Examine the firewall configuration 1 Not Applicable When implemented properly, standards and verify that they include TAVE will remove the PCI DSS requirements for a firewall at each validation requirements for the Internet connection and between any merchant’s host network. The DMZ and the internal network zone. firewall configuration standards testing requirements would not be applicable.

1.1.4.b Verify that the current network 4 Network Diagram Coalfire feels that a network diagram is consistent with the firewall diagram is still appropriate for the configuration standards. merchant environment; however, it will not need to be compared to network configuration standards.

1.1.4.c Observe network configurations to 1 Not Applicable When implemented properly, verify that a firewall is in place at each TAVE will remove the PCI DSS Internet connection and between any validation requirements for the demilitarized zone (DMZ) and the internal merchant’s host network. The network zone, per the documented firewall configuration standards configuration standards and network testing requirements would not diagrams. be applicable.

1.1.5.a Verify that firewall and router 1 Not Applicable When implemented properly, configuration standards include a TAVE will remove the PCI DSS description of groups, roles, and validation requirements for the responsibilities for management of merchant’s host network. The network components. firewall and router configuration standards testing requirements would not be applicable.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

1.1.5.b Interview personnel responsible for 1 Not Applicable When implemented properly, management of network components to TAVE will remove the PCI DSS confirm that roles and responsibilities are validation requirements for the assigned as documented. merchant’s host network.

1.1.6.a Verify that firewall and router 1 Not Applicable When implemented properly, configuration standards include a TAVE will remove the PCI DSS documented list of all services, protocols validation requirements for the and ports, including business justification merchant’s host network. The for each—for example, hypertext transfer firewall and router configuration protocol (HTTP) and Secure Sockets Layer standards testing requirements (SSL), Secure Shell (SSH), and Virtual would not be applicable. Private Network (VPN) protocols.

1.1.6.b Identify insecure services, 1 Not Applicable When implemented properly, protocols, and ports allowed; and verify TAVE will remove the PCI DSS that security features are documented for validation requirements for the each service. 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 1 Not Applicable When implemented properly, configurations to verify that the TAVE will remove the PCI DSS documented security features are validation requirements for the implemented for each insecure service, merchant’s host network. There protocol, and port. 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 1 Not Applicable When implemented properly, configuration standards require review of TAVE will remove the PCI DSS firewall and router rule sets at least every validation requirements for the six months. merchant’s host network. The firewall configuration standards testing requirements would not be applicable.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

1.1.7.b Examine documentation relating to 1 Not Applicable When implemented properly, rule set reviews and interview responsible TAVE will remove the PCI DSS personnel to verify that the rule sets are validation requirements for the reviewed at least every six months. 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:

1.2.1.a Examine firewall and router 1 Not Applicable When implemented properly, configuration standards to verify that they TAVE will remove the PCI DSS identify inbound and outbound traffic validation requirements for the necessary for the cardholder data merchant’s host network. The environment. firewall and router configuration standards testing requirements would not be applicable.

1.2.1.b Examine firewall and router 1 Not Applicable When implemented properly, configurations to verify that inbound and TAVE will remove the PCI DSS outbound traffic is limited to that which is validation requirements for the necessary for the cardholder data merchant’s host network. The environment. firewall and router configuration standards testing requirements would not be applicable.

1.2.1.c Examine firewall and router 1 Not Applicable When implemented properly, configurations to verify that all other TAVE will remove the PCI DSS inbound and outbound traffic is specifically validation requirements for the denied, for example by using an explicit merchant’s host network. The “deny all” or an implicit deny after allow firewall and router configuration statement. standards testing requirements would not be applicable.

1.2.2.a Examine router configuration files 1 Not Applicable When implemented properly, to verify they are secured from TAVE will remove the PCI DSS unauthorized access. validation requirements for the merchant’s host network. The firewall and router configuration standards testing requirements would not be applicable.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

1.2.2.b Examine router configurations to 1 Not Applicable When implemented properly, verify they are synchronized—for example, TAVE will remove the PCI DSS the running (or active) configuration validation requirements for the matches the start-up configuration (used merchant’s host network. The when machines are booted).into the router configurations testing cardholder data environment. requirements would not be applicable.

1.2.3.a Examine firewall and router 1 Not Applicable When implemented properly, configurations to verify that there are TAVE will remove the PCI DSS perimeter firewalls installed between all validation requirements for the wireless networks and the cardholder data merchant’s host network. The environment. firewall and router configurations testing requirements would not be applicable.

1.2.3.b Verify that the firewalls deny or, if 1 Not Applicable When implemented properly, traffic is necessary for business purposes, TAVE will remove the PCI DSS permit only authorized traffic between the validation requirements for the wireless environment and the cardholder merchant’s host network. There data environment. 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 1 Not Applicable When implemented properly, configurations to verify that a DMZ is TAVE will remove the PCI DSS implemented to limit inbound traffic to validation requirements for the only system components that provide merchant’s host network. There authorized publicly accessible services, is no cardholder data storage in a protocols, and ports. merchant environment and as such the DMZ network layer would not be applicable.

1.3.2 Examine firewall and router 1 Not Applicable When implemented properly, configurations to verify that inbound TAVE will remove the PCI DSS Internet traffic is limited to IP addresses validation requirements for the within the DMZ. merchant’s host network. There is no cardholder data storage in a merchant environment and as

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

such the DMZ network layer would not be applicable.

1.3.3 Examine firewall and router 1 Not Applicable When implemented properly, configurations to verify direct connections TAVE will remove the PCI DSS inbound or outbound are not allowed for validation requirements for the traffic between the Internet and the merchant’s host network. The cardholder data environment. firewall and router configurations testing requirements would not be applicable.

1.3.4 Examine firewall and router 1 Not Applicable When implemented properly, configurations to verify that anti-spoofing TAVE will remove the PCI DSS measures are implemented, for example validation requirements for the internal addresses cannot pass from the merchant’s host network. The Internet into the DMZ. firewall and router configurations testing requirements would not be applicable.

1.3.5 Examine firewall and router 1 Not Applicable When implemented properly, configurations to verify that outbound TAVE will remove the PCI DSS traffic from the cardholder data validation requirements for the environment to the Internet is explicitly merchant’s host network. The authorized. firewall and router configurations testing requirements would not be applicable.

1.3.6 Examine firewall and router 2 Network Diagram When implemented properly, configurations to verify that the firewall Network Configuration TAVE will remove the PCI DSS performs stateful inspection (dynamic Standards validation requirements for the packet filtering). (Only established merchant’s host network. connections should be allowed in, and only However, Coalfire still if they are associated with a previously recommends against direct established session.) unrestricted inbound Internet access to the POIs.

1.3.7 Examine firewall and router 1 Not Applicable When implemented properly, configurations to verify that system TAVE will remove the PCI DSS components that store cardholder data are validation requirements for the on an internal network zone, segregated merchant’s host network. There from the DMZ and other untrusted is no cardholder data storage in a networks. merchant environment and as

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

such the DMZ network layer would not be applicable.

1.3.8.a Examine firewall and router 1 Not Applicable When implemented properly, configurations to verify that methods are TAVE will remove the PCI DSS in place to prevent the disclosure of validation requirements for the private IP addresses and routing merchant’s host network. information from internal networks to the Internet.

1.3.8.b Interview personnel and examine 1 Not Applicable When implemented properly, documentation to verify that any TAVE will remove the PCI DSS disclosure of private IP addresses and validation requirements for the routing information to external entities is merchant’s host network. authorized.

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 1 Not Applicable When implemented properly, configuration standards to verify: TAVE will remove the PCI DSS • Personal firewall software is validation requirements for the required for all mobile and/or merchant’s host network. With employee-owned devices that no access to cardholder data, connect to the Internet (for mobile and/or employee owned example, laptops used by computers personal firewall employees) when outside the software requirement will be not network, and which are also used applicable. 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

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

users of mobile and/or employee- owned devices.

1.4.b Inspect a sample of mobile and/or 1 Not Applicable When implemented properly, employee-owned devices to verify that: TAVE will remove the PCI DSS validation requirements for the • Personal firewall software is merchant’s host network. With installed and configured per the no access to cardholder data, organization’s specific mobile and/or employee owned configuration settings. computers personal firewall • Personal firewall software is software requirement will be not actively running. applicable. • Personal firewall software is not alterable by users of mobile and/or employee- owned devices. 1.5 Ensure that security policies and operational procedures for managing firewalls are documented, in use, and known to all affected parties.

1.5 Examine documentation and interview 3 Network Diagram Even with the significant personnel to verify that security policies Network Configuration reduction of applicable controls and operational procedures for managing Standards TAVE obtains, Coalfire feels that firewalls are: Data Flow Diagram merchants should still maintain the data flow, network flow  Documented, diagrams of the retail locations  In use, and where TAVE will be utilized.  Known to all affected parties. 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 1 Not Applicable When implemented properly, components, and attempt to log on (with TAVE will remove the PCI DSS system administrator help) to the devices validation requirements for all and applications using default vendor- system components located on supplied accounts and passwords, to the merchant’s host network verify that ALL default passwords (outside of the POI devices). (including those on operating systems, software that provides security services, application and system accounts, POS

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value 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.)

2.1.b For the sample of system 1 Not Applicable When implemented properly, components, verify that all unnecessary TAVE will remove the PCI DSS default accounts (including accounts used validation requirements for all by operating systems, security software, system components located on applications, systems, POS terminals, the merchant’s host network SNMP, etc.) are removed or disabled. (outside of the POI devices).

2.1.c Interview personnel and examine 1 Not Applicable When implemented properly, supporting documentation to verify that: TAVE will remove the PCI DSS validation requirements for all  All vendor defaults (including default system components located on passwords on operating systems, the merchant’s host network software providing security services, (outside of the POI devices). application and system accounts, POS terminals, Simple Network Management Protocol (SNMP) community strings, etc.) are changed before a system is installed on the network.  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.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

2.1.1.a Interview responsible personnel 1 Not Applicable When implemented properly, and examine supporting documentation to TAVE will remove the PCI DSS verify that: validation requirements for the merchant’s host network.  Encryption keys were changed from Wireless device components default at installation would transmit cardholder data in encrypted format with merchant having no knowledge of decryption keys.

2.1.1.b Interview personnel and examine 1 Not Applicable When implemented properly, policies and procedures to verify: TAVE will remove the PCI DSS validation requirements for the  Default SNMP community strings are merchant’s host network. required to be changed upon Wireless device components installation. would transmit cardholder data in  Default passwords/phrases on access encrypted format with merchant points are required to be changed having no knowledge of upon installation. decryption keys.

2.1.1.c Examine vendor documentation 1 Not Applicable When implemented properly, and login to wireless devices, with system TAVE will remove the PCI DSS administrator help, to verify: 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.d Examine vendor documentation 1 Not Applicable When implemented properly, and observe wireless configuration TAVE will remove the PCI DSS settings to verify firmware on wireless validation requirements for the devices is updated to support strong merchant’s host network. Vendor encryption for: documentation specific to wireless configuration settings  Authentication over wireless networks would not be applicable.  Transmission over wireless networks 2.1.1.e Examine vendor documentation 1 Not Applicable When implemented properly, and observe wireless configuration TAVE will remove the PCI DSS settings to verify other security-related validation requirements for the wireless vendor defaults were changed, if merchant’s host network. Vendor applicable. documentation specific to

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

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 1 Not Applicable When implemented properly, configuration standards for all types of TAVE will remove the PCI DSS system components and verify the system validation requirements for all configuration standards are consistent system components located on with industry- accepted hardening the merchant’s host network standards. (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 1 Not Applicable When implemented properly, personnel to verify that system TAVE will remove the PCI DSS configuration standards are updated as validation requirements for all new vulnerability issues are identified, as system components located on defined in Requirement 6.1. 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.c Examine policies and interview 1 Not Applicable When implemented properly, personnel to verify that system TAVE will remove the PCI DSS configuration standards are applied when validation requirements for all new systems are configured and verified system components located on as being in place before a system is the merchant’s host network installed on the network. (outside of the POI devices). PCI requirements testing the configuration standards for

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

various system components would not be applicable.

2.2.d Verify that system configuration 1 Not Applicable When implemented properly, standards include the following TAVE will remove the PCI DSS procedures for all types of system validation requirements for all components: system components located on the merchant’s host network  Changing of all vendor- supplied (outside of the POI devices). PCI defaults and elimination of requirements testing the unnecessary default accounts configuration standards for  Implementing only one primary various system components function per server to prevent would not be applicable. 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 1 Not Applicable When implemented properly, components and inspect the system TAVE will remove the PCI DSS configurations to verify that only one validation requirements for all primary function is implemented per system components located on server. the merchant’s host network (outside of the POI devices).

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

2.2.1.b If virtualization technologies are 1 Not Applicable When implemented properly, used, inspect the system configurations to TAVE will remove the PCI DSS verify that only one primary function is validation requirements for all implemented per virtual system system components located on component or device 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 1 Not Applicable When implemented properly, components and inspect enabled system TAVE will remove the PCI DSS services, daemons, and protocols to verify validation requirements for all that only necessary services or protocols system components located on are enabled. the merchant’s host network (outside of the POI devices).

2.2.2.b Identify any enabled insecure 1 Not Applicable When implemented properly, services, daemons, or protocols and TAVE will remove the PCI DSS interview personnel to verify they are validation requirements for all justified per documented configuration system components located on standards. the merchant’s host network (outside of the POI devices).

2.2.3 Inspect configuration settings to 1 Not Applicable When implemented properly, verify that security features are TAVE will remove the PCI DSS documented and implemented for all validation requirements for all insecure services, daemons, or protocols. system components located on the merchant’s host network (outside of the POI devices).

2.2.4.a Interview system administrators 1 Not Applicable When implemented properly, and/or security managers to verify that TAVE will remove the PCI DSS they have knowledge of common security validation requirements for all parameter settings for system system components located on components. the merchant’s host network (outside of the POI devices).

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

2.2.4.b Examine the system configuration 1 Not Applicable When implemented properly, standards to verify that common security TAVE will remove the PCI DSS parameter settings are included. 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.4.c Select a sample of system 1 Not Applicable When implemented properly, components and inspect the common TAVE will remove the PCI DSS security parameters to verify that they are validation requirements for all set appropriately and in accordance with system components located on the configuration standards. 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.5.a Select a sample of system 1 Not Applicable When implemented properly, components and inspect the TAVE will remove the PCI DSS configurations to verify that all validation requirements for all unnecessary functionality (for example, system components located on scripts, drivers, features, subsystems, file the merchant’s host network systems, etc.) is removed. (outside of the POI devices).

2.2.5.b. Examine the documentation and 1 Not Applicable When implemented properly, security parameters to verify enabled TAVE will remove the PCI DSS functions are documented and support validation requirements for all secure configuration. 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.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

2.2.5.c. Examine the documentation and 1 Not Applicable When implemented properly, security parameters to verify that only TAVE will remove the PCI DSS documented functionality is present on validation requirements for all the sampled system components. 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.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.

2.3.a Observe an administrator log on to 1 Not Applicable When implemented properly, each system and examine system TAVE will remove the PCI DSS configurations to verify that a strong validation requirements for all encryption method is invoked before the system components located on administrator’s password is requested. the merchant’s host network (outside of the POI devices).

2.3.b Review services and parameter files 1 Not Applicable When implemented properly, on systems to determine that Telnet and TAVE will remove the PCI DSS other insecure remote-login commands validation requirements for all are not available for non-console access system components located on the merchant’s host network (outside of the POI devices).

2.3.c Observe an administrator log on to 1 Not Applicable When implemented properly, each system to verify that administrator TAVE will remove the PCI DSS access to any web-based management validation requirements for all interfaces is encrypted with strong system components located on cryptography. the merchant’s host network (outside of the POI devices).

2.3.d Examine vendor documentation and 1 Not Applicable When implemented properly, interview personnel to verify that strong TAVE will remove the PCI DSS cryptography for the technology in use is validation requirements for all implemented according to industry best system components located on practices and/or vendor the merchant’s host network recommendations. (outside of the POI devices).

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

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

2.4.a Examine system inventory to verify 4 POI Device Inventory Maintaining POI device inventory that a list of hardware and software will still apply to the merchant components is maintained and includes a environment. description of function/use for each.

2.4.b Interview personnel to verify the 4 POI Device Inventory Maintaining POI device inventory documented inventory is kept current. 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.

2.5 Examine documentation and interview 1 Not Applicable When implemented properly, personnel to verify that security policies TAVE will remove the PCI DSS and operational procedures for managing validation requirements for the vendor defaults and other security merchant’s host network. PCI parameters are: requirements testing the configuration standards for  Documented, various system components  In use, and would not be applicable.  Known to all affected parties. 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 1 Not Applicable Not Applicable for merchants. 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.

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.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

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

3.1.a Examine the data- retention and 3 Data Retention and If the merchant has any paper disposal policies, procedures and Storage Policies (if based processes associated with processes to verify they include at least applicable) this payment channel then this the following: requirement will still apply to their environment. Otherwise,  Legal, regulatory, and business this requirement can be requirements for data retention, considered not applicable. including  Specific requirements for retention of cardholder data (for example, cardholder data needs to be held for X period for Y business reasons).  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: 3 Data Retention and If the merchant has any paper Storage Policies (if based processes associated with  All locations of stored cardholder data applicable) this payment channel then this are included in the data-retention and requirement will still apply to disposal processes. their environment. Otherwise,  Either a quarterly automatic or manual this requirement can be process is in place to identify and considered not applicable. 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 3 Data Retention and If the merchant has any paper that store cardholder data: Storage Policies (if based processes associated with applicable) this payment channel then this  Examine files and system records to requirement will still apply to verify that the data stored does not their environment. Otherwise, exceed the requirements defined in the data-retention policy.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

 Observe the deletion mechanism to this requirement can be verify data is deleted securely. considered not applicable.

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 1 Not Applicable Not applicable for merchants. 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.

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

3.2.c For all other entities, if sensitive 1 Not Applicable Sensitive authentication data will authentication data is received, review not be stored within or outside of policies and procedures, and examine hardware POI devices. system configurations to verify the data is not retained after authorization.

3.2.d For all other entities, if sensitive 1 Not Applicable Sensitive authentication data will authentication data is received, review not be stored within or outside of procedures and examine the processes for hardware POI devices. 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.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

3.2.1 For a sample of system components, 1 Not Applicable Sensitive authentication data will examine data sources, including but not not be stored within or outside of limited to the following, and verify that hardware POI devices. 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 3.2.2 For a sample of system components, 3 Data Retention and If the merchant has any paper examine data sources, including but not Storage Policies (if based processes associated with limited to the following, and verify that applicable) its payment channel that includes the three-digit or four- digit card card validation codes then this verification code or value printed on the requirement will still apply to front of the card or the signature panel documents. Otherwise, this (CVV2, CVC2, CID, CAV2 data) is not stored requirement can be considered after authorization: not applicable.

 Incoming transaction data Sensitive authentication data will  All logs (for example, transaction, not be stored within or outside of history, debugging, error) hardware POI devices.  History files  Trace files  Several database schemas  Database contents

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

3.2.3 For a sample of system components, 1 Not Applicable Sensitive authentication data will examine data sources, including but not not be stored within or outside of limited to the following and verify that hardware POI devices. PINs and encrypted PIN blocks 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 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 3 Data Retention and If the merchant has any paper procedures for masking the display of Storage Policies (if based processes associated with PANs to verify: applicable) this payment channel then this requirement will still apply to  A list of roles that need access to their environment. Otherwise, displays of full PAN is documented, this requirement can be together with a legitimate business considered not applicable. 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.  All other roles not specifically authorized to see the full PAN must only see masked PANs. 3.3.b Examine system configurations to 3 Data Retention and If the merchant has any paper verify that full PAN is only displayed for Storage Policies (if based processes associated with users/roles with a documented business applicable) this payment channel then this need, and that PAN is masked for all other requirement will still apply to requests. their environment. Otherwise, this requirement can be considered not applicable.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

3.3.c Examine displays of PAN (for 3 Data Retention and If the merchant has any paper example, on screen, on paper receipts) to Storage Policies (if based processes associated with verify that PANs are masked when applicable) this payment channel then this displaying cardholder data, and that only requirement will still apply to those with a legitimate business need are their environment. Otherwise, able to see full PAN. this requirement can be considered not applicable.

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 1 Not Applicable PAN will be rendered unreadable system used to protect the PAN, including at swipe on POI devices. the vendor, type of system/process, and Merchants will have no the encryption algorithms (if applicable) to responsibility for secure storage verify that the PAN is rendered unreadable of cardholder data within their using any of the following methods: environments.

 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

3.4.b Examine several tables or files from a 1 Not Applicable PAN will be rendered unreadable sample of data repositories to verify the at swipe on POI devices. PAN is rendered unreadable (that is, not Merchants will have no stored in plain-text). responsibility for secure storage of cardholder data within their environments.

3.4.c Examine a sample of removable 1 Not Applicable PAN will be rendered unreadable media (for example, back-up tapes) to at swipe on POI devices. confirm that the PAN is rendered Merchants will have no unreadable. responsibility for secure storage

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

of cardholder data within their environments.

3.4.d Examine a sample of audit logs to 1 Not Applicable PAN will be rendered unreadable confirm that the PAN is rendered at swipe on POI devices. unreadable or removed from the logs. Merchants will have no responsibility for secure storage of cardholder data within their environments.

3.4.1.a If disk encryption is used, inspect 1 Not Applicable PAN will be rendered unreadable the configuration and observe the at swipe on POI devices. authentication process to verify that Merchants will have no logical access to encrypted file systems is responsibility for secure storage implemented via a mechanism that is of cardholder data within their separate from the native operating environments. 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 1 Not Applicable PAN will be rendered unreadable personnel to verify that cryptographic at swipe on POI devices. keys are stored securely (for example, Merchants will have no stored on removable media that is responsibility for secure storage adequately protected with strong access of cardholder data within their controls). environments.

3.4.1.c Examine the configurations and 1 Not Applicable PAN will be rendered unreadable observe the processes to verify that at swipe on POI devices. cardholder data on removable media is Merchants will have no encrypted wherever stored. responsibility for secure storage of cardholder data within their environments. Note: If disk encryption is not used to encrypt removable media, the data stored on this media will need to be rendered unreadable through some other method.

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

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

3.5 Examine key-management policies and 1 Not Applicable. If TAVE has been implemented procedures to verify processes are correctly, Merchants will have no specified to protect keys used for key management responsibilities encryption of cardholder data against within their environment. 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. 3.5.1 Examine user access lists to verify 1 Not Applicable. If TAVE has been implemented that access to keys is restricted to the correctly, Merchants will have no fewest number of custodians necessary. key management responsibilities within their environment.

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

3.5.2.a Examine documented procedures 1 Not Applicable. If TAVE has been implemented to verify that cryptographic keys used to correctly, Merchants will have no encrypt/decrypt cardholder data must key management responsibilities only exist in one (or more) of the following within their environment. As forms at all times. such, the key-management procedures documentation is not  Encrypted with a key- encrypting key applicable. 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)

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

or PTS-approved point-of-interaction device).  As key components or key shares, in accordance with an industry-accepted method.

3.5.2.b Examine system configurations 1 Not Applicable. If TAVE has been implemented and key storage locations to verify that correctly, Merchants will have no cryptographic keys used to key management responsibilities encrypt/decrypt cardholder data exist in within their environment. 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 1 Not Applicable. If TAVE has been implemented used, examine system configurations and correctly, Merchants will have no key storage locations to verify: key management responsibilities within their environment.  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. 3.5.3 Examine key storage locations and 1 Not Applicable. If TAVE has been implemented observe processes to verify that keys are correctly, Merchants will have no stored in the fewest possible locations. key management responsibilities within their environment.

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 1 Not Applicable. If TAVE has been implemented providers: If the service provider shares correctly, Merchants will have no keys with their customers for transmission key management responsibilities or storage of cardholder data, examine within their environment. the documentation that the service

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value 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 1 Not Applicable. If TAVE has been implemented procedures specify how to generate strong correctly, Merchants will have no keys. key management responsibilities within their environment. As such, the key-management procedures documentation is not applicable.

3.6.1.b Observe the method for 1 Not Applicable. If TAVE has been implemented generating keys to verify that strong keys correctly, Merchants will have no are generated. key management responsibilities within their environment.

3.6.2.a Verify that key- management 1 Not Applicable. If TAVE has been implemented procedures specify how to securely correctly, Merchants will have no distribute keys. key management responsibilities within their environment. As such, the key-management procedures documentation is not applicable.

3.6.2.b Observe the method for 1 Not Applicable. If TAVE has been implemented distributing keys to verify that keys are correctly, Merchants will have no distributed securely. key management responsibilities within their environment.

3.6.3.a Verify that key-management 1 Not Applicable. If TAVE has been implemented procedures specify how to securely store correctly, Merchants will have no keys. key management responsibilities within their environment. As such, the key-management procedures documentation is not applicable.

3.6.3.b Observe the method for storing 1 Not Applicable. If TAVE has been implemented keys to verify that keys are stored correctly, Merchants will have no securely.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

key management responsibilities within their environment.

3.6.4.a Verify that key- management 1 Not Applicable. If TAVE has been implemented procedures include a defined cryptoperiod correctly, Merchants will have no for each key type in use and define a key management responsibilities process for key changes at the end of the within their environment. As defined cryptoperiod(s). such, the key-management procedures documentation is not applicable.

3.6.4.b Interview personnel to verify that 1 Not Applicable. If TAVE has been implemented keys are changed at the end of the defined correctly, Merchants will have no cryptoperiod(s). key management responsibilities within their environment.

3.6.5.a Verify that key- management 1 Not Applicable. If TAVE has been implemented procedures specify processes for the correctly, Merchants will have no following: key management responsibilities within their environment. As  The retirement or replacement of keys such, the key-management when the integrity of the key has been procedures documentation is not weakened. applicable.  The replacement of known or suspected compromised keys.  Any keys retained after retiring or replacing are not used for encryption operations. 3.6.5.b Interview personnel to verify the 1 Not Applicable. If TAVE has been implemented following processes are implemented: correctly, Merchants will have no key management responsibilities  Keys are retired or replaced as within their environment. 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.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

3.6.6.a Verify that manual clear- text key- 1 Not Applicable. If TAVE has been implemented management procedures specify correctly, Merchants will have no processes for the use of the following: key management responsibilities within their environment. As  Split knowledge of keys, such that key such, the key-management components are under the control of at procedures documentation is not least two people who only have applicable. 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 1 Not Applicable. If TAVE has been implemented observe processes to verify that manual correctly, Merchants will have no clear-text keys are managed with: key management responsibilities within their environment.  Split knowledge, AND  Dual control 3.6.7.a Verify that key-management 1 Not Applicable. If TAVE has been implemented procedures specify processes to prevent correctly, Merchants will have no unauthorized substitution of keys. key management responsibilities within their environment. As such, the key-management procedures documentation is not applicable.

3.6.7.b Interview personnel and/or 1 Not Applicable. If TAVE has been implemented observe process to verify that correctly, Merchants will have no unauthorized substitution of keys is key management responsibilities prevented. within their environment.

3.6.8.a Verify that key- management 1 Not Applicable. If TAVE has been implemented procedures specify processes for key correctly, Merchants will have no custodians to acknowledge (in writing or key management responsibilities electronically) that they understand and within their environment. As accept their key-custodian responsibilities. such, key-management procedures documentation is not applicable.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

3.6.8.b Observe documentation or other 1 Not Applicable. If TAVE has been implemented evidence showing that key custodians correctly, Merchants will have no have acknowledged (in writing or key management responsibilities electronically) that they understand and within their environment. As accept their key-custodian responsibilities. 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 3 Data Retention and If the merchant has any paper personnel to verify that security policies Storage Policies (if based processes associated with and operational procedures for protecting applicable) this payment channel then this stored cardholder data are: requirement will still apply to their environment. Otherwise,  Documented, this requirement can be  In use, and considered not applicable.  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. 4.1.a Identify all locations where 1 Not Applicable When implemented properly, cardholder data is transmitted or received TAVE will remove the PCI DSS over open, public networks. 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 1 Not Applicable When implemented properly, procedures to verify processes are TAVE will remove the PCI DSS specified for the following: validation requirements for the merchant’s host network.  For acceptance of only trusted keys Cardholder data is encrypted at and/or certificates. POI device with no key  For the protocol in use to only support responsibilities with merchant. secure versions and configurations Cardholder data transmission

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

(that insecure versions or requirements will not be configurations are not supported). applicable for this environment.  For implementation of proper Transmission requirements will encryption strength per the encryption not be applicable. methodology in use. 4.1.c Select and observe a sample of 1 Not Applicable When implemented properly, inbound and outbound transmissions as TAVE will remove the PCI DSS they occur to verify that all cardholder validation requirements for the data is encrypted with strong merchant’s host network. cryptography during transit. 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.d Examine keys and certificates to 1 Not Applicable When implemented properly, verify that only trusted keys and/or TAVE will remove the PCI DSS certificates are accepted. 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.e Examine system configurations to 1 Not Applicable When implemented properly, verify that the protocol is implemented to TAVE will remove the PCI DSS use only secure configurations and does validation requirements for the not support insecure versions or merchant’s host network. configurations. 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.f Examine system configurations to 1 Not Applicable When implemented properly, verify that the proper encryption strength TAVE will remove the PCI DSS is implemented for the encryption validation requirements for the methodology in use. (Check vendor merchant’s host network. recommendations/best practices.) Cardholder data is encrypted at POI device with no key

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

responsibilities with merchant. Cardholder data transmission requirements will not be applicable for this environment.

4.1.g For SSL/TLS implementations, 1 Not Applicable When implemented properly, examine system configurations to verify TAVE will remove the PCI DSS that SSL/TLS is enabled whenever validation requirements for the cardholder data is transmitted or received. 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.1 Identify all wireless networks 1 Not Applicable When implemented properly, transmitting cardholder data or connected TAVE will remove the PCI DSS to the cardholder data environment. validation requirements for the Examine documented standards and merchant’s host network. compare to system configuration settings Cardholder data is encrypted at to verify the following for all wireless POI device with no key networks identified: responsibilities with merchant. Cardholder data transmission  Industry best practices (for example, requirements will not be IEEE 802.11i) are used to implement applicable for this environment. strong encryption for authentication and transmission.  Weak encryption (for example, WEP, SSL version  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 1 Not Applicable When implemented properly, are used to send cardholder data, observe TAVE will remove the PCI DSS processes for sending PAN and examine a validation requirements for the sample of outbound transmissions as they merchant’s host network. occur to verify that PAN is rendered unreadable or secured with strong cryptography whenever it is sent via end- user messaging technologies.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

4.2.b Review written policies to verify the 2 Acceptable Usage Policies Merchants will not have any existence of a policy stating that access to cardholder data within unprotected PANs are not to be sent via their environment; however, end-user messaging technologies. 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 2 Acceptable Usage Policies Merchants will not have any personnel to verify that security policies access to cardholder data within and operational procedures for encrypting their environment; however, transmissions of cardholder data are: employees will still have access to the physical credit card in retail  Documented, environments. As such, a policy  In use, and prohibiting the emailing of  Known to all affected parties. unprotected PAN is still appropriate for most retail environments.

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

5.1 For a sample of system components 1 Not Applicable When implemented properly, including all operating system types TAVE will remove the PCI DSS commonly affected by malicious software, validation requirements for all verify that anti-virus software is deployed server components located on if applicable anti-virus technology exists. the merchant’s host network. Anti-virus and anti-malware requirements will not be applicable. i. Review vendor documentation 1 Not Applicable When implemented properly, and examine anti- virus configurations to TAVE will remove the PCI DSS verify that anti-virus programs; validation requirements for all  Detect all known types of malicious server components located on software, the merchant’s host network.  Remove all known types of malicious Anti-virus and anti-malware software, and requirements will not be applicable.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

 Protect against all known types of malicious software.

5.1.2 Interview personnel to verify that 1 Not Applicable When implemented properly, evolving malware threats are monitored TAVE will remove the PCI DSS and evaluated for systems not currently validation requirements for all considered to be commonly affected by server components located on malicious software, in order to confirm the merchant’s host network. whether such systems continue to not Anti-virus and anti-malware require anti-virus software. requirements will not be applicable.

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 1 Not Applicable When implemented properly, verify that anti- virus software and TAVE will remove the PCI DSS definitions are required to be kept up-to- validation requirements for all date. server components located on the merchant’s host network. Anti-virus and anti-malware requirements will not be applicable.

5.2.b Examine anti-virus configurations, 1 Not Applicable When implemented properly, including the master installation of the TAVE will remove the PCI DSS software validation requirements for all server components located on the merchant’s host network. Anti-virus and anti-malware requirements will not be applicable.

5.2.c Examine a sample of system 1 Not Applicable When implemented properly, components, including all operating TAVE will remove the PCI DSS system types commonly affected by validation requirements for all malicious software, to verify that: server components located on the merchant’s host network.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

 The anti-virus software and definitions Anti-virus and anti-malware are current. requirements will not be  Periodic scans are performed. applicable.

5.2.d Examine anti-virus configurations, 1 Not Applicable When implemented properly, including the master installation of the TAVE will remove the PCI DSS software and a sample of system validation requirements for all components, to verify that: server components located on the merchant’s host network.  Anti-virus software log generation is Anti-virus and anti-malware enabled, and requirements will not be  Logs are retained in accordance with applicable. 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, 1 Not Applicable When implemented properly, including the master installation of the TAVE will remove the PCI DSS software and a sample of system validation requirements for all components, to verify the anti- virus server components located on software is actively running. the merchant’s host network. Anti-virus and anti-malware requirements will not be applicable.

5.3.b Examine anti-virus configurations, 1 Not Applicable When implemented properly, including the master installation of the TAVE will remove the PCI DSS software and a sample of system validation requirements for all components, to verify that the anti-virus server components located on software cannot be disabled or altered by the merchant’s host network. users. Anti-virus and anti-malware requirements will not be applicable.

5.3.c Interview responsible personnel and 1 Not Applicable When implemented properly, observe processes to verify that anti-virus TAVE will remove the PCI DSS software cannot be disabled or altered by validation requirements for all users, unless specifically authorized by server components located on management on a case-by-case basis for a the merchant’s host network. limited time period. Anti-virus and anti-malware requirements will not be applicable.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

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 1 Not Applicable When implemented properly, personnel to verify that security policies TAVE will remove the PCI DSS and operational procedures for protecting validation requirements for all systems against malware are: server components located on the merchant’s host network.  Documented, Anti-virus and anti-malware  In use, and requirements will not be  Known to all affected parties. applicable.

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 2 Vulnerability Alerting Even with the significant verify that processes are defined for the Procedures reduction of applicable controls following: TAVE obtains, Coalfire feels that merchants should still document  To identify new security vulnerabilities. the POI devices and payment  To assign a risk ranking to system’s vulnerability alerting vulnerabilities that includes processes. identification of all “high risk” and “critical” vulnerabilities.  To include using reputable outside sources for security vulnerability `information. 6.1.b Interview responsible personnel and 2 Vulnerability Alerting Even with the significant observe processes to verify that: Procedures reduction of applicable controls TAVE obtains, Coalfire feels that  New security vulnerabilities are merchants should still document identified. the POI devices and payment  A risk ranking is assigned to system’s vulnerability alerting vulnerabilities that includes processes. identification of all “high” risk and “critical” vulnerabilities.  Processes to identify new security vulnerabilities include using reputable outside sources for security vulnerability information. 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.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

6.2.a Examine policies and procedures 1 Not Applicable When implemented properly, related to security- patch installation to TAVE will remove the PCI DSS verify processes are defined for: validation requirements for all system components located on  Installation of applicable critical the merchant’s host network vendor-supplied security patches (outside of the POI devices). within one month of release. Patch management procedures  Installation of all applicable vendor- for various system components supplied security patches within an will not be applicable. appropriate time frame (for example, within three months). 6.2.b For a sample of system components 1 Not Applicable When implemented properly, and related software TAVE will remove the PCI DSS validation requirements for all  Identify the sample of system system components located on components and related software the merchant’s host network selected for this testing (outside of the POI devices). procedure. Patch management procedures  For each item in the sample, for various system components describe how the list of security will not be applicable. patches installed on each system was compared to the most recent vendor security-patch list to verify that: 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- 1 Not Applicable This control will be not applicable development processes to verify that the for merchants utilizing TAVE as processes are based on industry standards there will be no self-developed and/or best practices. payment applications within the CDE.

6.3.b Examine written software 1 Not Applicable This control should not apply for development processes to verify that merchants utilizing TAVE as there information security is included will be no self-developed throughout the life cycle. payment applications within the CDE. As such, software development processes

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

documentation will not be applicable.

6.3.c Examine written software 1 Not Applicable This control should not apply for development processes to verify that merchants utilizing TAVE as there software applications are developed in will be no self-developed accordance with PCI DSS. payment applications within the CDE. As such, software development processes documentation will not be applicable.

6.3.d Interview software developers to 1 Not Applicable This control will be not applicable verify that written software development for merchants utilizing TAVE as processes are implemented. there will be no self-developed payment applications within the CDE.

6.3.1 Examine written software- 1 Not Applicable This control should not apply for development procedures and interview merchants utilizing TAVE as there responsible personnel to verify that pre- will be no self-developed production and/or custom application payment applications within the accounts, user IDs and/or passwords are CDE. As such, software removed before an application goes into development processes production or is released to customers. documentation will not be applicable.

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 1 Not Applicable This control should not apply for development procedures and interview merchants utilizing TAVE as there responsible personnel to verify that all will be no self-developed custom application code changes must be payment applications within the reviewed (using either manual or CDE. As such, software automated processes) as follows: development processes documentation will not be  Code changes are reviewed by applicable. individuals other than the originating

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

code author, and by individuals who are knowledgeable in code review techniques and secure coding practices.  Code reviews ensure code is developed according to secure coding guidelines (see PCI DSS Requirement 6.5).  Appropriate corrections are implemented prior to release.  Code-review results are reviewed and approved by management prior to release. 6.3.2.b Select a sample of recent custom 1 Not Applicable This control will be not applicable application changes and verify that custom for merchants utilizing TAVE as application code is reviewed according to there will be no self-developed 6.3.2.a, above. payment applications within the CDE.

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 1 Not Applicable When implemented properly, verify the following are defined: TAVE will remove the PCI DSS validation requirements for all  Development/test environments are system components located on separate from production the merchant’s host network environments with access control in (outside of the POI devices). place to enforce separation. Change control processes and  A separation of duties between procedures for various system personnel assigned to the components will not be development/test environments and applicable. 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.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

6.4.1.a Examine network documentation 1 Not Applicable When implemented properly, and network device configurations to TAVE will remove the PCI DSS verify that the development/test validation requirements for all environments are separate from the system components located on production environment(s). the merchant’s host network (outside of the POI devices).

6.4.1.b Examine access controls settings to 1 Not Applicable When implemented properly, verify that access controls are in place to TAVE will remove the PCI DSS enforce separation between the validation requirements for all development/test environments and the system components located on production environment(s). the merchant’s host network (outside of the POI devices).

6.4.2 Observe processes and interview 1 Not Applicable When implemented properly, personnel assigned to development/test TAVE will remove the PCI DSS environments and personnel assigned to validation requirements for all production environments to verify that system components located on separation of duties is in place between the merchant’s host network development/test environments and the (outside of the POI devices). production environment.

6.4.3.a Observe testing processes and 1 Not Applicable When implemented properly, interview personnel to verify procedures TAVE will remove the PCI DSS are in place to ensure production data validation requirements for all (live PANs) are not used for testing or system components located on development. 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 1 Not Applicable When implemented properly, verify production data (live PANs) is not TAVE will remove the PCI DSS used for testing or development. validation requirements for all system components located on the merchant’s host network (outside of the POI devices).

6.4.4.a Observe testing processes and 1 Not Applicable When implemented properly, interview personnel to verify test data and TAVE will remove the PCI DSS accounts are removed before a production validation requirements for all system becomes active. system components located on

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

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

6.4.4.b Examine a sample of data and 1 Not Applicable When implemented properly, accounts from production systems TAVE will remove the PCI DSS recently installed or updated to verify test validation requirements for all data and accounts are removed before the system components located on system becomes active. the merchant’s host network (outside of the POI devices).

6.4.5.a Examine documented change- 2 Change control Change control procedures control procedures related to procedures POI devices should not apply for all of the implementing security patches and merchant environment; however, software modifications and verify Coalfire recommends change procedures are defined for: control processes be used for tracking POI devices within the  Documentation of impact. environment. Change  Documented change approval by management processes for other authorized parties. systems would be not applicable.  Functionality testing to verify that the change does not adversely impact the security of the system.  Back-out procedures. 6.4.5.b For a sample of system 2 Change control Change control procedures components, interview responsible procedures POI devices should not apply for all of the personnel to determine recent merchant environment; however, changes/security patches. Trace those Coalfire recommends change changes back to related change control control processes be used for documentation. For each change tracking POI devices within the examined, perform the following: environment. Change management processes for other For each item in the sample, identify the systems would be not applicable. 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 2 Change control Change control procedures impact is included in the change control procedures POI devices should not apply for all of the documentation for each sampled change. merchant environment; however, Coalfire recommends change control processes be used for tracking POI devices within the

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

environment. Change management processes for other systems would be not applicable.

6.4.5.2 Verify that documented approval 2 Change control Change control procedures by authorized parties is present for each procedures POI devices should not apply for all of the sampled change. 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.3.a For each sampled change, verify 2 Change control Change control procedures that functionality testing is performed to procedures POI devices should not apply for all of the verify that the change does not adversely merchant environment; however, impact the security of the system. 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.3.b For custom code changes, verify 1 Not Applicable This control will be not applicable that all updates are tested for compliance for merchants utilizing TAVE as with PCI DSS Requirement 6.5 before being there will be no self-developed deployed into production. payment applications within the CDE.

6.4.5.4 Verify that back-out procedures are 2 Change control Change control procedures prepared for each sampled change. procedures POI devices 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.5 Address common coding vulnerabilities in software-development processes as follows:

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

 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 1 Not Applicable This control should not apply for policies and procedures to verify that merchants utilizing TAVE as there training in secure coding techniques is will be no self-developed required for developers, based on industry payment applications within the best practices and guidance. CDE. As such, software development processes documentation will not be applicable.

6.5.b Interview a sample of developers to 1 Not Applicable This control will be not applicable verify that they are knowledgeable in for merchants utilizing TAVE as secure coding techniques. there will be no self-developed payment applications within the CDE.

6.5.c Examine records of training to verify 1 Not Applicable This control will be not applicable that software developers received training for merchants utilizing TAVE as on secure coding techniques, including there will be no self-developed how to avoid common coding payment applications within the vulnerabilities, and understanding how CDE. sensitive data is handled in memory.

6.5.d. Verify that processes are in place to 1 Not Applicable This control will be not applicable protect applications from, at a minimum, for merchants utilizing TAVE as the following vulnerabilities: there will be no self-developed payment applications within the CDE.

6.5.1 Examine software- development 1 Not Applicable This control will be not applicable policies and procedures and interview for merchants utilizing TAVE as responsible personnel to verify that there will be no self-developed injection flaws are addressed by coding payment applications within the techniques that include: CDE. As such, software development procedures and  Validating input to verify user data secure coding documentation will cannot modify meaning of commands not be applicable. and queries.  Utilizing parameterized queries.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

6.5.2 Examine software- development 1 Not Applicable This control should not apply for policies and procedures and interview merchants utilizing TAVE as there will be no self-developed For the interviews at 6.5.d, summarize the payment applications within the relevant interview details that confirm CDE. As such, software processes are in place, consistent with the development procedures and software development documentation at secure coding documentation will 6.5.d, to ensure that buffer overflows are not be applicable. addressed by coding techniques that include:

6.5.3 Examine software- development 1 Not Applicable This control should not apply for policies and procedures and interview merchants utilizing TAVE as there responsible personnel to verify that will be no self-developed insecure cryptographic storage is payment applications within the addressed by coding techniques that: CDE. As such, software development procedures and  Prevent cryptographic flaws. secure coding documentation will  Use strong cryptographic algorithms not be applicable. and keys. 6.5.4 Examine software- development 1 Not Applicable This control should not apply for policies and procedures and interview merchants utilizing TAVE as there responsible personnel to verify that will be no self-developed insecure communications are addressed payment applications within the by coding techniques that properly CDE. As such, software authenticate and encrypt all sensitive development procedures and communications. secure coding documentation will not be applicable.

6.5.5 Examine-software development 1 Not Applicable This control should not apply for policies and procedures and interview merchants utilizing TAVE as there responsible personnel to verify that will be no self-developed improper error handling is addressed by payment applications within the coding techniques that do not leak CDE. As such, software information via error messages (for development procedures and example, by returning generic rather than secure coding documentation will specific error details). not be applicable.

6.5.6 Examine software- development 1 Not Applicable This control should not apply for policies and procedures and interview merchants utilizing TAVE as there responsible personnel to verify that will be no self-developed coding techniques address any “high risk” payment applications within the vulnerabilities that could affect the CDE. As such, software development procedures and

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value application, as identified in PCI DSS secure coding documentation will Requirement 6.1. not be applicable.

6.5.7 Examine software- development 1 Not Applicable This control should not apply for policies and procedures and interview merchants utilizing TAVE as there responsible personnel to verify that cross- will be no self-developed site scripting (XSS) is addressed by coding payment applications within the techniques that include: CDE. As such, software development procedures and  Validating all parameters before secure coding documentation will inclusion. not be applicable.  Utilizing context-sensitive escaping. 6.5.8 Examine software- development 1 Not Applicable This control should not apply for policies and procedures and interview merchants utilizing TAVE as there responsible personnel to verify that will be no self-developed improper access control— such as payment applications within the insecure direct object references, failure CDE. As such, software to restrict URL access, and directory development procedures and traversal—is addressed by coding secure coding documentation will technique that include: not be applicable.

 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 1 Not Applicable This control should not apply for policies and procedures and interview merchants utilizing TAVE as there responsible personnel to verify that cross- will be no self-developed site request forgery (CSRF) is addressed by payment applications within the coding techniques that ensure CDE. As such, software applications do not rely on authorization development procedures and credentials and tokens automatically secure coding documentation will submitted by browsers. not be applicable.

6.5.10 Examine software development 1 Not Applicable This control should not apply for policies and procedures and interview merchants utilizing TAVE as there responsible personnel to verify that will be no self-developed broken authentication and session payment applications within the CDE. As such, software

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value management are addressed via coding development procedures and techniques that commonly include: secure coding documentation will not be applicable.  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.

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, 1 Not Applicable This control will not be applicable ensure that either one of the following for merchants utilizing TAVE as methods is in place as follows: this solution is not a web application requiring application  Examine documented processes, security assessments or interview personnel, and examine automated technical solution to records of application security detect and prevent web-based assessments to verify that public-facing attacks. Public-facing web web applications are reviewed— using applications are not in scope for either manual or automated this paper. 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

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

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

6.7 Examine documentation and interview 1 Not Applicable Security policies and operational personnel to verify that security policies procedures documentation for and operational procedures for maintaining secure systems and developing and maintaining secure applications would not be systems and applications are: applicable.

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

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 1 Not Applicable When implemented properly, control, and verify that the policy TAVE will remove the PCI DSS incorporates 7.1.1 through 7.1.4 as validation requirements for all follows: system components located on the merchant’s host network  Defining access needs and (outside of the POI devices). privilege assignments for each Access control policies will not be role. applicable for the merchant  Restriction of access to privileged environment. user IDs to least privileges necessary to perform job responsibilities.  Assignment of access based on individual personnel’s job classification and function.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

 Documented approval (electronically or in writing) by authorized parties for all access, including listing of specific privileges approved. 7.1.1 Select a sample of roles and verify 1 Not Applicable When implemented properly, access needs for each role are defined and TAVE will remove the PCI DSS include: validation requirements for all system components located on  System components and data the merchant’s host network resources that each role needs to (outside of the POI devices). access for their job function. Access control restriction  Identification of privilege requirements would not be necessary for each role to applicable. perform their job function. 7.1.2.a Interview personnel responsible 1 Not Applicable When implemented properly, for assigning access to verify that access to TAVE will remove the PCI DSS privileged user IDs is: validation requirements for all system components located on  Assigned only to roles that the merchant’s host network specifically require such (outside of the POI devices). privileged access. Access control restriction  Restricted to least privileges requirements would not be necessary to perform job applicable. responsibilities. 7.1.2.b Select a sample of user IDs with 1 Not Applicable When implemented properly, privileged access and interview TAVE will remove the PCI DSS responsible management personnel to validation requirements for all verify that privileges assigned are: system components located on the merchant’s host network  Necessary for that individual’s job (outside of the POI devices). function. Access control restriction  Restricted to least privileges requirements would not be necessary to perform job applicable. responsibilities. 7.1.3 Select a sample of user IDs and 1 Not Applicable When implemented properly, interview responsible management TAVE will remove the PCI DSS personnel to verify that privileges assigned validation requirements for all are based on that individual’s job system components located on classification and function. the merchant’s host network (outside of the POI devices). Access control restriction

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

requirements would not be applicable.

7.1.4 Select a sample of user IDs and 1 Not Applicable When implemented properly, compare with documented approvals to TAVE will remove the PCI DSS verify that: validation requirements for all system components located on  Documented approval exists for the merchant’s host network the assigned privileges. (outside of the POI devices).  The approval was by authorized Access control restriction parties. requirements would not be  That specified privileges match applicable. 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:

7.2.1 Confirm that access control systems 1 Not Applicable When implemented properly, are in place on all system components. TAVE 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 1 Not Applicable When implemented properly, are configured to enforce privileges TAVE will remove the PCI DSS assigned to individuals based on job validation requirements for all classification and function. 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.3 Confirm that the access control 1 Not Applicable When implemented properly, systems have a default “deny-all” setting. TAVE will remove the PCI DSS validation requirements for all system components located on the merchant’s host network

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

(outside of the POI devices). Access control system implementation requirements would not be applicable.

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 1 Not Applicable Merchant will have no access to personnel to verify that security policies cardholder data, security policies and operational procedures for restricting and operational procedures access to cardholder data are: documentation for restricting access to cardholder data would  Documented, not be applicable.  In use, and  Known to all affected parties. 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 1 Not Applicable When implemented properly, define processes for each of the items TAVE will remove the PCI DSS below at 8.1.1 through 8.1.8. 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.1 Interview administrative personnel 1 Not Applicable When implemented properly, to confirm that all users are assigned a TAVE will remove the PCI DSS unique ID for access to system validation requirements for all components or cardholder data. 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.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

8.1.2 For a sample of privileged user IDs 1 Not Applicable When implemented properly, and general user IDs, examine associated TAVE will remove the PCI DSS authorizations and observe system validation requirements for all settings to verify each user ID and system components located on privileged user ID has been implemented the merchant’s host network with only the privileges specified on the (outside of the POI devices). User documented approval. identification management procedures for merchant environments would not be applicable.

8.1.3.a Select a sample of users 1 Not Applicable When implemented properly, terminated in the past six months, and TAVE will remove the PCI DSS review current user access lists—for both validation requirements for all local and remote access—to verify that system components located on their IDs have been deactivated or the merchant’s host network removed from the access lists. (outside of the POI devices). User identification management procedures for merchant environments would not be applicable.

8.1.3.b Verify all physical authentication 1 Not Applicable When implemented properly, methods—such as, smart cards, tokens, TAVE will remove the PCI DSS etc.— have been returned or deactivated. 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.4 Observe user accounts to verify that 1 Not Applicable When implemented properly, any inactive accounts over 90 days old are TAVE will remove the PCI DSS either removed or disabled. 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.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

8.1.5.a Interview personnel and observe 1 Not Applicable When implemented properly, processes for managing accounts used by TAVE will remove the PCI DSS vendors to access, support, or maintain validation requirements for all system components to verify that system components located on accounts used by vendors for remote the merchant’s host network access are: (outside of the POI devices). Vendor remote access  Disabled when not in use. management procedures will not  Enabled only when needed by the be applicable. vendor, and disabled when not in use. 8.1.5.b Interview personnel and observe 1 Not Applicable When implemented properly, processes to verify that vendor remote TAVE will remove the PCI DSS access accounts are monitored while validation requirements for all being used. 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 1 Not Applicable When implemented properly, components, inspect system configuration TAVE will remove the PCI DSS settings to verify that authentication validation requirements for all parameters are set to require that user system components located on accounts be locked out after not more the merchant’s host network than six invalid logon attempts. (outside of the POI devices). Authentication parameter settings for various system components will not be applicable.

8.1.6.b Additional procedure for service 1 Not Applicable Not applicable in merchant providers: Review internal processes and environments. 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.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

8.1.7 For a sample of system components, 1 Not Applicable When implemented properly, inspect system configuration settings to TAVE will remove the PCI DSS verify that password parameters are set validation requirements for all to require that once a user account is system components located on locked out, it remains locked for a the merchant’s host network minimum of 30 minutes or until a system (outside of the POI devices). administrator resets the account. Authentication parameter settings for various system components will not be applicable.

8.1.8 For a sample of system components, 1 Not Applicable When implemented properly, inspect system configuration settings to TAVE will remove the PCI DSS verify that system/session idle time out validation requirements for all features have been set to 15 minutes or system components located on less. the merchant’s host network (outside of the POI devices).

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 1 Not Applicable Merchants will not have access to using unique ID and additional cardholder data. As such, user authentication (for example, a password) authentication management for access to the cardholder data requirements will not be environment, perform the following: applicable.

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

8.2.1.a Examine vendor documentation 1 Not Applicable When implemented properly, and system configuration settings to verify TAVE will remove the PCI DSS that passwords are protected with strong validation requirements for all cryptography during transmission and system components located on storage. the merchant’s host network (outside of the POI devices). User- authentication password protection requirements will not be applicable.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

8.2.1.b For a sample of system 1 Not Applicable When implemented properly, components, examine password files to TAVE will remove the PCI DSS verify that passwords are unreadable validation requirements for all during storage. 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 1 Not Applicable When implemented properly, components, examine data transmissions TAVE will remove the PCI DSS to verify that passwords are unreadable validation requirements for all during transmission. 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 1 Not Applicable Not applicable in merchant providers: Observe password files to verify environments. that customer passwords are unreadable during storage.

8.2.1.e Additional procedure for service 1 Not Applicable Not applicable in merchant providers: Observe data transmissions to environments. verify that customer passwords are unreadable during transmission.

8.2.2 Examine authentication procedures 1 Not Applicable When implemented properly, for modifying authentication credentials TAVE will remove the PCI DSS and observe security personnel to verify validation requirements for all that, if a user requests a reset of an system components located on authentication credential by phone, e- the merchant’s host network mail, web, or other non-face-to-face (outside of the POI devices). method, the user’s identity is verified Authentication procedures for before the authentication credential is users will not be applicable. modified.

8.2.3.a For a sample of system 1 Not Applicable When implemented properly, components, inspect system configuration TAVE will remove the PCI DSS settings to verify that user password validation requirements for all system components located on

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value parameters are set to require at least the the merchant’s host network following strength/complexity: (outside of the POI devices). Password parameter settings for  Require a minimum length of at various system components will least seven characters. not be applicable.  Contain both numeric and alphabetic characters. 8.2.3.b Additional procedure for service 1 Not Applicable Not applicable in merchant providers: Review internal processes and environments. 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 1 Not Applicable When implemented properly, components, inspect system configuration TAVE will remove the PCI DSS settings to verify that user password validation requirements for all parameters are set to require users to system components located on change passwords at least every 90 days. 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 1 Not Applicable Not applicable in merchant providers: Review internal processes and environments. 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 1 Not Applicable When implemented properly, components, obtain and inspect system TAVE will remove the PCI DSS configuration settings to verify that validation requirements for all password parameters are set to require system components located on the merchant’s host network

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value that new passwords cannot be the same (outside of the POI devices). 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 1 Not Applicable Not applicable in merchant providers, review internal processes and environments. 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 1 Not Applicable When implemented properly, observe security personnel to verify that TAVE will remove the PCI DSS first-time passwords for new users, and validation requirements for all reset passwords for existing users, are set system components located on to a unique value for each user and the merchant’s host network changed after first use. (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 1 Not Applicable When implemented properly, remote access servers and systems to TAVE will remove the PCI DSS verify two-factor authentication is validation requirements for all required for: system components located on the merchant’s host network  All remote access by personnel. (outside of the POI devices). Two-  All third-party/vendor remote factor authentication for remote access (including access to network access will not be applications and system applicable. components for support or maintenance purposes). 8.3.b Observe a sample of personnel (for 1 Not Applicable When implemented properly, example, users and administrators) TAVE will remove the PCI DSS connecting remotely to the network and validation requirements for all verify that at least two of the three system components located on authentication methods are used. the merchant’s host network (outside of the POI devices). Two-factor authentication for

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

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.  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 1 Not Applicable When implemented properly, personnel to verify that authentication TAVE will remove the PCI DSS procedures and policies are distributed to validation requirements for all all users. 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 1 Not Applicable When implemented properly, and policies that are distributed to users TAVE will remove the PCI DSS and verify they include: validation requirements for all system components located on  Guidance on selecting strong the merchant’s host network authentication credentials. (outside of the POI devices).  Guidance for how users should protect Authentication procedures and their authentication credentials. policies requirements will not be  Instructions for users not to reuse applicable. 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 1 Not Applicable When implemented properly, that they are familiar with authentication TAVE will remove the PCI DSS procedures and policies. 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.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

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. 8.5.a For a sample of system components, 1 Not Applicable When implemented properly, examine user ID lists to verify the following. TAVE will remove the PCI DSS validation requirements for all  Generic user IDs are disabled or system components located on removed. the merchant’s host network  Shared user IDs for system (outside of the POI devices). 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 1 Not Applicable When implemented properly, policies/procedures to verify that use of TAVE will remove the PCI DSS group and shared IDs and/or passwords or validation requirements for all other authentication methods are explicitly system components located on prohibited. the merchant’s host network (outside of the POI devices). Authentication procedures and policies requirements will not be applicable.

8.5.c Interview system administrators to 1 Not Applicable When implemented properly, verify that group and shared IDs and/or TAVE will remove the PCI DSS passwords or other authentication validation requirements for all methods are not distributed, even if system components located on requested. the merchant’s host network (outside of the POI devices). Authentication procedures and policies requirements will not be applicable.

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.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

8.5.1 Additional requirement for service 1 Not Applicable Not applicable in merchant providers: environments.

Examine authentication policies and procedures and interview personnel to verify that different authentication are used for access to each customer. 8.6.a Examine authentication policies and 1 Not Applicable When implemented properly, procedures to verify that procedures for TAVE will remove the PCI DSS using authentication mechanisms such as validation requirements for all physical security tokens, smart cards, and system components located on certificates are defined and include: the merchant’s host network (outside of the POI devices).  Authentication mechanisms are Authentication procedures and assigned to an individual account and policies requirements will not be not shared among multiple accounts. applicable.  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 1 Not Applicable When implemented properly, authentication mechanisms are assigned TAVE will remove the PCI DSS to an account and not shared among validation requirements for all multiple accounts. system components located on the merchant’s host network (outside of the POI devices). Authentication procedures and policies requirements will not be applicable.

8.6.c Examine system configuration 1 Not Applicable When implemented properly, settings and/or physical controls, as TAVE will remove the PCI DSS applicable, to verify that controls are validation requirements for all implemented to ensure only the intended system components located on account can use that mechanism to gain the merchant’s host network access. (outside of the POI devices).

8.7.a Review database and application 1 Not Applicable There will be no cardholder data configuration settings and verify that all repositories when TAVE is users are authenticated prior to access. implemented properly.

8.7.b Examine database and application 1 Not Applicable There will be no cardholder data configuration settings to verify that all user repositories when TAVE is access to, user queries of, and user actions implemented properly. on (for example, move, copy, delete), the

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value database are through programmatic methods only (for example, through stored procedures).

8.7.c Examine database access control 1 Not Applicable There will be no cardholder data settings and database application repositories when TAVE is configuration settings to verify that user implemented properly. direct access to or queries of databases are restricted to database administrators.

8.7.d Examine database access control 1 Not Applicable There will be no cardholder data settings, database application repositories when TAVE is configuration settings, and the related implemented properly. 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 1 Not Applicable Merchant will have no access to personnel to verify that security policies cardholder data, security policies and operational procedures for and operational procedures identification and authentication are: documentation for identification and authentication would not be  Documented, applicable.  In use, and  Known to all affected parties.

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 2 Physical Security Policy Appropriate physical controls to controls for each computer room, data ensure that the POI devices center, and other physical areas with cannot be physically altered, systems in the cardholder data perimeter devices are properly environment. protected should be in place. Physical controls also apply to  Verify that access is controlled with protection of paper media badge readers or other devices containing cardholder data. 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

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

that they are “locked” to prevent unauthorized use.

9.1.1.a Verify that video cameras and/or 1 Not Applicable This control requirement will access control mechanisms are in place to be not applicable since monitor the entry/exit points to sensitive there won't be any "sensitive" areas. areas in the merchant environment outside of the POI terminals.

9.1.1.b Verify that video cameras and/or 1 Not Applicable This control requirement will access control mechanisms are protected be not applicable since from tampering or disabling. 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 1 Not Applicable This control requirement will access control mechanisms are monitored be not applicable since and that data from cameras or other there won't be any "sensitive" mechanisms is stored for at least three areas in the merchant months. environment outside of the POI terminals

9.1.2 Interview responsible personnel and 2 Physical Security Policy Appropriate physical controls to observe locations of publicly accessible ensure that the POI devices network jacks to verify that physical cannot be physically altered, and/or logical controls are in place to perimeter devices are properly restrict access to publicly accessible protected should be in place. network jacks. Physical controls also apply to protection of paper media containing cardholder data.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

9.1.3 Verify that physical access to wireless 1 Not Applicable When implemented properly, access points, gateways, handheld devices, TAVE will remove the PCI DSS networking/communications hardware, validation requirements for the and telecommunication lines is merchant’s host network. 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 2 Physical Security Policy Cardholder data will not be verify that procedures are defined for accessible within the merchant identifying and distinguishing between environment; therefore, the onsite personnel and visitors. applicability of this requirement can be greatly reduced; however, Verify procedures include the following: controls should ensure that unauthorized visitors cannot  Identifying new onsite personnel or access perimeter systems or POI visitors (for example, assigning devices. badges),  Changing access requirements, and  Revoking terminated onsite personnel and expired visitor identification (such as ID badges) 9.2.b Observe processes for identifying 2 Physical Security Policy Cardholder data will not be and distinguishing between onsite accessible within the merchant personnel and visitors to verify that: environment; therefore, the applicability of this requirement  Visitors are clearly identified, and can be greatly reduced; however,  It is easy to distinguish between controls should ensure that onsite personnel and visitors. unauthorized visitors cannot access perimeter systems or POI devices.

9.2.c Verify that access to the 2 Physical Security Policy Cardholder data will not be identification process (such as a badge accessible within the merchant system) is limited to authorized personnel. environment; therefore, the applicability of this requirement can be greatly reduced; however, controls should ensure that unauthorized visitors cannot

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

access perimeter systems or POI devices.

9.2.d Examine identification methods 2 Physical Security Policy Cardholder data will not be (such as ID badges) in use to verify that accessible within the merchant they clearly identify visitors and it is easy environment; therefore, the to distinguish between onsite personnel applicability of this requirement and visitors. can be greatly reduced; however, controls should ensure that unauthorized visitors cannot access perimeter systems or POI devices.

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 2 Physical Security Policy Cardholder data will not be physical access to the CDE, interview accessible within the merchant responsible personnel and observe access environment; therefore, the control lists to verify that: applicability of this requirement can be greatly reduced; however,  Access to the CDE is authorized. controls should ensure that  Access is required for the unauthorized users cannot access individual’s job function. perimeter systems or POI devices.

9.3.b Observe personnel access the CDE to 2 Physical Security Policy Cardholder data will not be verify that all personnel are authorized accessible within the merchant before being granted access. 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 2 Physical Security Policy Cardholder data will not be terminated employees and review access accessible within the merchant control lists to verify the personnel do not environment; therefore, the have physical access to the CDE. applicability of this requirement

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

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 2 Physical Security Policy Cardholder data will not be personnel to verify that visitors must be accessible within the merchant authorized before they are granted access environment; therefore, the to, and escorted at all times within, areas applicability of this requirement where cardholder data is processed or maintained. can be greatly reduced; however, controls should ensure that unauthorized visitors cannot access perimeter systems or POI devices.

9.4.1.b Observe the use of visitor badges 2 Physical Security Policy Cardholder data will not be or other identification to verify that a accessible within the merchant physical token badge does not permit environment; therefore, the unescorted access to physical areas where applicability of this requirement cardholder data is processed or maintained. can be greatly reduced; however, controls should ensure that unauthorized visitors cannot access perimeter systems or POI devices.

9.4.2.a Observe people within the facility 2 Physical Security Policy Cardholder data will not be to verify the use of visitor badges or other accessible within the merchant identification, and that visitors are easily environment; therefore, the distinguishable from onsite personnel. applicability of this requirement can be greatly reduced; however, controls should ensure that unauthorized visitors cannot access perimeter systems or POI devices.

9.4.2.b Verify that visitor badges or other 2 Physical Security Policy Cardholder data will not be identification expire. accessible within the merchant environment; therefore, the applicability of this requirement can be greatly reduced; however, controls should ensure that unauthorized visitors cannot

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

access perimeter systems or POI devices.

9.4.3 Observe visitors leaving the facility to 2 Physical Security Policy Cardholder data will not be verify visitors are asked to surrender their accessible within the merchant badge or other identification upon environment; therefore, the departure or expiration. applicability of this requirement

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

9.4.4.a Verify that a visitor log is in use to 2 Physical Security Policy Cardholder data will not be record physical access to the facility as well accessible within the merchant as computer rooms and data centers environment; therefore, the where cardholder data is stored or applicability of this requirement transmitted. can be greatly reduced; however, controls should ensure that unauthorized visitors cannot access perimeter systems or POI devices.

9.4.4.b Verify that the log contains: 2 Physical Security Policy Cardholder data will not be  The visitor’s name, accessible within the merchant  The firm represented, and environment; therefore, the  The onsite personnel authorizing applicability of this requirement physical access. can be greatly reduced; however,

controls should ensure that unauthorized visitors cannot access perimeter systems or POI devices.

9.4.4.c Verify that the log is retained for at 2 Physical Security Policy Cardholder data will not be least three months. accessible within the merchant environment; therefore, the applicability of this requirement can be greatly reduced; however, controls should ensure that unauthorized visitors cannot

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

access perimeter systems or POI devices.

9.5 Physically secure all media.

9.5 Verify that procedures for protecting 2 Physical Security Policy If the merchant has any paper cardholder data include controls for based processes associated with physically securing all media (including but Data Retention and this payment channel then this not limited to computers, removable Storage Policies (if requirement will still apply to electronic media, paper receipts, paper applicable) reports, and faxes). their environment. Otherwise, this requirement can be considered not applicable.

9.5.1.a Observe the storage location’s 2 Physical Security Policy If the merchant has any paper physical security to confirm that backup based processes associated with media storage is secure. Data Retention and this payment channel then this Storage Policies (if requirement will still apply to applicable) their environment. Otherwise, this requirement can be considered not applicable.

9.5.1.b Verify that the storage location 2 Physical Security Policy If the merchant has any paper security is reviewed at least annually. based processes associated with Data Retention and this payment channel then this Storage Policies (if requirement will still apply to applicable) their environment. Otherwise, this requirement can be considered not applicable.

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 2 Data Retention and If the merchant has any paper distribution of media, and that the policy Storage Policies (if based processes associated with covers all distributed media including that applicable) this payment channel then this distributed to individuals. requirement will still apply to their environment. Otherwise, this requirement can be considered not applicable.

9.6.1 Verify that all media is classified so 2 Data Retention and If the merchant has any paper the sensitivity of the data can be Storage Policies (if based processes associated with determined. applicable) this payment channel then this requirement will still apply to their environment. Otherwise,

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

this requirement can be considered not applicable.

9.6.2.a Interview personnel and examine 2 Data Retention and If the merchant has any paper records to verify that all media sent Storage Policies (if based processes associated with outside the facility is logged and sent via applicable) this payment channel then this secured courier or other delivery method requirement will still apply to that can be tracked. their environment. Otherwise, this requirement can be considered not applicable.

9.6.2.b Select a recent sample of several 2 Data Retention and If the merchant has any paper days of offsite tracking logs for all media, Storage Policies (if based processes associated with and verify tracking details are applicable) this payment channel then this documented. requirement will still apply to their environment. Otherwise, this requirement can be considered not applicable.

9.6.3 Select a recent sample of several 2 Data Retention and If the merchant has any paper days of offsite tracking logs for all media. Storage Policies (if based processes associated with From examination of the logs and applicable) this payment channel then this interviews with responsible personnel, requirement will still apply to verify proper management authorization is obtained whenever media is moved from a their environment. Otherwise, secured area (including when media is this requirement can be distributed to individuals). considered not applicable.

9.7 Maintain strict control over the storage and accessibility of media. 9.7 Obtain and examine the policy for 2 Data Retention and If the merchant has any paper controlling storage and maintenance of all Storage Policies (if based processes associated with media and verify that the policy requires applicable) this payment channel then this periodic media inventories. requirement will still apply to

their environment. Otherwise, this requirement can be considered not applicable.

9.7.1 Review media inventory logs to verify 2 Data Retention and If the merchant has any paper that logs are maintained and media Storage Policies (if based processes associated with inventories are performed at least applicable) this payment channel then this annually. requirement will still apply to their environment. Otherwise,

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

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 2 Data Retention and If the merchant has any paper destruction policy and verify that it covers Storage Policies (if based processes associated with all media and defines requirements for the applicable) this payment channel then this following: requirement will still apply to  Hard-copy materials must be crosscut their environment. Otherwise, shredded, incinerated, or pulped such that there is reasonable assurance the this requirement can be hard-copy materials cannot be considered not applicable. 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 2 Data Retention and If the merchant has any paper procedures to verify that hard-copy Storage Policies (if based processes associated with materials are crosscut shredded, applicable) this payment channel then this incinerated, or pulped such that there is requirement will still apply to reasonable assurance the hard-copy materials cannot be reconstructed. their environment. Otherwise, this requirement can be considered not applicable.

9.8.1.b Examine storage containers used 2 Data Retention and If the merchant has any paper for materials that contain information to Storage Policies (if based processes associated with be destroyed to verify that the containers applicable) this payment channel then this are secured. requirement will still apply to their environment. Otherwise, this requirement can be considered not applicable.

9.8.2 Verify that cardholder data on 1 Not Applicable There will be no electronic electronic media is rendered instances of cardholder data unrecoverable via a secure wipe program storage within the merchant in accordance with industry-accepted environment. standards for secure deletion, or otherwise physically destroying the media).

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

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 4 Device Protection policies This requirement is fully in-scope procedures to verify they include: and procedures for the merchant’s PCI-DSS  Maintaining a list of devices assessment.  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. 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 4 Device Protection policies This requirement is fully in-scope it includes: and procedures for the merchant’s PCI-DSS  Make, model of device assessment.  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 4 Device Protection policies This requirement is fully in-scope list and observe device locations to verify and procedures for the merchant’s PCI-DSS that the list is accurate and up to date. assessment.

9.9.1.c Interview personnel to verify the 4 Device Protection policies This requirement is fully in-scope list of devices is updated when devices are and procedures for the merchant’s PCI-DSS added, relocated, decommissioned, etc. assessment.

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 4 Device Protection policies This requirement is fully in-scope to verify processes are defined to include and procedures for the merchant’s PCI-DSS the following: assessment.  Procedures for inspecting devices  Frequency of inspections.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

9.9.2.b Interview responsible personnel 4 Device Protection policies This requirement is fully in-scope and observe inspection processes to verify: and procedures for the merchant’s PCI-DSS  Personnel are aware of procedures for assessment. inspecting devices.  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 4 Device Protection policies This requirement is fully in-scope personnel at point-of-sale locations to and procedures for the merchant’s PCI-DSS verify they include training in the assessment. 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 4 Device Protection policies This requirement is fully in-scope point-of-sale locations to verify they have and procedures for the merchant’s PCI-DSS received training and are aware of the assessment. 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

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

 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.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 4 Physical Security Policy This requirement is fully in-scope interview personnel to verify that security for the merchant’s PCI-DSS policies and operational procedures for Data Retention and assessment. restricting physical access to cardholder Storage Policies (if data are: applicable)  Documented,  In use, and Device Protection policies  Known to all affected parties. and procedures

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

10.1 Verify, through observation and 1 Not Applicable When implemented properly, interviewing the system administrator, TAVE will remove the PCI DSS that: validation requirements for all  Audit trails are enabled and active for system components located on system components. the merchant’s host network  Access to system components is linked to individual users. (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 1 Not Applicable. Merchant access to cardholder cardholder data is logged. will not be possible with the proper implementation of TAVE.

10.2.2 Verify all actions taken by any 1 Not Applicable When implemented properly, individual with root or administrative TAVE will remove the PCI DSS privileges are logged. validation requirements for all

system components located on

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

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.3 Verify access to all audit trails is 1 Not Applicable When implemented properly, logged. TAVE 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.4 Verify invalid logical access 1 Not Applicable When implemented properly, attempts are logged. TAVE 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.5.a Verify use of identification and 1 Not Applicable When implemented properly, authentication mechanisms is logged. TAVE 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.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

10.2.5.b Verify all elevation of privileges is 1 Not Applicable When implemented properly, logged. TAVE 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.5.c Verify all changes, additions, or 1 Not Applicable When implemented properly, deletions to any account with root or TAVE will remove the PCI DSS administrative privileges are logged. 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.6 Verify the following are logged: 1 Not Applicable When implemented properly,  Initialization of audit logs TAVE will remove the PCI DSS  Stopping or pausing of audit logs. 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.7 Verify creation and deletion of 1 Not Applicable When implemented properly, system level objects are logged. TAVE 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

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

implementation of audit trails requirements would not be applicable.

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 1 Not Applicable When implemented properly, in log entries. TAVE 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.3.2 Verify type of event is included in 1 Not Applicable When implemented properly, log entries. TAVE 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.3.3 Verify date and time stamp is 1 Not Applicable When implemented properly, included in log entries. TAVE 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.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

10.3.4 Verify success or failure indication is 1 Not Applicable When implemented properly, included in log entries. TAVE 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.3.5 Verify origination of event is 1 Not Applicable When implemented properly, included in log entries. TAVE 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.3.6 Verify identity or name of affected 1 Not Applicable When implemented properly, data, system component, or resources is TAVE will remove the PCI DSS included in log entries. 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.4 Examine configuration standards and 1 Not Applicable When implemented properly, processes to verify that time- TAVE will remove the PCI DSS synchronization technology is validation requirements for all implemented and kept current per PCI DSS system components located on Requirements 6.1 and 6.2. the merchant’s host network (outside of the POI devices). Time-synchronization standards

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

and requirements would not be applicable.

10.4.1.a Examine the process for acquiring, 1 Not Applicable When implemented properly, distributing and storing the correct time TAVE will remove the PCI DSS within the organization to verify that: validation requirements for all  Only the designated central time system components located on server(s) receives time signals from the merchant’s host network external sources, and time signals from external sources are based on (outside of the POI devices). International Atomic Time or UTC. Time-synchronization standards  Where there is more than one and requirements would not be designated time server, the time applicable. servers peer with one another to keep accurate time,  Systems receive time information only from designated central time server(s). 10.4.1.b Observe the time-related system- 1 Not Applicable When implemented properly, parameter settings for a sample of system TAVE will remove the PCI DSS components to verify: validation requirements for all  Only the designated central time system components located on server(s) receives time signals from the merchant’s host network external sources, and time signals from external sources are based on (outside of the POI devices). International Atomic Time or UTC. Time-synchronization standards  Where there is more than one and requirements would not be designated time server, the applicable. 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 1 Not Applicable When implemented properly, and time-synchronization settings to verify TAVE will remove the PCI DSS that access to time data is restricted to validation requirements for all only personnel with a business need to system components located on access time data. the merchant’s host network (outside of the POI devices). Time-synchronization standards and requirements would not be applicable.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

10.4.2.b Examine system configurations, 1 Not Applicable When implemented properly, time synchronization settings and logs, and TAVE will remove the PCI DSS processes to verify that any changes to validation requirements for all time settings on critical systems are system components located on logged, monitored, and reviewed. the merchant’s host network (outside of the POI devices). Time-synchronization standards and requirements would not be applicable.

10.4.3 Examine systems configurations to 1 Not Applicable When implemented properly, verify that the time server(s) accept time TAVE will remove the PCI DSS updates from specific, industry-accepted validation requirements for all external sources (to prevent a malicious system components located on individual from changing the clock). Optionally, those updates can be the merchant’s host network encrypted with a symmetric key, and (outside of the POI devices). access control lists can be created that Time-synchronization standards specify the IP addresses of client machines and requirements would not be that will be provided with the time applicable. updates (to prevent unauthorized use of internal time servers). 10.5 Secure audit trails so they cannot be altered.

10.5 Interview system administrators and 1 Not Applicable When implemented properly, examine system configurations and TAVE will remove the PCI DSS permissions to verify that audit trails are validation requirements for all secured so that they cannot be altered as system components located on follows 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- 1 Not Applicable When implemented properly, related need can view audit trail files. TAVE 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

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

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

10.5.2 Current audit trail files are 1 Not Applicable When implemented properly, protected from unauthorized TAVE will remove the PCI DSS modifications via access control validation requirements for all mechanisms, physical segregation, and/or system components located on network segregation. 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.3 Current audit trail files are promptly 1 Not Applicable When implemented properly, backed up to a centralized log server or TAVE will remove the PCI DSS media that is difficult to alter. 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.4 Logs for external-facing 1 Not Applicable When implemented properly, technologies (for example, wireless, TAVE will remove the PCI DSS firewalls, DNS, mail) are written onto a validation requirements for all secure, centralized, internal log server or system components located on media. 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

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

requirements would not be applicable.

10.5.5 Examine system settings, monitored 1 Not Applicable When implemented properly, files, and results from monitoring activities TAVE will remove the PCI DSS to verify the use of file-integrity validation requirements for all monitoring or change-detection software system components located on on logs. 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 1 Not Applicable When implemented properly, procedures to verify that procedures are TAVE will remove the PCI DSS defined for reviewing the following at least validation requirements for all daily, either manually or via log tools: system components located on  All security events the merchant’s host network  Logs of all system components that store, process, or transmit CHD and/or (outside of the POI devices). SAD, or that could impact the security Merchant has no access to of CHD and/or SAD cardholder data, thus procedures  Logs of all critical system components related to implementation of  Logs of all servers and system audit trails and security events components that perform security would not be applicable. functions (for example, firewalls, intrusion-detection systems/intrusion- prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.) 10.6.1.b Observe processes and interview 1 Not Applicable When implemented properly, personnel to verify that the following are TAVE will remove the PCI DSS reviewed at least daily: validation requirements for all  All security events system components located on  Logs of all system components that the merchant’s host network store, process, or transmit CHD and/or SAD, or that could impact the security (outside of the POI devices). of CHD and/or SAD Merchant has no access to  Logs of all critical system components cardholder data, thus procedures  Logs of all servers and system related to implementation of components that perform security audit trails and security events functions (for example, firewalls, would not be applicable. intrusion-detection systems/intrusion- prevention systems (IDS/IPS),

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

authentication servers, e-commerce redirection servers, etc.).

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 1 Not Applicable When implemented properly, procedures to verify that procedures are TAVE will remove the PCI DSS defined for reviewing logs of all other validation requirements for all system components periodically—either system components located on manually or via log tools—based on the organization’s policies and risk the merchant’s host network management strategy. (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- 1 Not Applicable When implemented properly, assessment documentation and interview TAVE will remove the PCI DSS personnel to verify that reviews are validation requirements for all performed in accordance with system components located on organization’s policies and risk management strategy. 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 1 Not Applicable When implemented properly, procedures to verify that procedures are TAVE will remove the PCI DSS defined for following up on exceptions and validation requirements for all anomalies identified during the review system components located on process. the merchant’s host network (outside of the POI devices). Security policies and procedures for log review processes will not be applicable.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

10.6.3.b Observe processes and interview 1 Not Applicable When implemented properly, personnel to verify that follow-up to TAVE will remove the PCI DSS exceptions and anomalies is performed. 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 1 Not Applicable When implemented properly, procedures to verify that they define the TAVE will remove the PCI DSS following: validation requirements for all  Audit log retention policies system components located on  Procedures for retaining audit logs for the merchant’s host network at least one year, with a minimum of three months immediately available (outside of the POI devices). Audit online. log retention policies and procedures will not be applicable.

10.7.b Interview personnel and examine 1 Not Applicable When implemented properly, audit logs to verify that audit logs are TAVE will remove the PCI DSS available for at least one year. 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.c Interview personnel and observe 1 Not Applicable When implemented properly, processes to verify that at least the last TAVE will remove the PCI DSS three months’ logs can be immediately validation requirements for all restored for analysis. 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.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.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

10.8 Examine documentation interview 1 Not Applicable Merchant will have no access to personnel to verify that security policies cardholder data, thus security and operational procedures for monitoring policies and operational all access to network resources and procedures for monitoring all cardholder data are: access to network resources and  Documented,  In use, and cardholder data would not be  Known to all affected parties. 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 1 Not Applicable When implemented properly, verify processes are defined for detection TAVE will remove the PCI DSS and identification of both authorized and validation requirements for the unauthorized wireless access points on a merchant’s host network. quarterly basis. Policies and procedures for wireless access point detection and identification will not be applicable.

11.1.b Verify that the methodology is 1 Not Applicable When implemented properly, adequate to detect and identify any TAVE will remove the PCI DSS unauthorized wireless access points, validation requirements for the including at least the following: merchant’s host network. Policies and procedures for wireless  WLAN cards inserted into system access point detection and components identification will not be in  Portable wireless devices connected applicable. to system components (for example, by USB, etc.)  Wireless devices attached to a network port or network device 11.1.c Examine output from recent 1 Not Applicable When implemented properly, wireless scans to verify that: TAVE will remove the PCI DSS  Authorized and unauthorized wireless validation requirements for the access points are identified, and merchant’s host network. Policies  The scan is performed at least and procedures for wireless quarterly for all system components and facilities. access point detection and identification will not be in applicable.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

11.1.d If automated monitoring is utilized 1 Not Applicable When implemented properly, (for example, wireless IDS/IPS, NAC, etc.), TAVE will remove the PCI DSS verify the configuration will generate alerts validation requirements for the to notify personnel. merchant’s host network. Policies and procedures for wireless access point detection and identification will not be in applicable.

11.1.1 Examine documented records to 1 Not Applicable When implemented properly, verify that an inventory of authorized TAVE will remove the PCI DSS wireless access points is maintained and a validation requirements for the business justification is documented for all merchant’s host network. Policies authorized wireless access points. and procedures for wireless access point detection and identification will not be in applicable.

11.1.2.a Examine the organization’s 1 Not Applicable When implemented properly, incident response plan (Requirement TAVE will remove the PCI DSS 12.10) to verify it defines and requires a validation requirements for the response in the event that an merchant’s host network. Policies unauthorized wireless access point is detected. and procedures for wireless access point detection and identification will not be in applicable.

11.1.2.b Interview responsible personnel 1 Not Applicable When implemented properly, and/or inspect recent wireless scans and TAVE will remove the PCI DSS related responses to verify action is taken validation requirements for the when unauthorized wireless access points merchant’s host network. Policies are found. and procedures for wireless access point detection and identification will not be in applicable.

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.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

11.2.1.a Review the scan reports and 1 Not Applicable When implemented properly, verify that four quarterly internal scans TAVE will remove the PCI DSS occurred in the most recent 12-month validation requirements for all period. system components located on the merchant’s host network (outside of the POI devices).

As such, there are no applicable internal vulnerability scanning requirements.

11.2.1.b Review the scan reports and 1 Not Applicable When implemented properly, verify that the scan process includes TAVE will remove the PCI DSS rescans until all “high-risk” vulnerabilities validation requirements for all as defined in PCI DSS Requirement 6.1 are system components located on resolved. the merchant’s host network

(outside of the POI devices).

As such, there are no applicable internal vulnerability scanning requirements.

11.2.1.c Interview personnel to verify that 1 Not Applicable When implemented properly, the scan was performed by a qualified TAVE will remove the PCI DSS internal resource(s) or qualified external validation requirements for all third party, and if applicable, system components located on organizational independence of the tester exists (not required to be a QSA or ASV). the merchant’s host network (outside of the POI devices).

As such, there are no applicable internal vulnerability scanning requirements.

11.2.2.a Review output from the four most 1 Not Applicable When implemented properly, recent quarters of external vulnerability TAVE will remove the PCI DSS scans and verify that four quarterly scans validation requirements for all occurred in the most recent 12-month system components located on period. the merchant’s host network (outside of the POI devices).

As such, there are no applicable external vulnerability scanning requirements.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

11.2.2.b Review the results of each 1 Not Applicable When implemented properly, quarterly scan and rescan to verify that the TAVE will remove the PCI DSS ASV Program Guide requirements for a validation requirements for all passing scan have been met (for example, system components located on no vulnerabilities rated 4.0 or higher by the CVSS, and no automatic failures). the merchant’s host network (outside of the POI devices).

As such, there are no applicable external vulnerability scanning requirements.

11.2.2.c Review the scan reports to verify 1 Not Applicable When implemented properly, that the scans were completed by a PCI TAVE will remove the PCI DSS SSC Approved Scanning Vendor (ASV). validation requirements for all

system components located on the merchant’s host network (outside of the POI devices).

As such, there are no applicable external vulnerability scanning requirements.

11.2.3.a Inspect and correlate change 1 Not Applicable When implemented properly, control documentation and scan reports to TAVE will remove the PCI DSS verify that system components subject to validation requirements for all any significant change were scanned. system components located on the merchant’s host network (outside of the POI devices).

As such, there are no applicable vulnerability scanning requirements.

11.2.3.b Review scan reports and verify 1 Not Applicable When implemented properly, that the scan process includes rescans TAVE will remove the PCI DSS until: validation requirements for all  For external scans, no system components located on vulnerabilities exist that are the merchant’s host network scored 4.0 or higher by the CVSS.  For internal scans, all “high-risk” (outside of the POI devices). vulnerabilities as defined in PCI DSS Requirement 6.1 are As such, there are no applicable resolved. vulnerability scanning requirements.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

11.2.3.c Validate that the scan was 1 Not Applicable When implemented properly, performed by a qualified internal TAVE will remove the PCI DSS resource(s) or qualified external third validation requirements for all party, and if applicable, organizational system components located on independence of the tester exists (not the merchant’s host network required to be a QSA or ASV). (outside of the POI devices).

As such, there are no applicable vulnerability scanning requirements.

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.1 is in place.

11.3 Examine penetration-testing 1 Not Applicable When implemented properly, methodology and interview responsible TAVE will remove the PCI DSS personnel to verify a methodology is validation requirements for all implemented that includes the following: system components located on  Is based on industry-accepted the merchant’s host network penetration testing approaches (for example, NIST SP800-115) (outside of the POI devices).  Includes coverage for the entire CDE perimeter and critical systems As such, there are no applicable  Testing from both inside and outside penetration testing requirements. 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.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

11.3.1.a Examine the scope of work and 1 Not Applicable When implemented properly, results from the most recent external TAVE will remove the PCI DSS penetration test to verify that penetration validation requirements for all testing is performed as follows: system components located on  Per the defined methodology the merchant’s host network  At least annually  After any significant changes to (outside of the POI devices). the environment. As such, there are no applicable penetration testing requirements.

11.3.1.b Verify that the test was 1 Not Applicable When implemented properly, performed by a qualified internal resource TAVE will remove the PCI DSS or qualified external third party, and if validation requirements for all applicable, organizational independence of system components located on the tester exists (not required to be a QSA or ASV). the merchant’s host network (outside of the POI devices).

As such, there are no applicable penetration testing requirements.

11.3.2.a Examine the scope of work and 1 Not Applicable When implemented properly, results from the most recent internal TAVE will remove the PCI DSS penetration test to verify that penetration validation requirements for all testing is performed at least annually and system components located on after any significant changes to the the merchant’s host network environment. (outside of the POI devices).

 Per the defined methodology As such, there are no applicable  At least annually penetration testing requirements.  After any significant changes to the environment 11.3.2.b Verify that the test was 1 Not Applicable When implemented properly, performed by a qualified internal resource TAVE will remove the PCI DSS or qualified external third party, and if validation requirements for all applicable, organizational independence of system components located on the tester exists (not required to be a QSA the merchant’s host network or ASV). (outside of the POI devices).

As such, there are no applicable penetration testing requirements.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

11.3.3 Examine penetration testing results 1 Not Applicable When implemented properly, to verify that noted exploitable TAVE will remove the PCI DSS vulnerabilities were corrected and that validation requirements for all repeated testing confirmed the system components located on vulnerability was corrected. the merchant’s host network (outside of the POI devices).

As such, there are no applicable penetration testing requirements.

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 1 Not Applicable When implemented properly, and review penetration-testing TAVE will remove the PCI DSS methodology to verify that penetration- validation requirements for all testing procedures are defined to test all system components located on segmentation methods to confirm they are operational and effective, and isolate all the merchant’s host network out-of-scope systems from in-scope (outside of the POI devices). systems. As such, there are no applicable penetration testing requirements.

11.3.4.b Examine the results from the 1 Not Applicable When implemented properly, most recent penetration test to verify that TAVE will remove the PCI DSS penetration testing to verify segmentation validation requirements for all controls: system components located on  Is performed at least annually and the merchant’s host network after any changes to segmentation controls/methods. (outside of the POI devices).  Covers all segmentation controls/methods in use. As such, there are no applicable  Verifies that segmentation methods penetration testing requirements. 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 1 Not Applicable When implemented properly, network diagrams to verify that techniques TAVE will remove the PCI DSS (such as intrusion-detection systems validation requirements for the merchant’s host network.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value and/or intrusion-prevention systems) are Intrusion-detection and/or in place to monitor all traffic: intrusion prevention  At the perimeter of the cardholder requirements will be not data environment applicable.  At critical points in the cardholder data environment. 11.4.b Examine system configurations and 1 Not Applicable When implemented properly, interview responsible personnel to confirm TAVE will remove the PCI DSS intrusion-detection and/or intrusion- validation requirements for the prevention techniques alert personnel of merchant’s host network. suspected compromises. Intrusion-detection and/or

intrusion prevention requirements will be not applicable.

11.4.c Examine IDS/IPS configurations and 1 Not Applicable When implemented properly, vendor documentation to verify intrusion- TAVE will remove the PCI DSS detection and/or intrusion-prevention validation requirements for the techniques are configured, maintained, merchant’s host network. and updated per vendor instructions to ensure optimal protection. 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 1 Not Applicable When implemented properly, monitoring tools within the cardholder TAVE will remove the PCI DSS data environment by observing system validation requirements for all settings and monitored files, as well as system components located on reviewing results from monitoring the merchant’s host network activities. (outside of the POI devices). File- Examples of files that should be integrity monitoring or change- monitored: detection requirements will not be applicable.  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).

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

11.5.b Verify the mechanism is configured 1 Not Applicable When implemented properly, to alert personnel to unauthorized TAVE will remove the PCI DSS modification of critical files, and to validation requirements for all perform critical file comparisons at least system components located on weekly. the merchant’s host network (outside of the POI devices). File- integrity monitoring or change- detection requirements will not be applicable.

11.5.1 Interview personnel to verify that 1 Not Applicable When implemented properly, all alerts are investigated and resolved. TAVE 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.

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 1 Not Applicable Merchant will have no access to personnel to verify that security policies cardholder data, thus security and operational procedures for security policies and operational monitoring and testing are: procedures for security  Documented, monitoring and testing would not  In use, and  Known to all affected parties. be applicable. 12.1 Establish, publish, maintain, and disseminate a security policy.

12.1 Examine the information security 4 Information Security This requirement is fully in-scope policy and verify that the policy is Policy for the merchant’s PCI-DSS published and disseminated to all relevant assessment. personnel (including vendors and business partners).

12.1.1 Verify that the information security 4 Information Security This requirement is fully in-scope policy is reviewed at least annually and Policy for the merchant’s PCI-DSS updated as needed to reflect changes to assessment. business objectives or the risk environment.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

12.2.a Verify that an annual risk- 4 Information Security This requirement is fully in-scope assessment process is documented that Policy for the merchant’s PCI-DSS identifies assets, threats, vulnerabilities, assessment. and results in a formal risk assessment. Annual Risk Assessment

12.2.b Review risk-assessment 4 Information Security This requirement is fully in-scope documentation to verify that the risk- Policy for the merchant’s PCI-DSS assessment process is performed at least assessment. annually and upon significant changes to Annual Risk Assessment the environment.

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 4 Acceptable Usage Policies This requirement is fully in-scope include processes for explicit approval for the merchant’s PCI-DSS from authorized parties to use the assessment. technologies.

12.3.2 Verify that the usage policies 4 Acceptable Usage Policies This requirement is fully in-scope include processes for all technology use to for the merchant’s PCI-DSS be authenticated with user ID and assessment. password or other authentication item (for example, token).

12.3.3 Verify that the usage policies define 4 Acceptable Usage Policies This requirement is fully in-scope a list of all devices and personnel for the merchant’s PCI-DSS authorized to use the devices. assessment.

12.3.4 Verify that the usage policies define 4 Acceptable Usage Policies This requirement is fully in-scope a method to accurately and readily for the merchant’s PCI-DSS determine owner, contact information, assessment. and purpose (for example, labeling, coding, and/or inventorying of devices).

12.3.5 Verify that the usage policies 4 Acceptable Usage Policies This requirement is fully in-scope require acceptable uses for the for the merchant’s PCI-DSS technology. assessment.

12.3.6 Verify that the usage policies 4 Acceptable Usage Policies This requirement is fully in-scope require acceptable network locations for for the merchant’s PCI-DSS the technology. assessment.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

12.3.7 Verify that the usage policies 4 Acceptable Usage Policies This requirement is fully in-scope require a list of company-approved for the merchant’s PCI-DSS products. assessment.

12.3.8.a Verify that the usage policies 4 Acceptable Usage Policies This requirement is fully in-scope require automatic disconnect of sessions for the merchant’s PCI-DSS for remote-access technologies after a assessment. specific period of inactivity.

12.3.8.b Examine configurations for 4 Acceptable Usage Policies This requirement is fully in-scope remote access technologies to verify that for the merchant’s PCI-DSS remote access sessions will be assessment. automatically disconnected after a specific period of inactivity.

12.3.9 Verify that the usage policies 4 Acceptable Usage Policies This requirement is fully in-scope require activation of remote-access for the merchant’s PCI-DSS technologies used by vendors and business assessment. partners only when needed by vendors and business partners, with immediate deactivation after use.

12.3.10.a Verify that the usage policies 1 Not Applicable Cardholder data will not be prohibit copying, moving, or storing of accessible within the merchant cardholder data onto local hard drives and environment. removable electronic media when accessing such data via remote-access technologies.

12.3.10.b For personnel with proper 1 Not Applicable Cardholder data will not be authorization, verify that usage policies accessible within the merchant require the protection of cardholder data environment. in accordance with PCI DSS Requirements.

12.4.a Verify that information security 4 Information Security This requirement is fully in-scope policies clearly define information security Policy for the merchant’s PCI-DSS responsibilities for all personnel. assessment.

12.4.b Interview a sample of responsible 4 Incident Response Plan This requirement is fully in-scope personnel to verify they understand the (IRP) for the merchant’s PCI-DSS security policies. assessment.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

12.5 Examine information security policies 4 Information Security This requirement is fully in-scope and procedures to verify: Policy for the merchant’s PCI-DSS  The formal assignment of information assessment. 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 4 Information Security This requirement is fully in-scope establishing, documenting and distributing Policy for the merchant’s PCI-DSS security policies and procedures is formally assessment. assigned.

12.5.2 Verify that responsibility for 4 Information Security This requirement is fully in-scope monitoring and analyzing security alerts Policy for the merchant’s PCI-DSS and distributing information to assessment. appropriate information security and business unit management personnel is formally assigned. 12.5.3 Verify that responsibility for 4 Information Security This requirement is fully in-scope establishing, documenting, and Policy for the merchant’s PCI-DSS distributing security incident response and assessment. escalation procedures is formally assigned.

12.5.4 Verify that responsibility for 4 Information Security This requirement is fully in-scope administering (adding, deleting, and Policy for the merchant’s PCI-DSS modifying) user account and assessment. authentication management is formally assigned. 12.5.5 Verify that responsibility for 4 Information Security This requirement is fully in-scope monitoring and controlling all access to Policy for the merchant’s PCI-DSS data is formally assigned. assessment.

12.6.a Review the security awareness 4 Information Security This requirement is fully in-scope program to verify it provides awareness to Policy for the merchant’s PCI-DSS all personnel about the importance of assessment. cardholder data security. Security Awareness Policy/Program

12.6.b Examine security awareness 4 Security Awareness This requirement is fully in-scope program procedures and documentation Policy/Program for the merchant’s PCI-DSS and perform the following: assessment.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

12.6.1.a Verify that the security awareness 4 Security Awareness This requirement is fully in-scope program provides multiple methods of Policy/Program for the merchant’s PCI-DSS communicating awareness and educating assessment. personnel (for example, posters, letters, memos, web based training, meetings, and promotions).

12.6.1.b Verify that personnel attend 4 Security Awareness This requirement is fully in-scope awareness training upon hire and at least Policy/Program for the merchant’s PCI-DSS annually. assessment.

12.6.1.c Interview a sample of personnel 4 Incident Response Plan This requirement is fully in-scope to verify they have completed awareness (IRP) for the merchant’s PCI-DSS training and are aware of the importance assessment. of cardholder data security. 12.6.2 Verify that the security awareness 4 Security Awareness This requirement is fully in-scope program requires personnel to Policy/Program for the merchant’s PCI-DSS acknowledge, in writing or electronically, assessment. at least annually, that they have read and understand the information security policy. 12.7 Inquire with Human Resource 4 Information Security This requirement is fully in-scope department management and verify that Policy for the merchant’s PCI-DSS background checks are conducted (within assessment. 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:

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

12.8.1 Verify that a list of service providers 4 Information Security This requirement is fully in-scope is maintained. Policy for the merchant’s PCI-DSS assessment.

12.8.2 Observe written agreements and 4 Information Security This requirement is fully in-scope confirm they include an acknowledgement Policy for the merchant’s PCI-DSS by service providers that they are assessment. 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 4 Information Security This requirement is fully in-scope are documented and implemented Policy for the merchant’s PCI-DSS including proper due diligence prior to assessment. engaging any service provider. 12.8.4 Verify that the entity maintains a 4 Information Security This requirement is fully in-scope program to monitor its service providers’ Policy for the merchant’s PCI-DSS PCI DSS compliance status at least assessment. annually.

12.8.5 Verify the entity maintains 4 Incident Response Plan This requirement is fully in-scope information about which PCI DSS (IRP) for the merchant’s PCI-DSS requirements are managed by each service assessment. provider, and which are managed by the entity. 12.9 Additional testing procedure for 1 Not Applicable Not applicable in merchant service providers: Review service environments. 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:

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

12.10.1.a Verify that the incident response 4 Incident Response Plan This requirement is fully in-scope plan includes: (IRP) for the merchant’s PCI-DSS  Roles, responsibilities, and assessment. 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 4 Incident Response Plan This requirement is fully in-scope documentation from a sample of (IRP) for the merchant’s PCI-DSS previously reported incidents or alerts to assessment. verify that the documented incident response plan and procedures were followed. 12.10.2 Verify that the plan is tested at 4 Incident Response Plan This requirement is fully in-scope least annually. (IRP) for the merchant’s PCI-DSS assessment.

12.10.3 Verify through observation, review 4 Incident Response Plan This requirement is fully in-scope of policies, and interviews of responsible (IRP) for the merchant’s PCI-DSS personnel that designated personnel are assessment. 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 4 Incident Response Plan This requirement is fully in-scope of policies, and interviews of responsible (IRP) for the merchant’s PCI-DSS personnel that staff with responsibilities assessment. for security breach response are periodically trained.

PCI-DSS v3.1 Testing Procedure Control Merchant Justification Reduction Documentation Risk Value

12.10.5 Verify through observation and 4 Incident Response Plan This requirement is fully in-scope review of processes that monitoring and (IRP) for the merchant’s PCI-DSS responding to alerts from security assessment. monitoring systems, including detection of unauthorized wireless access points, are covered in the incident response plan.

12.10.6 Verify through observation, review 4 Incident Response Plan This requirement is fully in-scope of policies, and interviews of responsible (IRP) for the merchant’s PCI-DSS personnel that there is a process to modify assessment. and evolve the incident response plan according to lessons learned and to incorporate industry developments.