What does it take to write a PCI compliant assembly?

Question

I have a WPF application that we have integrated credit card processing into. We're currently having the credit info swiped/typed into a webpage in a WPF web browser to satisfy PCI compliance. Apparently this is ok because the web browser component is PCI compliant and our code never deals with the credit card info.

I pretty much hate this design and would love to write a stand-alone, PCI-Compliant WPF control/assembly that we can plug in instead of the web browser component. If our app's code can use the browser without itself being PCI certified, then it could use our own PCI certified assembly w/out itself being PCI certified right? All the new control/assembly it would do is collect the card info, and securely send it to a remote secure server via a WCF service. It wouldn't be storing the credit card or doing any processing with it locally. I've been told doing this requires like a 9 month review process which was why we went with the browser approach.

Can someone give me a general idea of what it would take to do this?

• Can it be written in C#/WPF?
• Does the code have to have special security measures implemented (like CAS)?
• Does the assembly have to be obfuscated?
• And once it's written, then what do you have to do?

Bisson

There's multiple levels of PCI compliance, as soon as you touch CC data that kicks up the level. There's no real way around this if you embed the capture of CC info in your app. The reason a web browser control would work is because the CC info is never in memory in your app, but sent directly to a third party. This whole PCI compliance this is a pain in the butt, but generally I'm happy that my data at least has the semblance of being safe. – Frag

Answer 1

Although there is a large amount of overlap with PCI-DSS, the formal name you're looking for is PA-DSS (Payment Application Data Security Standards).

One strategy on the best way to tackle your issue would be to separate out the card entry/card processing parts to an entirely separate solution. This separate solution would then ultimately be the 'app' that goes through PA-DSS certification. Once certified you would embed it into your larger project (which wouldn't alter the PCI compliance of the larger project)

The advantage of separating it out will become clear as you look into PA-DSS. One of the criteria is that any change that requires the app to be recompiled would then need the app to be recertified. That's not something you want to do on a frequent basis!

Another strategy to help make the process easier is to consider that 'in-house' applications (which are not distributed to clients) do not need to be PA-DSS certified (though still fall under PCI-DSS if they handle card data obviously). Therefore using a webservice within your domain would potentially make things easier. You could for example host a 'payment entry details' webpage, then use a standard webbrowser in your main app pointing to your payment entry page. This would potentially allow you to bypass PA-DSS certification (though still require PCI certification for the webpage you now host)

Whatever you decide, best advice would be to get a QSA involved as soon as you have a reasonable grasp on your intended design. The QSA will offer advice on what areas may cause compliance issues, and ultimately its the QSA that will sign off your compliance

Rm

Thanks! Hard part was figuring out where to look. – Bisson