Questions about PCI DSS Requirements 3 and 4? You’ve come to the right place.
As you may know, AISN is a PCI compliant cloud hosting provider. Previously, we addressed questions about PCI DSS Requirements 1 and 2. Today, we’re reprinting highlights from an exclusive online interview sponsored by our valued partner, KirkpatrickPrice. In this interview, KirkpatrickPrice Information Security Auditor Tim Cunningham responds to some frequently asked questions about PCI Data Security Standard Requirements 3 and 4. His specialized expertise fosters some clarity on the robust information security standard. Below are highlights:
Q: When we consider the concept of protecting stored cardholder data, what is the first thing to consider when planning compliance with Requirement 3?
An organization’s approach to PCI Compliance should be a top-down, management driven approach. When considering engaging a company to get a PCI ROC, ask, “Do we need to have cardholder data in our environment? Do we need to store it? Do we need to have that 16 digit number in our system if we can truncate or hash it someway and still have it serve a purpose for us that we need? Can we serve our customers without storing this information? Does our process rely on this information? Why? How long?”
Q: If I’ve encrypted backup tapes that have cardholder data that exceeds my retention period, do I have to go through the laborious process of removing that data?
The DSS is pretty specific about testing procedures — any place where it’s stored, it has to go away. This has been unwelcome news, but it is in compliance with DSS. Regardless of where it is “a quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention.”
Q: In regard to Requirement 3.2, but don’t I have to store the security code for recurring payments?
Sensitive authentication data is only used for authorization, and not stored and should be unrecoverable after authorization. You don’t really need the CVV number to authorize and you cannot store it. However, DSS says we can’t keep that after the authorization process. Find it at POS machine logs, places you don’t anticipate it to be. It doesn’t appear in dataflow diagram. You can store a value or token or authorization code that represents authorization for recurring payments.
Q: Do people struggle with the concept of masking the number or changing processes that have historically required the full number?
I think for the most part, everyone understands the reasons why we should do this. It’s good practice, it’s required in the DSS, and clients typically feel good about adopting and implementing.
Q: Are there any common issues to consider when dealing with encryption methodologies?
If you do have a legitimate business need to store the 16 digit number, you must store it in an unreadable way—wherever it’s stored. There are several allowed methods for rendering PANs unreadable. You can using hashing, truncation, index tokens and pads, or strong cryptography. Before you ask yourself how you should encrypt a PAN, ask yourself, do you need to store it? Don’t store the full PAN if you don’t have to. If using strong encryption, reference OWASP cheat sheet.
Q: Is Windows Bitlocker considered an OS-independent encryption method?
Since the credentials are maintained independent of the OS, and it is authenticated prior to loading the OS, and it is a separate mechanism with separate credentials. I think that it passes 3.4.1 for disc encryption using Bitlocker.
Q: When using encryption, you have to use keys to encrypt and keys to decrypt. We have to protect those keys as well by key management. Are there any common gaps that you find with these key management procedures?
This is one I find people wrestling a lot with. I would encourage people to use an integrated solution, a host security method of some sort who already addresses PCI DSS to help ease the load. I think the decision will be based on what’s being encrypted, and where it is. We can help present some solutions.
Q: According to 3.6.4, fully documented policies and procedures are required to demonstrate cryptographic key changes for keys that have reached the end of their cryptoperiod. A cryptoperiod is a defined period of time that has passed and/or after a certain amount of ciphertext has been produced by a given key. What is a reasonable cryptoperiod?
This is another commonly debated requirement. As noted, NIST Special Publication 800-57 is the recognized authority of key management and the idea of a cryptoperiod. I would encourage referencing that for industry best practices and guidelines. Consider volume of information encrypted, security function, strength of cryptographic mechanism, retention period of the data and other variables when analyzing and determining your cryptoperiod.
Q: What is considered early TLS?
It is TLS that relies on the SSL protocol (TLS v1.0). It is no longer recognized as secure due to security vulnerabilities in the protocol.
Q: What are some concerns to point out when it comes to wireless being in scope as part of the CDE?
Good question. For a service provider, if you don’t need wireless to push data across, then segregate that from the CDE to remove that from the scope. If you do need it, the DSS is very specific about what needs to be done to secure wireless at your organization.
Would you like to ask our auditors more specific questions? Email Sarah Morris at [email protected].
Looking for a PCI compliant hosting partner? Email Bill Peters at [email protected].