One typical question NetSPI receives from IT managers is “What does PA-DSS entail?” Hopefully, this will give you some answers.
PA-DSS
PA-DSS is a set of security practices and requirements developed by the PCI Security Standards Council to “…enhance payment account data security by driving education and awareness of the PCI Security Standards.[1]” 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. Payment applications that are sold, distributed or licensed to third parties are subject to the PA-DSS requirements.[2]
By ensuring the compliance of your application with PA-DSS requirements, your company helps facilitate its customers’ PCI DSS compliance.
NetSPI’s Answer
NetSPI has developed a program guide to assist your company in getting payment applications validated. This guide prepares a company to get ready for the audit and allows them to better understand the requirements of the different pieces of the audit. These include the documentation requirements for the implementation guide, troubleshooting procedures, SDLC documentation including change control, vulnerability and software patching procedures and the training materials that are required. It also goes into the topic of the interviews that will occur as well as the testing of the application.
What the program guide does not do is tell the different people in the company what is expected of them before the audit, during audit and after the audit.
This validation process can be simple and easy or it can be long and tedious. Work with your auditor to get through the process, they have the experience to get you through the process.
Before the Audit
As a manager, there are processes that have to be planned for and started before the auditors come into your office to start the audit process. The application has to meet the PCI requirements, which include:
Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CVC2, CVV2), or PIN block data
Protect stored cardholder data
Provide secure authentication features
Log payment application activity
Develop secure payment applications
Protect wireless transmissions
Test payment applications to address vulnerabilities
Facilitate secure network implementation
Cardholder data must never be stored on a server connected to the Internet
Facilitate secure remote software updates
Facilitate secure remote access to payment application
Encrypt sensitive traffic over public networks
Encrypt all non-console administrative access
Maintain instructional documentation and training programs for customers, resellers, and integrators
In addition to the application requirements, the documentation has to also be ready.The list of documentation includes:
Implementation guide – The most important document without which testing cannot start
Typical network deployment diagram and data flow diagram
Documentation of remote transmission of cardholder data, such as IPSec, TLS, SSL
New security vulnerabilities identification process/policy documentation
In many instances, use of specific language within policies is required. For example, the implementation guide requirements include required language, such as “Historical data (magnetic stripe data, card validation codes, PINs, or PIN blocks) MUST be removed for PCI compliance.” This wording is required by the PCI Council and if not included, can provide sufficient grounds for the rejection of the Report on Validation (ROV). NetSPI’s PA-DSS Program Guide has been developed expressly with intent of showing such working requirements.
As shown in the list above, documentation requirements are not limited to the implementation guide and need to be completed before a ROV can be filed. It’s not enough to have processes in place, such as the security coding standards; they need to be formally documented. Make sure to review the documentation requirements to make sure they are up to date.
The last but far from the least important part of the pre-audit process is to educate your employees on the PCI Council’s requirements for a payment application. They need to know that these requirements are not an optional part of the application and that they may be interviewed during the course of the audit. All team members should be familiar with established standards such as the SDLC documentation as well as be aware of the troubleshooting requirements as described in the process documentation.
Next Steps
The next blog entry will talk about what to expect during and after the audit.
Healthcare executives are concerned with a broad array of regulatory and compliance-related issues. Many of those concerns are focused on patient health, government oversight and regulation, HITECH and meaningful use, financial cost controls, and even on credit card security. That last item might not be a complete surprise, but I suspect that, for many of you, it is way down on the priority list.
It’s an understandable approach given the magnitude of your other concerns, but it is a decision that may come to haunt you, particularly given the emphasis that card brands (VISA, MasterCard, American Express, Discover, and JCB) have put on credit card security and the focus that they have been bringing to the healthcare field. Retailers have been struggling with credit card security for years, but the card brands have started to cast a wider net, and healthcare has become a primary focus for PCI compliance.
I am sure that you are aware of the Payment Card Industry Data Security Standards (PCI DSS), a very broadly applicable security standard that concerns itself with all aspects and environments that deal with credit card information. What you might not be fully aware of (or may not fully understand the implications of) is the Payment Application Data Security Standard (PA-DSS.) This standard is managed by the same organization that manages the PCI DSS and, with some important due dates having recently passed us by, healthcare software companies are only just starting to “wake up” to the fact that they may have to worry about PA-DSS. In this pair of articles I attempt to do three things:
Provide a brief overview of PA-DSS and why it came into existence.
Help you understand why you should know and care about the PA-DSS.
Provide you some steps that you can take to make sure your vendors are addressing PA-DSS
What is the PA-DSS?
To provide a bit of context, it’s important to understand where the PA-DSS originated. PA-DSS was born from a previous program known as the PABP, or the Payment Application Best Practices program. The PABP program was a voluntary program created and administered by VISA that would allow application vendors to have a third-party assessor validate that their applications were built using security industry best practices. The PABP was a program that didn’t have a lot of teeth, wasn’t overly prescriptive, and wasn’t mandated by VISA, so only a handful of companies (mostly retail-focused) bothered to go through the process – almost entirely for marketing purposes.
In 2008, the PCI Security Standards Council (the organization created by the major credit card brands to administer the PCI DSS) was asked to take over the PABP program and align it fully with the PCI DSS. The outcome of that effort is the PA-DSS, which translates the requirements of the PCI DSS into a standard that application companies follow to ensure that they are providing an application that their clients can utilize in a PCI DSS-compliant manner. The PA-DSS is a very, very detailed standard whose requirements span documentation, technology, architecture, coding practices, process, lab testing, and a full SDLC investigation to provide a complete assessment of the security of the application.
These dual standards did create some confusion for organizations concerned with or subject to the PCI DSS. Anyone accepting a credit card needs to be PCI DSS-compliant, but they didn’t have to use PA-DSS validated applications (a standard administrated by the same council.) To make their own position clear, VISA stepped forward and stated that they required the use of PA-DSS validated applications for organizations processing VISA transactions. As VISA accounts for the largest volume of credit card transactions in the United States, their stance on PA-DSS certainly carries a lot of weight.
Now, you may be thinking, ‘why all of this concern over a standard that is so focused on payment applications’? The concern within the healthcare community comes from the definition of “payment application” – the PCI SSC has declared that, if an application fits certain criteria, it is considered a payment application, regardless of industry or the primary focus of the application. The criteria can be boiled down to:
Does the application transmit, store, or process cardholder data? (i.e., does it touch relevant credit card information?)
Is the application sold, licensed, or distributed to third parties? (i.e., it’s not an application that you developed internally or had custom developed for your organization)
An FAQ on the PA-DSS program and its requirements is located on the PCI SSC’s website but, if you consider just the two points above, this standard covers a lot of application solutions within the healthcare space. Basically, any software application that deals with credit card data, even if it’s the most ancillary aspect of that software’s functionality, is subject to the PA-DSS.
Why Should I Care?
So, why should you care? Well, first of all, because VISA has mandated that every merchant (i.e., any organization taking a credit card for payment) must use PA-DSS-validated applications after a particular date. That date was July 1st of 2010 (yes, we’re already past the mandated date.) VISA has indicated that acquirers (the organizations that process credit card transactions) “must take prompt action to move all merchants and agents to PA-DSS-validated applications” and, although they have not at this point documented consequences for non-compliance, typical consequences could include fines, higher interchange rates, or a straight refusal from VISA to process any of your transactions. Also, as VISA works through the acquirer, not with you directly, your acquirer might simply cut you off from processing any credit card transactions.
A second reason to care is that you may already be contractually obligated to address both PCI DSS and PA-DSS. Many payment processors already include provisions for your PCI DSS compliance in their contracts, but, given the pressure from VISA, PA-DSS requirements are starting to show up as well. That means that utilizing PA-DSS compliant applications for managing and accepting payment may be a requirement for taking any credit card, not just VISA-branded cards. Even if a processor doesn’t restrict card acceptance, it may impose a penalty in the form of a higher interchange rate to cover their own exposure to potential security ramifications or action by VISA.
The third reason (although not the least important) you should care is that this is an issue which may have a material impact on your organization, but is largely out of your direct control. You cannot have someone validate the software that you use in your facility (unless you are utilizing internally developed or fully customized applications) – the process needs to be initiated by the software vendor, the documentation updates need to be done by the vendor, the testing needs to be done on specific revisions of the applications, etc. You can’t fix this problem no matter how good you are at making your environment and facility secure. This is the responsibility of the application vendor, but it has the potential to have a significant impact on your organization’s ability to accept credit card payments.
I’ll elaborate a little further in the next section, but action needs to be taken to get your vendors moving in the right direction on PA-DSS. In the retail community, it took retailers screening vendors for PA-DSS and building PA-DSS into contracts for application companies to finally stop arguing and get moving on their PA-DSS requirements. Healthcare organizations are only starting to recognize that they need to keep their vendors’ feet to the fire on PA-DSS, and it’s only now becoming a big issue as a few of the more forward-thinking application companies targeting the healthcare space are starting to prepare for and go through PA-DSS validation.
I am currently on my way back from Las Vegas and the PCI (Payment Card Industry) Assessors Meeting. I guess it is appropriate that the Delta flight that I am on is a cashless flight; you are now able to buy all the $5 Pringles you can eat with a credit card. But I digress; the real update here is regarding the PCI Assessors Meeting that I attended Thursday afternoon. In all there were approximately 30 representatives of QSA (Qualified Security Assessors)/ASV (Approved Scanning Vendors) companies in attendance. The event was not well attended from the perspective of many people that I spoke with, some attributing the lack of attendance on the session not being well publicized.
The meeting provided a summary of the last couple of months within the payment card industry. The monthly newsletter was discussed as well as the relevance of topics covered within the newsletter. Evidence gathering and how evidence is verified provided some information on the top 10 areas for improvement for DSS (Data Security Standard) and PA-DSS (Payment Application – Data Security Standard). Speaking of the PA-DSS, it was reported that there has been a 17% increase in the number of the ROVs (Report on Validation) being submitted. The recently released ASV Program Guide was summarized during the meeting, including the new reporting templates.
The question and answer session lasted longer than the presentation and covered a broad area of topics. There were questions related to assessment methodology and the need to have consistency in approach amongst the QSA firms. The QA Program will be updated in the fall to coincide with the update to the DSS. The updates or potential updates to the standard where not discussed as the card brands and the SSC (Security Standards Council) want to make sure that they adhere to the feedback lifecycle timelines that have been established.
Overall the meeting would have been better received if there was more information provided regarding the proposed updates to the DSS. However, the card brands and the members of the SSC were willing to engage in productive conversation that will benefit the standard in the long term.
This post is a result of many, many conversations with software companies regarding the PCI Payment Application Data Security Standard (PA-DSS). What’s really interesting about all those conversations is that they tend to fit into two categories – the first involves software companies that know that they need to go through PA-DSS validation and are looking for real guidance, the other typically involves organizations that are looking for someone to tell them that the standard doesn’t apply to them for some reason.
The questions below are the most common ones that we receive from that second group. Hopefully, the answers will help those non-POS companies that are wondering whether PA-DSS applies to them.
1. We are a healthcare (or some other type of) software company, not a POS vendor. We’re not even implemented in a retail setting. PA-DSS doesn’t really apply to us, right?
No, this is not correct. If your situation matches the criteria for the standard (just below), then PA-DSS applies. That doesn’t mean that you have to go through the validation process, it just means that you have to go through the validation process if you want to keep selling your software to companies that accept Visa transactions. Keep reading and I’ll explain.
General Criteria:
Is the application being sold, distributed, or licensed to a third party?
Does the application store, process, or transmit cardholder data (credit card information)? Note – ‘process’ doesn’t necessarily mean financial transaction. For example, taking and hashing a card number would be considered ‘processing’ cardholder data.
2. Our company is really a Service Provider – 80% of our business is hosted, and we only sell our software to a subset of our clients for implementation at their location. We don’t have to bother going through this, do we?
According to the PCI SSC, if your software matches the criteria (see #1), then you need to go through the process. In fact, if you haven’t already, you most likely need to go through the full PCI DSS process as a Service Provider as well.
There are exemptions for one-off, customized solutions, but if you are selling the same base application to two or more clients (and, again, you meet the criteria) you need to address PA-DSS.
3. Isn’t there some way of doing this more cheaply?
Not really. The process of validating an application under PA-DSS is actually quite involved. It includes documentation review, lab testing, interviewing, process and controls review, documentation, documentation, documentation, and some more documentation.
This is not PABP (if you are familiar with the original Visa software security standard). We have seen significant issues with companies that thought they could treat PA-DSS with the same level of attention and effort as they gave to the older standard.
4. Are the PCI Council and the card brands trying to put my company out of business?
No – I honestly don’t think so. They are just looking to make sure that applications capable of being implemented in a PCI-compliant manner are what are being sold in the marketplace to handle credit card information and transactions. Their interest is primarily in keeping their card data secure and in making sure that the merchant is choosing applications that will support that goal.
6. Do my customers need to have our product validated for them to be compliant with the PCI DSS?
No, your customers are not required by the PCI DSS to utilize PA-DSS validated applications today.
In practice (a point stressed at the recent PCI Community Meeting), Visa will be requiring merchants and service providers to use PA-DSS validated applications (unless the applications are developed internally). That Visa announcement makes PA-DSS a practical requirement (even if not technically a PCI requirement) for companies that want to continue accepting Visa as a form of payment.
7. How long does the PA-DSS process take?
It actually depends heavily on the software vendor. If they are highly motivated, committed, and well prepared (and timing with the PA-QSA matches up), the process can be fairly quick. This isn’t necessarily typical, however.
At NetSPI we work with our PA-DSS clients in a very interactive manner. We want to identify gaps and allow you to address them prior to testing and review being complete. Closing identified gaps requires the software vendor to take real action; without that action and commitment, the process can really drag. There is little the PA-QSA can do to move the process along without that commitment.
8. Why are there fewer PA-QSAs vs. PCI-QSAs?
In my opinion, it is due to a few things:
Application expertise and app security expertise are NECESSARY for PA-DSS – it’s not quite so easy to throw outside resources at PA-DSS and try to survive on a rigid audit process; you actually have to know what you are talking about.
The rigorous QA program that the PCI SSC has implemented on the PCI DSS side was actually ‘turned on’ from day one on the PA-DSS side and required a level of documentation and commitment on the part of the PA-QSA that many in the PCI community simply didn’t want to (or couldn’t) handle.
In PA-DSS, the relationship between the firm validating the software and the vendor going through validation is extremely important. This isn’t just about an audit and we’re done. If a PA-QSA firm is doing its job correctly, the QSAs are having discussions with their client about future updates, version control issues, architecture issues, how to operationalize future PA-DSS validation efforts, etc. That’s a consulting/partnership relationship, and many in the PCI community aren’t focused on that type of relationship.
9. Implementing our solution in our PA-DSS partner’s lab is a real pain, do we have to?
Not necessarily – the council prefers that your application be tested in a PA-QSA’s lab, but it’s not required. If it is impractical for the application to be installed in the testing lab (and your PA-QSA feels comfortable defending that opinion), you can bring the PA-QSA to your location.
10. We think this whole thing is ridiculous. What if we refuse?
You certainly have the right, but the PCI SSC has been very straightforward: the PCI PA-DSS list is to be the de facto standard on PCI–acceptable applications. If your application is not on the list, you are taking a risk, the potential impact of which would most likely go far beyond the expense of going through the process.
11. We’ve gone through CCHIT (or some other standard that includes security). Aren’t we covered?
No. PA-DSS is not a suggestion from Visa– it’s a requirement. It is also the only standard that is entirely focused on cardholder data (the data that card brands really care about). If your solution has been successfully audited or validated under another security-focused standard, you may have a head start on getting your solution to a PA-DSS-compliant state. That effort may help prepare you for PA-DSS validation.
Because of increasing threats, high-profile data breaches, and increased awareness of the damage they cause, we anticipate a substantial tightening of regulations and contractual requirements that will significantly impact information security in healthcare.
Today, HIPAA, CCHIT, and state breach notification laws are the main standards that govern security within healthcare systems that deal with protected health information (PHI). But these are generally high-level requirements with low levels of enforcement. The American Recovery and Reinvestment Act (ARRA) of 2009 contains legislation mandating broader and deeper security for healthcare, and the consensus view is that more legislated regulations will follow.
The Healthcare Information Trust Alliance (HITRUST) is an industry group that has developed a set of standards, the Common Security Framework (CSF). This set of standards generally follows industry best practices and is very comprehensive. Important members of this group (Humana, United Health Group, Blue Cross Blue Shield, and Columbia HCA, to name a few) are pushing to mandate these standards across the industry. It is possible that many of these standards will be adopted by the group members through a contractual stipulation that the software they purchase meet the HITRUST CSF standards.
In addition to HIPAA and CSF, Payment Card Industry (PCI) standards also affect healthcare payers and providers when credit card information is involved in any way (processing, storing, or transmitting). For healthcare payers and providers, the PCI Data Security Standard (PCI DSS) applies. For healthcare software providers whose applications touch credit card data, the PCI Payment Application Data Security Standard (PA-DSS) applies.
It is likely that the Obama administration will implement much stricter security standards in healthcare, in conjunction with its emphasis on greater use of electronic health records (EHR). It is also likely that these standards will follow industry best practices and be based on the most successful existing standards, such as PCI and HITRUST. Based on this likely increase in regulations and the increasing number of threats, healthcare organizations should develop a risk-based security strategy that includes industry best practices using HIPAA, CCHIT, PCI and HITRUST as a guide.
