Draft - pabp/pci faq
I wanted to post this out here for anyone that was interested in learning more about PABP/PCI and how it impacts AspDotNetStorefront. This is still a draft document, so don't shoot me for spelling/grammatical errors just yet. It contains a lot of good information however, and there has been a lot of talk lately regarding the subject, so I wanted to post this as soon as possible.
******************DRAFT******************
Frequently Asked Questions: PCI Security Standards Council Compliance
This document is intended to be used to answer common questions regarding PCI-DSS and PA-DSS/PABP. It is not intended, and should not be used as, a comprehensive compliance or decision-making guide. AspDotNetStorefront recommends contacting a certified auditor to discuss the specific requirements for your implementation. AspDotNetStorefront is not liable for errors, omissions, or damages caused by using the information contained within this or other documents published by AspDotNetStorefront.
What are the differences between PCI-DSS, PA-DSS, and PABP?
To summarize the differences, PCI-DSS primarily impacts the overall environment that the payment processing system is deployed in, and is the responsibility of the merchant and (if applicable) hosting provider. PA-DSS outlines requirements for developing secure commercial software applications that handle payment information, and is primarily the responsibility of the commercial payment application developer.
Both the PCI-DSS and PA-DSS are standards published by the PCI SSC (Payment Card Security Standards Council) and adopted by many payment card providers (such as Visa and MasterCard) for the purpose of minimizing the risk of theft and loss of sensitive payment card information. Although both standards have overlapping scopes, there are significant differences between PCI-DSS and PA-DSS.
PCI-DSS (often referred to when service providers, application vendors, and merchants discuss PCI compliance) is a blanket security standard that is primarily (though not specifically) concerned with the end-to-end payment card data processing environment. For example, PCI-DSS sets out requirements for things such as wireless network security, utilization of anti-virus and proper patching/maintenance of servers, proper physical access controls to prevent the theft of sensitive data, network segmentation, storage of hard-copy credit card information, and proper encryption and handling of backup media containing sensitive date.
PA-DSS differs from PCI-DSS in that it sets out specific requirements for application vendors as best practices for developing secure applications. These include encryption of payment information when stored in the database, implementing secure access controls into your application, preventing application errors from disclosing sensitive data, allowing fine-grained control of who can and cannot view credit card data, logging administrative users that view credit data, etc. PA-DSS also requires that software vendors follow a very strict and well-documented SDLC (software development lifecycle) and includes provisions for things such as peer review of sensitive code changes, separation of development, QA, and production environments, and security breach testing, research, and notification procedures. Simply put, PA-DSS not only defines secure coding practices, but also requires the software vendor to make a company-wide commitment to secure application development.
PABP stands for Visa Payment Application Best Practices. The PCI SSC assumed responsibility for PABP in 2008 and changed the name to PA-DSS. Although some changes were made as a result of the PCI SSC assuming the standard from Visa, payment applications certified against PABP are grandfathered into PA-DSS compliance for a time period dependent upon the version of PABP they were certified against. Specifically, applications that were certified against PABP versions prior to 1.3 are not recommended for new deployments, whereas applications certified against PABP v1.3 or later are considered acceptable for new deployments. AspDotNetStorefront ML 7.2 and 8.0 are certified against PABP v1.4, making them completely acceptable for new software deployments. From here out, we will use the term PA-DSS.
Am I required to use a PA-DSS compliant payment application?
Ultimately this depends on your merchant account provider and the types of payment cards you are accepting, but in short, yes. In 2007, Visa published a document outlining requirements for merchants to use PABP-compliant payment applications.
Beginning January 1, 2008, Visa will implement a series of mandates to eliminate the use of non-secure payment applications from the Visa payment system. These mandates require acquirers to ensure their merchants and agents do not use payment applications known to retain prohibited data elements and require the use of payment applications that adhere to Visa’s Payment Application Best Practices (PABP).
According to this document, all newly board level three or level four merchants (meaning merchants attempting to acquire a new merchant account) must either demonstrate PCI compliance before obtaining the account, or utilize an application that is PABP compliant as of October 1st, 2008. As of July 1st, 2010, ALL merchants, processors, and agents MUST use a PABP compliant application.
While you may be able to obtain a merchant account now by demonstrating PCI compliance, this is a short term solution.
Does using a PABP or PA-DSS compliant application automatically mean I am PCI compliant as well?
PCI compliance (more accurately, PCI-DSS compliance) requires more than just using a PA-DSS or PABP compliant payment application. Using a PA-DSS compliant application is a critical part of achieving PCI compliance, however there are additional requirements that a merchant must fulfill. A full compliance guide and other helpful information can be downloaded directly from the PCI SSC at http://www.pcisecuritystandards.org.
If I use a PABP or PA-DSS compliant application, am I required to be PCI compliant as well?
Every single merchant, regardless of size or processing volume, is required to be PCI compliant. Using a PABP or PA-DSS compliant payment application helps prevent unnecessary delays when applying for a merchant account, but does not circumvent a merchant’s responsibility to comply with all PCI-DSS requirements.
What happens if I am not compliant or use a payment application that stores prohibited data and there is a breach?
The payment card provider may levy fines against a merchant if the merchant does not comply with security requirements, or if the merchant fails to rectify a known security issue. Compliance fines differ based upon the type of breach and the payment card issuer. TJX and Fifth Third Bancorp paid fines and compensation of more than $2.2 million dollars following the theft of data impacting nearly 100 million customers.
Merchants may also be open to civil litigation from affected parties. For example, B.J.’s Wholesale club was subject to a highly publicized security breach in 2004 which led to a $5.7 million lawsuit against B.J.’s as a result of the breach.
What can I do as a merchant to limit my risk?
First and foremost, educate yourself regarding PA-DSS and PCI-DSS requirements. The PCI SSC has published both standards on their website at http://www.pcisecuritystandards.org. Many of the standards are highly technical and require IT and/or software development expertise to understand and implement. AspDotNetStorefront therefore recommends working with a reputable IT and/or software development firm to help you properly configure your software and environment if you do not possess this expertise in-house.
Secondly, use a PABP (v1.3 or greater) or PA-DSS certified payment application. This helps ensure that you are utilizing software that facilitates PCI compliance and was developed in accordance with PA-DSS standards.
What merchant level am I considered and what are the validation requirements?
See the following websites to determine your merchant level and see validations requirements:
VISA: http://usa.visa.com/merchants/risk_m...merchants.html
MasterCard: http://www.mastercard.com/us/sdp/mer...nt_levels.html
Which AspDotNetStorefront applications are PA-DSS compliant?
AspDotNetStorefront ML version 7.x and 8.x are PABP certified payment applications. In addition, AspDotNetStorefront ML/Express and AspDotNetStorefront ML/64 utilize 100% of the certified AspDotNetStorefront ML engine.
What can I do to limit my exposure to PCI compliance requirements?
PCI-DSS and PA-DSS apply to any application or environment that accepts, stores, processes, or transmits payment card information. By not performing any of these tasks, you limit your exposure to PCI requirements.
Specifically, to achieve this within AspDotNetStorefront, you would utilize a payment processor that provides what is referred to as a “boomerang” interface. This type of interface separates the payment environment from the shopping cart environment by taking the end-customer completely off of your website, and onto the payment processor’s website, during the checkout process.
A common example of this with which most merchants are familiar is PayPal Website Payments Standard. The end-customer adds items to their cart on your website. When they choose to check out, they click a link or button that takes them to the PayPal Website. While on the PayPal Website, the customer provides their payment information, PayPal processes the transaction, and then sends only the status of the transaction back to your website. The customer never enters any sensitive payment data directly on your site, and so the security requirements are vastly reduced. It is important to keep in mind however that this merely shifts the burden of compliance to the website or application ultimately processing the transaction. It is therefore important for you as a merchant to verify that the processor you are using complies with PA-DSS and PCI-DSS requirements.
AspDotNetStorefront supports “boomerang” interfaces from PayPal (both Website Payments Standard and PayPal Express Checkout), GoogleCheckout, OGone, WorldPay, 2Checkout, and is currently developing secondary integrations with Amazon Payment Systems, Authorize.NET, and Cybersource.
Are there disadvantages to using a “boomerang” gateway?
Boomerang gateways are typically much more complex than API integration-based gateways due to the increased amount of data that must be transferred to the payment processor. There is also a slightly increased risk of failure due to communication errors between the processor’s website and the AspDotNetStorefront application. There are also increased development and support costs due to the complexity of the integration.
The biggest disadvantage to using a “boomerang” interface is that the end-customer’s shopping experience is much less seamless when compared to a fully integrated API-based gateway. When using a “boomerang” gateway, the customer is taken completely off of your website to process payment. This means that they are going to be taken to a completely different site with a different URL, and most likely a different look and feel than your website. The result is that you can confuse or scare the end-customer, causing them to abandon the cart. Even if the payment is processed successfully, there is a risk that the customer will get “lost” and not return to your site after the purchase, meaning that the order may be left “in limbo,” or the customer will not receive the usual order confirmations.
These tend to be worst case scenarios, but nonetheless are important to note. Also keep in mind that just because a gateway supported by AspDotNetStorefront has a “boomerang” interface available, it does not mean that we support that interface. Many gateways have multiple methods of integration, so if the integration method is a deciding factor, please verify with our sales department first.
If I am using a “boomerang” gateway, do I still need an SSL certificate on my website?
AspDotNetStorefront strongly recommends having an SSL certificate from a trusted provider such as Thawte, Verisign, GeoTrust, or Comodo installed on your website at all times even if you are not processing payment information and are not specifically required to by PCI. First, many “boomerang” interfaces require SSL to make secure callbacks to your website. Secondly, customers will still be entering usernames, passwords, addresses, and other private data about themselves on your site, so you will want to ensure that is protected in transit, especially considering that this includes your administrative login credentials. Lastly, many consumers are trained to look for the “lock” in their browser ensuring them that the site is secure. If they don’t see this by the time they reach checkout, there is an increased risk of abandonment due to security and confidentiality concerns.
If I am not storing card numbers (PANS) am I still impacted by PCI requirements?
Storage of card numbers is only one aspect of securing sensitive payment information. Unless you are using a “boomerang” style gateway, you are still collecting and transmitting payment card information, meaning that you are fully affected by PCI-DSS and PA-DSS requirements.
Does AspDotNetStorefront recommend storing card numbers (PANS)?
AspDotNetStorefront strongly recommends AGAINST storing primary account numbers. In addition, AspDotNetStorefront as shipped will NEVER store CVV/CID codes per PA-DSS requirements. The rationale behind this is very simple. While AspDotNetStorefront always encrypts credit card numbers that are stored, thieves cannot steal and potentially decrypt what does not exist. By eliminating credit card number storage whenever possible, you decrease your potential exposure should there be a breach.
Modern payment gateway interfaces almost never require the storage of credit card numbers by the merchant. It is therefore possible for AspDotNetStorefront to securely send the credit card information to the payment gateway for processing, obliterate the card number immediately, and simply store the transaction id for the successful authorization or capture that the payment gateway returns. The transaction id can then be used for subsequent actions, such as voiding or refunding that order. Some payment gateways even support similar operations for recurring transactions, such as subscription services.
I process my transactions offline, and therefore need to store the PAN and CVV/CID. Does AspDotNetStorefront support this?
AspDotNetStorefront NEVER stores the CVV/CID code. Storage of this data is strictly prohibited. Payments can generally still be processed without this information, however you will be charged a higher transaction fee.
AspDotNetStorefront does support storage of credit card numbers, but only if the end-customer elects to have their card number stored. It is therefore recommended to utilize a gateway that supports online transaction processing. AspDotNetStorefront supports over three dozen of these gateways.
Merchant accounts tend to have different rates for different processing environments, such as card-present (where the customer hands a clerk their card to process the payment) versus card-not-present (where a customer provides their card number over the phone or internet). It is important to note that processing an online transaction as if it were a card-present sale is a violation of your merchant account agreement.
I couldn’t find AspDotNetStorefront on the PA-DSS list published on the PCI-SSC website. Does this mean that AspDotNetStorefront is not compliant?
AspDotNetStorefront was certified under PABP version 1.4, and is included in Visa’s list of PABP certified payment applications under Discovery Productions, Inc. This list can be downloaded from: http://usa.visa.com/download/merchan...plications.pdf
At the time of this writing, PCI SSC has accepted our filing for version 8.0 however the listing has not yet been updated by PCI SSC.
Where can I receive documentation that AspDotNetStorefront ML is PABP/PA-DSS compliant?
AspDotNetStorefront’s validation status is published in the Visa List of PABP Validated Payment Applications available at: http://usa.visa.com/download/merchan...plications.pdf
If I modify AspDotNetStorefront source code, is the application still PA-DSS compliant?
This is completely dependent upon the source code you make changes to, and the manner in which they are made. Whether the change would impact PA-DSS compliance or not would likely be up for interpretation by an auditor. Generally, if you make changes to the application, it is no longer seen as a commercial software application and would instead be validated as part of your PCI compliance audit. Only commercial applications are required to be PA-DSS certified.
Does PA-DSS compliance make AspDotNetStorefront a better product?
While AspDotNetStorefront has always been committed to building a secure and stable application, PA-DSS compliance ensures you that we are following industry-accepted best practices throughout the entire development lifecycle. AspDotNetStorefront makes no differentiation between its products during development, and therefore even non-PA-DSS validated versions of AspDotNetStorefront benefit from increased security focus and stringent QA procedures we adhere to in order tomaintain our compliance.
References:
Visa USA, “Visa Announces New Payment Application Security Mandates,” http://usa.visa.com/download/merchan...y_mandates.pdf, October 23, 2007
Visa USA, “Cardholder Information Security Program – CISP Overview,” http://usa.visa.com/merchants/risk_m..._overview.html
Ross Kerber, “Visa fines Ohio Bank in TJX Data Breach,” The Boston Globe, http://www.boston.com/business/globe...x_data_breach/, November 24, 2007
Steven P. Galante, “Aftermath of a Security Breach,” Boston Business Journal, http://www.bizjournals.com/boston/st...0club%20breach, June 3, 2005
******************DRAFT******************
Copyright © 2012, AspDotNetStorefront. All rights reserved.