PCI DSS PAYMENT CARD STANDARDS

Processing payment cards is a great way to handle online commerce. Not only do you get the safety of working with an established bank or credit union, but you can also be sure that, as a business, certain aspects of the transaction are secured on both sides, and that payment is largely assured.

To reap these benefits, however, certain standards must be adhered to, both for the protection of the consumer and the entity receiving payment. These standards are broadly codified in a variety of regulations and legislation, but the most common today is the PCI DSS Payment Card Standards.

Today, we’re going to go over these standards, and how, broadly speaking, they impact payment processors. We’ll take a look at how these standard impacts organizations, and how failing to adhere to them can have serious consequences.

WHAT IS THE PCI DSS?

The Payment Card Industry Data Security Standard, or PCI DSS, is a data security standard created by Visa, MasterCard, American Express, JCB, and Discover. The PCI standard is mandated by these companies, meaning that if you work with their systems, you must adhere to them. The standard is overseen by the Payment Card Industry Security Standards Council, and compliance is validated by a Qualified Security Assessor or Internal Security Assessor as defined by the council.

While the standard is not itself backed by any federal law, many states in the US mandate its usage or provide provisions derived from the standard.

Broadly speaking, the PCI DSS lays out a variety of requirements ranging from encryption to penetration resistance. They are generally summarized as:

• Building and maintaining a secure network, and enforcing security on systems that connect to that network;

• Encrypting cardholder data and ensuring secure transfer, storage, and destruction of data;

• Identify vulnerabilities and establish a vulnerability management program;

• Implement strong access controls;

• Regular monitoring, testing, and auditing of systems and networks;

• Establish and maintain an Information Security Policy;

• Compensating for specific situations in which one of these controls cannot functionally be met.

Security as a Plan

A big part of the PCI DSS standard is simply creating and maintaining a comprehensive data management plan. This makes as much sense, of course, as having a foundational security plan which informs the rest of your network as to how to correct security is adopted and utilized. This should already be something that is done as a basic business course of action but ensuring a comprehensive security view is really what the standard seeks.

Above all else, the PCI DSS is obsessed with data security from a cardholder perspective. This makes sense, as cardholders are the primary bread and butter of any card organization, and ensuring that their data is secured goes a long way towards preventing privacy and data breaches.

The biggest thing to mention here is that failing to meet the PCI DSS or adhering to their compliance orders doesn’t necessarily have any legislative or regulatory punitive measures (though in some states, it might) – so what’s to make this something everyone has to adhere to? These organizations that created this standard control almost the entire market, and where there are small store cards that aren’t expressly from these providers, they are typically backed by their network.

Failing to adhere to these standards then means possible exclusion – being unable to process payments in these networks. This has huge implications, of course, and for a business on the internet, is essentially a death knell. Accordingly, meeting and in some cases exceeding these standards is simply a good business investment.

Specific Regulations

With all that out of the way, here are the six main regulations that the PCI DSS sets forth, according to their documentation:

1. Scope – determine which system components and networks are in scope for PCI DSS

2. Assess – examine the compliance of system components in scope following the testing procedures for each PCI DSS requirement

3. Report – assessor and/or entity completes required documentation (e.g. Self-Assessment Questionnaire (SAQ) or Report on Compliance (ROC)), including documentation of all compensating controls

4. Attest – complete the appropriate Attestation of Compliance (AOC)

5. Submit – submit the SAQ, ROC, AOC and other requested supporting documentation such as ASV scan reports to the acquirer (for merchants) or to the payment brand/requestor (for service providers)

6. Remediate – if required, perform remediation to address requirements that are not in place, and provide an updated report

DATA SANITIZATION

We’ve talked previously about sanitizing data devices, but this is even more stringently controlled under the PCI DSS. Data is money – and for the PCI DSS, that is a literal phrase. Exposing payment methodologies and processed ID codes can easily result in huge net losses to the cardholder, the company which accepted payment, and the card distributor. Accordingly, securely wiping devices is a huge part of the standard.

You can’t simply “delete” this data either – forensic data, or data left over from deletion, still adheres to the drive in many cases, and unlike other situations where fragments of data are rendered largely ineffective, even a small piece of recovered data in a financial transaction can be used to cause great damage.

Thus, we need a secure data destruction solution. The PCI DSS specifically notes in 10.5 of its standards that the solution should secure audit trails so they cannot be altered.

So now we know our solution – we should have one that not only securely deletes data, but does so in an auditable way with good records.

Solution

There are a great number of ways to meet this standard. There is of course the “physical destruction” route, in which drives containing such data are physically rendered inoperable. This can be extremely expensive, however, and this cost can dramatically mount as more and more drives are destroyed.

Then there are software solutions. Ensuring that data is properly overwritten in a secure method with audit trails isn’t a hard thing to do, but it’s an easy thing to mess up. Accordingly, a proven solution is the best choice. ClaraWipe is one such solution, and since it matches all major national and international regulatory standards, it’s definitely a great choice:

• Sarbanes-Oxley Act (SOx)

• HIPAA & HITECH

• The Fair and Accurate Credit Transactions Act of 2003 (FACTA)

• US Department of Defense 5220.22-M

• CSEC ITSG-06

• Payment Card Industry Data Security Standard (PCI DSS)

• Personal Information Protection and Electronic Documents Act (PIPEDA)

• EU data protection directive of 1995

• Gramm-Leach-Bliley Act (GLBA)

• California Senate Bill 1386

There is always the option of coding a custom solution as well, but this is often more expensive than it’s worth, especially considering how many good solutions already exist.The main thing to consider here is independent, auditable trails that generate from whatever process you choose – the PCI DSS doesn’t play around, and being able to show you are in compliance is very, very important.

Conclusion

It’s important to keep in mind that we’re not just talking economics, here. Yes, it would suck to lose a contract with a card company, but there’s much more at stake. Internet commerce depends largely on trust – trust that payments will be rendered properly, that goods and services will be delivered, and that data is being secured.

As an online provider, you have a legal, moral, and ethical responsibility to ensure you’re treating your customer data as important as it actually is. Accordingly, adhering to this standard is not only important – it’s all but required.