Credit card data is just as vulnerable to hackers when it’s resting, as when it’s in use. Provisions in Requirement 3 of the Payment Card Industry Data Security Standard (PCI DSS) direct web application developers and IT departments to ensure personal account numbers (PANs) are protected, even after the purchase is made.
The mandates for protecting cardholder data at rest seem rather straight forward, but taking them at face value could be a mistake. Many factors about your company's or your client's business determine how this requirement is followed.
3.1 - Store Only Necessary Cardholder Data; Store Cardholder for the Minimum Time Possible
Section 3.1 says to store only necessary cardholder data and to store it for the minimum time possible. Data storage requirements may vary depending upon the nature of your company's or client's business. For example, businesses that provide single use products, or a service offering that is only likely to be used one time should probably not store cardholder data at all, or at most for a very short period.
On the other hand, subscription- or recurring billing-based businesses are on the rise. Invoicing and charging customers “automatically” every month has become a common reality for millions of software as a service (SaaS) companies today. When you have repeat customers, the idea of having your customers resubmit payment details on a regular basis is not just inconvenient, it's inconceivable. Therefore, businesses that cater to repeat customers have some special considerations to address, and because of the retention schedule, these companies go beyond the provisions of the standard to protect cardholder data when possible.
In either scenario, your company must develop and enforce a PAN disposal policy containing:
- A definition of what data is being stored;
- A definition of the time period for which this data is stored;
- A procedure for disposing of data after that time period has expired.
3.2 – Do Not Store Authentication Data
Since we primarily handle transactions online, PCI DSS provisions 3.2.1 and 3.2.3, which deal with magnetic stripe data and PIN numbers, are less applicable to web application developers. However, storing card validation codes (also known as card verification values, or CVV) is also prohibited by this subset of requirement 3, and to that detail we must pay close attention.
Your merchant account provider may give you favorable rates if the CVV number is provided in a transaction. Therefore, many companies make the business decision to retrieve this number from customers submitting orders online. In reality, you’re merely using the number as it was intended – for validating card not present purchases.
If your business has subscription-based orders and recurring charges, you’ll need to work with your merchant account provider to determine your options. For example, it may be possible to use a previous transaction’s payment method ID in lieu of storing and subsequently re-providing it each time the subscription installment is billed.
Portability is another “hot button” that keeps business owners and developers on the fence. Consider these risks:
- What if your payment processor goes out of business?
- What if a current system you use to bill your customers becomes interoperable?
- What if you are presented considerably more favorable rates with another processor?
In either case, the cardholder data must be migrated for business continuity. If you only have access to a masked PAN, expiration date, and reference ID, you’re out of luck and face requesting the payment card details from your customers again. This would be a costly and imperfect process, no doubt.
For these reasons and more, many businesses choose to store the data in its entirety. Just ensure you follow PCI DSS requirements and exceed the provisions when possible.
3.3-3.4 - Render Cardholder Data Useless to Malicious Parties While Upholding Usability Requirements
PAN must be masked. The PCI DSS standard states that the maximum amount of data you can display (either internally without a specific need defined in your security policy, or externally to the customer) is the first six and last four digits of the PAN.
Where possible, use the irreversible hashes in your application or site implementation, allowing you to verify a card number without storing the actual data. Hashes should be based on secure cryptography such as SHA-1 and should use either fixed or dynamic salts (salts are random bits used to improve encryption).
In most cases, this type of data storage is not possible. In cases where storing the cardholder data and maintaining its readability after cryptographic processes is a must it should be stored using encryption similar to what was described in a "Decoding PCI DSS Requirement 6: Develop and Maintain Secure Systems and Applications", a previous article here on Ecommerce Developer.
3.5-3.6 - Securing the Keys to the Castle: Encryption Key Management
The IT department will actively participate in key management, but developers are obviously an integral part of the process since we build, extend, and at the very minimum manage the application(s) that collects, encrypts, and stores PANs. In addition, developers will need to occasionally access the data to troubleshoot, test, or confirm web application integrity. Developers will want to refer to "Decoding PCI DSS Requirement 4: Encrypting and Storing Credit Card Data", published previously here, for more information.
Summary
While the third requirement of the PCI DSS standard may seem fairly straightforward, there are also several pitfalls developers and integrators often encounter while engaging PCI compliance. Clearly defining your business’s needs prior to undertaking PCI compliance can be extremely helpful, especially with regards to requirement 3, where the nature of the data defines how business is conducted in an online arena.
Luke Fritz is Lead Application Security Engineer for FireHost.
Related Articles
- Decoding PCI DSS Requirement 4: Encrypting and Storing Credit Card Data
- Decoding PCI DSS Requirement 6: Develop and Maintain Secure Systems and Applications
- Audio Interview: Chris Drake, FireHost CEO
This article is filed under PCI Compliance & Security and has the following keyword tags: PCI, PCI DSS, security.
