| This article is part of the
Payment Processing Software Library
|Connect to it...|
|Set it up...|
|Learn to use it...|
|More Info ...|
→ Not finding all the answers? Try Knowledge Base!
- 1 911 Software PA-DSS Certification
- 2 PCI Friendly Program
- 3 Operating Systems Requirements
- 4 Reference Documents
- 5 Dealer/Reseller & Customer Responsibilities
- 5.1 Sensitive Data Secure Storage
- 5.2 Security Credentials
- 5.3 Security Audit Trail
- 5.4 Secure Network Technologies
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)
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
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.
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 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
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.
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.