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.
In a post that I wrote earlier, “The Far-Reaching Impact of the PCI DSS,” I mentioned the influence of the PCI DSS on industries other than retail and hospitality. I’d like to expand on that topic by taking a look at healthcare software and the Payment Application Data Security Standard(or PA-DSS, a standard within the broader PCI DSS.)
Since the introduction of the PA-DSS, and the ‘retirement’ of the former standard (PABP), NetSPI has been constantly engaged with companies that suddenly have to address what was previously a voluntary standard and one that was considered relevant only by Point-Of-Sale (POS) vendors.
However, what has been pretty clear from the beginning is that PA-DSS is in no way limited to the retail checkout environment. As defined by the PCI SSC, the PA-DSS applies to applications that:
•Store, process, or transmit cardholder data
•Are sold, distributed, or licensed to third parties
It’s really pretty straightforward - if you are a software company and your product fits these two criteria, PA-DSS applies to you. That means that healthcare application companies whose products touch cardholder data now need to add PA-DSS to the list of standards they need to be concerned about. Also, I should mention that the deadline that VISA has set for PA-DSS compliance is July 2010.
Many integrated healthcare solutions are built to support a wide range of needs inside a complicated hospital or practice environment – managing workflow, interaction, and data sharing internally between departments as well as externally with patients, insurance companies, and, potentially, public health representatives.
Often these highly valuable (and highly intricate) systems were not built with a primary focus on financial transactions – they sprang from the needs of doctors, patients, and the medical system. The requirements involved with PA-DSS and the broader PCI DSS can be confusing and hard to translate for healthcare software companies that have certainly incorporated security and privacy into their products, but have traditionally focused on patient confidentiality rather than cardholder data protection.
Today, my recommendations for healthcare software companies would be:
Rapidly determine if their solutions meet the criteria for PA-DSS and, if so,
As the deadline approaches, addressing these two things is the first step in a process that really needs to be more holistic and take into account the full spectrum of security concerns that face the healthcare software community. That holistic view now includes validating against a standard that was not developed by a healthcare-centric entity, but rather by an organization that was created to ensure credit card security (regardless of the market or environment.)
Understanding where and how the PA-DSS translates into their solutions is one of the challenges for software providers in the space, and there are few knowledgeable, experienced partners to turn to as July gets closer
At the PCI Community Meeting last month in Las Vegas, one thing was abundantly clear – merchants and service providers need help. The confusion that comes with a complicated, comprehensive security standard, coupled with governance that shifts back and forth between the PCI-SSC and the card brands, has created a situation that requires that a QSA be more than just an auditor for their clients.
Now, I should state that I’m a full supporter of the PCI SSC and the PCI DSS – I’m not here to bash the council or the brands. Security around cardholder data is something that really needed improvement (and continues to need improvement), and the PCI DSS is really just a codified set of best practices with a tight focus on cardholder data.
At the community meeting I noticed that a number of the attendees appeared frustrated by how many times a question to the SSC (or to the card brand representatives to the SSC) elicited a response of “That’s really a brand-specific question and will need to be asked to the individual brands directly.” By this point most companies recognize that the PCI DSS is not the overall goal for their security strategy – its narrow focus ignores a great deal that organizations need to be concerned about in terms of information security. However, today many organizations still don’t realize that PCI isn’t even ‘complete’ in addressing credit card security – the brands may have important individual guidance that supersedes the PCI DSS.
Which brings me back to my initial statement – people need help and not just audits. The merchant and service provider community is looking for leadership and for partners to work with them to understand the unique and shifting landscape of compliance and security. This includes PCI, but it also includes the broader discussion of what the individual brands require outside of the PCI DSS and the impact of decisions on overall security.
The community expects and, truthfully, deserves this leadership. After all, we’re the experts and they are putting their trust in that expertise. Yes – passing your PCI audit is very important, but it isn’t the only thing that’s important, even within credit card security.
As the PCI Community Meeting is set to start tomorrow, I have been thinking about the current state of the retail marketplace and what that means for NetSPI’s focus–security and compliance.
During the down economic times no retailer really came through unscathed. Everyone suffered to some degree, but even during the most difficult periods of this recent recession, retailers that were well-run and focused on a strategic vision managed to weather the storm and to prepare themselves for the coming improvement in market conditions.
Interestingly enough, during this same period the attitude towards compliance and security also shifted within the management ranks at these same organizations. What was once something they hoped to avoid became not just accepted, but in some ways welcomed. The realization that compliance and security were not just checklist items, but rather could provide strategic advantage really sank in, and these leading retailers began to use the requirements of PCI (for example) to re-invigorate broader security initiatives and to use any technical or policy adjustments as opportunities to simplify their security scope and implement better overall security policy.
NetSPI’s retail clients expanded their security efforts during these poor economic times and now sit in a position where they can leverage that effort into a better experience for their customers as well as for their own employees. For them it was another facet of their plan to better position their company to lead in an improved economy.
We are now starting to see that trend expand to retail organizations that have been harder hit during the recession. Organizations that are in transition are also starting to see the light and to understand that, by taking a strategic approach to compliance and security, they will ultimately position themselves to fit better with the new attitudes of consumers. Consumers are not as brand-loyal as they were before the economic challenges and are far less forgiving of a retailer that doesn’t take their private information seriously.
With the economy showing signs of improvement, a rebirth is beginning in the retail space. Activities that have been conspicuously absent for the last few years–acquisitions, major technology investment, location expansion, and even IPOs–are starting to make headlines in the trade magazines and the broader press. This is a good sign for both the retail community and our economy at large, but the organizations that will take the lead over the next few years and separate themselves from the pack are those companies that have both a strategic vision (which includes security) and the ability to execute effectively.
The last few years have seen a great deal of discussion, arguing, hand-wringing, and posturing within the retail / hospitality community regarding the PCI DSS. It has also driven a lot of investment in technology–and a lot of investment by technology companies.
Then PA-DSS came along. The PCI Council took a voluntary program (PABP) and turned it into a robust, mandatory security standard, the impact of which is still being absorbed by software vendors that provide solutions to retail and hospitality merchants. Again, there was much hand-wringing, posturing, and general frustration (this time from the vendors.)
The remarkable thing to me is the degree to which, until very recently, this consternation over PCI and its applicability and requirements has largely been isolated to the retail / hospitality community. Slowly, the rest of the business world is waking up to the fact that PCI reaches far beyond retail. Electronic currency (i.e., debit and credit) is not a payment mechanism isolated to any one vertical; instead, it’s increasingly used by consumers in all aspects of their spending.
This realization ’process’ looks an awful lot like the classic grieving process–denial, anger, bargaining, depression, and finally, acceptance–and is the same process that the retail community has gone through for the last five years (for L1 & L2 merchants I think we’ve pretty much gotten to the acceptance stage). A lot of hospitals, higher education organizations, healthcare technology firms, and the like are really just beginning this process - denial is still a big part of the conversations that we have with these organizations.
Now, this is certainly not a universal situation. NetSPI is working with some very forward-thinking, security-focused organizations on PCI and related security initiatives, but it’s common enough to note and it’s where we spend a lot of time working to educate the broader community. Luckily, we have a lot of experience with these other industries and can help our clients work through this process with more than just a retail/hospitality perspective.
The fact that other standards are also applicable in some instances may be causing some of the difficulty in accepting the fact that PCI is important and applies. HIPAA, for example, has security requirements to protect personal health information. I have had numerous conversations about PCI with companies in healthcare that have sounded something like “I have to adhere to the HIPAA security standards, so I’m covered.” Actually, if you take credit card payments, and you are just worrying about HIPAA’s security requirements, you have a serious problem.
Anyone that takes or manages electronic payments–healthcare providers, lawn care companies, hospitals, insurance companies, doctor’s offices, accounting firms, tax preparation services, plumbers, event scheduling services, etc, etc, etc, etc.–is subject to PCI’s requirements. The software vendors that service and support all of these industries and handle PCI-relevant information within their solution are also subject to PCI’s requirements (via PA-DSS).
So my advice - learn to accept PCI and take the steps today that will help make compliance more efficient and improve overall security. Find a partner that is focused on PCI guidance, not just auditing. Make sure that they understand your industry, ask good questions that go beyond the scope of compliance, and give you honest feedback.
If you accept electronic payments, PCI applies to you. If you are in denial, you need to move through your grieving process quickly so that you can make critical decisions and take the actions required to protect your organization and minimize risk.
Subscribe