NetSPI Blog

Posts Tagged ‘PA-DSS’

PCI Assessors Meeting

Lee Buttke | Friday, May 14th, 2010

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.

Permalink | Email the Author

Tags: ,

Questions on PA-DSS from Software Companies and Straight Answers

Alex Crittenden | Thursday, November 5th, 2009

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.

5.    Are they really going to enforce this?

Yes, I think they are. Visa has given every indication that they fully intend to enforce PA-DSS validation and, given their willingness to do so on the broader PCI DSS, I would be willing to bet that they won’t back down.

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.

Permalink | Email the Author

Tags: , , ,

Healthcare Organizations and Tighter Security Requirements

Deke George | Tuesday, August 11th, 2009

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.

Permalink | Email the Author

Tags: , , , , ,

The Far-Reaching Impact of the PCI DSS

Alex Crittenden | Thursday, August 6th, 2009

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.

Permalink | Email the Author

Tags: , , , , , ,