Latest revision as of 18:23, 23 June 2016

CreditLine Payment Processing Software PA-DSS Compliance Guide. This site can also be reached at http://docs.911software.com

→ Looking for better rates?   Get a Free Credit Card Processing Cost Comparison!

Please, familiarize yourself with the contents of this Industry Required Security Guide for Payment Processing Applications!

→ This guide serves as a convenient summary of your responsibilities. It is not the official PCI SSC document and is subject to change! Please refer to the PCI Security Standards Web Site for all final implementation and operational decisions.

911 Software PA-DSS Certification

911 Software CreditLine version 4.1 has been reviewed by the PCI Security Standards Council (the Council) Quality Assurance Program and received a grade of PASS. Please see PA-DSS compliant application list for more info. The version will be released shortly.

PA-DSS Implementation Guide

Please, see CreditLine PA-DSS Implementation Guide

PCI Friendly Program

With 911 Software CreditLine Payment Processing Software you have the option to make your application PCI Friendly by removing any interaction (including user interface entry) with the sensitive cardholder data from your application.

Contrary to the popular opinion, offsite storage of payment processing data (e.g. Shift4, SDC) does not free the end-user from the liabilities of handling credit cards. The cards are still handled at the store and the credit card data is still being transmitted. Because of that the merchant remains in the PCI scope. The additional cost of gateway processing does not justify the benefits.

911 Software Crediline offers the best value in "PCI Friendly" technologies by offering both the ability to be "ISO Friendly" and processing through the clearing houses directly, and the benefit of removing any and all secure payment information handling from the client's Point Of Sale source code.
→ See PCI Tokenization and Encapsulation for more info

Operating Systems Requirements

If EOL version of Windows is in your cardholder data environment (CDE), your business will fall out of compliance on the date of the EOL deadline, as announced by the manufacturer, regardless of when your annual compliance validation is scheduled to take place.

PCI DSS Requirement 6.2 states 

Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release. (Source: www.pcisecuritystandards.org)

Reference Documents

For all PCI and PA-DSS documents please see PCI Security Standards Web Site The security standards are evolving constantly. Please refer to the specified PA-DSS Requirements on the PCI Security Standards Web Site directly.

Dealer/Reseller & Customer Responsibilities

The new PA-DSS procedures include customers and end-users in the list of responsible parties. The following are the responsibilities of the end-users.

Sensitive Data Secure Storage

Handling of Sensitive Data

PA-DSS 1.1.5 (old 1.1.6), 9.1

• Collect sensitive authentication data only when needed to solve a specific problem. Remove as soon as it is no longer needed
• Collect only the limited amount of data needed to solve a specific problem. Encrypt sensitive authentication data while stored.
• Store such data only in specific, known locations with limited access.
• Securely delete such data immediately after use.
• Do not store cardholder data on Internet-accessible systems (e.g., web server and database server must not be on same server, PA-DSS 9.1).

CreditLine Sensitive Data Storage Locations

CreditLine stores sensitive data in secure format in the following directories:

• JOR (for multiple merchant setups it is JOR? where ? is the merchant index)
• LOG (for multiple merchant setups it is LOG? where ? is the merchant index) may contain encrypted sensitive data if such logging is enabled.

Sensitive Data Deletion

PA-DSS 1.1.4, 1.1.5, 2.7

Delete sensitive credit card software authentication data and cryptographic material (encryption keys, etc) stored by previous payment application versions. Performed automatically with a manual force option. To perform the operation manually, see Security Journal Cleanup

Key Rotation/Re-Encryption With New Keys

PA-DSS 1.1.4, 1.1.5, 2.7

Please, see Key Rotation

Life Span

PA-DSS 2.1

Purge cardholder data after customer-defined retention period. Performed automatically. The life span of the sensitive data in secure storage is determined by the backup settings in CreditLine Business Configuration.

Security Credentials

PA-DSS 3.1-3.2

System Credentials

Use unique user names and secure authentication to access any PCs, servers, and databases with payment applications and/or cardholder data, per PCI DSS Requirements 8.5.8 through 8.5.15. Do not use default administrative accounts for system

CreditLine Credentials

CreditLine uses an authentication mechanism separate from that of the operating system. A minimum secure level of the passwords is mandated by the application itself. Passwords that do not qualify as "strong" are automatically rejected. The Default account can no longer access sensitive data.

Security Audit Trail

PA-DSS 4.2, 10.2, 10.3

CreditLine logs contain a complete audit trail of logins and all actions performed on the secure and regular data. Secure data is either encrypted or absent in the logs, as mandated by PA-DSS. Life span of the audit trail (logs) is determined by the backup settings in CreditLine Business Configuration.

Secure Network Technologies

Wireless Network

PA-DSS 4.1.1, 6.1, 6.2

Firewall and strong encryption must be used if wireless network is used at the customer site.

Firewall

PA-DSS 10.1

Deliver and receive payment application updates via firewall only.

Remote and Non-Console Access

PA-DSS 11.2, 11.3, 12.1, 12.2, 13.1

• Securely implement remote access software with two-factor authentication (username and password and an additional authentication item such as a token)
• Implement and use SSH/VPN or SSL/TLS for encryption of any non-console administrative access to payment application or servers
• Use SSL for secure data transmissions whenever necessary and encrypt the data if sent via end-user messaging technologies.