by 

The PCI Data Security Standards Council publishes a number of documents for businesses, IT professionals, software developers, and others who participate in implementing the PCI Data Security Standard (PCI DSS). One of these, the Requirements and Security Assessment Procedures (version 2.0), describes a set of requirements for businesses working with payment card data. The document describes a set of high-level requirements organized into six functional tasks:

• Build and maintain a secure network
• Protect cardholder data
• Maintain a vulnerability management program
• Implement strong access control measures
• Regularly monitor and test networks
• Maintain an information security policy

This chapter will describe these requirements in a slightly different structure, organized more around clusters of requirements that would be addressed by different groups within an IT department, for example, developers and systems administrators. These are not hard and fast divisions. Some of the requirements necessitate collaboration between developers, systems administrators, application architects, and application managers. Keeping in mind the need for multiple skill sets, we will discuss the requirements organized around:

• Data collection and storage practices
• Infrastructure security
• Vulnerability assessment
• Monitoring and reporting

We begin with the most basic of tasks: collecting data.

Data Collection and Storage Practices

The PCI DSS includes a substantial number of requirements about storing payment card data. There is no way to sufficiently summarize all these requirements in a brief statement but a crude approximation of the spirit of the requirements is:

Don’t store payment card data if you don’t have to, but if you do store payment card data, lock it down and don’t keep it any longer than necessary.

Locking down data in this case calls for strong encryption and comprehensive access controls. As we shall see later in the chapter, keeping partial payment account information is another method for protecting PCI DSS-relevant information.

Data Storage and Retention Regulations

The amount of payment card data stored in your applications and databases should be minimized. The PCI DSS recognizes there may be business, legal, and regulatory reasons that payment card data has to be stored. In such cases, the reasons for storing the data should be defined as part of a policy, and that policy should include a justification for storing the data and a specific data retention period. The PCI DSS also requires that you have a procedure in place to actually delete data when the retention period passes. That process should be executed quarterly.

Although there are reasons to store some payment card data, sensitive data should not be stored after the authorization process is complete. The kinds of data that may be retained include:

• Name of customer on payment card account
• The account number
• Expiration date on the card
• Service code

The PCI DSS requirements specify that the full contents of any of the tracks on the payment card should not be stored. Magnetic stripes used in payment cards contain multiple tracks with different information stored on each track. Not storing the full contents of payment card tracks helps reduce the risk that someone could create fraudulent duplicate cards. There are at most three tracks on a payment card. Track 2 was created by the banking industry and includes the following data elements:

• Start sentinel, which is a single character
• Primary account number
• One character separator
• Expiration date
• Service code, which indicates interchange rules, authorization processing, and range of services
• Discretionary data, which may include a card verification value (CVV)
• End sentinel, which is a single character
• Longitudinal redundancy check, which is used by the card reader to verify data was read correctly

The CVV code, also known as the CVC code, is one piece of data that should never be stored. This code is used to validate a transaction when the card is not present at the point of sale; for example, if someone is entering a card number online or providing it over the phone to a sales person. This information is only used for the card authorization process, so there should be no reason to store it after that process completes.

The primary account number (which may or may not be the same as the card number) is protected in a number of ways by the PCI DSS. Unless someone has a need to see the full primary account number, it should be masked when displayed. For example, a receipt might display just the last four digits such as “**** **** **** 1234.” This is enough to help those of us that have to track receipts from multiple cards without disclosing full account numbers.

Click here to download this chapter or book.

Tags: pci compliance, pci dss