October 30, 2009

Clearing the Mystery of PCI Compliance (Part 2)

Posted by 2Checkout Category Icon2Checkout Category IconTechnology

Last week I wrote an article detailing how to comply with the first two PCI DSS Standards. In this article, I will show what is involved in complying with the two requirements in the “Protect Cardholder Data” standard.

Requirement 3: Protect stored cardholder data

Requirement 4: Encrypt transmission of cardholder data across open, public networks

We have provided a secure network to collect and store our customer’s information. Now, we need to turn our attention to the data itself. To fulfill requirement 3, we need to come up with a policy detailing how we will store card holder data. This sounds easy enough, just make a few decisions and stick with them. However, this is actually a bit more complicated as the PCI-DSS FAQ explains. There are 20 different criteria to meet. While I suggest reading the linked FAQ some highlights are:

  • 3.1 Keep cardholder data storage to a minimum.
  • 3.2 Do not store sensitive authentication data after authorization (even if encrypted).
  • 3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block.
  • 3.3 Mask PAN (Personal Account Number) when displayed (the first six and last four digits are the maximum number of digits to be displayed).

I have to admit, after reading what is involved with this portion of PCI compliance, I nearly gave up. This part of PCI compliance doesn’t really have a cost that can easily be measured in money. The cost is in time – hours and hours of time spent looking over what information is stored, where it is stored, how long it should be stored, what systems are used to backup that data, etc. it gets exhausting. As you become familiar with the standard, you will need to figure out what data you must keep on hand and how long would be a reasonable amount of time to keep that data. The longer you keep the data, the more risky and potentially costly it becomes in the unfortunate event the data becomes compromised. Generally, to comply with requirement 3, you need to understand that all information you collect from your customers must be protected. This means that you can only store a limited amount of the data, and the data you do store must be encrypted (see below).A simple overview of the requirements for card data storage encryption can be found here. Requirement 4 is a little more straightforward. While most people recognize the need to encrypt sensitive information during transmission over networks that are easily accessed by malicious individuals, few recognize the importance of encrypting information sent between back-end systems. This also means that stored information needs to also be encrypted.

Encryption is the most effective way to achieve data security by translating data into a secret code. Essentially, both stored and transmitted data must be made unreadable. The most common method used by credit card processors to protect high speed transactions is a network security protocol called Secure Socket Layer (SSL).

To get an SSL certificate you will first need to choose a certificate that matches your specific needs. Then you need to generate a Certificate Signing Request (CSR) for the site. For example, I found a site selling a certificate for a single domain for $600.00/year. This is on the low end for SSL pricing considering that it comes with a warranty, re-issuance, and provides features I like (priority phone support and regular security audits). I should also note this is a 2Checkout supplier.

If someone were to access our network from the previous article, we want to have protections in place that both limit their access to our customer’s information and makes any information they may access unreadable. Complying with the second set of requirements provides another layer of security for our customers.

Bottom Line for Step 2Time:
Hours and hours – Literally HOURS and HOURS

SSL Certificate: $250-$700+/ year