PCI DSS - 13 Guidelines

The following PA-DSS Guidelines are being provided by ID TECH as a convenience to its customers. Customers should not rely on these PA-DSS Guidelines, but should instead always refer to the most recent PCI DSS Program Guide published by PCI SSC

1. Sensitive Data Storage Guidelines
   1. Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CVC2, CVV2), or PIN block data.
   2. Do not store sensitive authentication data after authorization (even if encrypted):

   3. Note: By prohibiting storage of sensitive authentication data after authorization, the assumption is that the transaction
      has completed the authorization process and the customer has received the final transaction approval. After
      authorization has completed, this sensitive authentication data cannot be stored.

   4. After authorization, do not store the full contents of any track from the magnetic stripe (located on the back of a card, contained in a chip, or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data.

   5. In the normal course of business, the following data elements from the magnetic stripe may need to be retained:
      • The account holders name,
      • Primary account number (PAN),
      • Expiration date, and
      • Service code
      • To minimize risk, store only those data elements needed for business.

   6. After authorization, do not store the card-validation value or code (three-digit or four-digit number printed on
      the front or back of a payment card) used to verify card-not-present transactions.

   7. After authorization, do not store the personal identification number (PIN) or the encrypted PIN block.

   8. Securely delete any magnetic stripe data, card validation values or codes, and PINs or PIN block data stored
      by previous versions of the payment application, in accordance with industry-accepted standards for secure deletion,
      as defined, for example by the list of approved products maintained by the National Security Agency, or by other
      State or National standards or regulations.

   9. Securely delete any sensitive authentication data (pre-authorization data) used for debugging or troubleshooting
      purposes from log files, debugging files, and other data sources received from customers, to ensure that magnetic
      stripe data, card validation codes or values, and PINs or PIN block data are not stored on software vendor
      systems. These data sources must be collected in limited amounts and only when necessary to resolve a problem,
      encrypted while stored, and deleted immediately after use

2. Protect stored cardholder data
   1. Software vendor must provide guidance to customers regarding purging of cardholder data after expiration of customer-defined retention period.
   2. Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).
   3. Notes:This requirement does not apply to those employees and other parties with a legitimate business need to see full PAN
3. Provide secure authentication features
   1. The payment application must support and enforce unique user IDs and secure authentication for all administrative access and for all access to cardholder data.
4. Log payment application activity
   1. At the completion of the installation process, the out of the box default installation of the payment application must log all user access (especially users with administrative privileges), and be able to link all activities to individual users. PCI Data Security Standard Requirement 10.1
5. Develop secure payment applications
   1. Develop all payment applications in accordance with PCI DSS (for example, secure authentication and logging) and based on industry best practices and incorporate information security throughout the software development life cycle. all testing configurations, samples, and data before finalizing the product for production.
6. Protect wireless transmissions
   1. For payment applications using wireless technology, the wireless technology must be implemented securely.
7. Test payment applications to address vulnerabilities
   1. Software vendors must establish a process to identify newly discovered security vulnerabilities (for example, subscribe to alert services freely available on the Internet) and to test their payment applications for vulnerabilities.
8. Facilitate secure network implementation
   1. The payment application must be able to be implemented into a secure network environment. Application must not interfere with use of devices, applications, or configurations required for PCI DSS compliance (for example, payment application cannot interfere with anti-virus protection, firewall configurations, or any other device, application, or configuration required for PCI DSS compliance).
9. Cardholder data must never be stored on a server connected to the Internet
   1. The payment application must be developed such that the database server and web server are not required to be on the same server, nor is the database server required to be in the DMZ with the web server. PCI Data Security
10. Facilitate secure remote software updates
    1. If payment application updates are delivered securely via remote access into customers systems, software vendors must tell customers to turn on remote-access technologies only when needed for downloads from vendor and to turn off immediately after download completes. Alternatively, if delivered via VPN or other high-speed connection, software vendors must advise customers to properly configure a firewall or a personal firewall product to secure authentication using a two factor authentication mechanism.
11. Encrypt sensitive traffic over public networks
    1. If the payment application sends, or facilitates sending, cardholder data over public networks, the payment application must support use of strong cryptography and security protocols such as SSL/TLS and Internet protocol security (IPSEC) to safeguard sensitive cardholder data during transmission over open, public networks.
12. Encrypt all non-console administrative access
    1. Instruct customers to encrypt all non-console administrative access using technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access. Telnet or remote login must never be used for administrative access.
13. Maintain instructional documentation and training programs for customers, resellers, and integrators
    1. Develop, maintain, and disseminate a PA-DSS Implementation Guide(s) for customers, resellers, and integrators.