Ready Theatre Systems RTS POS

Transcription

1 Ready Theatre Systems RTS POS PCI PA-DSS Implementation Guide Revision: 2.0 September, 2010 Ready Theatre Systems, LLC -

2 Table of Contents: Introduction to PCI PA DSS Compliance 2 Implementation Guide Overview 4 PCI PA-DSS Requirements and How They Apply to RTS POS: Requirement 1 5 Requirement 2 6 Requirement 3 8 Requirement 4 10 Requirement 5 12 Requirement 6 12 Requirement 7 14 Requirement 8 14 Requirement 9 15 Requirement Requirement Requirement Requirement Requirement PCI DSS Requirements and How They Apply to RTS POS: Requirement 2 19 Ready Theatre Systems, LLC 1

3 Introduction to PCI PA-DSS Compliance As a business entity that processes credit cards, in terms of both getting authorizations and processing sales, you are required to be compliant with the 'Payment Card Industry Data Security Standard' (PCI DSS). In order to meet this goal RTS must be compliant with the Payment Card Industry Payment Application-Data Security Standard (PCI PA- DSS). Our being a PCI PA-DSS compliant application does NOT however make you a PCI DSS compliant entity, you are still required to review the compliance documentation at: and take the necessary steps to obtain and maintain your appropriate PCI DSS compliant status. The PCI PA-DSS consists of 14 requirements that cover the handling, processing, and storage of credit card data. These sections are outlined below: Requirements: 1. Do not retain full magnetic strip, card validation code or value (CAV2, CID, CVC2, CVV2), or PIN block data 2. Protect stored cardholder data 3. Provide secure authentication features 4. Log payment application activity 5. Develop secure payment applications 6. Protect wireless transmissions 7. Test payment applications to address vulnerabilities 8. Facilitate secure network implementation 9. Cardholder data must never be stored on a server connected to the Internet 10. Facilitate secure remote software updates 11. Facilitate secure remote access to payment application 12. Encrypt sensitive traffic over public networks 13. Encrypt all non-console administrative access 14. Maintain instructional documentation and training programs for customers, resellers, and integrators More detailed information can be located at: Ready Theatre Systems, LLC 2

4 Introduction to PCI PA-DSS Compliance The goal of PCI PA-DSS is to help software vendors and others develop secure payment applications that do not store any prohibited data, such as full magnetic stripe, CVV2 or PIN data, and also ensure their payment applications support compliance with the PCI DSS. Payment applications that are sold, distributed or licensed to third parties are subject to the PCI PA-DSS requirements. In-house payment applications developed by merchants or service providers that are not sold to a third party are not subject to the PCI PA-DSS requirements, but must still be secured in accordance with the PCI DSS. As your software vendor Ready Theatre Systems (RTS) is responsible for the following: Creating PCI PA-DSS compliant applications that facilitate and do not prevent their customers PCI DSS compliance (The application cannot require an implementation or configuration setting that violates a PCI DSS requirement.) Following PCI DSS requirements whenever the vendor stores, processes or transmits cardholder data (for example, during customer troubleshooting) Creating an Implementation Guide, specific to each application, according to the requirements in the Payment Application Data Security Standard Educating customers, resellers, and integrators on how to install and configure the payment applications in a PCI DSS compliant manner. Ensuring payment applications meet PCI DSS requirements by successfully passing a PCI DSS review. Ready Theatre Systems, LLC 3

5 Implementation Guide Overview This Implementation Guide explains your and RTS' role in the security of your customers' credit card data; instructs you and your network administrator on what security settings to enable in regards to both your network and hardware; instructs you on secure RTS product implementation; and defines some of your responsibilities for meeting PCI DSS requirements. Following these guidelines does NOT make you PCI DSS compliant, nor does it guarantee your network's security. It is your responsibility, along with your network administrator, to ensure that your hardware and network systems are secure from internal as well as external intrusions. RTS makes no claims on the security of your network, nor of your level of being PCI DSS compliant. Anytime the RTS POS application is installed at your business, you are required to follow RTS' network specifications. You must review the current specifications and have your network administrator verify that the network you are running RTS over meets these specifications. This Implementation Guide is organized into 2 sections: PCI PA-DSS and PCI DSS requirements. Each section contains the following information: 1. An outline of the requirement 2. How the RTS application behaves in relation to the requirement 3. Any configuration you need to make in relation to the requirement Changes and Updates to the RTS POS PCI DSS Implementation Guide PCI DSS requires that this guide be reviewed and updated at least annually, however, this guide will also be updated any time a change is made to the RTS POS software that impacts one of the sections covered by the guide, or if the PCI DSS or PCI PA-DSS is updated. New versions of this guide can be found online at this URL: You should keep a copy of this guide for future reference. Ready Theatre Systems, LLC 4

6 PCI PA-DSS Requirements and How They Apply to RTS POS 7.1 Requirement 1: Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CVC2, CVV2), or PIN block data 1.1 Do not store sensitive authentication data after authorization (even if encrypted) RTS Behavior Relating to Requirement 1: 1.1 The RTS application does not store any sensitive authentication data. Customer Configuration Needs Relating to Requirement 1: 1.1 Due to the RTS application not storing any sensitive authentication data there is no configuration needed on your part, however, please be aware that you should make no attempt to store sensitive authentication data in any way, as this will put you out of PCI DSS compliance. In addition, even though there is no sensitive data collected by the RTS POS application, we are required to drawer your attention to the following guidelines from the PCI specifications: Collect sensitive authentication only when needed to solve a specific problem. Store such data only in specific, known locations with limited access. Collect only the limited amount of data needed to solve a specific problem. Encrypt sensitive authentication data while stored. Securely delete such data immediately after use. Ready Theatre Systems, LLC 5

7 Requirement 2: Protect stored cardholder data 2.1 Software vendor must provide guidance to customers regarding purging of cardholder data after expiration of customer-defined retention period. 2.6 Payment application must implement key management processes and procedures for cryptographic keys used for encryption of cardholder data. RTS Behavior Relating to Requirement 2: 2.1 The RTS POS application currently stores cardholder data in order to be able to batch out credit card transactions at the end of the night. This data is encrypted in line with the requirements of the PCI PA-DSS and cannot be viewed by any user of the RTS POS application. Once a batch has been successfully processed this cardholder data is deleted. If the batch fails to process it will remain on the disk until such a time when the batch is successfully processed. Batches in the RTS POS application are attempted twice each time a deposit is closed; this means that each failed batch will attempt to close each time you close a deposit (usually every day). In addition to this, the RTS POS application will stop allowing you to close deposits once five consecutive batches have failed and notify you that there is a problem. 2.6 Cardholder data in the RTS POS application is encrypted in line with the requirements outlined in the PCI PA-DSS standard, using the CryptoSys PKI library, which is NIST validated. The Public/Private keys used to facilitate this encryption are required to change periodically for security purposes, so the RTS POS application will change the keys each time the batching process is completed. We also provide a manual key method (see below). Customer Configuration Needs Relating to Requirement 2: 2.1 All of the cardholder data is handled by the RTS POS application automatically so there is no configuration or procedure you need to follow in regards to removing this data. 2.6 The RTS POS application provides a manual rekeying option in case you need to force a change of the encryption keys used in the protection of the cardholder data. Please be aware that this option can only be used when there are preauthorization transactions on the disk waiting to be batched out. Ready Theatre Systems, LLC 6

8 In order to access this option you would go to: Setup -> Credit Cards The following window will appear: In order to rekey manually click the Re-Key button, if rekeying is not available due to pre-authorizations being on the disk the RTS POS application will notify you. Ready Theatre Systems, LLC 7

9 Requirement 3: Provide Secure Password Features 3.1 The out of the box installation of the payment application in place at the completion of the installation process, must facilitate use of unique user IDs and secure authentication (defined at PCI DSS Requirements 8.1, 8.2, and ) for all administrative access and for all access to cardholder data. 3.2 Access to PCs, servers, and databases with payment applications must require a unique user ID and secure authentication. RTS Behavior Relating to Requirement 3: 3.1 As mentioned in Requirement 2, the credit card batch in RTS contains cardholder data (CHD) even though this data is encrypted and not viewable by you, RTS uses a system known as Secure Users inside the Credit Card configuration area to further secure this CHD. The Secure Users option allows for you to add unique user IDs and passwords for each user that will be administering the credit card processing information in RTS POS, and for each user that will be closing deposits (batching out credit cards) in the RTS POS application. 3.2 The RTS POS application runs within the Windows environment. Customer Configuration Needs Relating to Requirement 3: 3.1 When you first install a PCI PA-DSS compliant version of RTS POS it will prompt you to setup a Secure User account: Ready Theatre Systems, LLC 8

10 Also, when RTS Technical Support assists you in setting up your credit card processing information you will again be prompted to create a Secure User account: When creating a secure account the following limitations and guidelines should be understood and adhered to: Limitations: 1. Usernames must be unique 2. Passwords must contain at least 7 characters 3. Passwords must contain upper and lower case alphabetic characters 4. Passwords must contain at least 1 numerical character 5. Passwords will expire after 90 days and must then be changed 6. Passwords must not repeat any of the last four used Guidelines: 1. Group, shared, or generic accounts should not be used 2. Accounts will lock out after six failed attempts and will remain locked out for either 30 minutes or until unlocked by another secure user. 3. Account logins will time-out after 15 minutes of inactivity. Once a secure user has been added to the software, it can be used to manage other secure user accounts, or to view the access logs for the credit card settings. Ready Theatre Systems, LLC 9

11 3.2 You are advised to control access to your PCs and Servers by setting up Windows accounts with unique usernames and strong complex passwords. Requirement 4: Log Application Activity 4.2 Application must implement an automated audit trail to track and monitor access RTS Behavior Relating to Requirement 4: 4.2 Access and changes to credit card processing information, secure user accounts, rekeying, and the audit logs themselves are logged by the RTS POS application. Customer Configuration Needs Relating to Requirement 4: 4.2 Once Secure User accounts are setup (see above) logging of events relating to credit cards begins to be logged. All of these events are stored in an encrypted file which can be viewed by using the Change Log option located on the: Setup -> Credit Cards screen: Ready Theatre Systems, LLC 10

12 Below is a sample of the Access Log window: The above image shows the following: Successful access by user admin to the Change Log from PC named GARETHS Loading of Change Log data by user admin from PC named GARETHS Failed access attempt by user admin to the Secure User list from PC named GARETHS Successful access by user admin to the Secure User list from PC named GARETHS Addition of a new user test by user admin from PC named GARETHS Deletion of an existing user close by user admin from PC named GARETHS Successful access by user admin to the Change Log from PC named GARETHS Loading of Change Log data by user admin from PC named GARETHS IMPORTANT NOTES: This logging CANNOT be disabled. Accounts cannot be modified, only added or deleted. Card Holder Data: Due to the RTS POS application not allowing access to the CHD in the batch there is no logging relating to this item. In addition to the logging performed by the RTS POS application, it is important to maintain the use of any Operating System level logging that is available. Even though the RTS POS application does not write to the OS logs, only it s built in logs, it is important to maintain the logging of events that occur at the OS level. Ready Theatre Systems, LLC 11

13 Requirement 5: Develop secure payment applications 5.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. These processes must include the following: PCI Data Security Standard Requirement 6.3 RTS Behavior Relating to Requirement 5: 5.1 This requirement covers the development process of a PA-DSS compliant application and therefore is not applicable to customers, resellers or integrators. Customer Configuration Needs Relating to Requirement 5: 5.1 This requirement covers the development process of a PA-DSS compliant application and therefore is not applicable to customers, resellers or integrators. Requirement 6: Protect Wireless Transmissions 6.1 For wireless networks transmitting cardholder data, encrypt the transmissions by using Wi-Fi Protected Access (WPA or WPA2) technology, IPSEC VPN, or SSL/TLS. Never rely exclusively on wired equivalent privacy (WEP) to protect confidentiality and access to a wireless LAN. If WEP is used, do the following: Use with a minimum 104-bit encryption key and 24-bit initialization value. Use ONLY in conjunction with Wi-Fi Protected Access (WPA or WPA2) technology, VPN or SSL/TLS. Rotate shared WEP keys quarterly (or automatically if the technology permits). Rotate shared WEP keys whenever there are changes in personnel with access to keys. Restrict access based on media access code (MAC) address RTS Behavior Relating to Requirement 6: 6.1 The RTS application is able to use any network access method that is supported by Windows, thus it is possible that the application could be implemented into a wireless network environment. Ready Theatre Systems, LLC 12

14 Customer Configuration Needs Relating to Requirement 6: 6.1 If you are going to implement the RTS application in a wireless network environment, the following settings must be used to secure access to the wireless network: Enable the use of Wi-Fi Protected Access (WPA or WPA2), IPSEC VPN, or SSL/TLS technology on all wireless routers, access points, repeaters, etc If enabling Wired Equivalent Privacy (WEP), you must incorporate the following: Use with a minimum 104-bit encryption key and 24-bit initialization value. Use ONLY in conjunction with Wi-Fi Protected Access (WPA or WPA2) technology, VPN or SSL/TLS. Rotate shared WEP keys quarterly (or automatically if the technology permits). Rotate shared WEP keys whenever there are changes in personnel with access to keys. Restrict access based on media access code (MAC) address It is important to install a perimeter firewall between any wireless networks and the network that contains the RTS server and workstations. A rule should be added to the firewall to DENY access to all machines on the network that contains the RTS server and workstations, expect for approved wireless devices when needed. If wireless devices need to access the RTS server, a rule should be added to the firewall to only allow access for the approved wireless device(s), and this rule should only allow access to the RTS server, not the workstations. When using any wireless product it is important to change some of the default information contained within the device, this includes but is not limited to: Change default encryption keys Change default SNMP community strings Change default passwords for access points Update firmware to support strong encryption for authentication and data transmission. Ready Theatre Systems, LLC 13

15 Requirement 7: Test payment applications to address vulnerabilities 7.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. Any underlying software or systems that are provided with or required by the payment application (for example, web servers, 3rd-party libraries and programs) must be included in this process. RTS Behavior Related to Requirement 7: 7.1 This requirement covers the development process of a PA-DSS compliant application and therefore is not applicable to customers, resellers or integrators. Customer Configuration Needs Relating to Requirement 7: 7.1 This requirement covers the development process of a PA-DSS compliant application and therefore is not applicable to customers, resellers or integrators. Requirement 8: Facilitate secure network implementation 8.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). RTS Behavior Related to Requirement 8: 8.1 This requirement covers the development process of a PA-DSS compliant application and therefore is not applicable to customers, resellers or integrators. Customer Configuration Needs Relating to Requirement 7: 8.1 This requirement covers the development process of a PA-DSS compliant application and therefore is not applicable to customers, resellers or integrators. Ready Theatre Systems, LLC 14

16 Requirement 9: Cardholder Data Must Never be Stored on a Server Connected to the Internet 9.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. RTS Behavior Related to Requirement 9: 9.1 Due to the RTS POS application not utilizing a database server this requirement is not applicable to the RTS POS application. Customer Configuration Needs Relating to Requirement 9: 9.1 There is no configuration needed to meet this requirement, however, f your business requires a database server for any other applications you may run, please be sure to not install the database server on the machine that is acting as the RTS Server. Also, you should never place any Cardholder Data inside a DMZ as this will violate PCI compliance. Requirement 10: Facilitate Secure Remote Software Updates 10.1 If software updates are delivered via remote access into customers systems, software vendors must tell customers to turn on modem 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 personal firewall product to secure always-on connections. RTS Behavior Relating to Requirement 10: 10.1 Software updates for the RTS application are only downloaded at the customers initialization. The application connects to a secure (HTTPS) RTS managed server and downloads only approved updates. Customer Configuration Needs Relating to Requirement 10: 10.1 Due to the RTS application updates being initiated through an outbound (customer initiated) connection, there is no configuration that is required. However, you are advised to secure your PCs using Windows Firewall or some other firewall product. Ready Theatre Systems, LLC 15

17 Requirement 11: Facilitate Secure Remote Access to Application 11.1 The payment application must not interfere with use of a two-factor authentication mechanism. The payment application must allow for technologies such as RADIUS or TACACS with tokens, or VPN with individual certificates. RTS Behavior Relating to Requirement 11: 11.2 RTS Technical Support will sometimes need to connect remotely to your PCs running the RTS POS software, this is done through the use of a customer initiated UltraVNC SingleClick application which has been configured to use a Data Stream Modification (DSM) AES-256 Encryption plug-in (SecureVNC 32-bit or 64-bit) to provide a secure tunnel for the connection your location. Customer Configuration Needs Relating to Requirement 11: 11.2 The remote access method used by RTS Technical Support is setup to automatically create a secure connection, so there is no configuration required on your part. Customers who are intending to configure their PCs for remote access that does not use a customer initiated connection (e.g. remote access for their own use via UltraVNC or some other remote access package) should ensure the use of an encryption tunnel, such as a dedicated VPN connection, or an encryption package for their remote access package. In addition, be sure the use of twofactor authentication (user ID and password and an additional authentication item such as a smart card, token, or PIN) The remote access method used by RTS Technical Support is automatically set to use the DSM plug-in mentioned above. When requested by RTS Technical Support, the customer will initiate the outbound connection to RTS, which will be an encrypted tunnel between the customer and RTS. VNC activity is logged into the Event Viewer within Windows and can be accessed by going to: Control Panel -> Administrative Tools -> Event Viewer. In addition, if you choose to implement your own remote access method you must ensure that the method must use and implement remote access security features. Note: Examples of remote access security features include: 1. Change default settings in the remote access software (for example, change default passwords and use unique passwords for each customer). 2. Allow connections only from specific (known) IP/MAC addresses. Ready Theatre Systems, LLC 16

18 3. Use strong authentication and complex passwords for logins: according to PCI DSS Requirements 8.1, 8.3, and Enable encrypted data transmission according to PCI DSS Requirement Enable account lockout after a certain number of failed login attempts according to PCI DSS Requirement Configure the system so a remote user must establish a Virtual Private Network ( VPN ) connection via a firewall before access is allowed. 7. Enable the logging function. 8. Restrict access to customer passwords to authorized reseller/integrator personnel. 9. Establish customer passwords according to PCI DSS Requirements 8.1, 8.2, 8.4, and 8.5. The PCI DSS Requirements can be found here: Requirement 12: Encrypt Sensitive Traffic Over Public Networks 12.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. Examples of open, public networks that are in scope of the PCI DSS are: The Internet Wireless technologies Global System for Mobile Communications (GSM) General Packet Radio Service (GPRS) RTS Behavior Relating to Requirement 12: 12.1 The RTS POS application only transmits cardholder data to the credit card processing company; this transmission is IP based, using SSL technology for encryption. Customer Configuration Needs Relating to Requirement 12: 12.1 The RTS POS application automatically uses SSL technology to encrypt the transmission of cardholder data to the credit card processing company; no configuration is needed on your part. Ready Theatre Systems, LLC 17

19 In addition, no cardholder data is viewable by the users of the RTS POS application so this data cannot be transmitted, however, if you do transmit any RTS POS files please be sure to do so only over a secure connection (SSLv3, TLS, IPSEC, VPN, etc). Requirement 13: Encrypt All Non-Console Administrative Access 13.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. PCI Data Security Standard Requirement 2.3 Telnet or rlogin must never be used for administrative access. RTS Behavior Relating to Requirement 13: 13.1 There is no function in the RTS POS application to prevent non-console access Customer Configuration Needs Relating to Requirement 13: 13.1 Customers who are intending to remotely administer the RTS POS application via UltraVNC (or some other remote access method), over an open network, should ensure the use of an encryption tunnel, such as a dedicated VPN connection, or an encryption package for their remote access software. Requirement 14: Maintain instructional documentation and training programs for customers, resellers, and integrators 14.1 Develop, maintain, and disseminate a PADSS Implementation Guide for customers, resellers, and integrators. RTS Behavior Relating to Requirement 14: 14.1 RTS will annually review this guide for anything that needs to be updated or modified. If a change in the PCI DSS or PCI PA-DSS requires an update to this document a new version will be made available. Customer Configuration Needs Relating to Requirement 14: 14.1 Customers should periodically check the RTS web site for new versions of this guide. The web site URL is: ImplementationGuide.pdf Ready Theatre Systems, LLC 18

20 PCI DSS Requirements and How They Apply to RTS POS 7.1 Requirement 2 - Do Not Use Vendor-Supplied Defaults for System Passwords and Other Security Parameters Disable all unnecessary and insecure services and protocols (services and protocols not directly needed to perform the device s specified function). RTS Behavior Relating to PCI DSS Req. 2: The RTS software can automatically disable unnecessary services. Customer Configuration Needs Relating to PCI DSS Req. 2: The RTS software will automatically disable unnecessary services when the Windows Desktop is replaced, this should be done on all stations that are not used to administer the RTS system (selling stations). Any machines used to administer the RTS system (office machines) will usually not have the desktop replaced, so on those machines you should follow the steps below to disable Windows services: Go to: Setup -> Local Computer Choose the Other tab Click the Disable Services button Ready Theatre Systems, LLC 19