First Data TransArmor VeriFone Edition Detailed Technical ... · First Data TransArmor VeriFone Edition Detailed Technical Assessment White Paper Prepared for: October 1st, 2013 Dan

First Data TransArmor VeriFone Edition Detailed Technical Assessment

White Paper

Prepared for:

October 1st, 2013

Dan Fritsche, CISSP, QSA (P2PE), PA-QSA (P2PE)

[email protected]

mailto:[email protected]

© 2013 Coalfire® Systems, Inc. Page | 2

Table of Contents

EXECUTIVE SUMMARY ........................................................................................................................................... 3

OVERVIEW ............................................................................................................................................................ 3

SUMMARY FINDINGS ............................................................................................................................................... 6

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

SCOPE REDUCTION FOR MERCHANTS ......................................................................................................................... 10

DEPLOYMENT SCENARIOS ....................................................................................................................................... 10

PCI DSS SCOPE REDUCTION SUMMARY ..................................................................................................................... 11

DETAILED PCI DSS SCOPE REDUCTION ....................................................................................................................... 12

TECHNICAL ASSESSMENT ..................................................................................................................................... 13

SCOPE OF ASSESSMENT .......................................................................................................................................... 13

TRANSARMOR VERIFONE EDITION ENCRYPTION ASSESSMENT .......................................................................................... 17

KEY LOADING AND DISTRIBUTION.............................................................................................................................. 18

APPENDIX A: PCI DSS SCOPE REDUCTION RISK MAPPINGS .................................................................................. 23

DETAILED PCI DSS SCOPE REDUCTION ....................................................................................................................... 23


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 conduct an independent technical

assessment of the TransArmor VeriFone Edition (TAVE), secured by RSA security solution. Coalfire

conducted assessment activities including technical testing, an architectural assessment, industry

analysis, a compliance validation and peer review.

In this paper, Coalfire will describe how the TransArmor VeriFone Edition security solution can nearly

eliminate the current risk of payment card data compromise within a merchant’s retail environment and

can dramatically reduce the scope of PCI DSS validation when properly deployed. This scope reduction

will be based on evaluating the risk of each of the PCI DSS 2.0 requirements and how the TAVE security

solution applies to each control within the context of the current PCI P2PE standards released in 2012.

First Data could submit TransArmor VeriFone Edition to obtain a PCI P2PE listing, however the focus of

this paper is to clarify how a merchant can benefit from TAVE even though it may not be a formally

listed solution.

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 and scope of 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 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 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 scope reduction.

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 scope 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 utilized reviews and feedback obtained from members of the PCI community;

however, the opinions and findings within this evaluation are solely those of Coalfire and do not

represent any assessment findings, or opinions, from any other parties.

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

understood and leveraged in the context of PCI DSS v2.0 and the current PCI P2PE standards released in

2012. Tokenization is relevant to protecting and reducing PCI DSS scope 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

http://www.firstdata.com/downloads/thought-leadership/Value-of-Tokens-WP.pdf


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 the PCI DSS always applies to them. However, a properly implemented, and thoroughly

evaluated, encryption solution can satisfy a significant portion of the PCI DSS controls; thereby

significantly reducing the scope of what PCI DSS requirements a merchant is still responsible for

validating.

In 2012, the PCI SSC released an official P2PE standard detailing what controls must be in place for a

service provider to have a validated, listed P2PE solution. This program works best for level 4 merchants.

For encryption solutions not listed with the PCI SSC (which would include most level one merchant

solutions), the Council has stated that the acquirer or payment brand should be consulted to determine

how an encryption solution will affect their PCI DSS compliance requirements. This assessment can be

used by merchants using the TAVE solution to understand what scope reduction is possible.

To that end, a risk evaluation for each control is included to justify a corresponding scope reduction,

based on the PCI P2PE standards. Coalfire has reviewed each deployment scenario to assess its impact

on the cardholder data environment that would be considered “in scope” for PCI DSS validation. We

have leveraged our experience as a veteran QSA(P2PE)/PA-QSA(P2PE) firm in applying technologies such

as network segmentation, tokenization, and various encryption solutions to provide guidance on

appropriate PCI DSS scope reduction.

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” published by the PCI SSC in April 2012, as well as other related documents including updates to the

standard. The evaluation included verification of encryption methods, key length, algorithms, key

management methods, and physical and logical protection.

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.

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 scope 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, 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 scope reduction, Coalfire and First Data

recommend the use of a device with PTS 2.x with SRED or 3.x with SRED enabled.

Assessor Comments

Our assessment scope put a significant focus on validating the PCI DSS scope 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 the PCI DSS scope of 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 PCI DSS compliance scope you must reduce the potential security risk and access to payment

card data.

The PCI Security Standards Council has incorporated scope reduction guidance within the PCI DSS

framework and through FAQ guidance on specific technologies or architecture. Scope reduction has

most commonly been addressed through the implementation of network segmentation where systems

and environments that process, store or transmit card data are “isolated” from other non-payment

environments. This approach is not focused on reducing the applicability of any specific DSS control to a

merchant’s environment but rather reducing the validation expectations of the environment that the

DSS controls apply to.

As most of the DSS controls are designed to manage risk to card data from specific threat scenarios, it is

therefore possible to reduce their applicability by securing the card data in the merchant environment,

so that the threat scenarios are no longer a viable risk. By strongly encrypting card data at the point of

capture in a secure and restricted device, where no ability to decrypt the card data exists, you can

effectively “isolate” the majority of the merchant’s environment from scope. If specific deployment

scenarios are adhered to, the merchant environment can be treated as an untrusted environment

similar to a public network when using strong transmission encryption.

In 2012 the PCI Security Standards Council released two P2PE standard documents: the first was for a

“hardware/hardware” solution, the second for a “hardware/hybrid” solution. For the purposes of this

paper, the former will be the focus of all interpretations and comments. This standard can be found at

PCI’s document library, under the P2PE section, along with supporting documentation.

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

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


These documents, along with the PCI DSS 2.0 are the reference points used for all comments and

conclusions in this assessment. Additionally, PCI has updated some relevant FAQs:

FAQ of the Month - UPDATED

Is encrypted cardholder data in scope for PCI DSS?

August, 2012: This FAQ has been updated to reflect the evolving security landscape surrounding

the use of encrypted payment card data, and to eliminate inconsistencies in how the scope of PCI

DSS is determined with respect to the presence of encrypted data. With the release of the PCI

Point-to-Point Encryption (P2PE) Program, the Council is providing additional guidance on the

security of encrypted cardholder data through this updated FAQ, as well as two additional FAQs:

"Are third-party storage providers storing only encrypted cardholder data in scope for PCI DSS?"

and "Are merchants using Council-listed P2PE solutions out of scope for PCI DSS?" These FAQs

are intended to clarify that storage of encrypted data without access to the decryption keys does

not automatically result in the data, or the merchant, being out of scope.

Encryption of cardholder data with strong cryptography is an acceptable method of rendering

the data unreadable in order to meet PCI DSS Requirement 3.4. Because encrypted data can be

decrypted with the right cryptographic key, encrypted cardholder data remains in scope for PCI

DSS. Generally, the encrypted data is the responsibility of the entity (that is, the corporation,

organization or business being reviewed) that controls and/or has access to the encrypted data

and the decryption keys. It is possible that encrypted data may be deemed out of scope for a

particular entity if, and only if, it is validated that the entity in possession of the encrypted data

does not have the ability to decrypt it. This means the entity does not have decryption keys

anywhere in their environment, and that none of the entity's systems, processes or personnel

have access to the environment where decryption keys are located, nor do they have the ability

to retrieve them.

Furthermore, all applicable PCI DSS requirements apply if any of the following conditions are

met:

Encrypted cardholder data is stored on a system or media that also contains the decryption key,

Encrypted data is stored in the same environment as the decryption key,

Encrypted data is accessible to an entity that also has access to the decryption key.

For information about how a merchant may receive scope reduction through use of a validated

P2PE solution, please see the FAQ: "Are merchants using Council-listed P2PE solutions out of

scope for PCI DSS?"


This FAQ reference states:

Are merchants using Council-listed P2PE solutions out of scope for PCI DSS? A. No. While use of a validated, listed P2PE solution can help to reduce the scope of a merchant’s cardholder data environment, it does not remove the need for PCI DSS in the merchant environment. The merchant environment remains in scope for PCI DSS because cardholder data is always present within the merchant environment. For example, in a 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:

Can merchants use P2PE solutions not listed on the Council’s website for PCI DSS scope reduction?

A. Only Council-listed solutions are recognized as meeting the requirements necessary for merchants to reduce the scope of their cardholder data environment (CDE) through use of a P2PE solution. In addition to using a validated, Council-listed P2PE solution, merchants wishing to reduce the scope of their CDE must meet certain characteristics, as documented in the “Merchants Using P2PE Solutions” section of the P2PE Standard. SAQ-eligible merchants can review the P2PE-HW SAQ on our website for eligibility criteria and applicable PCI DSS requirements. Merchants using encryption solutions that are not included on PCI SSC’s list of Validated

P2PE Solutions should consult with their acquirer or the payment brands about the use of

these solutions.

Based on this guidance, one of the intentions for this assessment is to provide guidance for Merchants

wishing to use the 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 scope reduction for P2PE:

Dialogue with Council members regarding P2PE to understand their current position and future

intent

Reference and review of the FAQ released by the Council

Dialogue with respected QSAs from other QSA companies in the industry

Coalfire’s experience in implementing other PCI DSS scope reduction programs

Clarification of Compliance Scope Reduction

Clearly, PCI DSS scope reduction cannot remove a merchant from the requirement to be compliant. PCI

DSS scope reduction does not eliminate a merchant’s responsibility to validate compliance to their

Acquirer as PCI DSS always applies to merchants who accept card data. Traditional PCI DSS scope


reduction is only focused on addressing the applicability of specific controls to a merchant’s

environment based on “isolation” of data, systems and networks from security risks to payment card

data.

PCI DSS scope reduction’s biggest payoff for merchants is the opportunity to eliminate the cost of

control deployment for the sole purpose of meeting compliance obligations. The second major benefit is

the reduction of cost and effort to validate PCI DSS compliance of the merchant environment. Many

merchants have sensitive data assets other than payment card data in their environment that have a risk

of compromise. Reducing PCI DSS scope for payment card data does not mean the PCI DSS controls are

not justified to protect the merchants other information assets.

Scope 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 scope reduction. Coalfire has

presented the most common deployment scenario for a merchant implementing TransArmor VeriFone

Edition to reduce PCI DSS scope.

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 full PCI DSS scope reduction 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 Scope 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 PCI DSS control validation scope

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 Scope Reduction

PCI DSS

Area

Major Scope

Reduction

Moderate Scope

Reduction

Minor/No Scope

Reduction

Section 1 X

Section 2 X

Section 3 X

Section 4 X

Section 5 X

Section 6 X

Section 7 X

Section 8 X

Section 9 X

Section 10 X

Section 11 X

Section 12 X

Legend:

Major – A significant number of controls are either removed from scope or a reduction in the

number of IT assets requiring the controls

Moderate – A reduced number of controls are required and a significant reduction in the

number of IT assets requiring the controls


Minor – Either no controls are removed from scope or minor impact to the scope of IT assets

requiring the controls

Detailed PCI DSS Scope Reduction A table in Appendix A was created as a general guideline for determining the PCI-DSS scope within a merchant

environment utilizing TAVE. This risk-based guidance indicates Coalfire’s recommended PCI-DSS scope reduction

for merchants that have compliantly implemented TAVE. Scroll down to Appendix A to review the detailed PCI

DSS risk guidance.

Copyright 2013, Coalfire Systems Inc. Page | 13

Technical Assessment

Scope of Assessment First Data TransArmor VeriFone Edition was assessed for compliance relative to current PCI DSS 2.0 standards and PCI

P2PE 1.1. The assessment testing focused on the following functional areas:

1. Verification of Point-to-Point Encryption from the point of encryption to the point of decryption 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 scope reduction 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): PinPad applies VSP format preserving encryption.

Step (2): POS Register routes transaction to a Store Controller or 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 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 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.



Step (7): (STM Handler to Front End) STM Handler routes transaction to Front End Authorization Platform.



Step (8): (Front End to Store Controller) Token returned to the merchant in a successful authorization response.




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: VISA Manual Input vs. Encrypted PAN

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

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

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


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


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

For more detailed information regarding the TransArmor VeriFone Edition solution, please review the detailed Technical

Assessment which was published in concert with this summarized white paper.


Appendix A: PCI DSS Scope Reduction Risk Mappings

Detailed PCI DSS Scope Reduction The information contained in the table in Appendix A was created as a general guideline for determining the PCI-DSS

scope within a merchant environment utilizing TAVE. This risk-based guidance indicates Coalfire’s recommended PCI-

DSS scope reduction 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 v2.0.

Scope Reduction Risk Value: This is the associated risk value (1-4) associated with each PCI-DSS testing procedure. The

value indicates whether or not the scope for a PCI-DSS requirement can be reduced or eliminated. They are as follows:

1. Properly implemented, TAVE will completely eliminate the requirement from the scope of a merchant’s PCI-DSS assessment.

2. Properly implemented, TAVE can significantly reduce or eliminate the requirement from the scope of a merchant’s PCI-DSS assessment. Depending on the merchant’s cardholder data environment, some validation from the QSA may be required.

3. Properly implemented, 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 in-scope 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 for scope separately.

Merchant Documentation: Mapped against the PCI-DSS ROC Reporting Instructions v2.0, the documentation a

Merchant is responsible for maintaining if a requirement is deemed in-scope for their PCI-DSS assessment.

Requirements with a Scope Reduction Risk value of 1 will not have any associated documentation expectations.

Justification: The Coalfire justification for the scope reduction or scope elimination of each PCI-DSS requirement when

TAVE is properly implemented.


PCI-DSS v2.0 Testing

Procedure

Scope Reduction

Risk Value

Merchant Documentation Justification

1.1 Obtain and inspect the

firewall and router

configuration standards and

other documentation

specified below to verify

that standards are

complete. Complete the

following:

1.1.1 Verify that there is a

formal process for testing

and approval of all network

connections and changes to

firewall and router

configurations.

1 Not Applicable When implemented properly, TAVE will

remove the PCI DSS validation requirements

for the merchant’s host network.

1.1.2.a Verify that a current

network diagram (for

example, one that shows

cardholder data flows over

the network) exists and that

it documents all

connections to cardholder

data, including any wireless

networks.

3 Network Diagram Even with the significant scope reduction

TAVE obtains, Coalfire feels that merchants

should still diagram the data flow of the

retail locations where VTP will be utilized.

1.1.2.b Verify that the

diagram is kept current.

3 Network Diagram Even with the significant scope reduction

TAVE obtains, Coalfire feels that merchants

should still diagram the data flow of the

retail locations where VTP will be utilized.

1.1.3.a Verify that firewall

configuration standards

include requirements for a

firewall at each Internet

connection and between

any DMZ and the internal

network zone.





current network diagram is

consistent with the firewall

configuration standards.

3 Network Diagram

Coalfire feels that a network diagram is still

appropriate for the merchant environment;

however, it will not need to be compared to

network configuration standards.



Procedure

Scope Reduction

Risk Value


1.1.4 Verify that firewall

and router configuration

standards include a

description of groups, roles,

and responsibilities for

logical management of

network components.






standards include a

documented list of services,

protocols and ports

necessary for business—for

example, hypertext transfer

protocol (HTTP) and Secure

Sockets Layer (SSL), Secure

Shell (SSH), and Virtual

Private Network (VPN)

protocols.




1.1.5.b Identify insecure

services, protocols, and

ports allowed; and verify

they are necessary and that

security features are

documented and

implemented by examining

firewall and router

configuration standards and

settings for each service.






standards require review of

firewall and router rule sets

at least every six months.




1.1.6.b Obtain and examine

documentation to verify

that the rule sets are

reviewed at least every six

months.






Procedure

Scope Reduction

Risk Value


1.2 Examine firewall and

router configurations to

verify that connections are

restricted between

untrusted networks and

system components in the

cardholder data

environment, as follows:

1.2.1.a Verify that inbound

and outbound traffic is

limited to that which is

necessary for the

cardholder data

environment, and that the

restrictions are

documented.




1.2.1.b Verify that all other

inbound and outbound

traffic is specifically denied,

for example by using an

explicit “deny all” or an

implicit deny after allow

statement.




1.2.2 Verify that router

configuration files are

secure and synchronized—

for example, running

configuration files (used for

normal running of the

routers) and start-up

configuration files (used

when machines are re-

booted), have the same,

secure configurations.






Procedure

Scope Reduction

Risk Value


1.2.3 Verify that there are

perimeter firewalls installed

between any wireless

networks and systems that

store cardholder data, and

that these firewalls deny or

control (if such traffic is

necessary for business

purposes) any traffic from

the wireless environment

into the cardholder data

environment.



for the merchant’s host network. There will

be no cardholder data storage on the

Merchant’s network.

1.3 Examine firewall and

router configurations—

including but not limited to

the choke router at the

Internet, the DMZ router

and firewall, the DMZ

cardholder segment, the

perimeter router, and the

internal cardholder network

segment—to determine

that there is no direct

access between the

Internet and system

components in the internal

cardholder network

segment, as detailed below.

1.3.1 Verify that a DMZ is

implemented to limit

inbound traffic to only

system components that

provide authorized publicly

accessible services,

protocols, and ports.



for the merchant’s host network. There is

no cardholder data storage in a merchant

environment and as such the DMZ network

layer would not be applicable.

1.3.2 Verify that inbound

Internet traffic is limited to

IP addresses within the

DMZ.









Procedure

Scope Reduction

Risk Value


1.3.3 Verify direct

connections inbound or

outbound are not allowed

for traffic between the

Internet and the cardholder

data environment.

2 Network Diagram

Network Configuration

Standards

When implemented properly, TAVE will


for the merchant’s host network. However,

Coalfire still recommends against direct

unrestricted inbound Internet access to the

POIs.

1.3.4 Verify that internal

addresses cannot pass from

the Internet into the DMZ.




1.3.5 Verify that outbound

traffic from the cardholder

data environment to the

Internet is explicitly

authorized




1.3.6 Verify that the firewall

performs stateful inspection

(dynamic packet filtering).

(Only established

connections should be

allowed in, and only if they

are associated with a

previously established

session.)

2 Network Diagram

Network Configuration

Standards

When implemented properly, TAVE will


for the merchant’s host network. However,

Coalfire still recommends against direct

unrestricted inbound Internet access to the

POIs.

1.3.7 Verify that system

components that store

cardholder data are on an

internal network zone,

segregated from the DMZ

and other untrusted

networks.







1.3.8.a Verify that methods

are in place to prevent the

disclosure of private IP

addresses and routing

information from internal

networks to the Internet.






Procedure

Scope Reduction

Risk Value


1.3.8.b Verify that any

disclosure of private IP

addresses and routing

information to external

entities is authorized.




1.4.a Verify that mobile

and/or employee-owned

computers with direct

connectivity to the Internet

(for example, laptops used

by employees), and which

are used to access the

organization’s network,

have personal firewall

software installed and

active.



for the merchant’s host network. With no

access to cardholder data, mobile and/or

employee owned computers can be

considered out of scope for PCI DSS.

1.4.b Verify that the

personal firewall software is

configured by the

organization to specific

standards and is not

alterable by users of mobile

and/or employee-owned

computers.



for the merchant’s host network. With no

access to cardholder data, mobile and/or

employee owned computers can be

considered out of scope for PCI DSS.

2.1 Choose a sample of

system components, and

attempt to log on (with

system administrator help)

to the devices using default

vendor-supplied accounts

and passwords, to verify

that default accounts and

passwords have been

changed. (Use vendor

manuals and sources on the

Internet to find vendor-

supplied

accounts/passwords.)



for all system components located on the

merchant’s host network (outside of the POI

devices).

2.1.1 Verify the following

regarding vendor default

settings for wireless



Procedure

Scope Reduction

Risk Value


environments:

2.1.1.a Verify encryption

keys were changed from

default at installation, and

are changed anytime

anyone with knowledge of

the keys leaves the

company or changes

positions




2.1.1.b Verify default SNMP

community strings on

wireless devices were

changed.




2.1.1.c Verify default

passwords/passphrases on

access points were

changed.




2.1.1.d Verify firmware on

wireless devices is updated

to support strong

encryption for

authentication and

transmission over wireless

networks.




2.1.1.e Verify other

security-related wireless

vendor defaults were

changed, if applicable.




2.2.a Examine the

organization’s system

configuration standards for

all types of system

components and verify the

system configuration

standards are consistent

with industry-accepted

hardening standards.





devices).



Procedure

Scope Reduction

Risk Value


2.2.b Verify that system

configuration standards are

updated as new

vulnerability issues are

identified, as defined in

Requirement 6.2.





devices).

2.2.c Verify that system

configuration standards are

applied when new systems

are configured.





devices).

2.2.d Verify that system

configuration standards

include each item below

(2.2.1 – 2.2.4).

2.2.1.a For a sample of

system components, verify

that only one primary

function is implemented

per server.





devices).

2.2.1.b If virtualization

technologies are used,

verify that only one primary

function is implemented

per virtual system

component or device.





devices).


system components,

inspect enabled system

services, daemons, and

protocols. Verify that only

necessary services or

protocols are enabled.





devices).



Procedure

Scope Reduction

Risk Value


2.2.2.b Identify any enabled

insecure services, daemons,

or protocols. Verify they are

justified and that security

features are documented

and implemented.





devices).

2.2.3.a Interview system

administrators and/or

security managers to verify

that they have knowledge

of common security

parameter settings for

system components.





devices).

2.2.3.b Verify that common

security parameter settings

are included in the system

configuration standards.





devices).

2.2.3.c For a sample of


that common security

parameters are set

appropriately.





devices).



that all unnecessary

functionality (for example,

scripts, drivers, features,

subsystems, file systems,

etc.) is removed.





devices).



Procedure

Scope Reduction

Risk Value


2.2.4.b. Verify enabled

functions are documented

and support secure

configuration.





devices).

2.2.4.c. Verify that only

documented functionality is

present on the sampled

system components.





devices).

2.3 For a sample of system

components, verify that

non-console administrative

access is encrypted by

performing the following:

2.3.a Observe an

administrator log on to

each system to verify that a

strong encryption method is

invoked before the

administrator’s password is

requested.





devices).

2.3.b Review services and

parameter files on systems

to determine that Telnet

and other remote login

commands are not available

for use internally.





devices).

2.3.c Verify that

administrator access to the

web-based management

interfaces is encrypted with

strong cryptography.





devices).



Procedure

Scope Reduction

Risk Value


2.4 Perform testing

procedures A.1.1 through

A.1.4 detailed in Appendix

A: Additional PCI DSS

Requirements for Shared

Hosting Providers for PCI

DSS assessments of shared

hosting providers, to verify

that shared hosting

providers protect their

entities’ (merchants and

service providers) hosted

environment and data.

1 Not Applicable Not Applicable for merchants.

3.1 Obtain and examine the

policies, procedures and

processes for data retention

and disposal, and perform

the following:

3.1.1.a Verify that policies

and procedures are

implemented and include

legal, regulatory, and

business requirements for

data retention, including

specific requirements for

retention of cardholder

data (for example,

cardholder data needs to be

held for X period for Y

business reasons).

3 Data Retention and Storage

Policies (if applicable)

If the merchant has any paper based

processes associated with this payment

channel then this requirement will still apply

to their environment. Otherwise, this

requirement can be considered not

applicable.

3.1.1.b Verify that policies

and procedures include

provisions for secure

disposal of data when no

longer needed for legal,

regulatory, or business

reasons, including disposal

of cardholder data.








applicable.



Procedure

Scope Reduction

Risk Value


3.1.1.c Verify that policies

and procedures include

coverage for all storage of

cardholder data.








applicable.

3.1.1.d Verify that policies

and procedures include at

least one of the following:

* A programmatic process

(automatic or manual) to

remove, at least quarterly,

stored cardholder data that

exceeds requirements

defined in the data

retention policy

* Requirements for a

review, conducted at least

quarterly, to verify that

stored cardholder data does

not exceed requirements

defined in the data

retention policy.








applicable.

3.1.1.e For a sample of

system components that

store cardholder data,

verify that the data stored

does not exceed the

requirements defined in the

data retention policy.








applicable.

3.2.a For issuers and/or

companies that support

issuing services and store

sensitive authentication

data, verify there is a

business justification for the

storage of sensitive

authentication data, and

that the data is secured.

1 Not Applicable Not applicable for merchants.



Procedure

Scope Reduction

Risk Value


3.2.b For all other entities,

if sensitive authentication

data is received and

deleted, obtain and review

the processes for securely

deleting the data to verify

that the data is

unrecoverable.

1 Not Applicable Sensitive authentication data will not be

stored within or outside of hardware POI

devices.

3.2.c For each item of

sensitive authentication

data below, perform the

following steps:

3.2.1 For a sample of

system components,

examine data sources,


the following, and verify

that the full contents of any

track from the magnetic

stripe on the back of card or

equivalent data on a chip

are not stored under any

circumstance:

* Incoming transaction data

* All logs (for example,

transaction, history,

debugging, error)

* History files

* Trace files

* Several database schemas

* Database contents



devices.



Procedure

Scope Reduction

Risk Value



system components,



the following, and verify

that the three-digit or four-

digit card verification code

or value printed on the

front of the card or the

signature panel (CVV2,

CVC2, CID, CAV2 data) is not

stored under any

circumstance:




debugging, error)

* History files

* Trace files


* Database contents




processes associated with its payment

channel that includes card validation codes

then this requirement will still apply to

documents. Otherwise, this requirement

can be considered not applicable.

Sensitive authentication data will not be


devices.


system components,



the following and verify

that PINs and encrypted PIN

blocks are not stored under

any circumstance:




debugging, error)

* History files

* Trace files


* Database contents



devices.



Procedure

Scope Reduction

Risk Value


3.3 Obtain and examine

written policies and

examine displays of PAN

(for example, on screen, on

paper receipts) to verify

that primary account

numbers (PANs) are masked

when displaying cardholder

data, except for those with

a legitimate business need

to see full PAN.








applicable.

3.4.a Obtain and examine

documentation about the

system used to protect the

PAN, including the vendor,

type of system/process, and

the encryption algorithms

(if applicable). Verify that

the PAN is rendered

unreadable using any of the

following methods:

* One-way hashes based on

strong cryptography

* Truncation

* Index tokens and pads,

with the pads being

securely stored

* Strong cryptography, with

associated key-

management processes and

procedures

1 Not Applicable PAN will be rendered unreadable at swipe

on POI devices. Merchants will have no

responsibility for cardholder data within

their environments.

3.4.b Examine several

tables or files from a sample

of data repositories to

verify the PAN is rendered

unreadable (that is, not

stored in plain-text).




their environments.

3.4.c Examine a sample of

removable media (for

example, back-up tapes) to

confirm that the PAN is




their environments.



Procedure

Scope Reduction

Risk Value


rendered unreadable.

3.4.d Examine a sample of

audit logs to confirm that

the PAN is rendered

unreadable or removed

from the logs.




their environments.

3.4.1.a If disk encryption is

used, verify that logical

access to encrypted file

systems is implemented via

a mechanism that is

separate from the native

operating systems

mechanism (for example,

not using local user account

databases).




their environments.

3.4.1.b Verify that

cryptographic keys are

stored securely (for

example, stored on

removable media that is

adequately protected with

strong access controls).




their environments.

3.4.1.c Verify that

cardholder data on

removable media is

encrypted wherever stored.

Note: If disk encryption is

not used to encrypt

removable media, the data

stored on this media will

need to be rendered

unreadable through some

other method.




their environments.



Procedure

Scope Reduction

Risk Value


3.5 Verify processes to

protect keys used for

encryption of cardholder

data against disclosure and

misuse by performing the

following:

3.5.1 Examine user access

lists to verify that access to

keys is restricted to the

fewest number of

custodians necessary.

1 Not Applicable. If TAVE has been implemented correctly,

Merchants will have no key management

responsibilities within their environment.

3.5.2.a Examine system

configuration files to verify

that keys are stored in

encrypted format and that

key-encrypting keys are

stored separately from

data-encrypting keys.




3.5.2.b Identify key storage

locations to verify that keys

are stored in the fewest

possible locations and

forms




3.6.a Verify the existence of

key-management

procedures for keys used

for encryption of

cardholder data.






Procedure

Scope Reduction

Risk Value


3.6.b For service providers

only: If the service provider

shares keys with their

customers for transmission

or storage of cardholder

data, verify that the service

provider provides

documentation to

customers that includes

guidance on how to

securely transmit, store and

update customer’s keys, in

accordance with

Requirements 3.6.1 through

3.6.8 below.

1 Not Applicable. Not applicable for merchants.

3.6.c Examine the key-

management procedures

and perform the following:

3.6.1 Verify that key-


are implemented to require

the generation of strong

keys.







secure key distribution.







secure key storage.







periodic key changes at the

end of the defined

cryptoperiod.






Procedure

Scope Reduction

Risk Value


3.6.5.a Verify that key-



the retirement of keys

when the integrity of the

key has been weakened.




3.6.5.b Verify that the key-



the replacement of known

or suspected compromised

keys.




3.6.5.c If retired or replaced

cryptographic keys are

retained, verify that these

keys are not used for

encryption operations.




3.6.6 Verify that manual

clear-text key-management

procedures require split

knowledge and dual control

of keys.







the prevention of

unauthorized substitution

of keys.







key custodians to

acknowledge (in writing or

electronically) that they

understand and accept their

key-custodian

responsibilities.






Procedure

Scope Reduction

Risk Value


4.1 Verify the use of

security protocols wherever

cardholder data is

transmitted or received

over open, public networks.

Verify that strong

cryptography is used during

data transmission, as

follows:

4.1.a Select a sample of

transactions as they are

received and observe

transactions as they occur

to verify that cardholder

data is encrypted during

transit.




4.1.b Verify that only

trusted keys and/or

certificates are accepted.




4.1.c Verify that the

protocol is implemented to

use only secure

configurations, and does

not support insecure

versions or configurations.




4.1.d Verify that the proper

encryption strength is

implemented for the

encryption methodology in

use. (Check vendor

recommendations/best

practices.)




4.1.e For SSL/TLS

implementations:

* Verify that HTTPS appears

as a part of the browser

Universal Record Locator

(URL).

* Verify that no cardholder

data is required when






Procedure

Scope Reduction

Risk Value


HTTPS does not appear in

the URL.

4.1.1 For wireless networks

transmitting cardholder

data or connected to the

cardholder data

environment, verify that

industry best practices (for

example, IEEE 802.11i) are

used to implement strong

encryption for

authentication and

transmission.




4.2.a Verify that PAN is

rendered unreadable or

secured with strong

cryptography whenever it is

sent via end-user messaging

technologies.




4.2.b Verify the existence of

a policy stating that

unprotected PANs are not

to be sent via end-user

messaging technologies.

2 Acceptable Usage Policies Merchants will not have any access to

cardholder data within their environment;

however, employees will still have access to

the physcial credit card in retail

environments. As such, a policy prohibiting

the emailing of unprotected PAN is still

appropriate for most retail environments.

5.1 For a sample of system

components including all

operating system types

commonly affected by

malicious software, verify

that anti-virus software is

deployed if applicable anti-

virus technology exists.



for all server components located on the

merchant’s host network. Anti-virus and

anti-malware requirements will not be

applicable.



Procedure

Scope Reduction

Risk Value




that all anti-virus programs

detect, remove, and protect

against all known types of

malicious software (for

example, viruses, Trojans,

worms, spyware, adware,

and rootkits).






applicable.

5.2 Verify that all anti-virus

software is current, actively

running, and generating

logs by performing the

following:


the policy and verify that it

requires updating of anti-

virus software and

definitions.






applicable.

5.2.b Verify that the master

installation of the software

is enabled for automatic

updates and periodic scans.






applicable.

5.2.c For a sample of

system components

including all operating

system types commonly

affected by malicious

software, verify that

automatic updates and

periodic scans are enabled.






applicable.



Procedure

Scope Reduction

Risk Value


5.2.d For a sample of


that anti-virus software log

generation is enabled and

that such logs are retained

in accordance with PCI DSS

Requirement 10.7.






applicable.

6.1.a For a sample of

system components and

related software, compare

the list of security patches

installed on each system to

the most recent vendor

security patch list, to verify

that current vendor patches

are installed.





devices).

6.1.b Examine policies

related to security patch

installation to verify they

require installation of all

critical new security patches

within one month.





devices).

6.2.a Interview responsible

personnel to verify that

processes are implemented

to identify new security

vulnerabilities, and that a

risk ranking is assigned to

such vulnerabilities. (At

minimum, the most critical,

highest risk vulnerabilities

should be ranked as “High.”





devices).

6.2.b Verify that processes

to identify new security

vulnerabilities include using

outside sources for security

vulnerability information.





devices).



Procedure

Scope Reduction

Risk Value



written software

development processes to

verify that the processes

are based on industry

standards and/or best

practices.

1 Not Applicable This control will be out of scope for

merchants utilizing TAVE as there will be no

self-developed payment applications within

the CDE.

6.3.b Examine written

software development

processes to verify that

information security is

included throughout the life

cycle.




the CDE.

6.3.c Examine written


processes to verify that

software applications are

developed in accordance

with PCI DSS.




the CDE.

6.3.d From an examination

of written software

development processes,

and interviews of software

developers, verify that:




the CDE.

6.3.1 Custom application

accounts, user IDs and/or

passwords are removed

before system goes into

production or is released to

customers.




the CDE.



Procedure

Scope Reduction

Risk Value


6.3.2.a Obtain and review

policies to confirm that all

custom application code

changes must be reviewed

(using either manual or

automated processes) as

follows:

* Code changes are

reviewed by individuals

other than the originating

code author, and by

individuals who are

knowledgeable in code

review techniques and

secure coding practices.

* Code reviews ensure code

is developed according to

secure coding guidelines

(see PCI DSS Requirement

6.5).

* Appropriate corrections

are implemented prior to

release.

* Code review results are

reviewed and approved by

management prior to

release.




the CDE.

6.3.2.b Select a sample of

recent custom application

changes and verify that

custom application code is

reviewed according to

6.3.2.a, above.




the CDE.

6.4 From an examination of

change control processes,

interviews with system and

network administrators,

and examination of relevant

data (network configuration

documentation, production

and test data, etc.), verify

the following:



Procedure

Scope Reduction

Risk Value


6.4.1 The

development/test

environments are separate

from the production

environment, with access

control in place to enforce

the separation.





devices).

6.4.2 There is a separation

of duties between

personnel assigned to the

development/test

environments and those

assigned to the production

environment.





devices).

6.4.3 Production data (live

PANs) are not used for

testing or development.





devices).

Merchants will have no access to cardholder

data (PANs) within their environment.

6.4.4 Test data and

accounts are removed

before a production system

becomes active.





devices).

6.4.5.a Verify that change-

control procedures related

to implementing security

patches and software

modifications are

documented and require

items 6.4.5.1 – 6.4.5.4

below.





devices).



Procedure

Scope Reduction

Risk Value


6.4.5.b For a sample of

system components and

recent changes/security

patches, trace those

changes back to related

change control

documentation. For each

change examined, perform

the following:

6.4.5.1 Verify that

documentation of impact is

included in the change

control documentation for

each sampled change.





devices).

6.4.5.2 Verify that

documented approval by

authorized parties is

present for each sampled

change.





devices).

6.4.5.3.a For each sampled

change, verify that

functionality testing is

performed to verify that the

change does not adversely

impact the security of the

system.





devices).

6.4.5.3.b For custom code

changes, verify that all

updates are tested for

compliance with PCI DSS

Requirement 6.5 before

being deployed into

production.





devices).

This control will be out of scope for





Procedure

Scope Reduction

Risk Value


the CDE.

6.4.5.4 Verify that back-out

procedures are prepared

for each sampled change.





devices).

6.5.a Obtain and review


processes. Verify that

processes require training

in secure coding techniques

for developers, based on

industry best practices and

guidance.




the CDE.

6.5.b Interview a sample of

developers and obtain

evidence that they are

knowledgeable in secure

coding techniques.




the CDE.

6.5.c. Verify that processes

are in place to ensure that

applications are not

vulnerable to, at a

minimum, the following:

6.5.1 Injection flaws,

particularly SQL injection.

(Validate input to verify

user data cannot modify

meaning of commands and

queries, utilize

parameterized queries, etc.)




the CDE.



Procedure

Scope Reduction

Risk Value


6.5.2 Buffer overflow

(Validate buffer boundaries

and truncate input strings.)




the CDE.

6.5.3 Insecure

cryptographic storage

(Prevent cryptographic

flaws)




the CDE.

6.5.4 Insecure

communications (Properly

encrypt all authenticated

and sensitive

communications)




the CDE.

6.5.5 Improper error

handling (Do not leak

information via error

messages)




the CDE.

6.5.6 All “High”

vulnerabilities as identified

in PCI DSS Requirement 6.2.




the CDE.

6.5.7 Cross-site scripting

(XSS) (Validate all

parameters before

inclusion, utilize context-

sensitive escaping, etc.)




the CDE.

6.5.8 Improper Access

Control, such as insecure

direct object references,

failure to restrict URL

access, and directory

traversal (Properly

authenticate users and

sanitize input. Do not

expose internal object

references to users.)




the CDE.



Procedure

Scope Reduction

Risk Value


6.5.9 Cross-site request

forgery (CSRF). (Do not

reply on authorization

credentials and tokens

automatically submitted by

browsers.)




the CDE.

6.6 For public-facing web

applications, ensure that

either one of the following

methods are in place as

follows:

* Verify that public-facing

web applications are

reviewed (using either

manual or automated

vulnerability security

assessment tools or

methods), as follows:

- At least annually

- After any changes

- By an organization that

specializes in application

security

- That all vulnerabilities are

corrected

- That the application is re-

evaluated after the

corrections

* Verify that a web-

application firewall is in

place in front of public-

facing web applications to

detect and prevent web-

based attacks.

Note: “An organization that

specializes in application

security” can be either a

third-party company or an

internal organization, as

long as the reviewers

specialize in application

security and can




the CDE.



Procedure

Scope Reduction

Risk Value


demonstrate independence

from the development

team.


written policy for data

control, and verify that the

policy incorporates the

following:





devices).

7.1.1 Confirm that access

rights for privileged user IDs

are restricted to least

privileges necessary to

perform job responsibilities.





devices).



Procedure

Scope Reduction

Risk Value


7.1.2 Confirm that

privileges are assigned to

individuals based on job

classification and function

(also called “role-based

access control” or RBAC).





devices).

7.1.3 Confirm that

documented approval by

authorized parties is

required (in writing or

electronically) for all access,

and that it must specify

required privileges.





devices).


controls are implemented

via an automated access

control system.





devices).

7.2 Examine system settings

and vendor documentation

to verify that an access

control system is

implemented as follows:


control systems are in place

on all system components.





devices).


control systems are

configured to enforce

privileges assigned to

individuals based on job

classification and function.





devices).



Procedure

Scope Reduction

Risk Value


7.2.3 Confirm that the

access control systems have

a default “deny-all” setting.





devices).

8.1 Verify that all users are

assigned a unique ID for

access to system

components or cardholder

data.





devices).

8.2 To verify that users are

authenticated using unique

ID and additional

authentication (for

example, a password) for

access to the cardholder

data environment, perform

the following:

* Obtain and examine

documentation describing

the authentication

method(s) used.

* For each type of

authentication method

used and for each type of

system component, observe

an authentication to verify

authentication is

functioning consistent with

documented authentication

method(s).





devices).



Procedure

Scope Reduction

Risk Value


8.3 To verify that two-factor

authentication is

implemented for all remote

network access, observe an

employee (for example, an

administrator) connecting

remotely to the network

and verify that two of the

three authentication

methods are used.





devices).

8.4.a For a sample of

system components,

examine password files to

verify that passwords are

unreadable during

transmission and storage.





devices).

8.4.b For service providers

only, observe password files

to verify that customer

passwords are encrypted.

1 Not Applicable for merchants.

8.5 Review procedures and

interview personnel to

verify that procedures are

implemented for user

identification and

authentication

management, by

performing the following:



Procedure

Scope Reduction

Risk Value


8.5.1 Select a sample of

user IDs, including both

administrators and general

users. Verify that each user

is authorized to use the

system according to policy

by performing the

following:

* Obtain and examine an

authorization form for each

ID.

* Verify that the sampled

user IDs are implemented in

accordance with the

authorization form

(including with privileges as

specified and all signatures

obtained), by tracing

information from the

authorization form to the

system.





devices).

8.5.2 Examine

password/authentication

procedures and observe

security personnel to verify

that, if a user requests a

password reset by phone, e-

mail, web, or other non-

face-to-face method, the

user’s identity is verified

before the password is

reset.





devices).

8.5.3 Examine password

procedures and observe

security personnel to verify

that first-time passwords

for new users, and reset

passwords for existing

users, are set to a unique

value for each user and

changed after first use.





devices).



Procedure

Scope Reduction

Risk Value


8.5.4 Select a sample of

users terminated in the past

six months, and review

current user access lists to

verify that their IDs have

been deactivated or

removed.





devices).

8.5.5 Verify that inactive

accounts over 90 days old

are either removed or

disabled.





devices).

8.5.6.a Verify that any

accounts used by vendors

to access, support and

maintain system

components are disabled,

and enabled only when

needed by the vendor.





devices).

8.5.6.b Verify that vendor

remote access accounts are

monitored while being

used.





devices).

8.5.7 Interview the users

from a sample of user IDs,

to verify that they are

familiar with authentication

procedures and policies.





devices).



Procedure

Scope Reduction

Risk Value



system components,

examine user ID lists to

verify the following:

* Generic user IDs and

accounts are disabled or

removed

* Shared user IDs for

system administration

activities and other critical

functions do not exist

* Shared and generic user

IDs are not used to

administer any system

components





devices).

8.5.8.b Examine

authentication

policies/procedures to

verify that group and

shared passwords or other

authentication methods are

explicitly prohibited.





devices).

8.5.8.c Interview system

administrators to verify that

group and shared

passwords or other

authentication methods are

not distributed, even if

requested.





devices).


system components, obtain

and inspect system

configuration settings to

verify that user password

parameters are set to

require users to change

passwords at least every 90

days.





devices).



Procedure

Scope Reduction

Risk Value


8.5.9.b For service

providers only, review

internal processes and

customer/user


that non-consumer user

passwords are required to

change periodically and that

non-consumer users are

given guidance as to when,

and under what

circumstances, passwords

must change.

1 Not Applicable Not applicable in merchant environments.



and inspect system


verify that password


require passwords to be at

least seven characters long.





devices).

8.5.10.b For service



customer/user


that that non-consumer

user passwords are

required to meet minimum

length requirements.




and inspect system




require passwords to

contain both numeric and

alphabetic characters.





devices).



Procedure

Scope Reduction

Risk Value





customer/user



passwords are required to

contain both numeric and

alphabetic characters.




and inspect system




require that new passwords

cannot be the same as the

four previously used

passwords.





devices).




customer/user


that new non-consumer

user passwords cannot be

the same as the previous

four passwords.




and inspect system


verify that authentication


require that a user’s

account be locked out after

not more than six invalid

logon attempts.





devices).



Procedure

Scope Reduction

Risk Value





customer/user



accounts are temporarily

locked-out after not more

than six invalid access

attempts.




and inspect system




require that once a user

account is locked out, it

remains locked for a

minimum of 30 minutes or

until a system administrator

resets the account.





devices).



and inspect system


verify that system/session

idle time out features have

been set to 15 minutes or

less.





devices).

8.5.16.a Review database

and application

configuration settings and

verify that all users are

authenticated prior to

access.

1 Not Applicable There will be no cardholder data repositories

when TAVE is implemented properly.



Procedure

Scope Reduction

Risk Value


8.5.16.b Verify that

database and application

configuration settings

ensure that all user access

to, user queries of, and user

actions on (for example,

move, copy, delete), the

database are through

programmatic methods

only (for example, through

stored procedures).



8.5.16.c Verify that

database and application

configuration settings

restrict user direct access or

queries to databases to

database administrators.



8.5.16.d Review database

applications and the related

application IDs to verify that

application IDs can only be

used by the applications

(and not by individual users

or other processes).



9.1 Verify the existence of

physical security controls

for each computer room,

data center, and other

physical areas with systems

in the cardholder data

environment.

* Verify that access is

controlled with badge

readers or other devices

including authorized badges

and lock and key.

* Observe a system

administrator’s attempt to

log into consoles for

randomly selected systems

in the cardholder

environment and verify that

2 Physical Security Policy Appropriate physical controls to ensure that

the POI devices cannot be physically altered,

perimeter devices are properly protected

and protecting any paper media containing

cardholder data are protected should be in

place.



Procedure

Scope Reduction

Risk Value


they are “locked” to

prevent unauthorized use.

9.1.1.a Verify that video

cameras and/or access

control mechanisms are in

place to monitor the

entry/exit points to

sensitive areas.

1 Not Applicable This control requirement can be eliminated

from scope since there should not be any

"sensitive" areas in the merchant

environment outside of the POI terminals.

9.1.1.b Verify that video


control mechanisms are

protected from tampering

or disabling.





9.1.1.c Verify that video


control mechanisms are

monitored and that data

from cameras or other

mechanisms is stored for at

least three months.







Procedure

Scope Reduction

Risk Value


9.1.2 Verify by interviewing

network administrators and

by observation that

network jacks are enabled

only when needed by

authorized onsite

personnel. Alternatively,

verify that visitors are

escorted at all times in

areas with active network

jacks.

2 Physical Security Policy Appropriate physical controls to ensure that

the POI devices cannot be physically altered,

perimeter devices are properly protected

and protecting any paper media containing

cardholder data are protected should be in

place.

9.1.3 Verify that physical

access to wireless access

points, gateways, handheld

devices,

networking/communication

s hardware, and

telecommunication lines is

appropriately restricted.




9.2.a Review processes and

procedures for assigning

badges to onsite personnel

and visitors, and verify

these processes include the

following:

* Granting new badges,

* Changing access

requirements, and

* Revoking terminated

onsite personnel and

expired visitor badges

2 Physical Security Policy

Cardholder data will not be accessible within

the merchant environment; therefore, the

scope of this requirement can be greatly

reduced; however, controls should ensure

that unauthorized visitors cannot access

perimeter systems or POI devices.

9.2.b Verify that access to

the badge system is limited

to authorized personnel.

2 Physical Security Policy Cardholder data will not be accessible within








Procedure

Scope Reduction

Risk Value


9.2.c Examine badges in use

to verify that they clearly

identify visitors and it is

easy to distinguish between

onsite personnel and

visitors.







9.3 Verify that visitor

controls are in place as

follows:

9.3.1 Observe the use of

visitor ID badges to verify

that a visitor ID badge does

not permit unescorted

access to physical areas that

store cardholder data.







9.3.2.a Observe people

within the facility to verify

the use of visitor ID badges,

and that visitors are easily

distinguishable from onsite

personnel.







9.3.2.b Verify that visitor

badges expire.







9.3.3 Observe visitors

leaving the facility to verify

visitors are asked to

surrender their ID badge

upon departure or

expiration.







9.4.a Verify that a visitor log

is in use to record physical

access to the facility as well

as for computer rooms and

data centers where

cardholder data is stored or









Procedure

Scope Reduction

Risk Value


transmitted.

9.4.b Verify that the log

contains the visitor’s name,

the firm represented, and

the onsite personnel

authorizing physical access,

and is retained for at least

three months.







9.5.a Observe the storage

location’s physical security

to confirm that backup

media storage is secure.


Data Retention and Storage







applicable.

9.5.b Verify that the storage

location security is

reviewed at least annually.


Data Retention and Storage







applicable.

9.6 Verify that procedures

for protecting cardholder

data include controls for

physically securing all media

(including but not limited to

computers, removable

electronic media, paper

receipts, paper reports, and

faxes).








applicable.

9.7 Verify that a policy

exists to control distribution

of media, and that the

policy covers all distributed

media including that

distributed to individuals.








applicable.



Procedure

Scope Reduction

Risk Value


9.7.1 Verify that all media is

classified so the sensitivity

of the data can be

determined.








applicable.

9.7.2 Verify that all media

sent outside the facility is

logged and authorized by

management and sent via

secured courier or other

delivery method that can be

tracked.








applicable.

9.8 Select a recent sample

of several days of offsite

tracking logs for all media,

and verify the presence in

the logs of tracking details

and proper management

authorization.








applicable.

9.9 Obtain and examine the

policy for controlling

storage and maintenance of

all media and verify that the

policy requires periodic

media inventories.








applicable.

9.9.1 Obtain and review the

media inventory log to

verify that periodic media

inventories are performed

at least annually.








applicable.


the periodic media

destruction policy and

verify that it covers all

media, and confirm the

following:








applicable.



Procedure

Scope Reduction

Risk Value


9.10.1.a Verify that hard-

copy materials are crosscut

shredded, incinerated, or

pulped such that there is

reasonable assurance the

hard-copy materials cannot

be reconstructed.








applicable.

9.10.1.b Examine storage

containers used for

information to be destroyed

to verify that the containers

are secured. For example,

verify that a “to-be-

shredded” container has a

lock preventing access to its

contents.








applicable.

9.10.2 Verify that

cardholder data on

electronic media is

rendered unrecoverable via

a secure wipe program in

accordance with industry-

accepted standards for

secure deletion, or

otherwise physically

destroying the media (for

example, degaussing).

1 Not Applicable There will be no electronic instances of

cardholder data storage within the merchant

environment.

10.1 Verify through

observation and

interviewing the system

administrator, that audit

trails are enabled and active

for system components.





devices).

10.2 Through interviews,

examination of audit logs,

and examination of audit

log settings, perform the

following:



Procedure

Scope Reduction

Risk Value


10.2.1 Verify all individual

access to cardholder data is

logged.

1 Not Applicable. Merchant access to cardholder will not be

possible with the proper implementation of

TAVE.

10.2.2 Verify actions taken

by any individual with root

or administrative privileges

are logged.





devices).

10.2.3 Verify access to all

audit trails is logged.





devices).

10.2.4 Verify invalid logical

access attempts are logged.





devices).

10.2.5 Verify use of

identification and

authentication mechanisms

is logged.





devices).

10.2.6 Verify initialization of

audit logs is logged.





devices).



Procedure

Scope Reduction

Risk Value


10.2.7 Verify creation and

deletion of system level

objects are logged.





devices).

10.3 Through interviews

and observation, for each

auditable event (from 10.2),

perform the following:

10.3.1 Verify user

identification is included in

log entries.





devices).

10.3.2 Verify type of event

is included in log entries.





devices).

10.3.3 Verify date and time

stamp is included in log

entries.





devices).

10.3.4 Verify success or

failure indication is included

in log entries.





devices).



Procedure

Scope Reduction

Risk Value


10.3.5 Verify origination of

event is included in log

entries.





devices).

10.3.6 Verify identity or

name of affected data,

system component, or

resources is included in log

entries.





devices).

10.4.a Verify that time-

synchronization technology

is implemented and kept

current per PCI DSS

Requirements 6.1 and 6.2.





devices).

10.4.b Obtain and review

the process for acquiring,

distributing and storing the

correct time within the

organization, and review

the time-related system-

parameter settings for a

sample of system

components. Verify the

following is included in the

process and implemented:

10.4.1.a Verify that only

designated central time

servers receive time signals

from external sources, and

time signals from external

sources are based on

International Atomic Time

or UTC.





devices).



Procedure

Scope Reduction

Risk Value



designated central time

servers peer with each

other to keep accurate

time, and other internal

servers receive time only

from the central time

servers.





devices).

10.4.2.a Review system

configurations and time-

synchronization settings to

verify that access to time

data is restricted to only

personnel with a business

need to access time data.





devices).

10.4.2.b Review system

configurations and time

synchronization settings

and processes to verify that

any changes to time

settings on critical systems

are logged, monitored, and

reviewed.





devices).

10.4.3 Verify that the time

servers accept time updates

from specific, industry-

accepted external sources

(to prevent a malicious

individual from changing

the clock). Optionally, those

updates can be encrypted

with a symmetric key, and

access control lists can be

created that specify the IP

addresses of client

machines that will be

provided with the time

updates (to prevent

unauthorized use of

internal time servers).





devices).



Procedure

Scope Reduction

Risk Value


10.5 Interview system

administrator and examine

permissions to verify that

audit trails are secured so

that they cannot be altered

as follows:

10.5.1 Verify that only

individuals who have a job-

related need can view audit

trail files.





devices).

10.5.2 Verify that current

audit trail files are

protected from

unauthorized modifications

via access control

mechanisms, physical

segregation, and/or

network segregation.





devices).

10.5.3 Verify that current

audit trail files are promptly

backed up to a centralized

log server or media that is

difficult to alter.





devices).

10.5.4 Verify that logs for

external-facing technologies

(for example, wireless,

firewalls, DNS, mail) are

offloaded or copied onto a

secure centralized internal

log server or media.





devices).

10.5.5 Verify the use of file-

integrity monitoring or

change-detection software

for logs by examining

system settings and

monitored files and results





devices).



Procedure

Scope Reduction

Risk Value


from monitoring activities.


security policies and

procedures to verify that

they include procedures to

review security logs at least

daily and that follow-up to

exceptions is required.





devices).

10.6.b Through observation

and interviews, verify that

regular log reviews are

performed for all system

components.





devices).


security policies and

procedures and verify that

they include audit log

retention policies and

require audit log retention

for at least one year.





devices).

10.7.b Verify that audit logs

are available for at least

one year and processes are

in place to immediately

restore at least the last

three months’ logs for

analysis.





devices).

11.1.a Verify that the entity

has a documented process

to detect and identify

wireless access points on a

quarterly basis.






Procedure

Scope Reduction

Risk Value


11.1.b Verify that the

methodology is adequate to

detect and identify any

unauthorized wireless

access points, including at

least the following:

* WLAN cards inserted into

system components

* Portable wireless devices

connected to system

components (for example,

by USB, etc.)

* Wireless devices attached

to a network port or

network device




11.1.c Verify that the

documented process to

identify unauthorized

wireless access points is

performed at least

quarterly for all system

components and facilities.




11.1.d If automated

monitoring is utilized (for

example, wireless IDS/IPS,

NAC, etc.), verify the

configuration will generate

alerts to personnel.




11.1.e Verify the

organization’s incident

response plan

(Requirement 12.9) includes

a response in the event


devices are detected.




11.2 Verify that internal and

external vulnerability scans

are performed as follows:



Procedure

Scope Reduction

Risk Value


11.2.1.a Review the scan

reports and verify that four

quarterly internal scans

occurred in the most recent

12-month period.





devices).

As such, there are no applicable internal

vulnerability scanning requirements.

11.2.1.b Review the scan

reports and verify that the

scan process includes

rescans until passing results

are obtained, or all “High”

vulnerabilities as defined in

PCI DSS Requirement 6.2

are resolved.





devices).



11.2.1.c Validate that the

scan was performed by a

qualified internal

resource(s) or qualified

external third party, and if

applicable, organizational

independence of the tester

exists (not required to be a

QSA or ASV).





devices).



11.2.2.a Review output

from the four most recent

quarters of external

vulnerability scans and

verify that four quarterly

scans occurred in the most

recent 12-month period.





devices).

As such, there are no applicable external




Procedure

Scope Reduction

Risk Value


11.2.2.b Review the results

of each quarterly scan to

ensure that they satisfy the

ASV Program Guide

requirements (for example,

no vulnerabilities rated

higher than a 4.0 by the

CVSS and no automatic

failures).





devices).



11.2.2.c Review the scan

reports to verify that the

scans were completed by

an Approved Scanning

Vendor (ASV), approved by

the PCI SSC.





devices).



11.2.3.a Inspect change

control documentation and

scan reports to verify that

system components subject

to any significant change

were scanned.





devices).

As such, there are no applicable vulnerability

scanning requirements.

11.2.3.b Review scan

reports and verify that the

scan process includes

rescans until:

* For external scans, no

vulnerabilities exist that are

scored greater than a 4.0 by

the CVSS,

* For internal scans, a

passing result is obtained or

all “High” vulnerabilities as

defined in PCI DSS

Requirement 6.2 are





devices).





Procedure

Scope Reduction

Risk Value


resolved.

11.2.3.c Validate that the

scan was performed by a

qualified internal

resource(s) or qualified

external third party, and if

applicable, organizational



QSA or ASV).





devices).




the results from the most

recent penetration test to

verify that penetration

testing is performed at least

annually and after any

significant changes to the

environment.





devices).

As such, there are no applicable penetration

testing requirements.

11.3.b Verify that noted

exploitable vulnerabilities

were corrected and testing

repeated.





devices).





Procedure

Scope Reduction

Risk Value


11.3.c Verify that the test

was performed by a

qualified internal resource

or qualified external third

party, and if applicable,

organizational



QSA or ASV).





devices).



11.3.1 Verify that the

penetration test includes

network-layer penetration

tests. These tests should

include components that

support network functions

as well as operating

systems.





devices).




penetration test includes

application-layer

penetration tests. The tests

should include, at a

minimum, the

vulnerabilities listed in

Requirement 6.5.





devices).



11.4.a Verify the use of

intrusion-detection systems

and/or intrusion-prevention

systems and that all traffic

at the perimeter of the

cardholder data

environment as well as at

critical points in the

cardholder data

environment is monitored.




11.4.b Confirm IDS and/or

IPS are configured to alert

personnel of suspected

compromises.






Procedure

Scope Reduction

Risk Value


11.4.c Examine IDS/IPS

configurations and confirm

IDS/IPS devices are

configured, maintained, and

updated per vendor

instructions to ensure

optimal protection.




11.5.a Verify the use of file-

integrity monitoring tools

within the cardholder data

environment by observing

system settings and

monitored files, as well as

reviewing results from

monitoring activities.

Examples of files that

should be monitored:

* System executables

* Application executables

* Configuration and

parameter files

* Centrally stored, historical

or archived, log and audit

files





devices).

11.5.b Verify the tools are

configured to alert

personnel to unauthorized

modification of critical files,

and to perform critical file

comparisons at least

weekly.





devices).

12.1 Examine the

information security policy

and verify that the policy is

published and disseminated

to all relevant personnel

(including vendors and

business partners).

4 Information Security Policy This requirement is fully in-scope for the

merchant’s PCI-DSS assessment.

12.1.1 Verify that the policy

addresses all PCI DSS





Procedure

Scope Reduction

Risk Value


requirements.

12.1.2.a Verify that an

annual risk assessment

process is documented that

identifies threats,

vulnerabilities, and results

in a formal risk assessment.



12.1.2.b Review risk

assessment documentation

to verify that the risk

assessment process is

performed at least annually.

4 Information Security Policy

Annual Risk Assessment

This requirement is fully in-scope for the



information security policy

is reviewed at least annually

and updated as needed to

reflect changes to business

objectives or the risk

environment.



12.2 Examine the daily

operational security

procedures. Verify that they

are consistent with this

specification, and include

administrative and technical

procedures for each of the

requirements.




the usage policies for

critical technologies and


12.3.1 Verify that the usage

policies require explicit

approval from authorized

parties to use the

technologies.

4 Acceptable Usage Policies This requirement is fully in-scope for the




Procedure

Scope Reduction

Risk Value



policies require that all

technology use be

authenticated with user ID

and password or other

authentication item (for

example, token).




policies require a list of all

devices and personnel

authorized to use the

devices.




policies require labeling of

devices with information

that can be correlated to

owner, contact information

and purpose.




policies require acceptable

uses for the technology.




policies require acceptable

network locations for the

technology.




policies require a list of

company-approved

products.




policies require automatic

disconnect of sessions for

remote-access technologies

after a specific period of

inactivity.





Procedure

Scope Reduction

Risk Value



policies require activation

of remote-access

technologies used by

vendors and business

partners only when needed

by vendors and business

partners, with immediate

deactivation after use.



12.3.10.a Verify that the

usage policies prohibit

copying, moving, or storing

of cardholder data onto

local hard drives and

removable electronic media

when accessing such data

via remote-access

technologies.

1 Not Applicable Cardholder data will not be accessible within

the merchant environment.

12.3.10.b For personnel

with proper authorization,

verify that usage policies

require the protection of

cardholder data in

accordance with PCI DSS

Requirements.

1 Not Applicable Cardholder data will not be accessible within

the merchant environment.

12.4 Verify that information

security policies clearly

define information security

responsibilities for all

personnel.





Procedure

Scope Reduction

Risk Value


12.5 Verify the formal

assignment of information

security to a Chief Security

Officer or other security-

knowledgeable member of

management.

Obtain and examine

information security

policies and procedures to

verify that the following

information security

responsibilities are

specifically and formally

assigned:



12.5.1 Verify that

responsibility for creating

and distributing security

policies and procedures is

formally assigned.



12.5.2 Verify that

responsibility for

monitoring and analyzing

security alerts and

distributing information to

appropriate information

security and business unit

management personnel is

formally assigned.



12.5.3 Verify that

responsibility for creating

and distributing security

incident response and

escalation procedures is

formally assigned.



12.5.4 Verify that

responsibility for

administering user account

and authentication

management is formally





Procedure

Scope Reduction

Risk Value


assigned.

12.5.5 Verify that

responsibility for

monitoring and controlling

all access to data is formally

assigned.



12.6.a Verify the existence

of a formal security

awareness program for all

personnel.



12.6.b Obtain and examine

security awareness program

procedures and

documentation and


4 Security Awareness

Policy/Program





provides multiple methods

of communicating

awareness and educating

personnel (for example,

posters, letters, memos,

web based training,

meetings, and promotions).


Policy/Program



12.6.1.b Verify that

personnel attend

awareness training upon

hire and at least annually.


Policy/Program





requires personnel to

acknowledge, in writing or

electronically, at least

annually that they have

read and understand the

information security policy.


Policy/Program





Procedure

Scope Reduction

Risk Value


12.7 Inquire with Human

Resource department

management and verify

that background checks are

conducted (within the

constraints of local laws) on

potential personnel prior to

hire who will have access to

cardholder data or the

cardholder data

environment.



12.8 If the entity shares

cardholder data with

service providers (for

example, back-up tape

storage facilities, managed

service providers such as

Web hosting companies or

security service providers,

or those that receive data

for fraud modeling

purposes), through

observation, review of

policies and procedures,

and review of supporting

documentation, perform

the following:

12.8.1 Verify that a list of

service providers is

maintained.




written agreement includes

an acknowledgement by

the service providers of

their responsibility for

securing cardholder data.





Procedure

Scope Reduction

Risk Value


12.8.3 Verify that policies

and procedures are

documented and were

followed including proper

due diligence prior to

engaging any service

provider.



12.8.4 Verify that the entity

maintains a program to

monitor its service

providers’ PCI DSS

compliance status at least

annually.




the Incident Response Plan

and related procedures and



incident response plan

includes:

* Roles, responsibilities, and

communication strategies

in the event of a

compromise including

notification of the payment

brands, at a minimum:

* Specific incident response

procedures

* Business recovery and

continuity procedures

* Data back-up processes

* Analysis of legal

requirements for reporting

compromises (for example,

California Bill 1386 which

requires notification of

affected consumers in the

event of an actual or

suspected compromise for

any business with California

residents in their database)

* Coverage and responses

4 Incident Response Plan (IRP) This requirement is fully in-scope for the




Procedure

Scope Reduction

Risk Value


for all critical system

components

* Reference or inclusion of

incident response

procedures from the

payment brands

12.9.1.b Review

documentation from a

previously reported

incident or alert to verify

that the documented

incident response plan and

procedures were followed.



12.9.2 Verify that the plan is

tested at least annually.





Procedure

Scope Reduction

Risk Value


12.9.3 Verify through

observation and review of

policies, that designated

personnel are available for

24/7 incident response and

monitoring coverage for

any evidence of

unauthorized activity,

detection of unauthorized

wireless access points,

critical IDS alerts, and/or

reports of unauthorized

critical system or content

file changes.





policies that staff with

responsibilities for security

breach response are

periodically trained.





processes that monitoring

and responding to alerts

from security systems

including detection of


access points are covered in

the Incident Response Plan.





policies that there is a

process to modify and

evolve the incident

response plan according to

lessons learned and to

incorporate industry

developments.




Documents

First Data TransArmor VeriFone Edition Detailed Technical ... · First Data TransArmor VeriFone Edition Detailed Technical Assessment White Paper Prepared for: October 1st, 2013 Dan