|
PA-DSS Implementation Guide
|
Top Previous Next |
| 1 | Payment Systems Security
|
|
|
| In order to address the growing national and international concern for securing credit card information, Visa began to develop standards and announced the Cardholder Information Security Program (CISP) in April, 2000. These standards became required in June, 2001, for all entities that store, process or transmit Visa cardholder data.
|
|
|
| Since that time, other credit card companies have become involved, and a new group called the Payment Card Industry Security Standards Council was formed to standardize security requirements across the entire credit card industry. The result is a new security standard called Payment Card Industry Data Security Standard (PCI-DSS or simply 'PCI') which is designed to ensure standardized compliance for multiple associations.
|
|
|
| This document is provided to guide users of Campground Master into becoming and remaining PCI compliant.
|
|
|
| 1.2 | Why you need to be concerned about this
|
|
|
| Credit Card companies are requiring compliance with PCI standards for every entity that is involved in the storage, processing, or transmission of credit card information. Failure to comply can result in denial or revocation of your organization's ability to process credit cards.
|
|
|
| Furthermore, as these standards have become widely recognized, non-compliance places your organization at risk of legal and/or civil consequences if credit card information becomes compromised.
|
|
|
| Compliance with PCI standards is necessary whether or not you use Campground Master to process transactions "online." Even if you use a POS terminal or other method to process transactions, and simply retain information in Campground Master, you must be concerned about proper use of the program to maintain security and confidentiality of customer data.
|
|
|
| As of October 1, 2008, Credit Card Processors and Bank Card Acquirers must only accept level 3 and 4 merchants that are PCI-DSS compliant or that utilize PA-DSS compliant applications.
|
|
|
| Beginning October 1, 2009, all payment applications which are not PA-DSS compliant will be de-certified.
|
|
|
| Beginning July 1, 2010, Credit Card Processors and Bank Card Acquirers must ensure that merchants and agents use only PA-DSS compliant applications.
|
|
|
| 1.3 | The PCI Data Security Standard
|
|
|
| The "PCI-DSS" is a multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design and other critical protective measures. This comprehensive standard is intended to help organizations proactively protect customer account data.
|
|
|
| To learn more about PCI, visit www.pcisecuritystandards.org.
|
|
|
| The standard must constantly evolve in order to remain viable in today's rapidly changing internet and computing environment. Thus, the PCI-DSS will be reviewed at least every 24 months, and can be updated at any time.
|
|
|
| Campground Master Version 6 has been certified as compliant under the Payment Application Data Security Standard (PA-DSS) 1.2. The PA-DSS is a separate security standard that applies to software vendors that develop applications for sale to merchants to process and/or store cardholder data. Just because Campground Master has been certified as PA-DSS 1.2 compliant does not automatically make you, as a merchant, PCI compliant. It is an important and necessary step toward that goal. Payment applications validated per the PA-DSS, when implemented in a PCI-DSS-compliant manner, will minimize the potential for security breaches leading to compromises of sensitive cardholder data, and the damaging fraud resulting from these breaches, and speed you on your way to PCI compliance.
|
|
|
| 2 | Merchant and Requirements for Compliance
|
| There are twelve basic requirements (organized in six areas) which a merchant must meet in order to become certified as PCI-compliant. Each of these requirements, along with POS Vendor's recommendations, is noted in this document. However, you must familiarize yourself with the details of each requirement as set forth in the PCI Data Security Standard documentation. (Refer to Section 4 "Resources" for guidance on where to get more information.) The following table lists the twelve basic requirements.
|
|
|
PCI Requirements
|
|
|
|
|
|
|
| 3 | Campground Master PCI Security Practices
|
| Because it has been certified as compliant under the PA-DSS 1.2 requirements, using Campground Master as a tool will support you in meeting some of your merchant requirements to become and remain PCI-DSS compliant. However, it is important that you use the software as designed, and that you follow certain practices and procedures internally both when you install the software and as you enter transactions.
|
|
|
| Compliance with PCI standards is necessary and you must be concerned about proper use of the program to maintain security and confidentiality of customer data. Therefore, the following sections provide guidance on how to implement and maintain the Campground Master application per PA-DSS requirements (as they relate to PCI) along with other general PCI security information.
|
|
|
| 4 | Securely implementing Campground Master
|
| 4.1 | Sensitive Authentication Data
|
|
|
| 1. | Go to Maintenance / Credit Cards / History/Security Cleanup.
|
| 2. | Click the button "Remove Swipe data and CVC codes from ALL transactions", then click Yes to proceed.
|
| 3. | Click the button "Remove Swipe data and CVC codes from ALL Guarantee info", then click Yes to proceed.
|
|
|
| 4.2 | Protect Stored Cardholder Data
|
|
|
|
|
|
|
| 4.3 | Secure Authentication Features
|
|
|
| a) | A default administrative login ("Administrator") exists in new databases. This operator login should not be used for entering payments, customer, or reservation data that may have credit card information, as it does not uniquely identify a user.
|
| b) | The default Administrator operator's password must be changed, or the default Administrator operator deleted in favor of a more unique administrative login. (through Maintenance / Park Setup / Operators). The first time a user attempts to log in with the default, they will automatically be prompted for a new password, and cannot continue without providing a new password.
|
| c) | Assign secure authentication (as per (d) below) to logins whenever possible.
|
| d) | To create PCI DSS-compliant secure logins, the Operator records must have "Force password change every 90 days" selected, "Complex password required" selected, and must have "Auto-Logout after" set to no more than 15 minutes.
|
| e) | Failure to follow the rules above will result in noncompliance with PCI DSS.
|
| PCI DSS Requirement 8.1: Assign all users a unique ID before allowing them to access system components or cardholder data.
|
|
|
| PCI DSS Requirement 8.2: In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users:
|
| · | Password or passphrase
|
| · | Two-factor authentication (for example, token devices, smart cards, biometrics, or public keys)
|
|
|
| 4.4 | PA-DSS Requirement 4.0
|
|
|
|
|
|
|
| 4.5 | Protect Wireless Transmissions
|
|
|
|
|
|
|
| · | For new wireless implementations, it is prohibited to implement WEP after March 31, 2009.
|
| · | For current wireless implementations, it is prohibited to use WEP after June 30, 2010.
|
| 4.6 | Systems Connected to the Internet
|
| 4.7 | Secure Remote Software Updates
|
| 4.8 | Secure Remote Access to Payment Application
|
|
|
| PCI DSS Requirement 4.1: Use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks. Examples of open, public networks that are in scope of the PCI DSS are:
|
| o | The Internet,
|
| o | Wireless technologies,
|
| o | Global System for Mobile communications (GSM), and
|
| o | General Packet Radio Service (GPRS).
|
|
|
|
|
| 4.9 | Encrypt Sensitive Traffic over Public Networks
|
|
|
| 4.10 | Encrypt all Non-console Administrative Access
|
|
|
|
|
| 5 | Appendix
|
|
|
| PCI-DSS Requirement 8
|
| Assign a Unique ID to each Person with Computer Access
|
| PCI DSS 8.1: Assign all users a unique ID before allowing them to access system components or cardholder data.
|
|
|
| PCI DSS 8.2: In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users:
|
| · | Password or passphrase
|
| · | Two-factor authentication (for example, token devices, smart cards, biometrics, or public keys)
|
| PCI DSS 8.3: Incorporate two-factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties. Use technologies such as remote authentication and dial-in service (RADIUS); terminal access controller access control system (TACACS) with tokens; or VPN (based on SSL/TLS or IPSEC) with individual certificates.
|
| PCI DSS 8.4: Render all passwords unreadable during transmission and storage on all system components using strong cryptography (defined in PCI DSS Glossary of Terms, Abbreviations and Acronyms).
|
|
|
| PCI DSS 8.5: Ensure proper user authentication and password management for non-consumer users and administrators on all system components as follows:
|
|
|
| PCI DSS 8.5.1: Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.
|
|
|
| PCI DSS 8.5.2: Verify user identity before performing password resets
|
|
|
| PCI DSS 8.5.3: Set first-time passwords to a unique value for each user and change immediately after first use
|
|
|
| PCI DSS 8.5.4: Immediately revoke access for any terminated users
|
|
|
| PCI DSS 8.5.5: Remove/disable inactive user accounts at least every 90 days.
|
|
|
| PCI DSS 8.5.6: Enable accounts used by vendors for remote maintenance only during the time period needed
|
|
|
| PCI DSS 8.5.7: Communicate password procedures and policies to all users who have access to cardholder data
|
|
|
| PCI DSS 8.5.8: Do not use group, shared, or generic accounts and passwords
|
|
|
| PCI DSS 8.5.9: Change user passwords at least every 90-days
|
|
|
| PCI DSS 8.5.10: Require a minimum password length of at least seven characters
|
|
|
| PCI DSS 8.5.11: Use passwords containing both numeric and alpha characters
|
|
|
| PCI DSS 8.5.12: Do not allow an individual to submit a new password that is the same as any of the last four passwords he or she has used.
|
|
|
| PCI DSS 8.5.13: Limit repeated access attempts by locking out the user ID after not more than six attempts.
|
|
|
| PCI DSS 8.5.14: Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.
|
|
|
| PCI DSS 8.5.15: If a session has been idle for more than 15 minutes, require the user to re-enter the password to reactivate the terminal.
|
|
|
| PCI DSS 8.5.16: Authenticate all access to any database containing cardholder data. This includes access by applications, administrators, and all other users.
|