First Data TransArmor VeriFone Edition Technical Assessment … › downloads › pdf ›...

First Data TransArmor VeriFone Edition Technical Assessment

White Paper

Prepared for:

March, 2016

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

[email protected]

mailto:[email protected]

Copyright 2016, Coalfire Systems Inc. Page | 2

Table of Contents

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

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

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

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

CONTROL REDUCTION FOR MERCHANTS ........................................................................................................................... 11

DEPLOYMENT SCENARIOS .............................................................................................................................................. 11

PCI DSS CONTROL REDUCTION SUMMARY ....................................................................................................................... 12

SUMMARY CHART OF MERCHANT PCI DSS CONTROL REDUCTION ........................................................................................ 12

DETAILED PCI DSS CONTROL REDUCTION ......................................................................................................................... 13

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

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

TRANSARMOR VERIFONE EDITION ENCRYPTION ASSESSMENT ............................................................................................... 18

KEY LOADING AND DISTRIBUTION .................................................................................................................................... 19

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

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


Executive Summary

Overview First Data engaged Coalfire Systems Inc. (Coalfire), as a respected Payment Card Industry (PCI) Qualified

Security Assessor Point to Point Encryption (QSA P2PE) company to provide an update to the First Data

TransArmor VeriFone Edition (TAVE) PCI DSS 3.1 whitepaper reflecting the current standards. Coalfire

conducted an independent technical assessment of the TransArmor VeriFone Edition (TAVE), secured by

RSA security solution in 2013. During that timeframe, Coalfire conducted assessment activities including

technical testing, an architectural assessment, industry analysis, a compliance validation and peer review.

The Whitepaper with PCI DSS 2.0 standards was released in July 2013. This paper reflects the revised

whitepaper addressing First Data TAVE and how it aligns to current PCI-DSS v3.1 standards.

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

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

minimize PCI DSS validation when properly deployed. This reduction in validation effort will be based on

evaluating the risk of each of the PCI DSS 3.1 requirements and how the TAVE security solution applies to

each control within the context of the current PCI P2PE standards released in 2015. The focus of this

paper is to clarify how a merchant can benefit from TAVE even though it is not yet a formally listed

solution. The conclusions from this paper are provided as guidance to First Data so that they can make a

risk based decision for the reduction of a merchant’s scope when properly using TAVE.

About TransArmor VeriFone Edition

TransArmor VeriFone Edition is a comprehensive, modular and flexible solution designed to provide

merchants with strong encryption of payment card data from the point of capture to the point of

decryption in First Data’s secure data center. TAVE combines VeriFone’s encryption methodology,

VeriFone Total Protect (VTP) and Format Preserving Encryption (FPE), along with First Data’s TransArmor

tokenization technology.

The goals of the TransArmor VeriFone Edition solution are:

1. Reduce the risk of compromise to cardholder data throughout the entire transaction process,

from point of entry through authorization and settlement.

2. Minimize the number of applicable controls that merchants must address for compliance to the

Payment Card Industry (PCI) Data Security Standard (DSS).

3. Simplify and reduce costs associated for merchants with validation of PCI DSS compliance

efforts.

TAVE helps shift the burden of protecting payment card data from the merchant to First Data using the

latest encryption and tokenization technologies. This solution:

Combines encryption and tokenization to protect cardholder data at every processing stage.

Maintains all the merchant’s business benefits of storing the payment cardholder data

without the associated risk.

Compliments Card Authentication technologies like EMV.


TAVE includes these high level components:

1. Merchant Point of Interaction (POI) – A VeriFone device encrypting cardholder data in hardware

as it is collected.

2. First Data Switch – This includes First Data’s Front End Authorization Platform (FEP) and Secure

Transaction Management (STM) handler for routing and processing capabilities. This is hosted

by First Data in a PCI DSS compliant facility.

3. First Data Decryption and Tokenization – This includes the Hardware Security Module (HSM),

VeriShield Decryption Service (VSD) and TransArmor (TA) for tokenization. This is again hosted

by First Data in a PCI DSS compliant facility.

This assessment included the above components in PCI compliant testing labs and focused on First Data’s

implementation of VeriFone’s VTP encryption methodology, paired with TransArmor tokenization, to

provide a secure encryption solution for merchants.

Audience

This assessment report has three potential audiences. This report is addressed primarily to the first

group, merchants, but can be used by others as well.

1. Merchants: This audience is evaluating the First Data TransArmor VeriFone Edition security

solution for deployment in their payment card environment. Merchants will be able to clearly

understand what benefits they can receive from using TAVE in their environment, including risk

and the reduction of applicable controls.

2. QSAs and the Internal Audit Community: This audience may be evaluating the First Data

TransArmor VeriFone Edition security solution to determine the impact on PCI DSS validation on

behalf of their merchant.

3. First Data and Partners: The final target audience is the product and engineering teams of First

Data and its technology partners. The purpose of including this audience is to provide an

independent evaluation of their solution and help them identify any areas for improvement.

Assessment Scope

The scope of our assessment focused on the critical elements that validate the security and effectiveness

of the security solution. Coalfire incorporated in-depth analysis of compliance fundamentals that are

essential for evaluation by merchants, service providers and the QSA community. In addition, Coalfire

reviewed information and feedback obtained from members of the PCI community; however, the opinions

and findings within this evaluation are solely those of Coalfire and do not represent any assessment

findings, or opinions, from any other parties.

Although tokenization is part of the TAVE solution, this assessment focuses solely on how TAVE uses

encryption and decryption technologies. The reader should gain an understanding on how TAVE can be

leveraged in the context of PCI DSS v3.1 and the current PCI P2PE standards. Tokenization is relevant to


protecting and reducing PCI DSS validation post-authorization for data at rest. For additional information

regarding the value of Tokenization, please review the link below:

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

This First Data paper leverages the testing performed for 2013 FD TAVE assessment and provides an

update to the 2013 FD TAVE whitepaper to reflect the current PCI DSS 3.1 standards.

Methodology

Coalfire has implemented industry best practices in our assessment and testing methodologies. Standard

validation methods were used throughout the assessment. Coalfire conducted technical lab testing in

both the Coalfire Lab located in Louisville, Colorado and the First Data Lab in Omaha Nebraska. This

included interviews, documentation review, transaction testing, encryption evaluation and forensic

analysis.

Merchant PCI DSS Compliance Scope

Even the best encryption technologies do not completely eliminate the scope of PCI DSS compliance

validation, as some in the industry have claimed. In fact, if a merchant is accepting a payment card, the

entirety of PCI DSS always applies to them. However, a properly implemented, and thoroughly evaluated,

encryption solution can satisfy a significant portion of the PCI DSS controls; thereby significantly reducing

the number of PCI DSS requirements a merchant is still responsible for validating.

In July 2013, the PCI SSC released an official P2PE 1.1 standard detailing what controls must be in place

for a merchant to have a validated, listed P2PE solution. That P2PE standard was updated to 2.0 in 2015.

This program works best for level four merchants. For encryption solutions not listed with the PCI SSC

(which would include most level one merchant solutions), the Council has stated that the acquirer or

payment brand should be consulted to determine how an encryption solution will affect their PCI DSS

compliance requirements. This assessment can be used by merchants using the TAVE solution to

understand what reduction of applicable controls is possible.

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

applicability, based on the PCI P2PE standards. Coalfire has reviewed each deployment scenario to assess

its impact on the cardholder data environment that would be considered applicable for PCI DSS validation.

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

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

appropriate PCI DSS reduction of applicable controls.

Technical Security Assessment

Coalfire evaluated and tested the complete TransArmor VeriFone Edition security solution within the

context of the applicable controls in the 6 domains as described in “Solution Requirements and Testing

Procedures: Encryption, Decryption, and Key Management within Secure Cryptographic Devices Version

1.1.1” published by the PCI SSC in July 2013, as well as other related documents including updates to the

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

management methods, and physical and logical protection.

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


Applicable compliance control requirement adherence from the PCI DSS, PCI PA-DSS, PCI P2PE and PCI

PTS were validated within the scope of our security assessment. Where control gaps or vulnerabilities

were identified, remediation guidance was communicated to responsible parties and follow-up testing

was performed to validate gap closure.

Security and Risk Profile

The greatest value of P2PE solutions for merchants is the reduction in risk of payment card data

compromise. Using our extensive experience with threat analysis, computer forensics, data breach

investigations and security incident response we validated the critical aspects of risk mitigation that the

TransArmor VeriFone Edition solution can provide for merchants.

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

A properly deployed TransArmor VeriFone Edition solution can provide significant risk reduction

of data compromise and is one of the most effective data security controls available to

merchants today.

TAVE utilizes VeriFone’s encryption in a secure manner that enables TAVE to provide the key

benefits of using encryption to reduce a significant portion of PCI DSS controls remaining for a

merchant to manage on a consistent basis.

Minimizing then number of points where data is decrypted and then re-encrypted for another

hop, and the number of points where clear text cardholder data exists is a clear security benefit.

In deployments of TAVE that go directly from the merchant to the acquirer, there is additional

risk reduction because there is no gateway or other middle man that then has unencrypted

cardholder data, even for a brief time.

A merchant should have ownership rights to the decryption keys, but not have access to, or

possession of these keys to achieve the greatest PCI DSS reduction.

A merchant can dramatically reduce the PCI DSS controls they are responsible for validating in

their retail and corporate environments if all electronic card data is captured at the POI in a

TransArmor VeriFone Edition TRSM (Tamper Resistant Security Module), the merchant is not

capable of decrypting captured data, and decryption keys do not exist within their environment.

A VeriFone PTS validated terminal should be the only point in a merchant retail environment

that captures card data through any supported input method: swipe, manual, EMV or

contactless. To achieve the greatest PCI DSS control reduction, Coalfire and First Data

recommend the use of a device with PTS 2.x with SRED or 3.x with SRED (Secure Reading and

Exchange of Data) enabled.

Assessor Comments

Our assessment scope put a significant focus on validating the PCI DSS compliance control reduction

impact of the TransArmor VeriFone Edition solution. The TAVE solution can significantly reduce the risk

of payment card data compromise for a merchant’s retail environment. There can be very clear and

dramatic reduction of PCI DSS validation with a properly deployed solution. However, ignoring the PCI


DSS and security best practices, even if a merchant is out of scope for PCI DSS compliance validation, can

introduce many other security or business continuity risks. Security and business risk mitigation should

be any merchant’s goal and focus for selecting security controls. The TransArmor VeriFone Edition

solution can benefit merchants by helping reduce the cost of PCI DSS compliance validation and allow

them to invest more of those resources into business risk mitigating controls.

With the release of the current PCI P2PE standard, merchants have an increased expectation to receive a

more secure environment that utilizes the latest encryption technologies. First Data’s TransArmor

VeriFone Edition offering provides such an environment for several different types of merchants in light

of a P2PE standard that may not fit every merchant.

PCI DSS Validation Reduction The Payment Card Industry has developed the PCI Data Security Standard (DSS) to mitigate the risk of

compromise to a specific data set. The standard is focused only to the system components that are

“within scope” of PCI. For all system components, all PCI DSS controls apply. The PCI DSS is based on

industry security best practices but is not focused on the overall information security of merchants. To

reduce applicable PCI DSS controls you must reduce the potential security risk and access to payment card

data.

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

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

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

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

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

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

controls apply to.

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

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

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

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

effectively “isolate” the majority of the merchant’s environment from control applicability. If specific

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

environment similar to a public network when using strong transmission encryption.

In July 2013 the PCI Security Standards Council (SSC) released the P2PE 1.1 standard. In 2015, the PCI SSC

updated the standard to 2.0. These standards can be found at PCI’s document library, under the P2PE

section, along with supporting documentation.

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

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


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

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

Frequently Asked Questions (FAQs) For Point-to-Point Encryption (P2PE)

The below FAQ from April 2012 could be referenced for information about how a merchant may receive

scope reduction through use of validated P2PE solution.

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

Are merchants using Council-listed P2PE solutions out of scope for PCI DSS?

A. No. While use of a validated, listed P2PE solution can help to reduce the scope of a merchant’s cardholder data environment, it does not remove the need for PCI DSS in the merchant environment. The merchant environment remains in scope for PCI DSS because cardholder data is always present within the merchant environment. For example, in a card-present environment, merchants have physical access to the payment cards in order to complete a transaction, and may also have paper reports or receipts with cardholder data. As another example, in card-not-present environments (such as mail-order or telephone-order), payment card details are provided via other channels that need to be evaluated and protected according to PCI DSS. Only Council-listed P2PE solutions are recognized as meeting the requirements necessary for

merchants to reduce the scope of their cardholder data environment through use of a P2PE

solution. Merchants using encryption solutions that are not included on the Council’s List of

Validated P2PE Solutions should consult with their acquirer or payment brand about use of these

solutions.

Another important FAQ from April 2012:

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

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

Merchants using encryption solutions that are not included on PCI SSC’s list of Validated

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

these solutions.

FAQs that were released in July 2014 provide additional and timely clarifications to the application of the

P2PE Solution Requirements and Testing Procedures. The FAQ below provides clarifications on the physical

security of the POI devices.

Are POI devices required to be physically secured (e.g. bolted to a counter-top or tethered with

a cable) in the merchant environment? How does this requirement apply to handheld/wireless

POI devices?

A. The intent of this requirement is for the solution provider to provide instructions in the PIM about

how to physically secure the POI device – for example, if the device has a cable connection or a

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


fixed bracket, the PIM should describe how to use these features. The merchant should be able to

use these instructions to secure devices as appropriate for their environment. Whether the

merchant applies the physical security instructions will depend on the type of environment the

device is being used in, and does not impact the P2PE solution assessment.

If a POI device is not intended to be secured in one place – for example, it is a handheld or wireless

device – the solution provider is expected to provide merchants with instructions for how to

implement process controls to protect the device. Examples of process controls could include

storing the device in an area inaccessible to the public when the device is not in use, assigning

responsibility to specific personnel for supervising use of the device, and so on. Again, the solution

provider’s responsibility is to provide this information in the PIM so the merchant is aware of best

practices. The actual methods implemented by merchants to secure POI devices may vary

according to the needs of the particular merchant.

July 2014 - What is acceptable evidence concerning P2PE compliance for a third-party entity that

underwent a P2PE assessment for services they offer on behalf of P2PE solution providers, such

that the third-party can provide that evidence to subsequent P2PE solution providers who use those

same services?

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

A. This topic will be addressed in P2PE v2.0. In the interim and for P2PE v1.1.1 assessments, a

third-party who is providing services on behalf of P2PE solution providers can provide a statement

to solution providers pursuing a P2PE assessment based on a prior P2PE assessment of the third-

party entity. Note that this FAQ applies only to services governed under P2PE Domains 1, 5, or 6

(including Annexes A and B) such as POI device management, decryption environment related

functions, Key Injection Facility (KIF) services, Certification Authority (CA), or Registration Authority

(RA).

The date the P2PE statement is signed for the third-party’s P2PE assessment (whether assessed

as part of a full P2PE solution or in isolation) must be less than one year before the date of any

subsequent solutions provider’s P2PE assessment completion date (i.e., the statement described

herein is only valid for one year).

This statement, as stated above, must be prepared by the QSA (P2PE) who assessed the third

party. The statement must be signed and dated by both the third-party and the QSA (P2PE), and

must attest to the fact that the third-party entity is compliant with all applicable P2PE requirements.

The statement must also contain [at a minimum] the following information, as applicable to the third-

party. Note that the statement is not required to contain any sensitive information.

Provide a summary of services being offered by the third party.

Provide information per the following bullets, which reference sections and tables present

in the Solution P-ROV Template v1.1.1. Please refer to that document as applicable

o Provide administrative information regarding the third-party and the QSA (P2PE)

using Section 1.1 as a reference.

o Provide information requested in Sections 1.2 and 1.3 regarding the date and

timeframe of the assessment, as well as the version of the P2PE Standard utilized.

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


o Provide information requested in Section 2.4 regarding the P2PE decryption

environment(s).

o Provide all information requested in Section 3.5 regarding key management.

o Provide the information requested in Table 1.1 and 1.2 in Domain 1 regarding the

POI devices used. Exclude information regarding payment applications as they

are not relevant to third-party P2PE services applicable to this attestation.

o Provide all information requested in Table 1.3 and 1.4 in Domain 1 regarding SCDs

used to generate, load, or encrypt cryptographic keys. Examples include HSMs,

key injection/loading devices (KLDs) and other devices that generate or load keys.

o Provide all information requested in Table 5.1 and 5.2 in Domain 5 regarding

HSM’s used in the decryption environment.

o Provide all information requested in Table 5.3 in Domain 5 regarding Host Systems

used in the decryption environment (HW/Hybrid ONLY).

o Provide all information requested in Table 6.1 and 6.2 (Domain 6), as well as

Tables 6A.1 (Domain 6, Annex A) and 6B.1 (Domain 6, Annex B) regarding

cryptographic key types and their associated hardware devices.

List each high-level P2PE requirement assessed and indicate whether the requirement

was assessed in full (i.e., inclusive of all its sub-requirements), partially, or deemed not

applicable. Provide a justification for all applicable requirements only tested partially or

deemed not applicable. “Not Applicable” in this context infers the requirement may apply

but was deemed not applicable via the assessment process and the review of relevant

information. For example, applicable in this context would not refer to Domain 2

requirements that govern POI-resident payment applications. An example of requirements

later deemed not applicable via the course of the assessment would be a KIF facility that

doesn’t utilize DUKPT keys.

Include an explicit confirmation attesting to the fact the third-party entity’s prior P2PE

assessment includes all services, processes, and systems appropriate to the services the

third party offers to P2PE solution providers. At any time during the one-year period of the

statement’s validity, if any services, processes, or systems were changed or added, the

third-party must document any additions or changes and provide that documentation to

applicable current and potential P2PE solution providers.

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

wishing to use the First Data TransArmor VeriFone Edition Solution to be able to easily demonstrate to

their acquirer or payment brands how the solution addresses various PCI DSS controls.

In addition to this formal guidance from the Council, Coalfire has also utilized the following to formulate

our guidance on PCI DSS reduction of applicable controls for P2PE solutions:

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

intent

Reference and review of the FAQ released by the Council

Dialogue with respected QSAs from other QSA companies in the industry

Coalfire’s experience in implementing other PCI DSS applicable control reduction programs


Clarification of Control Reduction

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

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

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

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

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

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

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

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

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

of compromise. Reducing PCI DSS control applicability for payment card data does not mean the PCI DSS

controls are not justified to protect the merchants other information assets.

Control Reduction for Merchants Each merchant’s environment is different. Differences in card data capture processes or deployment

decisions could easily impact a merchant’s ability to achieve maximum reduction of applicable controls.

Coalfire has presented the most common deployment scenario for a merchant implementing TransArmor

VeriFone Edition to reduce PCI DSS controls that are applicable.

Deployment Scenarios The TransArmor VeriFone Edition solution can be used by many different types of merchants. The

primary deployment difference will be which POI options a merchant needs.

Regardless of which POI devices are used, there are still several deployment assumptions that are

required to achieve the most PCI DSS reduction of applicable controls for retail environments identified

later in this white paper. The following assumptions are:

Transaction locations only capture payment card data within a VeriFone PTS 3.x with SRED

validated payment device.

Payment applications and registers disable or procedurally restrict card swipe or card entry

outside of the TransArmor VeriFone Edition payment device.

No decryption capabilities of card data encrypted with TransArmor VeriFone Edition are

accessible to the merchant.

The merchant does not possess or have access to decryption keys in their retail or corporate

environments.

Chargeback and other customer support and payment research processes do not include or

require access to the full primary account number. Most merchants will use First Data’s

TransArmor tokenization solution to remove card data from these processes.

Public facing web applications for e-commerce or other payment transactional systems not

using the TransArmor VeriFone Edition solution must be addressed with your QSA to determine

PCI DSS requirements.


PCI DSS Control Reduction Summary The following summary chart provides a view of the impact to PCI DSS control requirements for a

merchant’s retail environment assuming TAVE has been properly implemented. Merchant environments

can differ and it is important to work with your QSA to validate appropriate PCI DSS control reduction

before making assumptions on scope reduction.

If a merchant has deployed TAVE in their environment, it is assumed that it is the only payment channel

within the merchant’s retail and corporate environments. Paper-based processes discussed within the

justifications below would be in support of the TAVE payment channel only. All recommended risk

reductions are based on the assumption that a QSA has fully validated that TAVE has been properly

implemented in the merchant’s environment.

Summary Chart of Merchant PCI DSS Control Reduction

PCI DSS

Area

Major Control

Reduction

Moderate Control

Reduction

Minor/No Control

Reduction

Requirement 1 X

Requirement 2 X

Requirement 3 X

Requirement 4 X

Requirement 5 X

Requirement 6 X

Requirement 7 X

Requirement 8 X

Requirement 9 X

Requirement 10 X

Requirement 11 X

Requirement 12 X

Legend:

Major – A significant number of controls are either no longer applicable or there is a

reduction in the number of IT assets requiring the controls

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

number of IT assets requiring the controls


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

Detailed PCI DSS Control Reduction A table in Appendix A was created as a general guideline for determining the PCI-DSS control applicability within

a merchant environment utilizing TAVE. This risk-based guidance indicates Coalfire’s recommended reduction of

applicable PCI-DSS controls for merchants that have compliantly implemented TAVE. Scroll down to Appendix A

to review the detailed PCI DSS risk guidance.

Technical Assessment

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

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

1. Verification of Point-to-Point Encryption from the point of encryption to the point of decryption and approval messages returned back to the merchant

a. Merchant transactions were simulated using known clear cardholder data b. Encrypted cardholder data was observed through the First Data Front End and STM handlers. c. Point-of-Decryption was a VeriShield Decryption Service (“VSD”) Test System hosted by First Data. d. Return messages were validated to contain no cardholder data.

2. Review of the integration of VTP for: a. Use of robust key management including remote key management via VKM b. Key-length and Cryptographic Standards

3. PCI DSS reduction of applicable controls based on the encryption used at the POI


Figure 1: Network Diagram

The diagram below illustrates the network layout used to validate TransArmor VeriFone Edition.


Figure 2: Dataflow Diagram

The diagram below illustrates the dataflow reviewed to validate TransArmor VeriFone Edition.

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

Step (2): POS Register routes transaction to a Store Controller or Electronic Funds Transfer (EFT) Switch or

combination of the two.

• The TransArmor Security Packet Field (SP <>) gets appended to the Auth Message Spec in Step 2.

• This is a dynamic field; the Encrypted Track/PAN must be extracted from the Auth request and inserted

into the SP <>.

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

Step (3): (Store Controller to Front End) EFT switch routes Auth request to a First Data (FD) Front End Authorization

Platform (FEP).

• If SP<> is present, Front End will route the SP <> to the STM Handler for processing.

• Card data (Track 1, Track 2, or PAN for manually keyed transactions) or Token

• Card data is encrypted with VeriFone format preserving proprietary algorithm; Token is in the clear


Step (4): (Front End to STM Handler) Private card data contained in the encrypted data block is sent to the STM

Handler to be decrypted and tokenized.

• Front End extracts MID/TID from the Auth Message spec and builds SP message for the STM Handler.

• Only the SP<> field is routed to the STM Handler.

• The STM Handler interrogates the “Encryption Type” in the SP<> to determine if it is RSA Encrypted

transaction or a VSP encrypted transaction.

• If RSA Encrypted – follow [Existing Process] and go to step (6) in diagram.

• If VSP, go to Step 5A below.


• Card data 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: Discover Manual Input vs. Encrypted PAN

Discover PAN - Approved

Original PAN 6011000990099818, exp 0416

Encrypted PAN 60046011001583599818

Table 3: VISA Get PAN vs. Encrypted PAN

VISA PAN - Approved

Original PAN 4012000033330026

Token 8875380764780026

Table 4: Discover Track 2 vs. Encrypted Track Data

Discover Test Card – Declined

Original Track Data 6221261111117766=160410123456789

Track Encryption 6221262156567766=600490936515360

Table 5: Visa Track 1 vs. Encrypted Track Data

Visa Test Card – Approved

Original Track Data B4012001386750026^^14121007644204482293072114216

Track Encryption B4012005401770026^^58121008651442176555181090362

These results demonstrate the encryption that is performed by the TransArmor VeriFone Edition VeriShield Crypto

Library (VCL) and all output is encrypted before transmission and before getting to First Data. The encrypted PANs pass

the Luhn (mod 10) test. Note that the Token does not pass the Luhn test.

Forensic and Wide Area Network (WAN) traffic Analysis

The technical assessment included a forensic examination of the logs and the traffic captures. The process included the

following:

1. Test transactions were performed, watching the traffic with iptrace;

2. Logs were collected from the transactions ; and

3. Traffic captures were examined in Wireshark for unencrypted PAN or track data; and

4. Log files were searched for unencrypted PAN or track data.

For the traffic captures, there was no PAN or track data found coming out from the simulated POS and into the First

Data environment. Once decrypted, no PAN or track data was observed to ever be returned to the merchant/POS. Only

tokens, approval codes and other non-sensitive data are returned to the merchant/POS. The logs were reviewed and no

evidence of track or PAN data was observed.


Key Loading and Distribution With derived key only one key is loaded into the device; the MDK (Master Derivation Key). Once loaded the MDK is used

to generate the DDK (Device Derivation Key) within the device. Once the DDKs are created, the MDK is securely deleted.

First Data uses the following to load the MDK into the VeriFone devices:

1. Master Key Component Cards

The HSM utility is used to create the files which are used to burn the Master Component cards for a specific

Key Encryption Key (KEK). The KEK is entered into the HSM utility and it creates the files that are used to

burn the Master Component Cards.

The Master Component Card swipes at the device cause VCL to fetch the wrapped MDK from the

vcl_settings file and to unwrap it with the KEK that is derived from the data on the Master Component cards.

Once the MDK has been successfully injected into the device, VCL uses it and other info to generate 90

DDKs. Then the MDK is deleted. VCL points to the 0th DDK.

Updating Keys

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

1. VCL Direct Interface This is the primary method First Data supports. A merchant can integrate directly to VCL to do the Advance DDK command. A merchant Point of Sale (POS) system will enable this feature so that the key can be advanced by direct interface from the POS. Once the advance DDK command is received, VCL will advance the DDK index to the next available DDK. The ‘old’ DDK is deleted. VCL will create a command response which, when received by VSD, causes VSD to increment the DDK index portion of the derivation data for the virtual device that represents that physical device in the VSD database. No key data is exchanged. If no virtual device exists yet, one is created.


Figure 3: Advance DDK - Key Management using VCL Direct Interface

2. Command Cards Also supported is the use of Command Cards. VMB is used to generate a file that is used to burn a merchant specific Advance DDK command card. When the Advance DDK command card is swiped at a device, VCL will advance the DDK index to the next available DDK. The ‘old’ DDK is deleted. VCL creates a command response which, when received by VSD, causes VSD to increment the DDK index portion of the derivation data for the virtual device that represents that physical device in the VSD database. No key data is exchanged. There is no key data on the Advance DDK command card. If no virtual device exists yet, one is created.


Figure 4: Advance DDK - Key Management using Command Card


Key Management via Command Cards, and VCL Direct Interface

VeriShield Remote Key (VRK) requires either TCP/IP connectivity or a mechanism to push a file to the PIN pad device. There are five different types of integration methods/commands: 1. RegiStart: This enables encryption and all transactions are then encrypted based on the current DDK.

2. Stop Command Card: Used to turn encryption off.

3. RegiStart SRED: This is identical as the regular RegiStart, except that once this is run, encryption cannot be turned off. The Stop command card was tested after use of this card and it failed.

4. Advance DDK: This is used to move from one DDK to the next. This is the one item that can be done via a command card or via VRK in production, although most service providers do not use the command card option.

5. Update Settings: This is used to update a configuration parameter in VCL or to update a BIN exclusion file. There are also master key components:

Master Key Component: Two components are used, replicating the two components that a KIF receives. These two

values are XORed and used to inject the MDK from the vcl_settings file. 90 DDKs are generated at this point and the

MDK is then deleted.

VCL Direct Interface and Key Management

A merchant POS vendor will work with the merchant to build the interface to VCL for the RegiStart command. After

the integration is complete, the RegiStart command can be triggered at the POS and VCL will set the encryption state

to ON. VCL creates a command response containing derivation data and the encryption on state which, when received

by VSD, causes VSD to apply the derivation data and encryption state to the virtual device that represents that physical

device in the VSD database. No key data is exchanged. There is no key data in the RegiStart command. If no virtual

device exists yet, one is created. This command card will fail at the device if the device is in SRED mode and the

command response will contain the failure info.

A merchant POS vendor will work with the merchant to build the interface to VCL for the RegiStart SRED

command. When the RegiStart SRED command is triggered at the POS, VCL will set the encryption state to ON and

SRED mode to enabled. VCL creates a command response containing derivation data, the encryption on state, and

SRED on state which, when received by VSD, causes VSD to apply the derivation data, encryption stat, and SRED on

mode to the virtual device that represents that physical device in the VSD database. No key data is exchanged. There

is no key data in the RegiStart SRED command. If no virtual device exists yet, one is created.

A merchant POS vendor will work with the merchant to build the interface to VCL for the Stop command. When the

Stop command is triggered at the POS, VCL will set the encryption state to OFF. VCL creates a command response

containing the encryption off state which, when received by VSD, causes VSD to apply the encryption state to the

virtual device that represents that physical device in the VSD database. No key data is exchanged. There is no key

data in the Stop command. If no virtual device exists yet, one is created – but it will have no derivation data at all.

This command will fail at the device if the device is in SRED mode and the command response will contain the failure

info.

A merchant POS vendor will work with the merchant to build the interface to VCL for the Advance DDK

command. When the Advance DDK command is triggered at the POS, VCL will advance the DDK index to the very next


value. VCL creates a command response containing the new derivation data, when received by VSD, causes VSD to

apply the new derivation data to the virtual device that represents that physical device in the VSD database. No key

data is exchanged. There is no key data in the Advance DDK command. If no virtual device exists yet, one is created.

This command will fail at the device if the device is on the last DDK and the command response will contain the failure

info.

Command Cards and Key Management:

VMB is used to generate a file that is used to burn a merchant specific RegiStart command card. When the RegiStart

command card is swiped at a device, VCL will set the encryption state to ON. VCL creates a command response

containing derivation data and the encryption ON state which, when received by VSD, causes VSD to apply the

derivation data and encryption state to the virtual device that represents that physical device in the VSD database.

No key data is exchanged. There is no key data on the RegiStart command card. If no virtual device exists yet, one is

created. This command card will fail at the device if the device is in SRED mode and the command response will

contain the failure info.

VMB is used to generate a file that is used to burn a merchant specific RegiStart SRED command card. When the

RegiStart SRED command card is swiped at a device, VCL will set the encryption state to ON and SRED mode to

enabled. VCL creates a command response containing derivation data, the encryption ON state, and SRED ON state

which, when received by VSD, causes VSD to apply the derivation data, encryption state, and SRED ON mode to the

virtual device that represents that physical device in the VSD database. No key data is exchanged. There is no key

data on the RegiStart SRED command card. If no virtual device exists yet, one is created.

VMB is used to generate a file that is used to burn a merchant specific Stop command card. When the Stop command

card is swiped at a device, VCL will set the encryption state to OFF. VCL creates a command response containing the

encryption OFF state which, when received by VSD, causes VSD to apply the encryption state to the virtual device that

represents that physical device in the VSD database. No key data is exchanged. There is no key data on the Stop

command card. If no virtual device exists yet, one is created – but it will have no derivation data at all. This command

card will fail at the device if the device is in SRED mode and the command response will contain the failure info.

Summary

TransArmor VeriFone Edition is a robust P2PE solution that, when implemented correctly, can be used by merchants to

dramatically reduce both risk and applicability of PCI DSS controls. First Data has integrated VeriFone’s encryption

properly and their back end decryption processes reside in a facility that has a current PCI DSS Report on Compliance

(ROC) in place. Merchants can use TAVE and this document to demonstrate how the technology works and enable QSAs

or other interested parties to evaluate their proper implementation of TransArmor VeriFone Edition into their

environment.

Legal Disclaimer:


Coalfire is solely responsible for the contents of this document as of the date of publication. The contents of this document are subject to change at any time based

on revisions to the applicable regulations and standards (HIPAA, PCI-DSS et.al). Consequently, any forward-looking statements are not predictions and are subject to

change without notice. While Coalfire has endeavored to ensure that the information contained in this document has been obtained from reliable sources, there may

be regulatory, compliance, or other reasons that prevent us from doing so. Consequently, Coalfire is not responsible for any errors or omissions, or for the results

obtained from the use of this information. Coalfire reserves the right to revise any or all of this document to reflect an accurate representation of the content relative

to the current technology landscape. In order to maintain contextual accuracy of this document, all references to this document must explicitly reference the entirety

of the document inclusive of the title and publication date; Neither party will publish a press release referring to the other party or excerpting highlights from the

document without prior written approval of the other party. If you have questions with regard to any legal or compliance matters referenced herein you should

consult legal counsel, your security advisor and/or your relevant standard authority.


Appendix A: PCI DSS Control Reduction Risk Mappings

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

control applicability within a merchant environment utilizing TAVE. This risk-based guidance indicates Coalfire’s

recommended PCI-DSS reduction of applicable controls for merchants that have compliantly implemented TAVE. The

information within the table is broken into the following columns:

PCI-DSS Testing Procedures: The PCI-DSS requirement testing procedure as outlined in the PCI-DSS v3.1.

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

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

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

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

3. Properly implemented, TAVE may reduce the testing associated with this requirement; however, the control will need to be validated by the merchant’s QSA.

4. This requirement is fully applicable for the merchant’s PCI-DSS assessment.

Note: The risk rankings associated with each PCI DSS requirement relate to the TAVE payment channel only. If the

merchant maintains other payment channels and processes they will need to be evaluated separately.

Merchant Documentation: Mapped against the PCI-DSS ROC Reporting Instructions v3.1 documentation, a Merchant is

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

Control Reduction Risk value of 1 will not have any associated documentation expectations.

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

when TAVE is properly implemented.


PCI-DSS v3.1 Testing Procedure Control

Reduction

Risk Value

Merchant

Documentation

Justification

1.1 Inspect the firewall and router configuration standards and other documentation specified below and verify that standards

are complete and implemented as follows:

1.1.1.a Examine documented

procedures to verify there is a formal

process for testing and approval of all:

• Network connections, and

• Changes to firewall and router

configurations.

1 Not Applicable When implemented properly,

TAVE will remove the PCI DSS

validation requirements for the

merchant’s host network. Formal

process for network components

testing and approval

requirements would not be

applicable.

1.1.1.b For a sample of network

connections, interview responsible

personnel and examine records to verify

that network connections were approved

and tested.








applicable.

1.1.1.c Identify a sample of actual changes

made to firewall and router

configurations, compare to the change

records, and interview responsible

personnel to verify the changes were

approved and tested.








applicable.

1.1.2.a Examine diagram(s) and observe

network configurations to verify that a

current network diagram exists and that it

documents all connections to the

cardholder data environment, including

any wireless networks.

4 Network Diagram Even with the significant

reduction of applicable controls

TAVE obtains, Coalfire feels that

merchants should still diagram

the network flow of the retail

locations where TAVE will be

utilized.

1.1.2.b Interview responsible personnel to

verify that the diagram is kept current.

4 Network Diagram Even with the significant




the network flow of the retail



Reduction

Risk Value

Merchant

Documentation

Justification


utilized.

1.1.3.a Examine data flow diagram and

interview personnel to verify the diagram:

Shows all cardholder data flows across systems and networks.

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

4 Data Flow Diagram Even with the significant




the data flow of the retail


utilized.

1.1.4.a Examine the firewall configuration

standards and verify that they include

requirements for a firewall at each

Internet connection and between any

DMZ and the internal network zone.




merchant’s host network. The

firewall configuration standards

testing requirements would not

be applicable.

1.1.4.b Verify that the current network

diagram is consistent with the firewall

configuration standards.

4 Network Diagram Coalfire feels that a network

diagram is still appropriate for the

merchant environment; however,

it will not need to be compared to

network configuration standards.

1.1.4.c Observe network configurations to

verify that a firewall is in place at each

Internet connection and between any

demilitarized zone (DMZ) and the internal

network zone, per the documented

configuration standards and network

diagrams.







be applicable.

1.1.5.a Verify that firewall and router

configuration standards include a

description of groups, roles, and

responsibilities for management of

network components.





firewall and router configuration

standards testing requirements

would not be applicable.



Reduction

Risk Value

Merchant

Documentation

Justification

1.1.5.b Interview personnel responsible for

management of network components to

confirm that roles and responsibilities are

assigned as documented.




merchant’s host network.


configuration standards include a

documented list of all services, protocols

and ports, including business justification

for each—for example, hypertext transfer

protocol (HTTP) and Secure Sockets Layer

(SSL), Secure Shell (SSH), and Virtual

Private Network (VPN) protocols.








1.1.6.b Identify insecure services,

protocols, and ports allowed; and verify

that security features are documented for

each service.




merchant’s host network. There

is no cardholder data storage in a

merchant environment and as

such the insecure services,

protocols and ports review


applicable.

1.1.6.c Examine firewall and router

configurations to verify that the

documented security features are

implemented for each insecure service,

protocol, and port.







such the insecure services,

protocols and ports review


applicable.


configuration standards require review of

firewall and router rule sets at least every

six months.







be applicable.



Reduction

Risk Value

Merchant

Documentation

Justification

1.1.7.b Examine documentation relating to

rule set reviews and interview responsible

personnel to verify that the rule sets are

reviewed at least every six months.





firewall review documentation


applicable.

1.2 Examine firewall and router configurations and perform the following to verify that connections are restricted between

untrusted networks and system components in the cardholder data environment:

1.2.1.a Examine firewall and router

configuration standards to verify that they

identify inbound and outbound traffic

necessary for the cardholder data

environment.








1.2.1.b Examine firewall and router

configurations to verify that inbound and

outbound traffic is limited to that which is

necessary for the cardholder data

environment.








1.2.1.c Examine firewall and router

configurations to verify that all other

inbound and outbound traffic is specifically

denied, for example by using an explicit

“deny all” or an implicit deny after allow

statement.








1.2.2.a Examine router configuration files

to verify they are secured from

unauthorized access.










Reduction

Risk Value

Merchant

Documentation

Justification

1.2.2.b Examine router configurations to

verify they are synchronized—for example,

the running (or active) configuration

matches the start-up configuration (used

when machines are booted).into the

cardholder data environment.





router configurations testing


applicable.


configurations to verify that there are

perimeter firewalls installed between all

wireless networks and the cardholder data

environment.





firewall and router configurations


be applicable.

1.2.3.b Verify that the firewalls deny or, if

traffic is necessary for business purposes,

permit only authorized traffic between the

wireless environment and the cardholder

data environment.





will be no cardholder data

storage on the Merchant’s

network.

1.3 Examine firewall and router configurations—including but not limited to the choke router at the Internet, the DMZ router

and firewall, the DMZ cardholder segment, the perimeter router, and the internal cardholder network segment—and

perform the following to determine that there is no direct access between the Internet and system components in the

internal cardholder network segment:

1.3.1 Examine firewall and router

configurations to verify that a DMZ is

implemented to limit inbound traffic to

only system components that provide

authorized publicly accessible services,

protocols, and ports.







such the DMZ network layer



configurations to verify that inbound

Internet traffic is limited to IP addresses

within the DMZ.









Reduction

Risk Value

Merchant

Documentation

Justification




configurations to verify direct connections

inbound or outbound are not allowed for

traffic between the Internet and the








be applicable.


configurations to verify that anti-spoofing

measures are implemented, for example

internal addresses cannot pass from the

Internet into the DMZ.







be applicable.


configurations to verify that outbound

traffic from the cardholder data

environment to the Internet is explicitly

authorized.







be applicable.


configurations to verify that the firewall

performs stateful inspection (dynamic

packet filtering). (Only established

connections should be allowed in, and only

if they are associated with a previously

established session.)

2 Network Diagram

Network Configuration

Standards

When implemented properly,




However, Coalfire still

recommends against direct

unrestricted inbound Internet

access to the POIs.


configurations to verify that system

components that store cardholder data are

on an internal network zone, segregated

from the DMZ and other untrusted

networks.









Reduction

Risk Value

Merchant

Documentation

Justification




configurations to verify that methods are

in place to prevent the disclosure of

private IP addresses and routing

information from internal networks to the

Internet.





1.3.8.b Interview personnel and examine

documentation to verify that any

disclosure of private IP addresses and

routing information to external entities is

authorized.





1.4 Install personal firewall software on any mobile and/or employee-owned devices that connect to the Internet when

outside the network (for example, laptops used by employees), and which are also used to access the network. Firewall

configurations include:

Specific configuration settings are defined for personal firewall software.

Personal firewall software is actively running.

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

1.4.a Examine policies and

configuration standards to verify:

• Personal firewall software is

required for all mobile and/or

employee-owned devices that

connect to the Internet (for

example, laptops used by

employees) when outside the

network, and which are also used

to access the network.

• Specific configuration settings are

defined for personal firewall

software.


configured to actively run.

Personal firewall software is

configured to not be alterable by




merchant’s host network. With

no access to cardholder data,

mobile and/or employee owned

computers personal firewall

software requirement will be not

applicable.



Reduction

Risk Value

Merchant

Documentation

Justification

users of mobile and/or employee-

owned devices.

1.4.b Inspect a sample of mobile and/or

employee-owned devices to verify that:


installed and configured per the

organization’s specific

configuration settings.


actively running.

• Personal firewall software is not

alterable by users of mobile

and/or employee- owned

devices.




merchant’s host network. With


mobile and/or employee owned

computers personal firewall

software requirement will be not

applicable.

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

affected parties.

1.5 Examine documentation and interview

personnel to verify that security policies

and operational procedures for managing

firewalls are:

Documented,

In use, and

Known to all affected parties.

3 Network Diagram

Network Configuration

Standards

Data Flow Diagram

Even with the significant



merchants should still maintain

the data flow, network flow

diagrams of the retail locations

where TAVE will be utilized.

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

on the network.

2.1.a Choose a sample of system

components, and attempt to log on (with

system administrator help) to the devices

and applications using default vendor-

supplied accounts and passwords, to

verify that ALL default passwords

(including those on operating systems,

software that provides security services,

application and system accounts, POS



validation requirements for all

system components located on

the merchant’s host network

(outside of the POI devices).



Reduction

Risk Value

Merchant

Documentation

Justification

terminals, and Simple Network

Management Protocol (SNMP) community

strings) have been changed. (Use vendor

manuals and sources on the Internet to

find vendor-supplied

accounts/passwords.)

2.1.b For the sample of system

components, verify that all unnecessary

default accounts (including accounts used

by operating systems, security software,

applications, systems, POS terminals,

SNMP, etc.) are removed or disabled.







2.1.c Interview personnel and examine

supporting documentation to verify that:

All vendor defaults (including default

passwords on operating systems,

software providing security services,

application and system accounts, POS

terminals, Simple Network

Management Protocol (SNMP)

community strings, etc.) are changed

before a system is installed on the

network.

Unnecessary default accounts

(including accounts used by operating

systems, security software,

applications, systems, POS terminals,

SNMP, etc.) are removed or disabled

before a system is installed on the

network.







2.1.1 For wireless environments connected to the cardholder data environment or transmitting cardholder data, change ALL

wireless vendor defaults at installation, including but not limited to default wireless encryption keys, passwords, and SNMP

community strings.



Reduction

Risk Value

Merchant

Documentation

Justification

2.1.1.a Interview responsible personnel

and examine supporting documentation to

verify that:

Encryption keys were changed from

default at installation





Wireless device components

would transmit cardholder data in

encrypted format with merchant

having no knowledge of

decryption keys.

2.1.1.b Interview personnel and examine

policies and procedures to verify:

Default SNMP community strings are

required to be changed upon

installation.

Default passwords/phrases on access

points are required to be changed

upon installation.









decryption keys.

2.1.1.c Examine vendor documentation

and login to wireless devices, with system

administrator help, to verify:









decryption keys.

2.1.1.d Examine vendor documentation

and observe wireless configuration

settings to verify firmware on wireless

devices is updated to support strong

encryption for:

Authentication over wireless networks

Transmission over wireless networks




merchant’s host network. Vendor

documentation specific to

wireless configuration settings


2.1.1.e Examine vendor documentation

and observe wireless configuration

settings to verify other security-related

wireless vendor defaults were changed, if

applicable.




merchant’s host network. Vendor

documentation specific to



Reduction

Risk Value

Merchant

Documentation

Justification

wireless configuration settings


2.2 Develop configuration standards for all system components. Assure that these standards address all known security

vulnerabilities and are consistent with industry-accepted system hardening standards.

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

Center for Internet Security (CIS)

International Organization for Standardization (ISO)

SysAdmin Audit Network Security (SANS) Institute

National Institute of Standards Technology (NIST)

2.2.a Examine the organization’s system

configuration standards for all types of

system components and verify the system

configuration standards are consistent

with industry- accepted hardening

standards.






(outside of the POI devices). PCI

requirements testing the

configuration standards for

various system components


2.2.b Examine policies and interview

personnel to verify that system

configuration standards are updated as

new vulnerability issues are identified, as

defined in Requirement 6.1.











2.2.c Examine policies and interview

personnel to verify that system

configuration standards are applied when

new systems are configured and verified

as being in place before a system is

installed on the network.











Reduction

Risk Value

Merchant

Documentation

Justification



2.2.d Verify that system configuration

standards include the following

procedures for all types of system

components:

Changing of all vendor- supplied

defaults and elimination of

unnecessary default accounts

Implementing only one primary

function per server to prevent

functions that require different

security levels from co-existing on

the same server

Enabling only necessary services,

protocols, daemons, etc., as

required for the function of the

system

Implementing additional security

features for any required services,

protocols or daemons that are

considered to be insecure

Configuring system security

parameters to prevent misuse

Removing all unnecessary

functionality, such as scripts, drivers,

features, subsystems, file systems,

and unnecessary web servers











2.2.1.a Select a sample of system

components and inspect the system

configurations to verify that only one

primary function is implemented per

server.









Reduction

Risk Value

Merchant

Documentation

Justification

2.2.1.b If virtualization technologies are

used, inspect the system configurations to

verify that only one primary function is

implemented per virtual system

component or device






(outside of the POI devices). With


there will be no applicable

requirements for virtualization

technologies.


components and inspect enabled system

services, daemons, and protocols to verify

that only necessary services or protocols

are enabled.







2.2.2.b Identify any enabled insecure

services, daemons, or protocols and

interview personnel to verify they are

justified per documented configuration

standards.







2.2.3 Inspect configuration settings to

verify that security features are

documented and implemented for all

insecure services, daemons, or protocols.







2.2.4.a Interview system administrators

and/or security managers to verify that

they have knowledge of common security

parameter settings for system

components.









Reduction

Risk Value

Merchant

Documentation

Justification

2.2.4.b Examine the system configuration

standards to verify that common security

parameter settings are included.











2.2.4.c Select a sample of system

components and inspect the common

security parameters to verify that they are

set appropriately and in accordance with

the configuration standards.












components and inspect the

configurations to verify that all

unnecessary functionality (for example,

scripts, drivers, features, subsystems, file

systems, etc.) is removed.







2.2.5.b. Examine the documentation and

security parameters to verify enabled

functions are documented and support

secure configuration.













Reduction

Risk Value

Merchant

Documentation

Justification

2.2.5.c. Examine the documentation and

security parameters to verify that only

documented functionality is present on

the sampled system components.











2.3 Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS

for web-based management and other non-console administrative access.

2.3.a Observe an administrator log on to

each system and examine system

configurations to verify that a strong

encryption method is invoked before the

administrator’s password is requested.







2.3.b Review services and parameter files

on systems to determine that Telnet and

other insecure remote-login commands

are not available for non-console access







2.3.c Observe an administrator log on to

each system to verify that administrator

access to any web-based management

interfaces is encrypted with strong

cryptography.







2.3.d Examine vendor documentation and

interview personnel to verify that strong

cryptography for the technology in use is

implemented according to industry best

practices and/or vendor

recommendations.









Reduction

Risk Value

Merchant

Documentation

Justification

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

2.4.a Examine system inventory to verify

that a list of hardware and software

components is maintained and includes a

description of function/use for each.

4 POI Device Inventory Maintaining POI device inventory

will still apply to the merchant

environment.

2.4.b Interview personnel to verify the

documented inventory is kept current.

4 POI Device Inventory Maintaining POI device inventory

will still apply to the merchant

environment.

2.5 Ensure that security policies and operational procedures for managing vendor defaults and other security parameters

are documented, in use, and known to all affected parties.



and operational procedures for managing

vendor defaults and other security

parameters are:

Documented,

In use, and





merchant’s host network. PCI





2.6 Shared hosting providers must protect each entity’s hosted environment and cardholder data. These providers must

meet specific requirements as detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers.

2.6 Perform testing procedures A.1.1

through A.1.4 detailed in Appendix A:

Additional PCI DSS Requirements for

Shared Hosting Providers for PCI DSS

assessments of shared hosting providers,

to verify that shared hosting providers

protect their entities’ (merchants and

service providers) hosted environment

and data.

1 Not Applicable Not Applicable for merchants.

3.1 Keep cardholder data storage to a minimum by implementing data-retention and disposal policies, procedures and

processes that include at least the following for all CHD storage:

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

requirements.

Processes for secure deletion of data when no longer needed.

Specific retention requirements for cardholder data.



Reduction

Risk Value

Merchant

Documentation

Justification

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

3.1.a Examine the data- retention and

disposal policies, procedures and

processes to verify they include at least

the following:

Legal, regulatory, and business

requirements for data retention,

including

Specific requirements for retention of

cardholder data (for example,

cardholder data needs to be held for X

period for Y business reasons).

Secure deletion of cardholder data

when no longer needed for legal,

regulatory, or business reasons

Coverage for all storage of cardholder

data

A quarterly process for identifying and

securely deleting stored cardholder

data that exceeds defined retention

requirements.

3 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.b Interview personnel to verify that:

All locations of stored cardholder data

are included in the data-retention and

disposal processes.

Either a quarterly automatic or manual

process is in place to identify and

securely delete stored cardholder data.

The quarterly automatic or manual

process is performed for all locations of

cardholder data.



applicable)








3.1.c For a sample of system components

that store cardholder data:

Examine files and system records to

verify that the data stored does not

exceed the requirements defined in

the data-retention policy.



applicable)








Reduction

Risk Value

Merchant

Documentation

Justification

Observe the deletion mechanism to

verify data is deleted securely.



3.2 Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is

received, render all data unrecoverable upon completion of the authorization process.

3.2.a For issuers and/or companies that

support issuing services and store

sensitive authentication data, review

policies and interview personnel to verify

there is a documented business

justification for the storage of sensitive

authentication data.

1 Not Applicable Not applicable for merchants.

3.2.b For issuers and/or companies that

support issuing services and store

sensitive authentication data, examine

data stores and system configurations to

verify that the sensitive authentication

data is secured.

1 Not Applicable Not applicable for merchants.

3.2.c For all other entities, if sensitive

authentication data is received, review

policies and procedures, and examine

system configurations to verify the data is

not retained after authorization.

1 Not Applicable Sensitive authentication data will

not be stored within or outside of

hardware POI devices.

3.2.d For all other entities, if sensitive

authentication data is received, review

procedures and examine the processes for

securely deleting the data to verify that

the data is unrecoverable.




3.2.1 Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data

contained on a chip, or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data.



Reduction

Risk Value

Merchant

Documentation

Justification

3.2.1 For a sample of system components,

examine data sources, including but not

limited to the following, and verify that

the full contents of any track from the

magnetic stripe on the back of card or

equivalent data on a chip are not stored

after authorization:

Incoming transaction data

All logs (for example, transaction,

history, debugging, error)

History files

Trace files

Several database schemas

Database contents






limited to the following, and verify that

the three-digit or four- digit card

verification code or value printed on the

front of the card or the signature panel

(CVV2, CVC2, CID, CAV2 data) is not stored

after authorization:




History files

Trace files


Database contents



applicable)



its payment channel that includes

card validation codes then this


documents. Otherwise, this

requirement can be considered

not applicable.

Sensitive authentication data will





Reduction

Risk Value

Merchant

Documentation

Justification



limited to the following and verify that

PINs and encrypted PIN blocks are not

stored after authorization:




History files

Trace files


Database contents




3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that

only personnel with a legitimate business need can see the full PAN.

3.3.a Examine written policies and

procedures for masking the display of

PANs to verify:

A list of roles that need access to

displays of full PAN is documented,

together with a legitimate business

need for each role to have such access.

PAN must be masked when displayed

such that only personnel with a

legitimate business need can see the

full PAN.

All other roles not specifically

authorized to see the full PAN must

only see masked PANs.



applicable)








3.3.b Examine system configurations to

verify that full PAN is only displayed for

users/roles with a documented business

need, and that PAN is masked for all other

requests.



applicable)










Reduction

Risk Value

Merchant

Documentation

Justification

3.3.c Examine displays of PAN (for

example, on screen, on paper receipts) to

verify that PANs are masked when

displaying cardholder data, and that only

those with a legitimate business need are

able to see full PAN.



applicable)








3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using

any of the following approaches:

One-way hashes based on strong cryptography, (hash must be of the entire PAN).

Truncation (hashing cannot be used to replace the truncated segment of PAN).

Index tokens and pads (pads must be securely stored).

Strong cryptography with associated key-management processes and procedures.

3.4.a Examine documentation about the

system used to protect the PAN, including

the vendor, type of system/process, and

the encryption algorithms (if applicable) to

verify that the PAN is rendered unreadable

using any of the following methods:

One-way hashes based on strong

cryptography,

Truncation

Index tokens and pads, with the pads

being securely stored

Strong cryptography, with associated

key- management processes and

procedures

1 Not Applicable PAN will be rendered unreadable

at swipe on POI devices.

Merchants will have no

responsibility for secure storage

of cardholder data within their

environments.

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






environments.

3.4.c Examine a sample of removable

media (for example, back-up tapes) to

confirm that the PAN is rendered

unreadable.







Reduction

Risk Value

Merchant

Documentation

Justification


environments.

3.4.d Examine a sample of audit logs to

confirm that the PAN is rendered

unreadable or removed from the logs.






environments.

3.4.1.a If disk encryption is used, inspect

the configuration and observe the

authentication process to verify that

logical access to encrypted file systems is

implemented via a mechanism that is

separate from the native operating

system’s authentication mechanism (for

example, not using local user account

databases or general network login

credentials).






environments.

3.4.1.b Observe processes and interview

personnel to verify that cryptographic

keys are stored securely (for example,

stored on removable media that is

adequately protected with strong access

controls).






environments.

3.4.1.c Examine the configurations and

observe the processes to verify that

cardholder data on removable media is

encrypted wherever stored.

Note: If disk encryption is not used to

encrypt removable media, the data stored

on this media will need to be rendered

unreadable through some other method.






environments.

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

misuse:



Reduction

Risk Value

Merchant

Documentation

Justification

3.5 Examine key-management policies and

procedures to verify processes are

specified to protect keys used for

encryption of cardholder data against

disclosure and misuse and include at least

the following:

Access to keys is restricted to the

fewest number of custodians

necessary.

Key-encrypting keys are at least as

strong as the data- encrypting keys

they protect.

Key-encrypting keys are stored

separately from data- encrypting keys.

Keys are stored securely in the fewest

possible locations and forms.

1 Not Applicable. If TAVE has been implemented

correctly, Merchants will have no

key management responsibilities

within their environment.

3.5.1 Examine user access lists to verify

that access to keys is restricted to the

fewest number of custodians necessary.





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

times:

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

from the data-encrypting key.

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

• As at least two full-length key components or key shares, in accordance with an industry-accepted method

3.5.2.a Examine documented procedures

to verify that cryptographic keys used to

encrypt/decrypt cardholder data must

only exist in one (or more) of the following

forms at all times.

Encrypted with a key- encrypting key

that is at least as strong as the data-

encrypting key, and that is stored

separately from the data-encrypting

key.

Within a secure cryptographic device

(such as a host security module (HSM)




within their environment. As

such, the key-management

procedures documentation is not

applicable.



Reduction

Risk Value

Merchant

Documentation

Justification

or PTS-approved point-of-interaction

device).

As key components or key shares, in

accordance with an industry-accepted

method.

3.5.2.b Examine system configurations

and key storage locations to verify that

cryptographic keys used to

encrypt/decrypt cardholder data exist in

one, (or more), of the following form at all

times.

Encrypted with a key- encrypting key.

Within a secure cryptographic device

(such as a host security module (HSM)

or PTS-approved point-of-interaction

device).

As key components or key shares, in

accordance with an industry-accepted

method.





3.5.2.c Wherever key- encrypting keys are

used, examine system configurations and

key storage locations to verify:

Key-encrypting keys are at least as

strong as the data- encrypting keys

they protect.

Key-encrypting keys are stored

separately from data- encrypting keys.





3.5.3 Examine key storage locations and

observe processes to verify that keys are

stored in the fewest possible locations.





3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption

of cardholder data, including the following:

3.6.a Additional Procedure for service

providers: If the service provider shares

keys with their customers for transmission

or storage of cardholder data, examine

the documentation that the service







Reduction

Risk Value

Merchant

Documentation

Justification

provider provides to their customers to

verify that it includes guidance on how to

securely transmit, store, and update

customers’ keys, in accordance with

Requirements 3.6.1 through 3.6.8 below.

3.6.1.a Verify that key- management

procedures specify how to generate strong

keys.







applicable.

3.6.1.b Observe the method for

generating keys to verify that strong keys

are generated.






procedures specify how to securely

distribute keys.







applicable.

3.6.2.b Observe the method for

distributing keys to verify that keys are

distributed securely.





3.6.3.a Verify that key-management

procedures specify how to securely store

keys.







applicable.

3.6.3.b Observe the method for storing

keys to verify that keys are stored

securely.





Reduction

Risk Value

Merchant

Documentation

Justification




procedures include a defined cryptoperiod

for each key type in use and define a

process for key changes at the end of the

defined cryptoperiod(s).







applicable.

3.6.4.b Interview personnel to verify that

keys are changed at the end of the defined

cryptoperiod(s).






procedures specify processes for the

following:

The retirement or replacement of keys

when the integrity of the key has been

weakened.

The replacement of known or

suspected compromised keys.

Any keys retained after retiring or

replacing are not used for encryption

operations.







applicable.

3.6.5.b Interview personnel to verify the

following processes are implemented:

Keys are retired or replaced as

necessary when the integrity of the key

has been weakened, including when

someone with knowledge of the key

leaves the company.

Keys are replaced if known or

suspected to be compromised.

Any keys retained after retiring or

replacing are not used for encryption

operations.







Reduction

Risk Value

Merchant

Documentation

Justification

3.6.6.a Verify that manual clear- text key-

management procedures specify

processes for the use of the following:

Split knowledge of keys, such that key

components are under the control of at

least two people who only have

knowledge of their own key

components; AND

Dual control of keys, such that at least

two people are required to perform

any key- management operations and

no one person has access to the

authentication materials (for example,

passwords or keys) of another.







applicable.

3.6.6 b Interview personnel and/or

observe processes to verify that manual

clear-text keys are managed with:

Split knowledge, AND

Dual control





3.6.7.a Verify that key-management

procedures specify processes to prevent

unauthorized substitution of keys.







applicable.

3.6.7.b Interview personnel and/or

observe process to verify that

unauthorized substitution of keys is

prevented.






procedures specify processes for key

custodians to acknowledge (in writing or

electronically) that they understand and

accept their key-custodian responsibilities.





such, key-management


applicable.



Reduction

Risk Value

Merchant

Documentation

Justification

3.6.8.b Observe documentation or other

evidence showing that key custodians

have acknowledged (in writing or

electronically) that they understand and

accept their key-custodian responsibilities.





such, key-management


applicable.

3.7 Ensure that security policies and operational procedures for protecting stored cardholder data are documented, in use,

and known to all affected parties.



and operational procedures for protecting

stored cardholder data are:

Documented,

In use, and

Known to all affected parties



applicable)








4.1 Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder

data during transmission over open, public networks, including the following:

Only trusted keys and certificates are accepted.

The protocol in use only supports secure versions or configurations.

The encryption strength is appropriate for the encryption methodology in use.

4.1.a Identify all locations where

cardholder data is transmitted or received

over open, public networks.





Cardholder data is encrypted at

POI device with no key

responsibilities with merchant.

Cardholder data transmission

requirements will not be

applicable for this environment.

4.1.b Review documented policies and

procedures to verify processes are

specified for the following:

For acceptance of only trusted keys

and/or certificates.

For the protocol in use to only support

secure versions and configurations











Reduction

Risk Value

Merchant

Documentation

Justification

(that insecure versions or

configurations are not supported).

For implementation of proper

encryption strength per the encryption

methodology in use.



Transmission requirements will

not be applicable.

4.1.c Select and observe a sample of

inbound and outbound transmissions as

they occur to verify that all cardholder

data is encrypted with strong

cryptography during transit.











4.1.d Examine keys and certificates to

verify that only trusted keys and/or

certificates are accepted.











4.1.e Examine system configurations to

verify that the protocol is implemented to

use only secure configurations and does

not support insecure versions or

configurations.











4.1.f Examine system configurations to

verify that the proper encryption strength

is implemented for the encryption

methodology in use. (Check vendor

recommendations/best practices.)









Reduction

Risk Value

Merchant

Documentation

Justification





4.1.g For SSL/TLS implementations,

examine system configurations to verify

that SSL/TLS is enabled whenever

cardholder data is transmitted or received.











4.1.1 Identify all wireless networks

transmitting cardholder data or connected

to the cardholder data environment.

Examine documented standards and

compare to system configuration settings

to verify the following for all wireless

networks identified:

Industry best practices (for example,

IEEE 802.11i) are used to implement

strong encryption for authentication

and transmission.

Weak encryption (for example, WEP,

SSL version

2.0 or older) is not used as a security

control for authentication or

transmission.











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

4.2.a If end-user messaging technologies

are used to send cardholder data, observe

processes for sending PAN and examine a

sample of outbound transmissions as they

occur to verify that PAN is rendered

unreadable or secured with strong

cryptography whenever it is sent via end-

user messaging technologies.







Reduction

Risk Value

Merchant

Documentation

Justification

4.2.b Review written policies to verify the

existence of a policy stating that

unprotected PANs are not to be sent via

end-user messaging technologies.

2 Acceptable Usage Policies Merchants will not have any

access to cardholder data within

their environment; however,

employees will still have access to

the physical credit card in retail

environments. As such, a policy

prohibiting the emailing of

unprotected PAN is still

appropriate for most retail

environments.

4.3 Ensure that security policies and operational procedures for encrypting transmissions of cardholder data are

documented, in use, and known to all affected parties.



and operational procedures for encrypting

transmissions of cardholder data are:

Documented,

In use, and


2 Acceptable Usage Policies Merchants will not have any

access to cardholder data within

their environment; however,

employees will still have access to

the physical credit card in retail

environments. As such, a policy

prohibiting the emailing of

unprotected PAN is still

appropriate for most retail

environments.

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

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.




server components located on

the merchant’s host network.

Anti-virus and anti-malware


applicable.

i. Review vendor documentation

and examine anti- virus configurations to

verify that anti-virus programs;

Detect all known types of malicious

software,

Remove all known types of malicious

software, and








applicable.



Reduction

Risk Value

Merchant

Documentation

Justification

Protect against all known types of

malicious software.

5.1.2 Interview personnel to verify that

evolving malware threats are monitored

and evaluated for systems not currently

considered to be commonly affected by

malicious software, in order to confirm

whether such systems continue to not

require anti-virus software.








applicable.

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

Are kept current.

Perform periodic scans.

Generate audit logs which are retained per PCI DSS Requirement 10.7.

5.2.a Examine policies and procedures to

verify that anti- virus software and

definitions are required to be kept up-to-

date.








applicable.

5.2.b Examine anti-virus configurations,

including the master installation of the

software








applicable.

5.2.c Examine a sample of system

components, including all operating

system types commonly affected by

malicious software, to verify that:








Reduction

Risk Value

Merchant

Documentation

Justification

The anti-virus software and definitions

are current.

Periodic scans are performed.



applicable.

5.2.d Examine anti-virus configurations,


software and a sample of system

components, to verify that:

Anti-virus software log generation is

enabled, and

Logs are retained in accordance with

PCI DSS Requirement 10.7.








applicable.

5.3 Ensure that anti-virus mechanisms are actively running and cannot be disabled or altered by users, unless specifically

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

5.3.a Examine anti-virus configurations,



components, to verify the anti- virus

software is actively running.








applicable.

5.3.b Examine anti-virus configurations,



components, to verify that the anti-virus

software cannot be disabled or altered by

users.








applicable.

5.3.c Interview responsible personnel and

observe processes to verify that anti-virus

software cannot be disabled or altered by

users, unless specifically authorized by

management on a case-by-case basis for a

limited time period.








applicable.



Reduction

Risk Value

Merchant

Documentation

Justification

5.4 Ensure that security policies and operational procedures for protecting systems against malware are documented, in use,




and operational procedures for protecting

systems against malware are:

Documented,

In use, and









applicable.

6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability

information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security

vulnerabilities.

6.1.a Examine policies and procedures to

verify that processes are defined for the

following:

To identify new security vulnerabilities.

To assign a risk ranking to

vulnerabilities that includes

identification of all “high risk” and

“critical” vulnerabilities.

To include using reputable outside

sources for security vulnerability

`information.

2 Vulnerability Alerting

Procedures




merchants should still document

the POI devices and payment

system’s vulnerability alerting

processes.

6.1.b Interview responsible personnel and

observe processes to verify that:

New security vulnerabilities are

identified.

A risk ranking is assigned to

vulnerabilities that includes

identification of all “high” risk and

“critical” vulnerabilities.

Processes to identify new security

vulnerabilities include using reputable

outside sources for security

vulnerability information.

2 Vulnerability Alerting

Procedures




merchants should still document

the POI devices and payment

system’s vulnerability alerting

processes.

6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable

vendor-supplied security patches. Install critical security patches within one month of release.



Reduction

Risk Value

Merchant

Documentation

Justification

6.2.a Examine policies and procedures

related to security- patch installation to

verify processes are defined for:

Installation of applicable critical

vendor-supplied security patches

within one month of release.

Installation of all applicable vendor-

supplied security patches within an

appropriate time frame (for example,

within three months).







Patch management procedures

for various system components

will not be applicable.

6.2.b For a sample of system components

and related software

Identify the sample of system

components and related software

selected for this testing

procedure.

For each item in the sample,

describe how the list of security

patches installed on each system

was compared to the most recent

vendor security-patch list to verify

that:







Patch management procedures

for various system components

will not be applicable.

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

as follows:

In accordance with PCI DSS (for example, secure authentication and logging).

Based on industry standards and/or best practices.

Incorporate information security throughout the software development life cycle.

6.3.a Examine written software-

development processes to verify that the

processes are based on industry standards

and/or best practices.

1 Not Applicable This control will be not applicable

for merchants utilizing 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.

1 Not Applicable This control should not apply for

merchants utilizing TAVE as there

will be no self-developed


CDE. As such, software

development processes



Reduction

Risk Value

Merchant

Documentation

Justification

documentation will not be

applicable.

6.3.c Examine written software

development processes to verify that

software applications are developed in

accordance with PCI DSS.








applicable.

6.3.d Interview software developers to

verify that written software development

processes are implemented.





CDE.

6.3.1 Examine written software-

development procedures and interview

responsible personnel to verify that pre-

production and/or custom application

accounts, user IDs and/or passwords are

removed before an application goes into

production or is released to customers.








applicable.

6.3.2 Review custom code prior to release to production or customers in order to identify any potential coding vulnerability

(using either manual or automated processes) to include at least the following:

• Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about

code review techniques and secure coding practices.

• Code reviews ensure code is developed according to secure coding guidelines.

• Appropriate corrections are implemented prior to release.

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

6.3.2.a Examine written software

development procedures and interview

responsible personnel to verify that all

custom application code changes must be

reviewed (using either manual or

automated processes) as follows:

Code changes are reviewed by

individuals other than the originating








applicable.



Reduction

Risk Value

Merchant

Documentation

Justification

code author, and by individuals who

are knowledgeable in code review

techniques and secure coding

practices.

Code reviews ensure code is developed

according to secure coding guidelines

(see PCI DSS Requirement 6.5).

Appropriate corrections are

implemented prior to release.

Code-review results are reviewed and

approved by management prior to

release.

6.3.2.b Select a sample of recent custom

application changes and verify that custom

application code is reviewed according to

6.3.2.a, above.





CDE.

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

following:

6.4 Examine policies and procedures to

verify the following are defined:

Development/test environments are

separate from production

environments with access control in

place to enforce separation.

A separation of duties between

personnel assigned to the

development/test environments and

those assigned to the production

environment.

Production data (live PANs) are not

used for testing or development.

Test data and accounts are removed

before a production system becomes

active.

Change control procedures related to

implementing security patches and

software modifications are

documented.







Change control processes and

procedures for various system

components will not be

applicable.



Reduction

Risk Value

Merchant

Documentation

Justification

6.4.1.a Examine network documentation

and network device configurations to

verify that the development/test

environments are separate from the

production environment(s).







6.4.1.b Examine access controls settings to

verify that access controls are in place to

enforce separation between the

development/test environments and the

production environment(s).







6.4.2 Observe processes and interview

personnel assigned to development/test

environments and personnel assigned to

production environments to verify that

separation of duties is in place between

development/test environments and the

production environment.







6.4.3.a Observe testing processes and

interview personnel to verify procedures

are in place to ensure production data

(live PANs) are not used for testing or

development.







Merchants will have no access to

cardholder data (PANs) within

their environment.

6.4.3.b Examine a sample of test data to

verify production data (live PANs) is not

used for testing or development.







6.4.4.a Observe testing processes and

interview personnel to verify test data and

accounts are removed before a production

system becomes active.







Reduction

Risk Value

Merchant

Documentation

Justification



6.4.4.b Examine a sample of data and

accounts from production systems

recently installed or updated to verify test

data and accounts are removed before the

system becomes active.







6.4.5.a Examine documented change-

control procedures related to

implementing security patches and

software modifications and verify

procedures are defined for:

Documentation of impact.

Documented change approval by

authorized parties.

Functionality testing to verify that the

change does not adversely impact the

security of the system.

Back-out procedures.

2 Change control

procedures POI devices

Change control procedures

should not apply for all of the


Coalfire recommends change

control processes be used for

tracking POI devices within the

environment. Change

management processes for other

systems would be not applicable.

6.4.5.b For a sample of system

components, interview responsible

personnel to determine recent

changes/security patches. Trace those

changes back to related change control

documentation. For each change

examined, perform the following:

For each item in the sample, identify the

sample of changes and the related change

control documentation selected for this

testing procedure (through 6.4.5.4)

2 Change control








environment. Change



6.4.5.1 Verify that documentation of

impact is included in the change control

documentation for each sampled change.

2 Change control










Reduction

Risk Value

Merchant

Documentation

Justification

environment. Change



6.4.5.2 Verify that documented approval

by authorized parties is present for each

sampled change.

2 Change control








environment. Change



6.4.5.3.a For each sampled change, verify

that functionality testing is performed to

verify that the change does not adversely

impact the security of the system.

2 Change control








environment. Change



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.





CDE.

6.4.5.4 Verify that back-out procedures are

prepared for each sampled change.

2 Change control








environment. Change



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



Reduction

Risk Value

Merchant

Documentation

Justification

Train developers in secure coding techniques, including how to avoid common coding vulnerabilities, and

understanding how sensitive data is handled in memory.

Develop applications based on secure coding guidelines.

6.5.a Examine software development

policies and procedures to verify that

training in secure coding techniques is

required for developers, based on industry

best practices and guidance.








applicable.

6.5.b Interview a sample of developers to

verify that they are knowledgeable in

secure coding techniques.





CDE.

6.5.c Examine records of training to verify

that software developers received training

on secure coding techniques, including

how to avoid common coding

vulnerabilities, and understanding how

sensitive data is handled in memory.





CDE.

6.5.d. Verify that processes are in place to

protect applications from, at a minimum,

the following vulnerabilities:





CDE.

6.5.1 Examine software- development

policies and procedures and interview

responsible personnel to verify that

injection flaws are addressed by coding

techniques that include:

Validating input to verify user data

cannot modify meaning of commands

and queries.

Utilizing parameterized queries.






development procedures and

secure coding documentation will

not be applicable.



Reduction

Risk Value

Merchant

Documentation

Justification



For the interviews at 6.5.d, summarize the

relevant interview details that confirm

processes are in place, consistent with the

software development documentation at

6.5.d, to ensure that buffer overflows are

addressed by coding techniques that

include:








not be applicable.




insecure cryptographic storage is

addressed by coding techniques that:

Prevent cryptographic flaws.

Use strong cryptographic algorithms

and keys.








not be applicable.




insecure communications are addressed

by coding techniques that properly

authenticate and encrypt all sensitive

communications.








not be applicable.

6.5.5 Examine-software development



improper error handling is addressed by

coding techniques that do not leak

information via error messages (for

example, by returning generic rather than

specific error details).








not be applicable.




coding techniques address any “high risk”

vulnerabilities that could affect the









Reduction

Risk Value

Merchant

Documentation

Justification

application, as identified in PCI DSS

Requirement 6.1.


not be applicable.



responsible personnel to verify that cross-

site scripting (XSS) is addressed by coding

techniques that include:

Validating all parameters before

inclusion.

Utilizing context-sensitive

escaping.








not be applicable.




improper access control— such as

insecure direct object references, failure

to restrict URL access, and directory

traversal—is addressed by coding

technique that include:

Proper authentication of users.

Sanitizing input.

Not exposing internal object references

to users.

User interfaces that do not permit

access to unauthorized functions.








not be applicable.

6.5.9 Examine software development


responsible personnel to verify that cross-

site request forgery (CSRF) is addressed by

coding techniques that ensure

applications do not rely on authorization

credentials and tokens automatically

submitted by browsers.








not be applicable.

6.5.10 Examine software development



broken authentication and session








Reduction

Risk Value

Merchant

Documentation

Justification

management are addressed via coding

techniques that commonly include:

Flagging session tokens (for example

cookies) as “secure.”

Not exposing session IDs in the URL.

Incorporating appropriate time-outs

and rotation of session IDs after a

successful login.



not be applicable.

6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these

applications are protected against known attacks by either of the following methods:

Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or

methods, at least annually and after any changes.

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

Installing an automated technical solution that detects and prevents web-based attacks (for example, a web- application

firewall) in front of public-facing web applications, to continually check all traffic.

6.6 For public-facing web applications,

ensure that either one of the following

methods is in place as follows:

Examine documented processes,

interview personnel, and examine

records of application security

assessments to verify that public-facing

web applications are reviewed— using

either manual or automated

vulnerability security assessment tools

or methods—as follows:

At least annually.

After any changes.

By an organization that specializes in

application security.

That, at a minimum, all

vulnerabilities in Requirement 6.5

are included in the assessment.

That all vulnerabilities are corrected.

That the application is re-evaluated

after the corrections.

Examine the system configuration

settings and interview responsible

1 Not Applicable This control will not be applicable


this solution is not a web

application requiring application

security assessments or

automated technical solution to

detect and prevent web-based

attacks. Public-facing web

applications are not in scope for

this paper.



Reduction

Risk Value

Merchant

Documentation

Justification

personnel to verify that an automated

technical solution that detects and

prevents web-based attacks (for

example, a web-application firewall) is

in place as follows:

Is situated in front of public-facing

web applications to detect and

prevent web-based attacks.

Is actively running and up-to-date as

applicable.

Is generating audit logs.

Is configured to either block web-

based attacks, or generate an alert.

6.7 Ensure that security policies and operational procedures for developing and maintaining secure systems and applications

are documented, in use, and known to all affected parties.



and operational procedures for

developing and maintaining secure

systems and applications are:

Documented,

In use, and


1 Not Applicable Security policies and operational

procedures documentation for

maintaining secure systems and

applications would not be

applicable.

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

7.1.a Examine written policy for access

control, and verify that the policy

incorporates 7.1.1 through 7.1.4 as

follows:

Defining access needs and

privilege assignments for each

role.

Restriction of access to privileged

user IDs to least privileges

necessary to perform job

responsibilities.

Assignment of access based on

individual personnel’s job

classification and function.







Access control policies will not be

applicable for the merchant

environment.



Reduction

Risk Value

Merchant

Documentation

Justification

Documented approval

(electronically or in writing) by

authorized parties for all access,

including listing of specific

privileges approved.

7.1.1 Select a sample of roles and verify

access needs for each role are defined and

include:

System components and data

resources that each role needs to

access for their job function.

Identification of privilege

necessary for each role to

perform their job function.







Access control restriction


applicable.

7.1.2.a Interview personnel responsible

for assigning access to verify that access to

privileged user IDs is:

Assigned only to roles that

specifically require such

privileged access.

Restricted to least privileges


responsibilities.









applicable.

7.1.2.b Select a sample of user IDs with

privileged access and interview

responsible management personnel to

verify that privileges assigned are:

Necessary for that individual’s job

function.

Restricted to least privileges


responsibilities.









applicable.

7.1.3 Select a sample of user IDs and

interview responsible management

personnel to verify that privileges assigned

are based on that individual’s job











Reduction

Risk Value

Merchant

Documentation

Justification


applicable.

7.1.4 Select a sample of user IDs and

compare with documented approvals to

verify that:

Documented approval exists for

the assigned privileges.

The approval was by authorized

parties.

That specified privileges match

the roles assigned to the

individual.









applicable.

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

7.2.1 Confirm that access control systems

are in place on all system components.







Access control system

implementation requirements


7.2.2 Confirm that access control systems

are configured to enforce privileges

assigned to individuals based on job











7.2.3 Confirm that the access control

systems have a default “deny-all” setting.








Reduction

Risk Value

Merchant

Documentation

Justification





7.3 Ensure that security policies and operational procedures for restricting access to cardholder data are documented, in use,




and operational procedures for restricting

access to cardholder data are:

Documented,

In use, and


1 Not Applicable Merchant will have no access to

cardholder data, security policies

and operational procedures

documentation for restricting

access to cardholder data would

not be applicable.

8.1 Define and implement policies and procedures to ensure proper user identification management for non-consumer users

and administrators on all system components as follows:

8.1.a Review procedures and confirm they

define processes for each of the items

below at 8.1.1 through 8.1.8.






(outside of the POI devices). User

identification management

procedures for merchant

environments would not be

applicable.

8.1.1 Interview administrative personnel

to confirm that all users are assigned a

unique ID for access to system

components or cardholder data.










applicable.



Reduction

Risk Value

Merchant

Documentation

Justification

8.1.2 For a sample of privileged user IDs

and general user IDs, examine associated

authorizations and observe system

settings to verify each user ID and

privileged user ID has been implemented

with only the privileges specified on the

documented approval.










applicable.

8.1.3.a Select a sample of users

terminated in the past six months, and

review current user access lists—for both

local and remote access—to verify that

their IDs have been deactivated or

removed from the access lists.










applicable.

8.1.3.b Verify all physical authentication

methods—such as, smart cards, tokens,

etc.— have been returned or deactivated.










applicable.

8.1.4 Observe user accounts to verify that

any inactive accounts over 90 days old are

either removed or disabled.










applicable.



Reduction

Risk Value

Merchant

Documentation

Justification

8.1.5.a Interview personnel and observe

processes for managing accounts used by

vendors to access, support, or maintain

system components to verify that

accounts used by vendors for remote

access are:

Disabled when not in use.

Enabled only when needed by the

vendor, and disabled when not in use.







Vendor remote access

management procedures will not

be applicable.

8.1.5.b Interview personnel and observe

processes to verify that vendor remote

access accounts are monitored while

being used.







Vendor remote access

management procedures will not

be applicable.

8.1.6.a For a sample of system

components, inspect system configuration

settings to verify that authentication

parameters are set to require that user

accounts be locked out after not more

than six invalid logon attempts.







Authentication parameter

settings for various system


applicable.

8.1.6.b Additional procedure for service

providers: Review internal processes and

customer/user documentation, and

observe implemented processes to verify

that non- consumer user accounts are

temporarily locked-out after not more

than six invalid access attempts.

1 Not Applicable Not applicable in merchant

environments.



Reduction

Risk Value

Merchant

Documentation

Justification


inspect system configuration settings to

verify that password parameters are set

to require that once a user account is

locked out, it remains locked for a

minimum of 30 minutes or until a system

administrator resets the account.







Authentication parameter

settings for various system


applicable.


inspect system configuration settings to

verify that system/session idle time out

features have been set to 15 minutes or

less.







8.2 In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and

administrators on all system components by employing at least one of the following methods to authenticate all users:

Something you know, such as a password or passphrase.

Something you have, such as a token device or smart card.

Something you are, such as a biometric.

8.2 To verify that users are authenticated

using unique ID and additional

authentication (for example, a password)

for access to the cardholder data

environment, perform the following:

Examine documentation describing the

authentication method(s) used.

1 Not Applicable Merchants will not have access to

cardholder data. As such, user

authentication management


applicable.

8.2.1.a Examine vendor documentation

and system configuration settings to verify

that passwords are protected with strong

cryptography during transmission and

storage.






(outside of the POI devices). User-

authentication password

protection requirements will not

be applicable.



Reduction

Risk Value

Merchant

Documentation

Justification

8.2.1.b For a sample of system

components, examine password files to

verify that passwords are unreadable

during storage.









be applicable.

8.2.1.c For a sample of system

components, examine data transmissions

to verify that passwords are unreadable

during transmission.









be applicable.

8.2.1.d Additional procedure for service

providers: Observe password files to verify

that customer passwords are unreadable

during storage.


environments.

8.2.1.e Additional procedure for service

providers: Observe data transmissions to

verify that customer passwords are

unreadable during transmission.


environments.

8.2.2 Examine authentication procedures

for modifying authentication credentials

and observe security personnel to verify

that, if a user requests a reset of an

authentication credential by phone, e-

mail, web, or other non-face-to-face

method, the user’s identity is verified

before the authentication credential is

modified.







Authentication procedures for

users will not be applicable.



settings to verify that user password







Reduction

Risk Value

Merchant

Documentation

Justification

parameters are set to require at least the

following strength/complexity:

Require a minimum length of at

least seven characters.

Contain both numeric and

alphabetic characters.



Password parameter settings for

various system components will

not be applicable.



customer/user documentation to verify

that non-consumer user passwords are

required to meet at least the following

strength/complexity:

Require a minimum length of at

least seven characters.

Contain both numeric and

alphabetic characters.


environments.



settings to verify that user password

parameters are set to require users to

change passwords at least every 90 days.









not be applicable.




that:

Non-consumer user passwords are

required to change periodically; and

Non-consumer users are given

guidance as to when, and under what

circumstances, passwords must

change.


environments.


components, obtain and inspect system

configuration settings to verify that

password parameters are set to require








Reduction

Risk Value

Merchant

Documentation

Justification

that new passwords cannot be the same

as the four previously used passwords.




not be applicable.

8.2.5.b Additional Procedure for service

providers, review internal processes and


that new non- consumer user passwords

cannot be the same as the previous four

passwords.


environments.

8.2.6 Examine password procedures and

observe security personnel to verify that

first-time passwords for new users, and

reset passwords for existing users, are set

to a unique value for each user and

changed after first use.









not be applicable.

8.3 Incorporate two-factor authentication for remote network access originating from outside the network, by personnel

(including users and administrators) and all third parties, (including vendor access for support or maintenance).

8.3.a Examine system configurations for

remote access servers and systems to

verify two-factor authentication is

required for:

All remote access by personnel.

All third-party/vendor remote

access (including access to

applications and system

components for support or

maintenance purposes).






(outside of the POI devices). Two-

factor authentication for remote

network access will not be

applicable.

8.3.b Observe a sample of personnel (for

example, users and administrators)

connecting remotely to the network and

verify that at least two of the three

authentication methods are used.







Two-factor authentication for



Reduction

Risk Value

Merchant

Documentation

Justification

remote network access will not

be applicable.

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

Guidance on selecting strong authentication credentials.

Guidance for how users should protect their authentication credentials.

Instructions not to reuse previously used passwords.

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

8.4.a Examine procedures and interview

personnel to verify that authentication

procedures and policies are distributed to

all users.







Authentication procedures and

policies requirements will not be

applicable.

8.4.b Review authentication procedures

and policies that are distributed to users

and verify they include:

Guidance on selecting strong

authentication credentials.

Guidance for how users should protect

their authentication credentials.

Instructions for users not to reuse

previously used passwords.

Instructions to change passwords if

there is any suspicion the password

could be compromised.









applicable.

8.4.c Interview a sample of users to verify

that they are familiar with authentication

procedures and policies.









applicable.



Reduction

Risk Value

Merchant

Documentation

Justification

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

Generic user IDs are disabled or removed.

Shared user IDs do not exist for system administration and other critical functions.

Shared and generic user IDs are not used to administer any system components.

8.5.a For a sample of system components,

examine user ID lists to verify the following.

Generic user IDs are disabled or

removed.

Shared user IDs for system

administration activities and other

critical functions do not exist.

Shared and generic user IDs are

not used to administer any system

components.







8.5.b Examine authentication

policies/procedures to verify that use of

group and shared IDs and/or passwords or

other authentication methods are explicitly

prohibited.









applicable.

8.5.c Interview system administrators to

verify that group and shared IDs and/or

passwords or other authentication

methods are not distributed, even if

requested.









applicable.

8.5.1 Additional requirement for service providers: Service providers with remote access to customer premises (for example,

for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each

customer.



Reduction

Risk Value

Merchant

Documentation

Justification

8.5.1 Additional requirement for service

providers:

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


environments.

8.6.a Examine authentication policies and

procedures to verify that procedures for

using authentication mechanisms such as

physical security tokens, smart cards, and

certificates are defined and include:

Authentication mechanisms are

assigned to an individual account and

not shared among multiple accounts.

Physical and/or logical controls are

defined to ensure only the intended

account can use that mechanism to

gain access.









applicable.

8.6.b Interview security personnel to verify

authentication mechanisms are assigned

to an account and not shared among

multiple accounts.









applicable.

8.6.c Examine system configuration

settings and/or physical controls, as

applicable, to verify that controls are

implemented to ensure only the intended

account can use that mechanism to gain

access.







8.7.a Review database and application

configuration settings and verify that all

users are authenticated prior to access.

1 Not Applicable There will be no cardholder data

repositories when TAVE is

implemented properly.

8.7.b Examine database and application

configuration settings to verify that all user

access to, user queries of, and user actions

on (for example, move, copy, delete), the






Reduction

Risk Value

Merchant

Documentation

Justification

database are through programmatic

methods only (for example, through stored

procedures).

8.7.c Examine database access control

settings and database application

configuration settings to verify that user

direct access to or queries of databases are

restricted to database administrators.




8.7.d Examine database access control

settings, database application

configuration settings, and the related

application IDs to verify that application

IDs can only be used by the applications

(and not by individual users or other

processes).




8.8 Examine documentation interview


and operational procedures for

identification and authentication are:

Documented,

In use, and



cardholder data, security policies

and operational procedures

documentation for identification

and authentication would not be

applicable.

9.1 Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment.

9.1 Verify the existence of physical security

controls for each computer room, data

center, and other physical areas with

systems in the cardholder data

environment.

Verify that access is controlled with

badge readers or other devices

including authorized badges and lock

and key.

Observe a system administrator’s

attempt to log into consoles for

randomly selected systems in the

cardholder environment and verify

2 Physical Security Policy Appropriate physical controls to

ensure that the POI devices

cannot be physically altered,

perimeter devices are properly

protected should be in place.

Physical controls also apply to

protection of paper media

containing cardholder data.



Reduction

Risk Value

Merchant

Documentation

Justification

that 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 will

be not applicable since

there won't be any "sensitive"

areas in the merchant

environment outside of the POI

terminals.

9.1.1.b Verify that video cameras and/or

access control mechanisms are protected

from tampering or disabling.






terminals.

9.1.1.c Verify that video cameras and/or

access control mechanisms are monitored

and that data from cameras or other

mechanisms is stored for at least three

months.






terminals

9.1.2 Interview responsible personnel and

observe locations of publicly accessible

network jacks to verify that physical

and/or logical controls are in place to

restrict access to publicly accessible

network jacks.

2 Physical Security Policy Appropriate physical controls to

ensure that the POI devices

cannot be physically altered,

perimeter devices are properly

protected should be in place.

Physical controls also apply to

protection of paper media

containing cardholder data.



Reduction

Risk Value

Merchant

Documentation

Justification

9.1.3 Verify that physical access to wireless

access points, gateways, handheld devices,

networking/communications hardware,

and telecommunication lines is

appropriately restricted.





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

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

Changes to access requirements.

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

9.2.a Review documented processes to

verify that procedures are defined for

identifying and distinguishing between

onsite personnel and visitors.

Verify procedures include the following:

Identifying new onsite personnel or

visitors (for example, assigning

badges),

Changing access requirements, and

Revoking terminated onsite personnel

and expired visitor identification (such

as ID badges)

2 Physical Security Policy

Cardholder data will not be

accessible within the merchant

environment; therefore, the

applicability of this requirement

can be greatly reduced; however,

controls should ensure that

unauthorized visitors cannot

access perimeter systems or POI

devices.

9.2.b Observe processes for identifying

and distinguishing between onsite

personnel and visitors to verify that:

Visitors are clearly identified, and

It is easy to distinguish between

onsite personnel and visitors.

2 Physical Security Policy Cardholder data will not be








devices.

9.2.c Verify that access to the

identification process (such as a badge

system) is limited to authorized personnel.










Reduction

Risk Value

Merchant

Documentation

Justification


devices.

9.2.d Examine identification methods

(such as ID badges) in use to verify that

they clearly identify visitors and it is easy

to distinguish between onsite personnel

and visitors.









devices.

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

Access must be authorized and based on individual job function.

Access is revoked immediately upon termination, and all physical access mechanisms, such as keys, access cards, etc.,

are returned or disabled.

9.3.a For a sample of onsite personnel with

physical access to the CDE, interview

responsible personnel and observe access

control lists to verify that:

Access to the CDE is authorized.

Access is required for the

individual’s job function.








unauthorized users cannot access

perimeter systems or POI devices.

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










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








Reduction

Risk Value

Merchant

Documentation

Justification





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

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









devices.

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









devices.

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









devices.

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










Reduction

Risk Value

Merchant

Documentation

Justification


devices.

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









devices.

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









devices.

9.4.4.b Verify that the log contains:

The visitor’s name,

The firm represented, and

The onsite personnel authorizing physical access.









devices.

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










Reduction

Risk Value

Merchant

Documentation

Justification


devices.

9.5 Physically secure all media.

9.5 Verify that procedures for protecting cardholder data include controls for physically securing all media (including but not limited to computers, removable electronic media, paper receipts, paper reports, and faxes).


Data Retention and


applicable)








9.5.1.a Observe the storage location’s

physical security to confirm that backup

media storage is secure.


Data Retention and


applicable)








9.5.1.b Verify that the storage location

security is reviewed at least annually.


Data Retention and


applicable)








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

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



applicable)








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



applicable)








Reduction

Risk Value

Merchant

Documentation

Justification



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



applicable)








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



applicable)








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



applicable)








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

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



applicable)








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



applicable)








Reduction

Risk Value

Merchant

Documentation

Justification



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

9.8 Examine the periodic media destruction policy and verify that it covers all media and defines requirements for the following:

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

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

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



applicable)








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



applicable)








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



applicable)








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

1 Not Applicable There will be no electronic

instances of cardholder data

storage within the merchant

environment.



Reduction

Risk Value

Merchant

Documentation

Justification

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

9.9 Examine documented policies and procedures to verify they include:

Maintaining a list of devices

Periodically inspecting devices to look for tampering or substitution

Training personnel to be aware of suspicious behavior and to report tampering or substitution of devices.

4 Device Protection policies

and procedures

This requirement is fully in-scope

for the merchant’s PCI-DSS

assessment.

9.9.1 Maintain an up-to-date list of devices. The list should include the following:

Make, model of device.

Location of device (for example, the address of the site or facility where the device is located).

Device serial number or other method of unique identification.

9.9.1.a Examine the list of devices to verify it includes:

Make, model of device

Location of device (for example, the address of the site or facility where the device is located)

Device serial number or other method of unique identification.


and procedures



assessment.

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


and procedures



assessment.

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


and procedures



assessment.

9.9.2 Periodically inspect device surfaces to detect tampering (for example, addition of card skimmers to devices), or

substitution (for example, by checking the serial number or other device characteristics to verify it has not been swapped

with a fraudulent device).

9.9.2.a Examine documented procedures to verify processes are defined to include the following:

Procedures for inspecting devices

Frequency of inspections.


and procedures



assessment.



Reduction

Risk Value

Merchant

Documentation

Justification

9.9.2.b Interview responsible personnel and observe inspection processes to verify:

Personnel are aware of procedures for inspecting devices.

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


and procedures



assessment.

9.9.3 Provide training for personnel to be aware of attempted tampering or replacement of devices. Training should include the following:

Verify the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices.

Do not install, replace, or return devices without verification.

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

Report suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a

manager or security officer).

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

Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices

Not to install, replace, or return devices without verification

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

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


and procedures



assessment.

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

Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices

Not to install, replace, or return devices without verification


and procedures



assessment.



Reduction

Risk Value

Merchant

Documentation

Justification

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

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

9.10 Ensure that security policies and operational procedures for restricting physical access to cardholder data are

documented, in use, and known to all affected parties.

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

Documented,

In use, and



Data Retention and


applicable)

Device Protection policies

and procedures



assessment.

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

10.1 Verify, through observation and interviewing the system administrator, that:

Audit trails are enabled and active for system components.

Access to system components is linked to individual users.







Merchant has no access to

cardholder data, thus

implementation of audit trails


applicable.

10.2 Through interviews of responsible personnel, observation of audit logs, and examination of audit log settings, perform the following:

10.2.1 Verify all individual access to cardholder data is logged.

1 Not Applicable. Merchant access to cardholder

will not be possible with the

proper implementation of TAVE.

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







Reduction

Risk Value

Merchant

Documentation

Justification







applicable.

10.2.3 Verify access to all audit trails is

logged.











applicable.

10.2.4 Verify invalid logical access

attempts are logged.











applicable.

10.2.5.a Verify use of identification and

authentication mechanisms is logged.











applicable.



Reduction

Risk Value

Merchant

Documentation

Justification

10.2.5.b Verify all elevation of privileges is logged.











applicable.

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











applicable.

10.2.6 Verify the following are logged:

Initialization of audit logs

Stopping or pausing of audit logs.











applicable.

10.2.7 Verify creation and deletion of

system level objects are logged.











Reduction

Risk Value

Merchant

Documentation

Justification



applicable.

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

10.3.1 Verify user identification is included

in log entries.











applicable.

10.3.2 Verify type of event is included in

log entries.











applicable.

10.3.3 Verify date and time stamp is

included in log entries.











applicable.



Reduction

Risk Value

Merchant

Documentation

Justification

10.3.4 Verify success or failure indication is












applicable.

10.3.5 Verify origination of event is












applicable.

10.3.6 Verify identity or name of affected

data, system component, or resources is












applicable.

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







Time-synchronization standards



Reduction

Risk Value

Merchant

Documentation

Justification

and requirements would not be

applicable.

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

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

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

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









applicable.

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

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

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

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









applicable.

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









applicable.



Reduction

Risk Value

Merchant

Documentation

Justification

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









applicable.

10.4.3 Examine systems configurations to verify that the time server(s) accept time updates from specific, industry-accepted external sources (to prevent a malicious individual from changing the clock). Optionally, those updates can be encrypted with a symmetric key, and access control lists can be created that specify the IP addresses of client machines that will be provided with the time updates (to prevent unauthorized use of internal time servers).









applicable.

10.5 Secure audit trails so they cannot be altered.

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










along with security of audit trail


applicable.

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











Reduction

Risk Value

Merchant

Documentation

Justification




applicable.

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












applicable.

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












applicable.

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













Reduction

Risk Value

Merchant

Documentation

Justification


applicable.

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






(outside of the POI devices). File-

integrity monitoring or change-

detection requirements will not

be applicable.

10.6 Review logs and security events for all system components to identify anomalies or suspicious activity. Perform the following:

10.6.1.a Examine security policies and procedures to verify that procedures are defined for reviewing the following at least daily, either manually or via log tools:

All security events

Logs of all system components that store, process, or transmit CHD and/or SAD, or that could impact the security of CHD and/or SAD

Logs of all critical system components

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








cardholder data, thus procedures

related to implementation of

audit trails and security events


10.6.1.b Observe processes and interview personnel to verify that the following are reviewed at least daily:

All security events

Logs of all system components that store, process, or transmit CHD and/or SAD, or that could impact the security of CHD and/or SAD

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

components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS),









related to implementation of

audit trails and security events




Reduction

Risk Value

Merchant

Documentation

Justification

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

10.6.2 Review logs of all other system components periodically based on the organization’s policies and risk management strategy, as determined by the organization’s annual risk assessment.

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









related to logging and security

events would not be applicable.

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









related to logging and security

events would not be applicable.

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

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







Security policies and procedures

for log review processes will not

be applicable.



Reduction

Risk Value

Merchant

Documentation

Justification

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







Security policies and procedures

for log review processes will not

be applicable.

10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for

example, online, archived, or restorable from backup).

10.7.a Examine security policies and procedures to verify that they define the following:

Audit log retention policies

Procedures for retaining audit logs for at least one year, with a minimum of three months immediately available online.






(outside of the POI devices). Audit

log retention policies and

procedures will not be applicable.

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









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









10.8 Ensure that security policies and operational procedures for monitoring all access to network resources and cardholder

data are documented, in use, and known to all affected parties.



Reduction

Risk Value

Merchant

Documentation

Justification

10.8 Examine documentation interview personnel to verify that security policies and operational procedures for monitoring all access to network resources and cardholder data are:

Documented,

In use, and



cardholder data, thus security

policies and operational

procedures for monitoring all

access to network resources and

cardholder data would not be

applicable.

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

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





Policies and procedures for

wireless access point detection

and identification will not be

applicable.

11.1.b Verify that the methodology is

adequate to detect and identify any

unauthorized wireless access points,

including at least the following:

WLAN cards inserted into system

components

Portable wireless devices connected

to system components (for example,

by USB, etc.)

Wireless devices attached to a

network port or network device




merchant’s host network. Policies

and procedures for wireless

access point detection and

identification will not be in

applicable.

11.1.c Examine output from recent wireless scans to verify that:

Authorized and unauthorized wireless access points are identified, and

The scan is performed at least quarterly for all system components and facilities.








applicable.



Reduction

Risk Value

Merchant

Documentation

Justification

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








applicable.

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








applicable.

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








applicable.

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








applicable.

11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network

(such as new system component installations, changes in network topology, firewall rule modifications, product

upgrades).Verify that internal and external vulnerability scans are performed as follows:

11.2.1 Perform quarterly internal vulnerability scans, and rescans as needed, until all “high-risk” vulnerabilities (as identified

in Requirement 6.1) are resolved. Scans must be performed by qualified personnel.



Reduction

Risk Value

Merchant

Documentation

Justification

11.2.1.a Review the scan reports and

verify that four quarterly internal scans

occurred in the most recent 12-month

period.







As such, there are no applicable

internal vulnerability scanning

requirements.

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









requirements.

11.2.1.c Interview personnel to verify that the scan was performed by a qualified internal resource(s) or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).









requirements.

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.








external vulnerability scanning

requirements.



Reduction

Risk Value

Merchant

Documentation

Justification

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









requirements.

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









requirements.

11.2.3.a Inspect and correlate change control documentation and scan reports to verify that system components subject to any significant change were scanned.








vulnerability scanning

requirements.

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

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

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









requirements.



Reduction

Risk Value

Merchant

Documentation

Justification

11.2.3.c Validate that the scan was

performed by a qualified internal

resource(s) or qualified external third

party, and if applicable, organizational

independence of the tester exists (not

required to be a QSA or ASV).









requirements.

11.3 Penetration Testing

Note: The update to Requirement 11.3 is a best practice until June 30, 2015, after which it becomes a requirement. PCI DSS

v2.0 requirements for penetration testing must be followed until v3.1 is in place.

11.3 Examine penetration-testing methodology and interview responsible personnel to verify a methodology is implemented that includes the following:

Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115)

Includes coverage for the entire CDE perimeter and critical systems

Testing from both inside and outside the network

Includes testing to validate any segmentation and scope-reduction controls

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

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

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

Specifies retention of penetration testing results and remediation activities results.








penetration testing requirements.



Reduction

Risk Value

Merchant

Documentation

Justification

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

Per the defined methodology

At least annually

After any significant changes to the environment.









11.3.1.b Verify that the test was performed by a qualified internal resource or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).









11.3.2.a Examine the scope of work and

results from the most recent internal

penetration test to verify that penetration

testing is performed at least annually and

after any significant changes to the

environment.

Per the defined methodology

At least annually

After any significant changes to the

environment









11.3.2.b Verify that the test was

performed by a qualified internal resource

or qualified external third party, and if

applicable, organizational independence of

the tester exists (not required to be a QSA

or ASV).











Reduction

Risk Value

Merchant

Documentation

Justification

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









11.3.4 If segmentation is used to isolate the CDE from other networks, perform penetration tests at least annually and after

any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective, and

isolate all out-of-scope systems from in-scope systems.

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









11.3.4.b Examine the results from the most recent penetration test to verify that penetration testing to verify segmentation controls:

Is performed at least annually and after any changes to segmentation controls/methods.

Covers all segmentation controls/methods in use.

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









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

11.4.a Examine system configurations and network diagrams to verify that techniques (such as intrusion-detection systems







Reduction

Risk Value

Merchant

Documentation

Justification

and/or intrusion-prevention systems) are in place to monitor all traffic:

At the perimeter of the cardholder data environment

At critical points in the cardholder data environment.

Intrusion-detection and/or

intrusion prevention

requirements will be not

applicable.

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








applicable.

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








applicable.

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

11.5.a Verify the use of file-integrity

monitoring tools within the cardholder

data environment by observing system

settings and monitored files, as well as

reviewing results from monitoring

activities.

Examples of files that should be

monitored:

System executables

Application executables

Configuration and parameter files

Centrally stored, historical or archived,

log and audit files

Additional critical files determined by

entity (for example, through risk

assessment or other means).









be applicable.



Reduction

Risk Value

Merchant

Documentation

Justification

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









be applicable.

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









be applicable.

11.6 Ensure that security policies and operational procedures for security monitoring and testing are documented, in use, and

known to all affected parties.

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

Documented,

In use, and



cardholder data, thus security

policies and operational

procedures for security

monitoring and testing would not

be applicable.

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

12.1 Examine the information security

policy and verify that the policy is

published and disseminated to all relevant

personnel (including vendors and business

partners).

4 Information Security

Policy



assessment.

12.1.1 Verify that the information security policy is reviewed at least annually and updated as needed to reflect changes to business objectives or the risk environment.


Policy



assessment.



Reduction

Risk Value

Merchant

Documentation

Justification

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


Policy

Annual Risk Assessment



assessment.

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


Policy

Annual Risk Assessment



assessment.

12.3 Examine the usage policies for critical technologies and interview responsible personnel to verify the following policies

are implemented and followed:

12.3.1 Verify that the usage policies include processes for explicit approval from authorized parties to use the technologies.

4 Acceptable Usage Policies This requirement is fully in-scope


assessment.

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



assessment.

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



assessment.

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



assessment.

12.3.5 Verify that the usage policies

require acceptable uses for the

technology.



assessment.


require acceptable network locations for

the technology.



assessment.



Reduction

Risk Value

Merchant

Documentation

Justification


require a list of company-approved

products.



assessment.

12.3.8.a Verify that the usage policies

require automatic disconnect of sessions

for remote-access technologies after a

specific period of inactivity.



assessment.

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



assessment.


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.



assessment.

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


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


environment.

12.4.a Verify that information security

policies clearly define information security

responsibilities for all personnel.


Policy



assessment.

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

4 Incident Response Plan

(IRP)



assessment.



Reduction

Risk Value

Merchant

Documentation

Justification

12.5 Examine information security policies and procedures to verify:

The formal assignment of information security to a Chief Security Officer or other security-knowledgeable member of management.

The following information security responsibilities are specifically and formally assigned:


Policy



assessment.

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


Policy



assessment.

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.


Policy



assessment.

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


Policy



assessment.

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


Policy



assessment.

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


Policy



assessment.

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


Policy

Security Awareness

Policy/Program



assessment.

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

4 Security Awareness

Policy/Program



assessment.



Reduction

Risk Value

Merchant

Documentation

Justification

12.6.1.a Verify that the security awareness

program provides multiple methods of

communicating awareness and educating

personnel (for example, posters, letters,

memos, web based training, meetings, and

promotions).


Policy/Program



assessment.

12.6.1.b Verify that personnel attend

awareness training upon hire and at least

annually.


Policy/Program



assessment.

12.6.1.c Interview a sample of personnel to verify they have completed awareness training and are aware of the importance of cardholder data security.


(IRP)



assessment.

12.6.2 Verify that the security awareness program requires personnel to acknowledge, in writing or electronically, at least annually, that they have read and understand the information security policy.


Policy/Program



assessment.

12.7 Inquire with Human Resource

department management and verify that

background checks are conducted (within

the constraints of local laws) prior to hire

on potential personnel who will have

access to cardholder data or the



Policy



assessment.

12.8 Through observation, review of

policies and procedures, and review of

supporting documentation, verify that

processes are implemented to manage

service providers with whom cardholder

data is shared, or that could affect the

security of cardholder data (for example,

backup tape storage facilities, managed

service providers such as web-hosting

companies or security service providers,

those that receive data for fraud modeling

purposes, etc.), as follows:



Reduction

Risk Value

Merchant

Documentation

Justification

12.8.1 Verify that a list of service providers

is maintained.


Policy



assessment.

12.8.2 Observe written agreements and confirm they include an acknowledgement by service providers that they are responsible for the security of cardholder data the service providers possess or otherwise store, process or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.


Policy



assessment.

12.8.3 Verify that policies and procedures are documented and implemented including proper due diligence prior to engaging any service provider.


Policy



assessment.

12.8.4 Verify that the entity maintains a

program to monitor its service providers’

PCI DSS compliance status at least

annually.


Policy



assessment.

12.8.5 Verify the entity maintains information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.


(IRP)



assessment.

12.9 Additional testing procedure for service providers: Review service provider’s policies and procedures and observe written agreement templates to confirm the service provider acknowledges in writing to customers that the service provider will maintain all applicable PCI DSS requirements to the extent the service provider handles, has access to, or otherwise stores, processes or transmits the customer’s cardholder data or sensitive authentication data, or manages the customer's cardholder data environment on behalf of a customer.


environments.

12.10 Examine the incident response plan and related procedures to verify entity is prepared to respond immediately to a

system breach by performing the following:



Reduction

Risk Value

Merchant

Documentation

Justification

12.10.1.a Verify that the incident response plan includes:

Roles, responsibilities, and communication strategies in the event of a compromise including notification of the payment brands, at a minimum

Specific incident response procedures

Business recovery and continuity procedures

Data backup processes

Analysis of legal requirements for reporting compromises (for example, California Bill 1386, which requires notification of affected consumers in the event of an actual or suspected compromise for any business with California residents in their database)

Coverage and responses for all critical system components

Reference or inclusion of incident response procedures from the payment brands.


(IRP)



assessment.

12.10.1.b Interview personnel and review documentation from a sample of previously reported incidents or alerts to verify that the documented incident response plan and procedures were followed.


(IRP)



assessment.

12.10.2 Verify that the plan is tested at least annually.


(IRP)



assessment.

12.10.3 Verify through observation, review of policies, and interviews of responsible personnel that designated personnel are available for 24/7 incident response and monitoring coverage for any evidence of unauthorized activity, detection of unauthorized wireless access points, critical IDS alerts, and/or reports of unauthorized critical system or content file changes.


(IRP)



assessment.

12.10.4 Verify through observation, review of policies, and interviews of responsible personnel that staff with responsibilities for security breach response are periodically trained.


(IRP)



assessment.



Reduction

Risk Value

Merchant

Documentation

Justification

12.10.5 Verify through observation and review of processes that monitoring and responding to alerts from security monitoring systems, including detection of unauthorized wireless access points, are covered in the incident response plan.


(IRP)



assessment.

12.10.6 Verify through observation, review of policies, and interviews of responsible personnel that there is a process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments.


(IRP)



assessment.

Date post:	06-Jul-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

First Data TransArmor VeriFone Edition Technical Assessment … › downloads › pdf ›...

Documents