A MERCHANTS GUIDE TO THE PAYMENT APPLICATION DATA SECURITY STANDARD (PA-DSS)

Transcription

1 A MERCHANTS GUIDE TO THE PAYMENT APPLICATION DATA SECURITY STANDARD (PA-DSS) The mandatory guide for storing, processing or transmitting cardholder information

2 Overview and applicability Any application that stores, processes, or transmits cardholder data falls within the scope of the Payment Card Industry Data Security Standards (PCI DSS). If this application is sold to 3rd parties it falls within the compliance program known as Payment Application Data Security Standard or PA-DSS (formally known as Visa's Payment Application Best Practices [PABP]). The goal of PA-DSS is to help software vendors and others develop secure payment applications that do not store prohibited data, such as full magnetic stripe, CVV2 or PIN data, and ensure their payment applications support compliance with the PCI DSS. It is important to note that PA-DSS validated payment applications alone do not guarantee PCI DSS compliance and that the validated payment application must be implemented in a PCI DSS compliant environment. If you are a merchant it is your responsibility to ensure you use PA-DSS compliant payment software, but it is the software developers responsibility to ensure it is built to meet the standard. In scope Payment applications that are sold, distributed or licensed to third parties are subject to the requirements of PA-DSS. Out of scope In-house payment applications developed by merchants or service providers that are not sold to a third party are not subject to the PA-DSS requirements, but must still be secured in accordance with the PCI DSS. What does PA-DSS Compliance involve? PA-DSS ensures that the payment software is compliant with 14 specific requirements (similar to PCI DSS). Some of the headings you may recognise from PCI DSS and each requirement have sub sections. The headline requirements are: 1. Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CVC2, CVV2), or PIN block data Ensure that Sensitive Authentication Data is not stored and securely deleted 2. Protect stored cardholder data Render the card number unreadable where it is stored and key management 3. Provide secure authentication features Must facilitate the use of unique IDs and passwords 4. Log payment application activity Produce an audit log of user access 5. Develop secure payment applications Payment applications must be designed in line with PCI DSS and Industry best practices 6. Protect wireless transmissions If wireless permitted must be implemented in line with PCI DSS and industry best practices. 7. Test payment applications to address vulnerabilities Software vendors must establish a process to identify newly discovered security vulnerabilities and have timely development and deployment of security patches and upgrades

3 8. Facilitate secure network implementation The application must not interfere with use of devices, applications, or configurations required for PCI DSS compliance. For example, payment application cannot interfere with anti-virus protection 9. Cardholder data must never be stored on a server connected to the Internet The payment application must be developed such that the database server and web server are not required to be on the same server 10. Facilitate secure remote software updates If payment application updates are delivered via remote access into customers systems, software vendors must tell customers to turn on remote-access technologies only when needed for downloads from vendor, and to turn off immediately after download completes. 11. Facilitate secure remote access to payment application If vendors or customers can access customers payment applications remotely, the remote access must be implemented securely. 12. Encrypt sensitive traffic over public networks If the payment application sends, or facilitates sending, cardholder data over public networks, the PA must support use of strong cryptography and security protocols 13. Encrypt all non-console administrative access If payment application or server allows non-console administration, the vendor recommends use of SSH, VPN, or SSL/TLS for encryption of non-console administrative access. 14. Maintain instructional documentation/training programs for customers, resellers, and integrators The Vendor must develop, maintain, and disseminate a PADSS Implementation Guide(s) for its customers Is the PA-DSS mandatory? Yes. If you are in scope of the PA-DSS, there is a mandatory requirement to achieve compliance. If you use a payment application there are key deadline dates to note. Please contact the Payment Security team at paymentsecurity@worldpay.co.uk and we can discuss them with you. Who mandates security review and approval of payment applications? The PCI Security Standards Council (PCI SSC) has established the guidelines and the Card Schemes (Visa Europe and MasterCard) serve as the source of enforcement. Processors, Acquirers and manufacturers are the mechanisms by which the regulations will be implemented. What protection does a PA-DSS application provide? Applications that have successfully completed a PA-DSS audit are certified to not retain or compromise what is considered to be secure elements of the card s track data [full magnetic stripe data, card validation codes and values (CAV2, CID, CVC2, and CVV2), PINs and PIN blocks. A PA-DSS certified application can also facilitate merchants in meeting a number of requirements included in PCI DSS. In particular;

4 R1: Don t retain full magnetic stripe, card validation code/value (SAD), or PIN block data R2: Do not use computer passwords that have been provided by external suppliers R3: Protect stored cardholder data R4: Encrypt transmission of cardholder data across open, public net-works R6: Develop and maintain secure systems and applications R7: Restrict access to cardholder data by business need-to-know R10: Regularly check who accesses your computers and cardholder data that you hold R12: Create/maintain own security policy to ensure you remain compliant with PCI DSS For further clarification and guidance it is always advisable to make contact with a Payment Application Qualified Security Assessor (PA-QSA). For a full list of approved assessors please visit the official Security Standard Councils website - Benefits of using PA-DSS software include: Prevents storage of sensitive cardholder data Reduces opportunities for compromise and misuse Ensures payment solutions meet the highest levels of security Supports merchants PCI DSS compliance Where can I find more information on PA-DSS? You can contact your payment software supplier or you should engage with a PA-QSA for more detailed information and specific requirements for your business. If you are already using a QSA to confirm compliance, speak to them about PA-DSS too. The PCI Security Standards Council (PCI SSC) is also a reliable place to read more detail on PA-DSS. Some useful links include: Guide to whether PA-DSS applies to a given payment application: PA-DSS does apply to payment applications that are typically sold and installed off the shelf without much customisation by software vendors. PA-DSS does apply to payment applications provided in modules, which typically includes a baseline module and other modules specific to customer types or functions, or customised per customer request. PA-DSS may only apply to the baseline module if that module is the only one performing payment functions (once confirmed by a PA-QSA). If other modules also perform payment functions, PA-DSS applies to those modules as well. Note that it is considered a best practice for software vendors to isolate payment functions into a single or small number of baseline modules, reserving other modules for non-payment functions. This best practice (though not a requirement) can limit the number of modules subject to PA-DSS. PA-DSS does NOT apply to payment applications offered by application or service providers only as a service (unless such applications are also sold, licensed, or distributed to third parties) because:

5 1. The application is a service offered to customers (typically merchants) and the customers do not have the ability to manage, install, or control the application or its environment; 2. The application is covered by the application or service provider s own PCI DSS review (this coverage should be confirmed by the customer); and/or 3. The application is not sold, distributed, or licensed to third parties. Examples of these software as a service payment applications include: Those offered by Application Service Providers (ASP) who host a payment application on their site for their customers use. Note that PA-DSS would apply, however, if the ASP s payment application is also sold to, and implemented on, a third-party site, and the application was not covered by the ASP s PCI DSS review. Virtual terminal applications that reside on a service providers site and are used by merchants to enter payment transactions. Note that PA-DSS would apply if the virtual terminal application has a portion that is distributed to, and implemented on, the merchant s site, and was not covered by the virtual terminal provider s PCI DSS review. PA-DSS does NOT apply to non-payment applications that are part of a payment application suite. Such applications (e.g. a fraud-monitoring, scoring, or detection application included in a suite) can be, but are not required to be, covered by PA-DSS if the whole suite is assessed together. However, if a payment application is part of a suite that relies on PA-DSS requirements being met by controls in other applications in the suite, a single PA-DSS assessment should be performed for the payment application and all other applications in the suite upon which it relies. These applications should not be assessed separately from other applications they rely upon since all PA-DSS requirements are not met within a single application PA-DSS does NOT apply to a payment application developed for and sold to only one customer since this application will be covered as part of the customer s normal PCI DSS compliance review. Note that such an application (which may be referred to as a bespoke ) is sold to only one customer (usually a large merchant or service provider), and it is designed and developed according to customer-provided specifications. PA-DSS does NOT apply to payment applications developed by merchants and service providers if used only in-house (not sold, distributed, or licensed to a third party), since this in-house developed payment application would be covered as part of the merchant s or service provider s normal PCI DSS compliance.