visa data security compliance programs - cisp... · 2020. 6. 18. · the pci dss was developed by...

Overview The Payment Card Industry Data Security Standard (PCI DSS) is a comprehensive set of international security requirements for protecting cardholder data. The PCI DSS was developed by Visa® and the founding payment brands of the PCI Security Standards Council to help facilitate the broad adoption of consistent data security measures on a global basis. These 12 requirements are the foundation of Visa’s data security compliance programs including the Cardholder Information Security Program (CISP) and Account Information Security (AIS) Program.

Payment Card Industry Data Security Standard (PCI DSS)n Build and Maintain a Secure Network

1. Install and maintain a firewall configuration to protect data2. Do not use vendor-supplied defaults for system passwords and other

security parameters

n Protect Cardholder Data3. Protect stored cardholder data4. Encrypt transmission of cardholder data and sensitive information

across open public networks

n Maintain a Vulnerability Management Program5. Use and regularly update anti-virus software6. Develop and maintain secure systems and applications

n Implement Strong Access Control Measures7. Restrict access to data by business need-to-know 8. Assign a unique ID to each person with computer access9. Restrict physical access to cardholder data

n Regularly Monitor and Test Networks10. Track and monitor all access to network resources and cardholder data11. Regularly test security systems and processes

n Maintain an Information Security Policy12. Maintain a policy that addresses information security

For More InformationA detailed description of Visa’s payment system security compliance programs including PCI DSS compliance and validation requirements, payment application security mandates, and PIN security and key management requirements can be found at www.visa.com/CISP. In addition, Visa publishes data security alerts, bulletins and webinar presentations; all are available for download.

Every piece of cardholder account information that passes through the Visa payment system is vital to our business. Without proper safeguards in place, this information can be vulnerable to internal and external compromise, leading to fraud and loss of consumer confidence. The goal of Visa’s security programs is to ensure the highest standard of due diligence to protect sensitive cardholder data from hackers and fraudsters.

About the ProgramWhat is PCI DSS?The PCI DSS protects Visa cardholder data wherever it resides.

Who Needs to Know?All Visa acquirers and issuers must comply, and must also ensure the compliance of their merchants and service providers who store, process, or transmit Visa account numbers. This program applies to all payment channels including card present, mail/telephone order, and e-commerce.

How Does it Work?To achieve PCI DSS compliance, all Visa acquirers, issuers, merchants and service providers must adhere to the PCI DSS requirements set forth by the PCI Security Standards Council, which offers a single approach to safeguarding sensitive data for all card brands. Businesses may also be required to validate PCI DSS compliance in accordance with payment card brand requirements.

Why is it Important?By complying with the PCI DSS, businesses meet their obligations to the Visa payment system and also build a culture of security that benefits all parties.

Visa Data Security Compliance Programs

What To Do If CompromisedIn the event of a security incident, Visa acquirers, issuers, merchants, and service providers must take immediate action to investigate the incident, limit the exposure of cardholder data, notify Visa, and report investigation findings. Visa’s What To Do If Compromised guide, which can be found online at www.visa.com/CISP, contains step-by-step guidelines to assist clients, merchants, and service providers through a security incident.

Separate from the mandate to comply with PCI DSS is the validation of compliance. Validation identifies vulnerabilities and ensures that appropriate levels of cardholder information security are maintained. Visa has prioritized and defined validation levels based on the volume of transactions and the potential risk and exposure introduced into the Visa system.

Some businesses validate compliance through an Annual On-Site Security Assessment and Quarterly Network Vulnerability Scan; others complete an Annual Self-Assessment Questionnaire and Quarterly Network Vulnerability Scan.

Acquirers and Issuers

All Visa acquirers and issuers must comply with the PCI DSS and will be advised by Visa of applicable validation requirements. At minimum, acquirers are responsible for ensuring the compliance and validation of their merchants. Issuers and acquirers must also ensure that their third party agents—and the third party agents used by their merchants—are registered with Visa and are PCI DSS compliant.

Merchants

Merchants who store, process, or transmit Visa cardholder data generally fall into one of four merchant levels based on Visa transaction volume over a 12-month period. Transaction volume is based on the aggregate number of Visa transactions from a merchant Doing Business As (DBA).

MerChant LeVeL

DeSCriPtion

1 • Any merchant, regardless of acceptance channel, processing over 6,000,000 Visa transactions per year.

• Any merchant that Visa, at its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the Visa system.

2 Any merchant, regardless of acceptance channel, processing 1,000,000 to 6,000,000 Visa transactions per year.

3 Any merchant processing 20,000 to 1,000,000 Visa e-commerce transactions per year.

4 Any merchant processing fewer than 20,000 Visa e-commerce transactions per year, and all other merchants processing up to 1,000,000 Visa transactions per year.

Service Providers

Effective February 1, 2009, service providers that store, process or transmit Visa cardholder data on behalf of Visa acquirers, issuers, merchants or other service providers will fall into one of two service provider levels. Level 2 service providers will not be posted on Visa’s list of compliant services providers unless they opt to undergo a Level 1 onsite security assessment. Service providers who validate Level 2 compliance prior to February 1, 2009 will be grandfathered onto Visa’s list until their next annual revalidation date.

SerViCe ProViDer

LeVeL

DeSCriPtion PoSteD on ViSa’S LiSt oF CoMPLiant SerViCe ProViDerS

1 VisaNet® processors and third party agents that store, process or transmit more than 300,000 Visa transactions annually.

Yes

2 Any third party agent that stores, processes or transmits less than 300,000 Visa transactions annually.

No*

* Level 2 service providers may choose to validate as a Level 1 service provider in order to be listed on Visa’s list of compliant service providers.

PCi DSS Compliance Validation

© 2008 Visa Inc. VRM 09.20.08

Payment Application Security

The PCI Payment Application Data Security Standard (PA-DSS), developed to create security standards for payment application vendors, mitigates the risk of compromises through vulnerable payment applications, prevents storage of sensitive authentication data (i.e., full magnetic-stripe data, CVV2 and PIN data) and supports overall compliance with the PCI DSS. Visa developed a series of payment application mandates that require acquirers to ensure that their merchants and service providers do not use vulnerable payment applications known to retain sensitive authentication data and also ensure the use of PCI PA-DSS compliant applications. Details on these mandates are available at www.visa.com/CISP.

CoMPLianCe aCtionS VaLiDation aCtionS

Group Level Comply with PCI DSS On-Site Security AssessmentSelf-Assessment

Questionnaire Network Scan*

Merchant 1 Required Required Annually Required Quarterly

2 & 3 Required Required Annually Required Quarterly

4** Required Recommended Required Quarterly

Service Providers

1 Required Required Annually Required Quarterly

2 Required Required Annually Required Quarterly

*Network scanning is applicable to any internet facing system. ** Validation requirements are determined by the merchant’s acquirer.

Visa acquirers and issuers must also register all third party agents with Visa. Registration of third party agents can be accomplished through the Visa Membership Management application (VMM), which is accessible through Visa Online (www.us.visaonline.com)

In April 2000, Visa announced the launch of its Cardholder Information Security Program (CISP). Approved in October 1999 and mandated June 2001. CISP defines a standard of due care for securing Visa cardholder data, wherever it is located. CISP compliance has been required of all entities storing, processing, or transmitting Visa cardholder data. Members must comply with CISP and are responsible for ensuring the compliance of their merchants and Agents—whether they support Issuing or Acquiring activity—for all payment channels, including retail (brick-and-mortar), mail/telephone-order, and e-commerce.

Fines will be assessed to any entity that fails to comply with CISP.

CISP Requirements How CISP Works CISP Groups Defined Why Comply? Visa Regulations Contact Information

The CISP Requirements

• An easy to remember list of 12 basic security requirements with which all Visa payment system constituents need to comply

• More detailed sub-requirements, always tying back to the CISP requirements

1. Install and maintain a working firewall to protect data 2. Keep security patches up-to-date 3. Protect stored data 4. Encrypt data sent across public networks 5. Use and regularly update anti-virus software 6. Restrict access by "need to know" 7. Assign unique ID to each person with computer access 8. Don't use vendor-supplied defaults for passwords and security parameters 9. Track all access to data by unique ID 10. Regularly test security systems and processes 11. Implement and maintain an information security policy 12. Restrict physical access to data

If you are a non-U.S. based entity, please click here to access Visa International's Account Information Security (AIS).

How CISP Works

Visa has categorized validation of CISP compliance based on the volume of transactions and the potential risk and exposure introduced into the Visa System by merchants and service providers.

Members must use, and are responsible for ensuring that their merchants use, service providers that are CISP-compliant. Service providers who have validated compliance with CISP can be found on the List of CISP-Compliant service providers.

http://usa.visa.com/business/merchants/http://usa.visa.com/business/merchants/http://usa.visa.com/business/merchants/http://usa.visa.com/business/merchants/http://usa.visa.com/business/merchants/#bhttp://usa.visa.com/business/merchants/#chttp://usa.visa.com/business/merchants/#dhttp://usa.visa.com/business/merchants/#ehttp://usa.visa.com/business/merchants/#fhttp://usa.visa.com/business/merchants/#ghttp://usa.visa.com/trk/dyredir.jsp?it=il_/business/merchant/cisp_index.html&d=il_busmerch/cisp_index.html&rDirl=http://www.visa.com/securedhttp://usa.visa.com/media/business/cisp/List_of_CISP_Compliant_Service_Providers.pdf

Visa has categorized validation of CISP compliance based on the volume of transactions and the potential risk and exposure introduced into the Visa System by merchants and service providers.

Members must use, and are responsible for ensuring that their merchants use, service providers that are CISP-compliant. Service providers who have validated compliance with CISP can be found on the List of CISP-Compliant service providers. A Member who uses a service provider, or whose merchant uses a service provider, that is not a compliant service provider should refer that service provider to the CISP site for information on how to become compliant. Although there may not be a direct contractual relationship between merchant service providers and Acquiring Members, Members remain responsible for any liability that may occur as a result of non-compliance with CISP.

CISP assessment and verification takes place at the participating merchant or service provider's expense. Length of time and cost of compliance depend on the extent to which the merchant or service provider is already in compliance.

If a merchant or service provider refuses to participate in CISP, Visa may impose a fine on such Member responsible for the merchant or service provider. Ultimately, merchants and their service providers must meet the CISP requirements to continue to accept Visa Payment products.

In the event of a security breach, Members must take immediate action to investigate the incident and limit the exposure of cardholder data. If a Member knows or suspects a security breach with a merchant or service provider, the Member must immediately notify Visa. Additionally, Members must take immediate action to investigate the incident and report its findings to Visa. Members receive protection from fines for merchants or service providers that have been compromised but found to be CISP-compliant at the time of the security breach. Members are, however, subject to fines—up to $500,000 per incident—for any merchant or service provider that is compromised and not CISP-compliant at the time of the breach.

CISP Groups Defined

To access CISP compliance details for a specific group, click on its title.

Merchant Level

Selection Criteria Must submit Compliance documentation by:

1 More than 6 million Visa transactions processed annually September 30, 2004

2 500 thousand to 6 million Visa March 31, 2005

http://usa.visa.com/business/merchants/http://usa.visa.com/media/business/cisp/List_of_CISP_Compliant_Service_Providers.pdfhttp://usa.visa.com/media/business/cisp/List_of_CISP_Compliant_Service_Providers.pdfhttp://usa.visa.com/business/merchants/cisp_index.htmlhttp://usa.visa.com/business/merchants/cisp_merch.htmlhttp://usa.visa.com/business/merchants/cisp_merch.html

transactions processed annually

3 Less than 500 thousand Visa transactions processed annually TBD by Member

Why Comply?

CISP was mandated by the Visa U.S.A. Board of Directors in October 1999 and has been supported by ever-expanding Operating Regulations since that time. The CISP requirements help Visa Members, merchants, and service providers protect their information assets and meet the obligations to the Visa payment structure.

• Consumers Want Security Recent media reports of hacker incidences, stolen credit card numbers, and identity theft have triggered, for consumers, a serious concern about information security. Today, consumers want absolute assurance from the businesses they are dealing with that their bankcard account and other personal identifiable information is safe.

• Minimized Threat to Reputation and Financial Position Financial and resource outlay is minimal compared to the costs associated with the reactive hiring of security and public relations specialists, or the loss of significant revenue and goodwill that can result from a compromise.

Visa Regulations

The Visa U.S.A. Operating Regulations govern the activities of Member financial institutions and, by extension, merchants and service providers as participants in the Visa payment system. The requirements below are extracted in "plain language" to help clarify the intent of the more formal regulations. If there is any conflict between the Operating Regulations and the plain language below, the Visa U.S.A. Operating Regulations will take precedence.

• CISP Compliance A Member must comply and ensure that its merchants or service providers comply with the CISP requirements. Acquirers must include a CISP compliance provision in all contracts with merchants and nonmember agents.

• Disclosure of Cardholder Information Issuers, Acquirers, and merchants may only disclose Visa transaction information to service providers approved by Visa: - supporting a loyalty program; or

http://usa.visa.com/business/merchants/http://usa.visa.com/business/merchants/#f

- providing fraud control services. To receive Visa approval, a service provider must comply with the CISP requirements. Additionally, a Member that discloses or allows its merchants to disclose Visa transaction information to a third party that has not demonstrated CISP compliance will be subject to the program fines and penalties.

• CISP Compliance Penalties Failure to comply with CISP standards or to rectify a security issue may result in:

- fines (described below)

- restrictions on the merchant; or

- permanent prohibition of the merchant or service provider's participation in Visa programs.

• The following fines apply for non-compliance, within a rolling 12-month period:

First violation $50,000

Second violation $100,000

Third violation Management discretion

Payment Applications | Merchants | Visa USA

● Home ● Personal ● Small Business ● Merchants ● Mid-Size & Large Companies ● Government

Search:

New Acceptance Operations & Procedures Risk Management Marketing Center Payment Technologies Merchant Resources

Fraud Control Basics Online Safety Cardholder Information Security Program Verified by Visa Zero Liability

● Overview

● Merchants

● Service Providers

● Payment Applications

● PIN Security

● If Compromised

● Assessors

● Alerts, Bulletins & Webinars

● Tools and FAQ

Visa developed the Payment Application Best Practices (PABP) to assist software vendors in creating secure payment applications that help merchants and agents mitigate compromises, prevent storage of sensitive cardholder data (i.e. full magnetic stripe data, CVV, CVV2 or PIN data) and support overall compliance with the PCI Data Security Standard (PCI DSS).

Visa Offers Training Seminar for Payment Application Vendors, Acquirers and Processors on December 11, 2008Visa will be offering a training seminar for payment application vendors, acquirers and processors to provide insight into the Payment Application Data Security Standard (PA-DSS) and associated Visa compliance mandates. The date of the training seminar is December 11, 2008 in Foster City, CA. Please click here to learn more.

On this page

● Payment Application Security

● PABP scope

● Payment Application Security Mandates

● Validation procedures and documentation

● PABP-validated List

● For more information

Payment Application SecurityPayment applications must not retain full magnetic stripe data, CVV, CVV2 or PIN data and must support a merchant's and agent’s ability to comply with the PCI DSS. Merchants and agents using vulnerable payment applications are at heightened risk of compromise attacks.

The PCI Security Standards Council (PCI SSC) has adopted Visa’s PABP and released the standard as the Payment Application Data Security Standard (PA-DSS) in April 2008. Visa strongly encourages payment application vendors to validate the conformance of their products to the PA-DSS. Acquirers should insist that their merchants and agents use PA-DSS compliant applications and upgrade or patch applications that cause the storage of sensitive cardholder data.

To locate a PABP-validated payment application, download the Validated Payment Applications (PDF, 276k).

Back to top

PABP scopeThe PABP applies to software vendors who develop payment applications that store, process, or transmit cardholder data as part of authorization or settlement. Examples of applicable payment applications include but are not limited to POS software, e-commerce shopping carts, and web-based payment applications. PABP does not apply to payment applications developed by merchants and agents if used only in-house (not sold to a third party). PABP also does not apply to standalone POS terminals. Standalone POS terminals are out of scope only if all of the following are true:

● The terminal has no connections to any of the merchant’s systems or networks

Top Downloads

● Visa's PABP adopted as Security Standard-April 15, 2008 PDF | 36k

● Payment Applications Best Practices DOC | 334k

● Validated Payment Applications PDF | 276k

● Payment Application Security Mandates PDF | 60k

● Qualified Payment Application Security Company (QPASC) List PDF | 84k

● PABP Validation Letter to Vendors PDF | 50k

● View all CISP downloads

● Get Acrobat Reader from Adobe.com

● Printable page

http://usa.visa.com/merchants/risk_management/cisp_payment_applications.html (1 of 3) [10/21/2008 7:30:11 AM]

http://usa.visa.com/index.htmlhttp://usa.visa.com/personal/index.htmlhttp://usa.visa.com/business/index.htmlhttp://usa.visa.com/merchants/index.htmlhttp://usa.visa.com/corporate/index.htmlhttp://usa.visa.com/government/index.htmlhttp://usa.visa.com/merchants/new_acceptance/index.htmlhttp://usa.visa.com/merchants/operations/index.htmlhttp://usa.visa.com/merchants/risk_management/index.htmlhttp://usa.visa.com/merchants/marketing_center/index.htmlhttp://usa.visa.com/merchants/payment_technologies/index.htmlhttp://usa.visa.com/merchants/merchant_resources/index.htmlhttp://usa.visa.com/merchants/risk_management/fraud_control_basics.htmlhttp://usa.visa.com/merchants/risk_management/online_transaction_safet.htmlhttp://usa.visa.com/merchants/risk_management/cisp.htmlhttp://usa.visa.com/merchants/risk_management/vbv.htmlhttp://usa.visa.com/merchants/risk_management/zero_liability.htmlhttp://usa.visa.com/merchants/risk_management/cisp_overview.htmlhttp://usa.visa.com/merchants/risk_management/cisp_merchants.htmlhttp://usa.visa.com/merchants/risk_management/cisp_service_providers.htmlhttp://usa.visa.com/merchants/risk_management/cisp_pin_security.htmlhttp://usa.visa.com/merchants/risk_management/cisp_if_compromised.htmlhttp://usa.visa.com/merchants/risk_management/cisp_assessors.htmlhttp://usa.visa.com/merchants/risk_management/cisp_alerts.htmlhttp://usa.visa.com/merchants/risk_management/cisp_tools_faq.htmlhttp://usa.visa.com/download/merchants/visa-bulletin-padss-training-dec08.pdfhttp://usa.visa.com/download/merchants/validated_payment_applications.pdfhttp://usa.visa.com/download/merchants/cisp_bulletin_payment_applications_adoption.pdfhttp://usa.visa.com/download/merchants/cisp_bulletin_payment_applications_adoption.pdfhttp://usa.visa.com/download/merchants/cisp_payment_application_best_practices.dochttp://usa.visa.com/download/merchants/cisp_payment_application_best_practices.dochttp://usa.visa.com/download/merchants/validated_payment_applications.pdfhttp://usa.visa.com/download/merchants/payment_application_security_mandates.pdfhttp://usa.visa.com/download/merchants/payment_application_security_mandates.pdfhttp://usa.visa.com/download/merchants/cisp_qualified_payment_applications_security_company_list.pdfhttp://usa.visa.com/download/merchants/cisp_qualified_payment_applications_security_company_list.pdfhttp://usa.visa.com/download/merchants/cisp_PABP_Validation_Letter_to_Vendors.pdfhttp://usa.visa.com/download/merchants/cisp_PABP_Validation_Letter_to_Vendors.pdfhttp://usa.visa.com/merchants/risk_management/cisp_tools_faq.htmlhttp://www.adobe.com/acrobat/http://usa.visa.com/index.htmlhttp://usa.visa.com/merchants/risk_management/cisp_payment_applications.html?printable=yes


● The terminal connects to the acquirer or processor ● The terminal vendor provides secure remote access, updates, maintenance and troubleshooting ● The following are never stored post authorization: the full contents from the magnetic stripe (that is on the

back of a card, in a chip, or elsewhere), CVV, CVV2, PIN or encrypted PIN block

Back to top

Payment Application Security MandatesBeginning January 1, 2008, Visa has implemented a series of mandates to eliminate the use of vulnerable payment applications from the Visa payment system. These mandates require acquirers to ensure that their merchants and agents do not use payment applications known to retain sensitive cardholder data elements data (i.e. full magnetic stripe data, CVV, CVV2 or PIN data) and require the use of payment applications that adhere to the PA-DSS.

Outlined below are each of the five mandates, which will take effect over the next three years.

Phase Compliance Mandate Effective Date

INewly boarded merchants must not use known vulnerable payment applications, and VisaNet Processors (VNPs) and agents must not certify new payment applications to their platforms that are known vulnerable payment applications

1/1/08

II VNPs and agents must only certify new payment applications to their platforms that are PA-DSS-compliant 7/1/08

III Newly boarded Level 3 and 4 merchants must be PCI DSS compliant or use PA-DSS-compliant applications* 10/1/08

IV VNPs and agents must decertify all vulnerable payment applications** 10/1/09

V Acquirers must ensure their merchants, VNPs and agents use only PA compliant applications*** 7/1/10

* In-house use only developed applications & stand-alone POS hardware terminals are not applicable ** VisaNet Processors (VNPs) and agents must decertify vulnerable payment applications within 12 months of identification *** Date is aligned with TDES mandate for all POS PEDs to support TDES and be Visa-Approved/Lab-Evaluated

Validation procedures and documentationSoftware vendors seeking to validate their payment applications must engage a PA-QSA qualified by the PCI-SSC to perform payment application assessments. Compliance validation takes place at the software vendor's expense.

The assessment must be completed according to the Payment Application Best Practices document. This document is also to be used as the template for the Report on Validation to be submitted to Visa.

The Confirmation of Report Accuracy (for Payment Application Companies) must be completed by all payment application vendors validating compliance and their assessor and submitted to Visa.

Download Payment Application Best Practices (DOC, 334k).

Download Confirmation of Report Accuracy (Payment Application Companies) (DOC, 123k).

Visa does not require re-validation for previously validated product versions if no changes were made to the validated payment application version. However, Visa will require a Confirmation of Report Accuracy from the software vendor prior to the expiration date (one year from the validation date) indicating that no changes were made to the validated payment application. If changes were made to a previously validated payment application version but these changes do not impact the compliance of any of the PABP requirements, Visa will require the software vendor to submit a description of each change in addition to a Confirmation of Report Accuracy indicating so. For any version upgrades, Visa will require a completely new and separate PABP validation performed by a QPASP in order to be listed on the PABP-validated payment application list.

Back to top

PABP-validated ListThe following List of Validated Payment Applications have been assessed for compliance with the Payment Application Best Practices ("PABP"). Only those versions of the application identified in the listing below have been evaluated and determined to comply with PABP. Compliance with the PABP is determined based upon data and information developed by an evaluation of the application by a Qualified Payment Application Security Company ("QPASC"). Although Visa reviews the QPASC-developed data and information, Visa does not independently confirm such data or information nor does Visa perform any tests or analysis of the functionality, performance or suitability of any of the applications and/or products listed. Visa makes no endorsement or recommendation of applications or products, or of their respective developers or distributors. Furthermore, Visa makes no warranties, guarantees or representations that any of the applications or products will meet your


http://usa.visa.com/download/merchants/cisp_payment_application_best_practices.dochttp://usa.visa.com/download/merchants/cora_pa_2007.doc


requirements for performance or functionality, that the applications or products will be free from errors or malicious code, or that the applications or products will be compatible with any other systems or applications. Any and all representations or warranties, including any and all representations and warranties made by the payment application vendor, are disclaimed by Visa.

The information provided herein is provided "as is" with no warranties, expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose and/or non-infringement. The information provided herein is subject to change by Visa, with or without notice. Although Visa makes good faith efforts to provide accurate and complete information, merchants, or anyone else utilizing the information set forth on the following List of Validated Payment Applications remain responsible for confirming the accuracy of the information set forth below, including but not limited to, confirming with the appropriate payment application vendor that the version of the application identified below is in compliance with PABP. Use of any one or more of the applications below (i) does not guarantee or ensure compliance with the PCI DSS; and (ii) does not satisfy any Acquirers' obligation to perform their own evaluation and due diligence, to ensure the PCI DSS compliance of their merchants and agents.

Download the PABP-validated Payment Applications List (PDF, 262k).

For more informationTo learn more about Visa's compliance programs, contact Visa via email at [email protected].

Back to top


http://usa.visa.com/download/merchants/validated_payment_applications.pdfmailto:[email protected]

Visa U.S.A. Cardholder Information Security Program (CISP) Payment Application Best Practices (PABP)

© 2007 Visa U.S.A. Inc. CISP Payment Application Best Practices, Version 1.4 January 2007

This document is to be used for payment application vendors to validate that the payment application complies with the Visa U.S.A. Payment Application Best Practices (PABP) and to create the Report on Validation. Relationship between PCI DSS and PABP The requirements for the PABP are derived from the Payment Card Industry Data Security Standard (PCI DSS) and the PCI DSS Security Audit Procedures. These documents, which can be found at www.pcisecuritystandards.org, detail what is required to be PCI DSS compliant (and therefore what a payment application must support to facilitate an application user’s PCI DSS compliance) and should be used as a reference for the PCI DSS and supporting documentation. Secure payment applications, when implemented in a PCI DSS-compliant environment, will minimize the potential for security breaches leading to compromises of full magnetic stripe data, card validation codes and values (CAV2, CID, CVC2, CVV2), PINs and PIN blocks, and the damaging fraud resulting from these breaches. Scope of PABP The PABP applies to software vendors who develop payment applications that store, process, or transmit cardholder data as part of authorization or settlement. The PABP does not apply to payment software developed by merchants and agents if used only in-house (not sold to a third party), since this in-house developed payment software would be covered as part of the merchant’s or agent’s normal PCI DSS compliance. NOTE: All validated payment application products must be general releases and not beta versions. Data Retention Requirements The following table (from the PCI DSS) illustrates commonly used elements of cardholder data and sensitive authentication data, whether storage of that data is permitted or prohibited, and whether this data needs to be protected. This table is not meant to be exhaustive; its sole purpose is to illustrate the different type of requirements that apply to each data element.

The Primary Account Number (PAN) is the defining factor in the applicability of PCI DSS requirements and the PABP. If PAN is not stored, processed, or transmitted, PCI DSS and PABP do not apply.

Visa U.S.A. CISP Payment Application Best Practices & Audit Procedures


* These data elements must be protected if stored in conjunction with the PAN. This protection should be per PCI DSS requirements for general protection of the cardholder environment. Additionally, other legislation (e.g., related to consumer personal data protection, privacy, identity theft, or data security) may require specific protection of this data, or proper disclosure of a company's practices if consumer related personal data is being collected during the course of business. PCI DSS; however, does not apply if PANs are not stored, processed, or transmitted. ** Do not store sensitive authentication data subsequent to authorization (not even if encrypted). PABP Implementation Guide Validated applications must be capable of being implemented in a PCI DSS-compliant manner. Software vendors are required to provide a PABP Implementation Guide to instruct their customers and resellers/integrators on secure product implementation, to document the secure configuration specifics mentioned throughout this document, and to clearly delineate vendor, reseller/integrator, and customer responsibilities for meeting PCI DSS requirements. It should detail how the customer and/or reseller/integrator should enable security settings within the customer’s network, (for example, the PABP Implementation Guide should cover responsibilities and basic features of PCI DSS password security even if this is not controlled by the application, so that the customer or reseller /integrator understands how to implement secure passwords for PCI DSS compliance). Payment applications, when implemented according to the PABP Implementation Guide, and when implemented into a PCI DSS compliant environment, should facilitate and support customers’ PCI DSS compliance.

Data Element Storage Permitted

Protection Required

PCI DSS REQ. 3.4

Cardholder Data Primary Account Number (PAN) YES YES YES

Cardholder Name* YES YES* NO

Service Code* YES YES* NO

Expiration Date* YES YES* NO

Sensitive Authentication Data** Full Magnetic Stripe NO N/A N/A

CVC2/CVV2/CID NO N/A N/A

PIN / PIN Block NO N/A N/A



Qualified Payment Application Security Professional (QPASP) Requirements

• Only Qualified Payment Application Security Professionals (QPASP) employed by Qualified Payment Application Security Companies (QPASC) are allowed to perform PABP audits. Please refer to the Qualified Payment Application Security Company (QPASC) list at www.visa.com/cisp for more information.

• The QPASP must utilize the testing procedures documented in this Payment Application Best Practices document. • Both QPASP and software vendor must complete and sign the Confirmation of Report Accuracy letters (available at www.visa.com/cisp) and

submit to Visa USA in a secure manner along with the Report on Validation. • Once compliant, Visa will include the software vendor and product version in the Validated Payment Application List at www.visa.com/cisp for

one year only. The expiration date will be determined by the date that Visa approves the Report on Validation. Visa will send an acceptance letter to software vendors indicating approval of the report. Software vendors must re-validate their application for PABP compliance utilizing a QPASP if they wish to be “active” on the Visa website. Otherwise, Visa will remove the software vendor’s listing from the website if re-validation is not received by the due date (please refer to Re-Validation section).

Testing Laboratory The software vendor must have a working, semi-production laboratory where the validation process is to occur. The laboratory must include the following:

All common implementations (including region/country specific versions) of the payment application to be tested. Implementation of security devices. At a minimum, the following must be running per PCI DSS requirements: firewall or traffic filtering devices,

Network Address Translators (NAT), Port Address Translators (PAT), anti-virus software and encryption. Establishment of PCI DSS compliant operating systems and applications necessary to run the software.

The laboratory implementation must include all systems where the application is implemented. For example, a standard implementation of software vendor’s payment application might include a client/server environment within a retail storefront, and back office or corporate network. The laboratory must simulate the total implementation. It is required that the laboratory is capable of simulating and validating all functions of the software, to include generation of all error conditions and log entries. Note: Alternatively, the software vendor may elect to have the validation performed at the QPASC’s laboratory provided that the above requirements are met. Instructions and Content for Report on Validation This document is to be used by QPASPs as the template for creating the Report on Validation and must be submitted to Visa securely. All software vendors and product versions which have validated full compliance with PABP will be included on the list of validated payment applications published at www.visa.com/cisp. No software vendor and product version will be included until all PABP controls are validated to be in place. All QPASPs must follow the instructions for report content and format when completing a Report on Validation.



1. Executive Summary Include the following: • Software vendor name • Software vendor contact information • Software vendor mailing address • QPASP name and contact information • Product Name • Product Version (if applicable) • List of resellers and/or integrators for this product • Operating system with which the payment application was tested. Include other applications required by the payment application. • Database software used or supported by the application. • Brief description of the payment application/family of products (2-3 sentences) • Brief description of the software vendor or QPASC’s laboratory (2-3 sentences) • A network diagram of a typical implementation of the software (not necessarily a specific implementation at a merchant’s site) that

includes, at high-level, connections into and out of a merchant’s network and the implementation components within the merchant’s network, including implementation of POS devices, systems, databases, and web servers as applicable

• Describe/diagram each piece of the communication link, including 1) LAN, WAN or internet, 2) host to host software communication, and 3) within host where software is deployed (e.g. how two different processes communicate with each other on the same host)

• All flows of cardholder data • All payment application related software components, including third party software dependencies • End to end authentication, including application authentication mechanism, authentication database, and security of data storage • Describe the typical merchant that this product is sold to (for example, large, small, if industry-specific, Internet, brick-and-mortar) and

vendor’s customer’s base. (e.g. market segment, big customer names).

2. Description of Scope of Validation and Approach Taken • Describe scope of review as defined at Scope of assessment, above • Describe region/country specific implementations covered • Timeframe of validation • List of documentation reviewed

3. Findings and Observations • All QPASPs must use the following template to provide detailed report descriptions and findings • Describe tests performed other than those included in the testing procedures column.

4. Contact Information and Report Date • Software vendor contact information (include URL, phone number and email address) • QPASP contact information (include phone number and email address)



• Date of report Re-Validation No change - Visa does NOT currently require re-validation for previously validated product versions if no changes were made to the compliant payment application version. However, Visa will require a Confirmation of Report Accuracy from the software vendor prior to the expiration date indicating that no changes were made to the validated payment application. Changes made but does not affect any of the 14 PABP requirements - If changes were made to a previously validated payment application version but does not impact the compliance of any of the 14 PABP requirements, Visa will require the software vendor to submit a description of each change in addition to a Confirmation of Letter Accuracy indicating so. Major changes and product version upgrade – Changes made to a previously validated payment application version which impact any of the 14 PABP requirements will require a completely new and separate PABP validation performed by a QPASP. All PABP validation requirements apply. Definitions The following definitions pertain to the Validation Procedures and Reporting:

• Best Practices – Recommended practices for software vendor to create secure payment applications to help their customers comply with CISP. • Testing Procedures – A process to be followed by an independent security audit firm to address individual Best Practices and testing

considerations • In Place - Please provide a brief description of Best Practices found to be in place. If a Best Practice is Not Applicable to the software, please

explain why and define where this control should be implemented (e.g. this server-based control is the customers’ responsibility). • Not In Place – Please provide a brief description of Best Practices that are not in place. • Target Date/Comments – For those Best Practices “Not In Place” include a target date that the application vendor expects to have “In Place.”

Any additional notes or comments may be included here as well.



PABP Requirements Testing Procedures In Place Not In Place Target Date /

Comments

1. Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CVC2, CVV2), or PIN block data. 1.1 Do not store sensitive authentication data subsequent to authorization (even if encrypted): Sensitive authentication data includes the data as cited in the following requirements 1.1.1 through 1.1.3:

PCI Data Security Standard 3.2

1.1 If sensitive authentication data (see 1.1.1 – 1.1.3 below) is received and deleted, obtain and review methodology for deleting the data to determine that the data is unrecoverable. For each item of sensitive authentication data below, perform the following steps after completing numerous test transactions that simulate all functions of the software, to include generation of error conditions and log entries:

1.1.1 Do not store the full contents of any track from the magnetic stripe (that is on the back of a card, in a chip or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic stripe data. In the normal course of business, the following data elements from the magnetic stripe may need to be retained: the accountholder’s name, primary account number (PAN), expiration date, and service code. To minimize risk, store only those data elements needed for business. NEVER store the card verification code or value or PIN verification value data elements. Note: See PCI DSS Glossary for additional information.

PCI Data Security Standard 3.2.1

1.1.1 Examine the following files created by the application and verify that the full contents of any track from the magnetic stripe on the back of the card are not stored under any circumstance: • Incoming transaction data • Transaction logs • History files • Trace files • Debugging and error logs • Audit logs • Database schemas and tables • Database contents



PABP Requirements Testing Procedures In Place Not In Place Target Date / Comments

1.1.2 Do not store the card-validation value or code (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions.. Note: See PCI DSS Glossary for additional information.


1.1.2 Examine the following files created by the application and verify that the three-digit or four-digit card-validation code printed on the front of the card or the signature panel (CVV2, CVC2, CID, CAV2 data) is not stored under any circumstance: • Incoming transaction data • Transaction logs • History files • Trace files • Debugging and error logs • Audit logs • Database schemas and tables • Database contents

1.1.3 Do not store the personal identification number (PIN) or the encrypted PIN block.


PIN blocks must never be retained (even if encrypted) after transaction authorization.

1.1.3. Examine the following files created by the application, and verify that PINs and encrypted PIN blocks are not stored under any circumstance: • Incoming transaction data • Transaction logs • History files • Trace files • Debugging and error logs • Audit logs • Database schemas and tables • Database contents




1.1.4.a, Review the PABP Implementation Guide prepared by the vendor and verify the documentation includes the following instructions for merchants and resellers/integrators: • that historical data must be removed

(magnetic stripe data, card validation codes, PINs, or PIN blocks stored by previous versions of the software)

• how to remove historical data • that such removal is absolutely

necessary for PCI compliance

1.1.4.b Verify the vendor provides a secure wipe tool or procedure to remove the data.

1.1.4 Securely delete any magnetic stripe data, card validation values or codes, and PINs or PIN block data stored by previous versions of the software. PCI Data Security Standard 3.2

1.1.4.c Verify the secure wipe tool or procedure securely removes the data.

1.1.5.a Review the PABP Implementation Guide prepared by the vendor and verify the documentation includes the following instructions for merchants and resellers/integrators: • that cryptographic material must be

removed • how to remove cryptographic material • that such removal is absolutely

necessary for PCI compliance

1.1.5.b Verify vendor provides a secure wipe tool or procedure to remove cryptographic material.

1.1.5 Securely delete any cryptographic key material or cryptogram stored by previous versions of the software. This could be cryptographic keys used for computation or verification of cardholder data or sensitive authentication data.

1.1.5.c Verify the secure wipe tool or procedure securely removes the cryptographic material.




1.1.6.a Examine the software vendor’s procedures for troubleshooting customers’ problems and verify the procedures include: • Collection of sensitive authentication

data only when needed to solve a specific problem

• Storage of such data in a specific, known location with limited access

• Collection of only a limited amount of data needed to solve a specific problem

• Encryption of sensitive authentication data while stored

• Secure deletion of such data immediately after use.

1.1.6.b Select a sample of recent troubleshooting requests from customers, and verify each event followed the procedure examined at 1.1.6.a.

1.1.6 Securely delete any log files, debugging files, and other data sources received from customers for debugging or troubleshooting purposes, to ensure that magnetic stripe data, card validation codes or values, and PINS or PIN block data are not stored on software vendor systems. These data sources must be collected in limited amounts and only when necessary to resolve a problem, encrypted while stored, and deleted immediately after use. PCI Data Security Standard 3.2

1.1.6.c Review the PABP Implementation Guide prepared by the vendor and verify the documentation includes the following instructions for resellers/integrators: • resellers/integrators must collect

sensitive authentication only when needed to solve a specific problem

• Resellers/integrators must store such data only in specific, known locations with limited access

• Resellers/integrators must collect only the limited amount of data needed to solve a specific problem

• Resellers/integrators must encrypt sensitive authentication data while stored

• Resellers/integrators must securely delete such data immediately after use.




2. Protect stored cardholder data

2.1 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed). Note: This requirement does not apply to those employees and other parties with a specific need to see full PAN; nor does the requirement supersede stricter requirements in place for displays of cardholder data (for example, for point of sale [POS] receipts).


2.1 Review displays of credit card data, including but not limited to POS devices, screens, logs, and receipts, to determine that credit card numbers are masked when displaying cardholder data, except for those with a specific need to see full credit card numbers.

2.2 Render PAN, at a minimum, unreadable anywhere it is stored, (including data on portable digital media, backup media, in logs, and data received from or stored by wireless networks) by using any of the following approaches:

• Strong one-way hash functions (hashed indexes)

• Truncation

• Index tokens and pads (pads must be

2.2.a Verify that the PAN is rendered unreadable anywhere it is stored, in accordance with PCI Data Security Standard 3.4.




securely stored)

• Strong cryptography with associated key management processes and procedures.

The MINIMUM account information that needs to be rendered unreadable is the PAN.


The PAN must be rendered unreadable anywhere it is stored, even outside the payment application.

2.2.b If the software vendor stores the PAN for any reason (for example, because log files, debugging files, and other data sources are received from customers for debugging or troubleshooting purposes), verify that the PAN is rendered unreadable in accordance with PCI Data Security Standard 3.4.

2.3 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system access control mechanisms (e.g. not using local system accounts). Decryption keys cannot be tied to local user accounts.


2.3 If disk encryption is used, verify that it is implemented in accordance with PCI Data Security Standard 3.4.1.a through 3.4.1.c

2.4 Application must protect encryption keys used for encryption of cardholder data against disclosure and misuse.


2.4 Verify the application protects encryption keys against disclosure and misuse, per PCI Data Security Standard 3.5.

2.5 Application must implement key management processes and procedures for keys used for encryption of cardholder data.


2.5 Verify the application implements key management techniques, per PCI Data Security Standard 3.6.

3. Provide secure password features.




3.1 Test the application to verify that unique usernames and complex passwords are required for all administrative access and for all access to cardholder data, in accordance with PCI DSS requirement 8.1, 8.2, and 8.5all.

3.1.b Test the application to verify the application does not use (or require the use of) default administrative accounts for other necessary software (e.g., the application must not use the administrative account for database software)

3.1 Application must require unique usernames and complex passwords for all administrative access and for all access to cardholder data.

PCI Data Security Standard 8.1 and 8.2

Note: These password controls are not intended to apply to employees who only have access to one card number at a time to facilitate a single transaction. These controls are applicable for access by employees with administrative capabilities, for access to servers with cardholder data, and for access controlled by the application.

3.1.c Examine PABP Implementation Guide created by vendor to verify the following: • Customers and resellers/integrators are

advised against using administrative accounts for application logins (e.g., don’t use the “sa” account for application access to the database).

• Customers and resellers/integrators are advised to assign strong passwords to these default accounts (even if they won’t be used), and then disable or do not use the accounts.

• Customers and resellers/integrators are advised to assign strong application and system passwords whenever possible.

• Customers and resellers/integrators are advised how to create PCI DSS-compliant complex passwords to access the payment application, per PCI Data Security Standard 8.5.8 through 8.5.15

3.2 Access to PCs, servers, and databases with payment applications must require a unique username and complex password.


3.2 Examine PABP Implementation Guide created by vendor to verify customers and resellers/integrators are advised to control access, via unique username and PCI DSS-compliant complex passwords, to any PCs, servers, and databases with payment applications and cardholder data.




3.3 Encrypt application passwords.


3.3 Examine application password files to verify that passwords are encrypted.

4. Log application activity 4.1 Application must log all user access (especially users with administrative privileges), and be able to link all activities to individual users.


4.1 Examine application settings to verify that application audit trails are automatically enabled or are available to be enabled by customers.

4.2 Application must implement an automated audit trail to track and monitor access.


4.2.a Examine application log parameters and verify that logs contain the data required in PCI Data Security Standard 10.2 and 10.3. 4.2.b If application log settings are configurable by the customer and resellers/integrators, or customers or resellers/integrators are responsible for implementing logging, examine PABP Implementation Guide prepared by the vendor to verify that customers are instructed on how to set PCI DSS-compliant log settings, per PCI Data Security Standard 10.2 and 10.3.

5. Develop secure applications




5.1 Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines. Review custom application code to identify coding vulnerabilities. Cover prevention of common coding vulnerabilities in software development processes, to include:


5.1 Obtain and review software development processes for any web-based applications. Verify the process includes training in secure coding techniques for developers, and is based on guidance such as the OWASP guidelines (http://www.owasp.org). Interview a sample of developers and obtain evidence that they are knowledgeable in secure coding techniques. For any web-based applications, verify that processes are in place to confirm that applications are not vulnerable to the following:

5.1.1 Unvalidated input. 5.1.1 Unvalidated input. 5.1.2 Broken access control (e.g., malicious use of user IDs).

5.1.2 Broken access control (e.g., malicious use of user IDs).

5.1.3 Broken authentication and session management (use of account credentials and session cookies).

5.1.3 Broken authentication and session management (use of account credentials and session cookies).

5.1.4 Cross-site scripting (XSS) attacks. 5.1.4 Cross-site scripting (XSS) attacks. 5.1.5 Buffer overflows. 5.1.5 Buffer overflows. 5.1.6 Injection flaws (e.g., SQL injection). 5.1.6 Injection flaws (e.g., SQL injection). 5.1.7 Improper error handling 5.1.7 Improper error handling 5.1.8 Insecure storage 5.1.8 Insecure storage 5.1.9 Insecure configuration management. 5.1.9 Insecure configuration management.

5.2 Develop software applications based on industry best practices and incorporate information security throughout the software development life cycle.


5.2 Obtain and examine written software development processes to verify that they are based on industry standards and that security is included throughout the life cycle. From an examination of written software development processes, interviews of software developers, and examination of relevant data (network configuration documentation, production and test data, etc.), verify that:

5.2.1 Testing of all security patches and system and software configuration changes before deployment

5.2.1 All changes (including patches) are tested before being deployed.




5.2.2 Separate development, test, and production environments

5.2.2 The test/development environments are separate from the production environment, with access control in place to enforce the separation

5.2.3 Separation of duties between development, test, and production environments

5.2.3 There is a separation of duties between personnel assigned to the development/test environments and those assigned to the production environment

5.2.4 Live PANs are not used for testing or development

5.2.4 Live PANs are not used for testing and development, or are sanitized before use

5.2.5 Removal of test data and accounts before production systems become active.

5.2.5 Test data and accounts are removed before a production system becomes active

5.2.6 Removal of custom application accounts, usernames, and passwords before applications are released to customers.

5.2.6 Custom application accounts, usernames, and passwords are removed before application is released to customers.

5.2.7.a Confirm the vendor performs code reviews, and that individuals other than the originating author of the code perform the reviews..

5.2.7 Review of custom code prior to release to customers, to identify any potential coding vulnerability.

5.2.7.b Confirm that code reviews occur for new code as well as for code changes

5.3.a Obtain and examine the vendor’s change-control procedures for software modifications, and verify that the procedures require items 5.3.1 – 5.3.4 below

5.3 Software vendor must follow change control procedures for all product software configuration changes. The procedures must include the following:

PCI Data Security Standard 6.4 5.3.b Examine recent software changes, and trace those changes back to related change control documentation. Verify that, for each change examined, the following was documented according to the change control procedures:

5.3.1 Documentation of impact 5.3.1 Verify that documentation of customer impact is included in the change control documentation for each change




5.3.2 Management sign-off by appropriate parties

5.3.2 Verify that management sign-off by appropriate parties is present for each change

5.3.3 Testing of operational functionality 5.3.3 Verify that operational functionality testing was performed for each change

5.3.4 Back-out procedures 5.3.4 Verify that back-out procedures are prepared for each change

5.4 Disable or remove unnecessary and insecure services and protocols (e.g., NetBIOS, file-sharing, Telnet, unencrypted FTP, and others). These services and protocols must not be used or required by the application.


5.4 Examine system services, daemons, and protocols enabled or required by the application. Verify that unnecessary and insecure services or protocols are not enabled by default or required by the application (for example, FTP is not enabled, or is encrypted via SSH or other technology).

5.5 Ensure that all web-facing applications are protected against known attacks by either of the following methods: • Having all custom application code

reviewed for common vulnerabilities by an organization that specializes in application security

• Installing an application-layer firewall in front of web-facing applications


Note: For PCI DSS, this method is considered a best practice until June 30, 2008, after which it becomes a requirement.

5.5 For web-based applications, ensure that one of the following methods are in place as follows. • Verify that custom application code is

periodically reviewed by an organization that specializes in application security; that all coding vulnerabilities were corrected; and that the application was re-evaluated after the corrections

• Verify that an application-layer firewall is in place in front of web-facing applications to detect and prevent web-based attacks



6. Protect wireless transmissions

6.1.a For wireless payment applications, and other wireless applications connected to cardholder data environments, verify that appropriate encryption methodologies implemented in accordance with PCI Data Security Standard 4.1.1.a.

6.1.b If WEP is used, verify it is used in accordance with in PCI Data Security Standard 4.1.1.b.

6.1 For wireless networks transmitting cardholder data, encrypt the transmissions by using WiFi Protected Access (WPA or WPA2) technology, IPSEC VPN, or SSL/TLS. Never rely exclusively on wired equivalent privacy (WEP) to protect confidentiality and access to a wireless LAN. If WEP is used, do the following: • Use with a minimum 104-bit encryption

key and 24 bit-initialization value. • Use ONLY in conjunction with WiFi

Protected Access (WPA or WPA2) technology, VPN, or SSL/TLS.

• Rotate shared WEP keys quarterly (or automatically if the technology permits)

• Rotate shared WEP keys whenever there are changes in personnel with access to keys.

• Restrict access based on media access code (MAC) address.


6.1.c If customer could implement the payment application into a wireless environment, examine PABP Implementation Guide prepared by vendor to verify customers and resellers/integrators are instructed on PCI DSS-compliant wireless settings, per PCI Data Security Standard 1.3.9, 2.1.1 and 4.1.1.



6.2 If wireless technology is used within the payment environment, it must be implemented securely.

PCI Data Security Standard 1.3.8 & 2.1.1

6.2 For wireless payment applications, and other wireless applications connected to cardholder data environments, verify that the wireless technology has been protected with a firewall configuration and that wireless vendor defaults have been changed per PCI Data Security Standard 1.3.8 and 2.1.1.

7. Test applications to address vulnerabilities.

7.1 Software vendors must establish a process to identify newly discovered security vulnerabilities (e.g., subscribe to alert services freely available on the Internet), to test their applications for vulnerabilities, and for timely development and deployment of security patches and upgrades. Updates and patches must be delivered in a secure manner with a known chain-of-trust. Any underlying software or systems that are provided along with the payment application (e.g., web servers) must

7.1.a Obtain and examine development processes to identify new vulnerabilities and implement corrections into software. Verify the processes include: Using outside sources for security

vulnerability information Testing of applications for new

vulnerabilities Delivery of patches and updates in a

secure manner with a known chain-of-trust Timely development and deployment of

patches to customers.



be included in this process.


7.1.b Verify that processes to identify new vulnerabilities and implement corrections into software apply to all software provided with the payment application (e.g., web servers).

8. Facilitate secure network implementation 8.1 The payment application must be able to be implemented into a secure network environment. Application must not interfere with use of network address translation (NAT), port address translation (PAT), traffic filtering network devices, anti-virus protection, patch or update installation, or encryption.

PCI Data Security Standard 1, 3, 4, and 5

8.1 Test the application in a lab to obtain evidence that it can run in a network with NAT, PAT, traffic-filtering devices, anti-virus software, and encryption. Verify that the application does not inhibit installation of patches or updates to other components in the environment.

9. Cardholder data must never be stored on a server connected to the Internet 9.1 The payment application must not require that the database server and web server be on the same server, or in the DMZ with the web server.

PCI Data Security Standard 1.3 and 1.3.4

9.1.a To verify that the application stores cardholder data in the internal network, and never in the DMZ, obtain evidence that the application does not require data storage in the DMZ, and will allow use of a DMZ to separate the Internet from systems storing cardholder data (e.g., application must not require that the database server and web server be on the same server, or in the DMZ with the web server).



9.1.b If customer could store cardholder data on a server connected to the Internet, examine PABP Implementation Guide prepared by vendor to verify customers and resellers/integrators are told not to store cardholder data on Internet-accessible systems (e.g., web server and database server must not be on same server.)

10. Facilitate secure remote software updates 10.1 If software updates are delivered via remote access into customers’ systems, software vendors must tell customers to turn on modem only when needed for downloads from vendor, and to turn off immediately after download completes. Alternatively, if delivered via VPN or other high-speed connection, software vendors must advise customers to properly configure a personal firewall product to secure “always-on” connections.

PCI Data Security Standard 1.3.9 and 12.3.9

10.1 If the vendor delivers software and/or updates via remote access to customer networks, examine PABP Implementation Guide prepared by vendor, and verify it contains: Instructions for customers and

resellers/integrators regarding secure modem use, per PCI Data Security Standard 12.3.

Recommendation for customers and resellers/integrators to use a personal firewall product if computer is connected via VPN or other high-speed connection, to secure these “always-on” connections, per PCI Data Security Standard 1.3.10.

11. Facilitate secure remote access to application 11.1 The payment application must not interfere with use of a two-factor authentication mechanism. The application must allow for technologies such as RADIUS or TACACS with tokens, or VPN with individual certificates.


11.1 Test the application in a lab to obtain evidence that it can run with a two-factor authentication mechanism (the application must not prohibit an organization’s ability to implement two-factor authentication).



11.2 Remote access must be authenticated using a two-factor authentication mechanism.


11.2 If the payment application may be accessed remotely, examine PABP Implementation Guide prepared by the software vendor, and verify it contains instructions for customers and resellers/integrators regarding required use of two-factor authentication (username and password and an additional authentication item such as a token or certificate).

11.3 If vendors, resellers/integrators, or customers can access customers’ applications remotely, the remote access software must be implemented securely.


11.3.a If the software vendor uses remote access software for remote access to the customers’ application, verify that vendor personnel implement and use remote access software security features. See example below at 11.3.b.



11.3.b If resellers/integrators or customers can use remote access software, examine PABP Implementation Guide prepared by the software vendor, and verify that customers and resellers/integrators are instructed to use and implement remote access software security features. For example: Change default settings in the remote

access software (for example, change default Passwords and use unique Passwords for each customer)

Allow connections only from specific (known) IP/MAC addresses

Use strong authentication or complex Passwords for logins

Enable encrypted data transmission Enable account lockout after a certain

number of failed login attempts Configure the system so a remote user

must establish a Virtual Private Network (“VPN”) connection via a firewall before access is allowed

Enable the logging function Restrict access to customer Passwords to

authorized reseller/integrator personnel Establish customer Passwords according

to PCI DSS requirements 8.1, 8.2, 8.4, 8.5.

12. Encrypt sensitive traffic over public networks.



12.1 Use strong cryptography and security protocols such as secure sockets layer (SSL) / transport layer security (TLS) and, internet protocol security (IPSEC)) to safeguard sensitive cardholder data during transmission over open, public networks. Examples of open, public networks that are in scope of the PCI DSS are the Internet, WiFi (IEEE 802.11x), global system for mobile communications (GSM), and general packet radio service (GPRS).


12.1 If the application allows data transmission over the Internet, examine PABP Implementation Guide prepared by the vendor, and verify the vendor recommends use of SSL for secure data transmission in accordance with PCI DSS requirement 4.1.

12.2.a If the application allows and/or facilitates sending of PANs by e-mail, verify that an e-mail encryption solution is provided.

12.2 The application must never send unencrypted PANs by e-mail.

PCI Data Security Standard 4.2 12.2.b If the application allows and/or facilitates the sending of PANs by e-mail, examine the PABP Implementation Guide prepared by the vendor, and verify the vendor includes directions for customers and resellers/integrators to use an email encryption solution.

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


Telnet or rlogin must never be used for non-console administrative access.

13.1 If application or server allows non-console administration, examine the PABP Implementation Guide prepared by vendor, and verify vendor recommends use of SSH, VPN, or SSL/TLS for encryption of non-console administrative access.

14. Maintain instructional documentation and training programs for customers, resellers, and integrators.



14.1 Develop, maintain, and disseminate a PABP Implementation Guide(s) for customers, resellers, and integrators that accomplishes the following:

14.1 Examine the PABP Implementation Guide and related processes, and verify the guide is disseminated to all relevant application users (including customers, resellers, and integrators).

14.1.1 Addresses all requirements in this document wherever the PABP Implementation Guide is referenced.

14.1.1 Verify the PABP Implementation Guide covers all related requirements in this document.

14.1.2 Includes a review at least annually and updates to keep the documentation current with software changes as well as with changes to the requirements in this document.

14.1.2 Verify the PABP Implementation Guide is reviewed on an annual basis and updated for changes to software and for changes to the requirements in this document.

14.2.a Examine the training materials and communication program for resellers and integrators, and confirm the materials cover all items noted for the PABP Implementation Guide throughout this document

14.2.b Examine the training materials for resellers and integrators and verify the materials are updated on an annual basis and when new software versions are released.

14.2 Develop and implement training and communication programs to ensure software resellers and integrators know how to implement the application software and related systems and networks in a PABP-compliant manner. Update the training on an annual basis and whenever new software versions are released.

14.2.c Select a sample of resellers and integrators and interview them to verify they received the training materials.

PCI - CISP Regulations Visa USA - 11.08.pdfPCI - CISP Regulations Visa USA - 11.08.pdfPCI - CISP Regulations Visa USA - 11.08.pdfCISP Regs.pdf

Visa_Payment_Application_Best_Practices_(PABP)[1].pdfvisa.comPayment Applications | Merchants | Visa USA

Visa_Payment_Application_Best_Practices[1].pdf

JIHMDAFDEKIFDENGNLFHLMAIOCMECHKP: form1: x: f1: f2: usaf3: f4: 0f5: 1f6: usa

f7:

visa data security compliance programs - cisp... · 2020. 6. 18. · the pci dss was developed by...

Documents