Difference between revisions of "PA-DSS Guide"
(→Where is our QAS or ROC?) |
(→Where is our QAS or ROC?) |
||
Line 11: | Line 11: | ||
==Where is our QAS or ROC?== | ==Where is our QAS or ROC?== | ||
− | + | You can find the latest QAS here: [http://911software.com/files/compliance/ Compliance Folder] | |
+ | However, see below for official statement by PCI counsel: | ||
<blockquote>''In addition to the official PCI SSC reporting forms and templates, some QSA or ASV companies provide certificates, letters or other documentation as confirmation that an organization is PCI DSS compliant. The PCI SSC does not prevent QSAs or ASVs from producing this type of documentation, as it is considered an additional service which the assessor company may elect to provide and is therefore outside of the purview of the Council. However, in accordance with the ethical requirements for QSA and ASV companies, any such certificates, letters and other documentation must be accurate and not be in any way misleading. Additionally, these certificates, letters and other documentation should be clearly identified as supplemental materials provided by the QSA or ASV; they should not be presented as documents endorsed by the PCI SSC, nor should they be considered replacements for the official PCI SSC templates and forms which have been approved by the payment brands. The PCI SSC website contains reporting templates and forms which have been approved by all payment brands, including ROC templates, Attestations of Compliance, Self-Assessment Questionnaires, and Attestations of Scan Compliance for ASV scans. Compliance validation and reporting requirements are determined by the individual payment card brands and, irrespective of whether an organization is performing a self-assessment or has an onsite review completed by a QSA company, acceptance of a validation method outside of those listed on the Council website is ultimately up to the entity accepting the validation (that is, the acquiring bank or payment card brand). In many cases, certificates, letters or other documentation issued by QSA or ASV companies outside of the official PCI SSC templates may not be accepted by acquiring banks or payment card brands. ASVs and QSAs should encourage their clients to check with their acquirer or the payment brands directly to determine their compliance reporting requirements, including whether the submission of such certificates is acceptable.''</blockquote> | <blockquote>''In addition to the official PCI SSC reporting forms and templates, some QSA or ASV companies provide certificates, letters or other documentation as confirmation that an organization is PCI DSS compliant. The PCI SSC does not prevent QSAs or ASVs from producing this type of documentation, as it is considered an additional service which the assessor company may elect to provide and is therefore outside of the purview of the Council. However, in accordance with the ethical requirements for QSA and ASV companies, any such certificates, letters and other documentation must be accurate and not be in any way misleading. Additionally, these certificates, letters and other documentation should be clearly identified as supplemental materials provided by the QSA or ASV; they should not be presented as documents endorsed by the PCI SSC, nor should they be considered replacements for the official PCI SSC templates and forms which have been approved by the payment brands. The PCI SSC website contains reporting templates and forms which have been approved by all payment brands, including ROC templates, Attestations of Compliance, Self-Assessment Questionnaires, and Attestations of Scan Compliance for ASV scans. Compliance validation and reporting requirements are determined by the individual payment card brands and, irrespective of whether an organization is performing a self-assessment or has an onsite review completed by a QSA company, acceptance of a validation method outside of those listed on the Council website is ultimately up to the entity accepting the validation (that is, the acquiring bank or payment card brand). In many cases, certificates, letters or other documentation issued by QSA or ASV companies outside of the official PCI SSC templates may not be accepted by acquiring banks or payment card brands. ASVs and QSAs should encourage their clients to check with their acquirer or the payment brands directly to determine their compliance reporting requirements, including whether the submission of such certificates is acceptable.''</blockquote> | ||
Revision as of 13:33, 14 August 2012
This article is part of the Payment Processing Software Library |
|
Get it... | |
Install it... | |
Connect to it... | |
Set it up... | |
Learn to use it... | |
→ Manual & User Guide | |
Fix it... | |
→ Errors & Troubleshooting | |
Get Help... | |
More Info ... | |
See also... | |
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!
Contents
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.
PA-DSS Definition
PA-DSS is the next generation PCI Security Guidelines that replaces the older PABP standard. The PABP program was created and overseen by Visa. Now, through PCI SSC, the five majorglobal payment brands (American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc.) will support the PA-DSS, allowing even greater opportunity to standardize security requirements, Qualified Security Assessor testing and lab methodologies, and approval processes for payment applications.
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.
Where is our QAS or ROC?
You can find the latest QAS here: Compliance Folder However, see below for official statement by PCI counsel:
In addition to the official PCI SSC reporting forms and templates, some QSA or ASV companies provide certificates, letters or other documentation as confirmation that an organization is PCI DSS compliant. The PCI SSC does not prevent QSAs or ASVs from producing this type of documentation, as it is considered an additional service which the assessor company may elect to provide and is therefore outside of the purview of the Council. However, in accordance with the ethical requirements for QSA and ASV companies, any such certificates, letters and other documentation must be accurate and not be in any way misleading. Additionally, these certificates, letters and other documentation should be clearly identified as supplemental materials provided by the QSA or ASV; they should not be presented as documents endorsed by the PCI SSC, nor should they be considered replacements for the official PCI SSC templates and forms which have been approved by the payment brands. The PCI SSC website contains reporting templates and forms which have been approved by all payment brands, including ROC templates, Attestations of Compliance, Self-Assessment Questionnaires, and Attestations of Scan Compliance for ASV scans. Compliance validation and reporting requirements are determined by the individual payment card brands and, irrespective of whether an organization is performing a self-assessment or has an onsite review completed by a QSA company, acceptance of a validation method outside of those listed on the Council website is ultimately up to the entity accepting the validation (that is, the acquiring bank or payment card brand). In many cases, certificates, letters or other documentation issued by QSA or ASV companies outside of the official PCI SSC templates may not be accepted by acquiring banks or payment card brands. ASVs and QSAs should encourage their clients to check with their acquirer or the payment brands directly to determine their compliance reporting requirements, including whether the submission of such certificates is acceptable.
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
Deadlines
- Jul 1, 08 – VNPs and agents must only certify new payment applications to their platforms that are PABP-compliant
- Aug 1, 08 – New payment application assessments will be assessed under the PA-DSS
- Oct 1, 08 – Newly boarded Level 3 and 4 merchants must be PCI DSS compliant or use PABP-compliant applications
- Jul 1, 10 – Acquirers must ensure their merchants, VNPs and agents use only PA-DSS-compliant applications
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
Re-encrypt sensitive authentication data. Performed automatically with a manual force option. See Security Journal Cleanup
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.