CBORD Explains: PA-DSS

Payment Application Data Security Standard—or PA-DSS—is applicable anywhere you would install software on a piece of hardware to accept payments. The payment application could be on a cash register, a kiosk, a mobile device, a portable device such as a tablet. In our world, PA-DSS is most important with MICROS®, because MICROS has to go through PA-DSS audits and validation for every version that they release.

PA-DSS falls under PCI-DSS which was created by the PCI Council

About ten years ago the major credit card brands— VISA, MasterCard, AmEx, Discover—all created the PCI Council. Previously, each had their own method of protecting cardholder data—but in 2004 they created a unified standard for everyone. A part of the charter for this organization is that it is made up of industry people: card brands, banks, processors, gateways, vendors for point of sale software, vendors like us for hosted products—all these entities can be part of the council. Members usually serve for a specific term, and then they provide input and counsel on the pressing issues of the day.

Keeping up with the updates

Every year or two, the council issues updated requirements—which they just did earlier this year. They started with PCI-DSS 1.0, and they just issued 3.1 in April 2015, which added a little to 3.0. With a new update, they usually have language along the lines of: This will go fully into effect January 1 of next year, and it will be in effect for two years. When we validate our software in the Cloud, or when MICROS validates hardware, we have to do it with whatever the current version of PA-DSS or PCI is, after the update. It's good for a year, and you can install your software at new sites. It's called 'acceptable for new deployment.' After your year is up, if you don't re-validate that version, that version then becomes 'acceptable for pre-existing deployments.' And this is an important distinction for our customers.

The PCI Council allows this because it's an issue for merchants to chase a new version every two years. Can you imagine if a site with 200+ terminals had to update their software every year to be compliant? The costs would be astronomical.

Regulations recognize that if the device was compliant at install, the merchants can continue to run the software—while still adhering to overall PCI compliance—even though the version is not compliant by today's PA-DSS standards. We rely pretty heavily on this grandfather clause as a lot of our customers will run software that was compliant when it was installed, and once that PA-DSS has expired, they're motivated to move to the newer version, but they don't HAVE to do it. On the PCI website for versions of MICROS software, for instance, you will see this distinction with 'acceptable for new deployments', and then older versions will say 'acceptable for preexisting deployments.' And that's the way that PA-DSS works.


Do software versions grandfathered in ever expire?

Kind of. Take for example Windows software running on 2003 servers. Microsoft has a life cycle for each version which is published when they release the product. When they release new versions—like Windows 10 this summer—Microsoft will say: "This version will be released in July and we will provide active support for the next five years, with extended support for another five years. At ten years, you have reached its end of life and cannot do extended support anymore." At the end of extended support, Microsoft will no longer make patches available for vulnerabilities, and that is a big no-no for PCI. So if your software is at its end of life, you need to have a plan.

This exact scenario is coming up this summer for a lot of our customers. Windows 2003 server extended support ends in July 2015. If they are still on 2003, this means they need to be moved off of Windows 2003 server. If they're not, they have to compensate for that in some way with a Plan B.

A Plan B example might be, "We are going to protect servers A, B & C, and add another firewall. We also have a plan to migrate in the next six months and remove this vulnerability."

Plan B comes with a lot of paperwork but most merchants will make this work and be OK. If, however, you are a location that doesn't do any of this and you don't do the paperwork… you are a ticking time bomb. If you have a security breach when you are out of compliance and haven't submitted your Plan B paperwork, it's a pretty disastrous situation. The fines can be very, very expensive, and the reputation costs are even more expensive.