PCI Compliance Test! Trivia Quiz

1. Encryption key management is an optional PA-DSS requirement to be used only if the customer requests encryption requirements above and beyond PCI.

True

False

Payment application must implement key
management processes and procedures for
cryptographic keys used for encryption of
cardholder data

Explanation

Payment application must implement key
management processes and procedures for
cryptographic keys used for encryption of
cardholder data

2. It is acceptable to store the PAN# in clear text as long as the PAN# is purged after authorization.

True

False

Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:
• One-way hashes based on strong cryptography (hash must be of the entire PAN)
• Truncation (hashing cannot be used to replace the truncated segment of PAN)
• Index tokens and pads (pads must be securely stored)
• Strong cryptography with associated key-management processes and procedures

Explanation

Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:
• One-way hashes based on strong cryptography (hash must be of the entire PAN)
• Truncation (hashing cannot be used to replace the truncated segment of PAN)
• Index tokens and pads (pads must be securely stored)
• Strong cryptography with associated key-management processes and procedures

3. Strong passwords are used to mitigate brute force attacks. Typically strong passwords are at least 7 characters long, contain alpha, numeric, special and upper lower case

True

False

Require a minimum password length of at least seven characters

Explanation

Require a minimum password length of at least seven characters

4. Track Data can not be stored in a payment application after authorization.

True

False

Do not store sensitive authentication data after authorization (even if encrypted). Sensitive authentication data consists of magnetic stripe (or track) data6, card validation code or value7, and PIN data8. Storage of sensitive authentication data after authorization is prohibited! This data is very valuable to malicious individuals as it allows them to generate counterfeit payment cards and create fraudulent transactions

Explanation

Do not store sensitive authentication data after authorization (even if encrypted). Sensitive authentication data consists of magnetic stripe (or track) data6, card validation code or value7, and PIN data8. Storage of sensitive authentication data after authorization is prohibited! This data is very valuable to malicious individuals as it allows them to generate counterfeit payment cards and create fraudulent transactions

5. A PCI pre-engagement check list form is used to determine if a payment vendor's PA-DSS validated application can meet the PCI-DSS requirements of a merchant customer. For example, determine if the customer is using an OS that the vendor's payment application was PA-DSS validated against.

True

False

The main purpose of PA-DSS validation from a customers point of view is liability shift. When installed correctly in the customers CDE as per the payment vendors installation guide, card fraud liability shifts from the merchants PCI-DSS to the payment vendors PA-DSS if a forensic audit proves that the vendors payment application was at fault.

Explanation

The main purpose of PA-DSS validation from a customers point of view is liability shift. When installed correctly in the customers CDE as per the payment vendors installation guide, card fraud liability shifts from the merchants PCI-DSS to the payment vendors PA-DSS if a forensic audit proves that the vendors payment application was at fault.

6. A commercial payment product has been PA-DSS 1.2.1 validated by a PA-QSA. It is also listed on the PCI Security Standards Council Website as a validated payment application. As a result, the product is guaranteed to be PCI-DSS compliant when deployed in the merchant's environment.

True

False

Payment application vendors can only state in the engagement contracts that products are PA-DSS validated when installed correctly in the customers CDE. Vendor can not guarantee that merchants who use vendor payment products will be PCI-DSS validated since a ‘PASS’ PCI-DSS report of compliance (RoC) is at the discretion of the merchant QSA.

Explanation

Payment application vendors can only state in the engagement contracts that products are PA-DSS validated when installed correctly in the customers CDE. Vendor can not guarantee that merchants who use vendor payment products will be PCI-DSS validated since a ‘PASS’ PCI-DSS report of compliance (RoC) is at the discretion of the merchant QSA.

7. If a payment product is deployed in such away at the customers CDE, that the payment product never stores,processes or handles credit card data, PA-DSS is not in scope. Examples of this include products that only process loyalty cards.

True

False

Only card holder data (i.e. PAN and track data) is in PCI scope.

Explanation

Only card holder data (i.e. PAN and track data) is in PCI scope.

8. A PA-DSS policy exception should be used to document a security breach when card data is stolen.

True

False

A payment vendor PA-DSS policy exception should be used when a customer can not meet PA-DSS requirements due to business, operational or technical constraints. For example, disable PAN encryption at the PIN PAD to perform transaction troubleshooting. A policy exception is used to state to the customer, that a risk of a card breach is increased, not that a breach has already occured.

Explanation

A payment vendor PA-DSS policy exception should be used when a customer can not meet PA-DSS requirements due to business, operational or technical constraints. For example, disable PAN encryption at the PIN PAD to perform transaction troubleshooting. A policy exception is used to state to the customer, that a risk of a card breach is increased, not that a breach has already occured.

9. A customer is using an operating system (OS) that is no longer supported by the OS vendor. However, payment vendor can PA-DSS validate payment product on the unsupported OS using compensating controls which is allowed under the rules of PA-DSS

True

False

If an OS is no longer supported by an OS vendor, an application can not be PA-DSS validated against it. PA-DSS does not allow compensating controls.

Explanation

If an OS is no longer supported by an OS vendor, an application can not be PA-DSS validated against it. PA-DSS does not allow compensating controls.

10. Starting January 1, 2012, merchants will have to validate their CDE to PCI-DSS 2.0. As a result, payment software validated against PA-DSS 1.2.1 will no longer be valid after December 31, 2011.

True

False

Payment software validated validated to PA-DSS 1.2.1 software can still be used as long as it has not yet expired and no modifcations have been made to the paymemt application covered in the RoV. For example, for software PA-DSS validated on December 1, 2009, the expiry will be December 1, 2012 if the validated software has not changed from a PCI requirements point of view.

Explanation

Payment software validated validated to PA-DSS 1.2.1 software can still be used as long as it has not yet expired and no modifcations have been made to the paymemt application covered in the RoV. For example, for software PA-DSS validated on December 1, 2009, the expiry will be December 1, 2012 if the validated software has not changed from a PCI requirements point of view.