Removing CHD from existing app then segregate CHD handling to separate PA-DSS app

[StevePC]

A partner we are working with offers membership management software to various industry verticals. This software stores CHD for the purpose of processing recurring membership subscription fees.

To this end the partner is asking for our assistance in making their solution compliant by utilising a Tokenization Vault service we provide for storage of card numbers.

The challenge lies in de-coupling CHD handling from the application in order to simplify the remediation work required. Our initial thoughts were to develop a PA-DSS certified mini-application that's sole purpose is to capture the PAN from the operator, communicate with our Vault service via Internet/TLS and receive a Token back. The Token is then passed back into the membership management software for storage. The net result is that the member management software can process member's payments via our payment system using a Token rather than needing to store / transmit / process the customers real PAN.

First Question - Does this sound like a reasonable approach to solving a PA-DSS problem of this nature? Has anyone seen something like this done before using a separate application to take PA-DSS away from an existing solution (and hence avoid mass re-engineering).

When originally suggesting this approach, our idea was the membership management application shells-out to the PA-DSS application in order to show clear deliniation between the 2 applications. However, the partner has indicated they have a way of making the separate application appear as a module within their own application (written in VS2008) without the visual affect of a shell-out event being seen. There are concerns that this is not separate enough and would potentially bring the main membership application back into scope of PA-DSS if the CHD handling appears to not be separate.

Is there any opinions or advice in how we determine if this would be acceptable or not?

The ultimate goal here is to avoid PA-DSS certification within the legacy membership management platform and quarantine CHD handling to a separate simple application that is easy to manage and maintain certification of.

Thanks in advance,
Steve

[jbhall56]

First Question - Does this sound like a reasonable approach to solving a PA-DSS problem of this nature? Has anyone seen something like this done before using a separate application to take PA-DSS away from an existing solution (and hence avoid mass re-engineering).

I am not aware of any commercially available packaged solutions like you describe, but I have seen a number of packaged solutions that were then modified by the purchaser to do something similar.

When originally suggesting this approach, our idea was the membership management application shells-out to the PA-DSS application in order to show clear deliniation between the 2 applications. However, the partner has indicated they have a way of making the separate application appear as a module within their own application (written in VS2008) without the visual affect of a shell-out event being seen. There are concerns that this is not separate enough and would potentially bring the main membership application back into scope of PA-DSS if the CHD handling appears to not be separate.

When talking about a separate module, I'm assuming you are referring to a separate DLL. That said, I would say as long as you document in detail how the two interface with each other, I would say you could achieve your objective. However, your PA-QSA would have to confirm that this was in fact how your tokenization module works and their testing would have to confirm those facts.