Posts Tagged ‘PA-QSA


PA-DSS Certification “Clarification”

In the November 2010 Assessor Update newsletter from the PCI SSC, there is a clarification of what constitute “minor changes” to PA-DSS certified applications.  Based on my reading of this clarification, there is going to have to be more clarification done.

The first thing the clarification does is define a “minor change.”  According to the PCI SSC, a “minor change” includes, but is not limited to, a change to the application that:

  • Only impacts the aesthetics of the application such as GUI enhancements, movement of buttons, color updates or changes and marketing changes.
  • Only impacts components of the application that do not relate to the authorization or settlement processes such as adding a field not related to cardholder data processing and updates to the Implementation Guide.

Changes that fall into these two categories do not require that the PA-QSA conduct a re-assessment of the application and file a new Report On Validation (ROV).  Therefore, the application continues to hold its existing PA-DSS certification.  However, the PA-QSA is required to prepare and file a Minor Update Attestation form with the PCI SSC.  Should the PCI SSC reject the Minor Update Attestation form, the PA-QSA could be placed in remediation.  So PA-QSAs will likely be very picky about signing off on any “minor” changes.

So what then are considered changes that require a new ROV?  The PCI SSC defines the following changes as those requiring that an application be reassessed and a new ROV prepared and filed.

  • Changes that directly impact components of the application, which performs the authorization or settlement of the payment transaction, such as any change that can be tied to a PA-DSS requirement.
  • Changes made to how cardholder data is stored, processed, or transmitted such as adding a new authentication module or database.
  • Changes that impact the approved underlying operating system or platform.

The first two points should not surprise anyone.  However, the last point regarding changes to the operating system is interesting as I know a lot of vendors and my own clients that will now hide behind this as a way to keep from patching their systems.  I do not think this is the effect that the PCI SSC desires, but I can tell you that is exactly the effect they will get.  As a result, vendors and merchants alike will not patch because any patching other than the OS release certified will now invalidate their PA-DSS certification.  This would seem to be in direct conflict with the PCI DSS, a situation that the PCI SSC told us would not happen under v2.0 as they were aligning the two standards to complement one another.

Under such a scenario, should Microsoft issue an emergency patch to SQL Server in response to a severe threat such as SQL Slammer, that patch would likely not be applied by merchants because that act will invalidate the application’s PA-DSS certification and the vendor would also likely not recommend that the patch be applied for support issues as well because of the PA-DSS certification issue.  This will only lead to making applications less secure, not more secure.  The PCI SSC will need to further clarify this point to make sure this is not the case.

I also have to question the change to the approved underlying platform.  So, if a vendor only certified their application on Windows or Linux running on HP hardware, if they change to IBM hardware configured with exactly the same memory, processor, expansion slots, etc. the application must be reassessed?  In this day of common Intel or AMD -based hardware, that seems a bit over the top even for the PCI SSC.  However, in the case of going from an Intel to AMD or from Windows to Linux, I would agree that the AMD or Linux systems need to be assessed.  I know what the PCI SSC is trying to accomplish with this definition, but they will have to clarify this as well.  Just what constitutes a platform change?  Is it the whole platform, CPU, memory, sub-components such as NICs, modems, SAN, NAS, etc.?  How they answer will drive the costs of certification.  I think they have opened a Pandora’s box that they should have discussed further with the PA-QSAs and application vendors before issuing this “clarification.”

Then there are those of you that develop in-house custom applications that are in-scope for the PCI DSS.  Do not think that the PA-DSS does not apply to you.  While it technically does not apply, as I point out to my clients that develop applications, the PA-DSS is a great framework for secure application development.  I urge our clients’ application developers to use the PA-DSS standard as a reference and framework for their own secure development practices.  Therefore, I would recommend that all custom application developers follow the aforementioned definitions.


Open Source PA-DSS Certification

I got the following comment regarding open source solutions.

“Is it correct to assume that open source e-Commerce solutions like Magento Community, VirtueMart, Ubercart, Zen Cart, etc. will never be PA-DSS compliant since, by their very nature, they are modifiable and extensible via plug-ins?

Does it mean that a commercial e-Commerce solution will need to be “locked down” with encrypted code to be PA-DSS compliant?”

Now before all of you open source “bigots” out there send me tons of nasty comments and flame mail, keep in mind that I am a big fan of open source code and rely on a lot of it in my network security practice.  The problem is not with open source solutions but with the practices used to create those solutions that typically create the compliance issues with the PA-DSS.  I am not implying that these issues cannot be overcome.  Just that given the state of open source at the moment, I just do not see these issues being overcome in the near future.  That is not to say that open source solutions cannot be used for payment processing.  It is just that they will need to be individually assessed as part of the merchant’s PCI Report On Compliance (ROC) assessment process.

Let us remind everyone about the 14 points that the PA-DSS covers.

  • 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 my opinion, none of the aforementioned solutions will ever likely be PA-DSS certified.  Here are the highlights of my rationale for that assessment.

Requirement 5 – develop secure payment applications is where I think the majority of the issues with PA-DSS certification occur.  Requirement 5 deals with the development practices used to develop the solution.  The problem here is in the PA-QSA reviewing all documentation, interviewing the developers and observing elements of the development process.

Open source documentation is typically only available online and can be very spotty at best.  Usually the focus is on installation and basic operation.  The PA-DSS and PCI DSS require documentation on how to properly install the solution so that it complies with the PCI DSS.  Documentation for open source solutions that I have evaluated have not included such information.

One of the biggest stumbling blocks for open source solutions will be in documenting the system development life cycle (SDLC) that is used.  In my experience, while documentation on the application can be scarce, documentation on the development life cycle typically is non-existent with open source.  As a result, it will be impossible to get around the requirement of an SDLC.

Then there is the whole process around change control.  How changes are managed from the initial request through implementation is a big part of the PA-DSS assessment process.  These communities usually do not have a change control process that can be audited let alone meet the rigor required by the PA-DSS.  There is also the question of who approves the changes.  These open source solutions usually do not have a documented organizational structure, so who is the person that approves the changes for development, approves the changes for production?

As with change control, testing is another big part of the PA-DSS certification process.  While open source communities conduct testing before releasing their products, the testing they perform is usually not documented in a way that it would meet the requirements of the PA-DSS assessment.  Testing also requires documented approvals, so the issues with change control approval exist with testing.

While all of these requirements can be met with compensating controls, without a control environment to start with, just how one would develop compensating controls is a big hurdle to overcome.

Besides the problems in meeting Requirement 5, here are some other items that I also think preclude a PA-DSS certification for open source solutions.

Who would be the organization of record that certifies the application?  Most of these open source projects and communities do not exist in a legal sense.  As a result, they technically cannot legally represent the application in question which is required for PA-DSS certification.  And for those instances where there is a legal entity, would such an entity be willing to assume the risk entailed in certifying their solution?

Then there is who would pay for the certification?  Most of these projects and communities exist on the goodness of the people who devote their time to the software solutions in question.  There is little if any money involved and it would be difficult for most to raise the kind of money to pay for a PA-DSS assessment.  For those of you wondering, most PA-DSS certifications cost at least $30,000 or more depending on the complexity of the application and the number of platforms involved.  When you are structured like most open source projects, such an amount of money is daunting to raise.

And finally, assuming that your open source solution gets PA-DSS certified, how would you know that your version of the open source is untouched?  .  This basically means that the solution now needs to be distributed in a secure manner.  So, the community will need to have a known, secure distribution point for the software, not distributing it from any outlet that wants to provide it for downloading.  Yes, you can use MD5 or similar hash algorithms to confirm that the version is the correct, certified version.  However, given the requirements of the PA-DSS regarding distribution of the solution and any updates, open source communities will have to invest in a bit better distribution system.

The bottom line is that the PA-DSS is skewed to commercial software, not the open source community.  That is not to say that open source solutions will not get certified as I believe there may be some that do get certified.  I think what you will see is organizations spring up that offer a certified version of the open source solution but you will have to purchase that version, you will not be able to download it for free.  Very similar in concept to how Red Hat and Novell operate with their versions of Linux.  However, based on the current certification process, in my humble opinion, PA-DSS certified open source solutions will be the rarity not the rule.

Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

February 2023