Introduction to PCI DSS

ProcessOut recently got certified for full PCI DSS (Payment Card Industry Data Security Standard) compliance. We went from zero to being compliant in just three months of an engineer’s time and got our final attestation a few weeks ago.

I’m starting a series of posts about the process, from the basics we stumbled upon, to the techniques that saved us weeks of work. This is some general information to understand how the standard works, and who it applies to. I have tried to be thorough with this information, but there may be some pieces missing.

In two minutes: what is PCI DSS?

PCI DSS is a security standard published by a council made up of various financial institutions. It’s a set of requirements for day-to-day business processes (e.g. hiring an employee, setting up a new server), designed to avoid the most common security pitfalls. PCI DSS is enforced by merchant acquirers and processors on the behalf of card brands (such as Visa, MasterCard…). It applies to cardholder data, which is any of the following:

• Card numbers (also known as PAN / Primary Account Number)
• Cardholder names
• Expiration dates
• CVV2/CVC2/CID (the three or four-digit numbers printed on a card for authentication purposes)
• Magnetic track data (account numbers, CVV/CVC…)

Any merchant that processes, stores or transmits cardholder data must comply with PCI DSS in some way. Let me rephrase that: if something (a server, a person…) from your company gets anywhere close to a card number, you’re concerned.

PCI DSS applies to everything digital, but also to over-the-phone or physical transactions. The certification has to be renewed yearly. The latest version of PCI DSS as of time of writing is v3.2, from April 2016.

Merchant/Service Provider distinction

Most organizations certified for compliance fall under the Merchant category. These are entities that accept payments for good and services with credit cards.

Other entities that are involved in the payment process (and may impact the security of cardholder data) are deemed Service Providers. Being a service provider is a bit constraining, because they typically aggregate multiple merchants. That implies more requirements, and they can also process fewer transactions than normal merchants before they have to undergo a complete audit (more on this later!).

Compliance levels

PCI DSS compliance is organized by levels; the lower the number of the level, the more involved the standard is (Level 1 being the most difficult to attain). Compliance levels are not the same for merchants and service providers. For instance, every payment service you know (Braintree, Adyen…) is likely to be PCI DSS Level 1 Service Provider compliant.

There are four levels of compliance for merchants: they all depend on the volume of transactions for a particular brand within a year. Mastercard typically uses the same values as Visa.

• Level 4: < 20k transactions/year — Questionnaire (e-commerce only)
• Level 3: < 1M transactions/year — Questionnaire
• Level 2: < 6M transactions/year — Questionnaire + Quarterly vulnerability scans
• Level 1: ≥ 6M transactions/year — Full onsite audit + Vulnerability scans

Source: Visa Europe.

For service providers, there are just two levels of compliance. This Visa document defines them as the following:

• Level 2: < 300k transactions/year — Questionnaire + Vulnerability scans
• Level 1: ≥ 300k transactions/year — Full onsite audit + Vulnerability scans

Methods for getting compliant

There used to be ways for merchant to process card payments without being compliant, generally using redirections to their payment processor’s checkout interfaces or with iframes. These are now covered under the current standard. Any actor in the transaction process that may compromise the security of cardholder data has to be compliant.

Using a SAQ

A SAQ (Self-Assessment Questionnaire) is a form that can be filled out by anyone to document their PCI status. There are a few categories of SAQs, which are listed in this document and downloaded here. The questionnaires themselves are pretty much the full standard minus the irrelevant parts. They are associated with a document called the AoC (Attestation of Compliance). The AoC is the final certification of one’s compliance with PCI DSS (well, final until the following year).

A QSA can help with filling a SAQ, and be mentioned in the appropriate part of the form. However, they can’t sign off on the final AoC (Attention of Compliance). Since SAQs are not submitted to much validation, some payment providers may refuse to work with non-level 1 merchants or service providers when risk is involved.

QSAs and ASVs: your new best friends

QSAs (Qualified Security Assessors) are responsible for auditing entities that aim for level 1 compliance. They produce a RoC (Report on Compliance) and the associated AoC. I’ll take more time explaining how we picked ours in another post. Let’s just say that quality and cost from a QSAC to the other vary a lot. The biggest three are Coalfire, Trustwave and Verizon.

ASVs (Approved Security Vendors) offer services and tools for vulnerability scanning. They are approved by the PCI SSC (Security Standards Council). The most well-known is probably Qualys.

Scoping

Even though this is a non-technical guide, I have to mention scoping. This is perhaps the most important concept for simplifying assessments. The principle is simple: reduce as much as possible the surface area subject to PCI DSS controls.

Let’s say, for instance, that we have a few servers that process payments, and a lot of application servers that don’t. With careful planning, we could architect our infrastructure so that only payment servers can see card data. There are a few additional steps involved to determine whether our servers are segmented (another important term) properly, but our overall compliance burden ends up being much lower!

What happens if I’m not compliant?

The answer is, if you’re just getting started, not much. You don’t have to follow PCI DSS to process credit card payments. If payment service providers enforced compliance right from the beginning, getting a new business up and running would be much harder. In addition, PCI DSS is rather new compared to the time credit cards have existed; there are still some companies out there that are not compliant, because they’ve always done it that way.

However, that doesn’t mean that everything we’ve talked about is optional. If you start a business right now and grow to any significant revenue, most processors will ask you for a proof of compliance swiftly.

If card brands notice non-compliance for a business with significant volumes, they will fine the acquiring bank that processes transactions for this business. The banks are responsible for monitoring the compliance status of their merchants, but they’ll pass on these fines. In the case of a security breach with card data compromise, the fines are much higher. Transaction processing fees may get increased as well, because of the additional risk involved.

Wrapping up

If I’ve done my job well, you should know a lot more about the matter. You probably know more than I knew a year ago (some of this information was surprisingly hard to find initially)! Unfortunately, even with great partners and a fast-moving company, the process is still very long and tedious. I’ll write more posts about the lessons we learned working our way through compliance. Please email me if you have any questions.

Notes

1. Read this if you need a refresher on the usual terms.
2. Note that if a merchant suffered a security breach resulting in compromise of cardholder data, card brands may force them to comply with PCI DSS Level 1, no matter their volume.
3. The amounts are not public, but they apparently start in the high six digits for larger merchants.