Copyright August 2012, Tender Retail All rights reserved.
- 2 - Table of Contents Table of Contents... 2 Introduction... 4 Scope and Target Audience... 4 Recommendations... 4 Payment Card Industry Data Security Standard (PCI-DSS)... 5 Product Overview... 6 Configuration Types and Authorization Flow using Merchant Connect Multi... 7 Centralized Solution... 7 De-centralized Solution... 8 Authorization Flow... 9 Product Support... 9 Security Implementation Guidelines... 10 Security Best Practices... 10 Networking Guidelines... 10 Wireless Connection... 10 Remote Access... 11 System Privileges... 11 Password Safety... 11 Log Data... 11 Security Implementation Guidelines Payment Application Data Security Standard... 13 Delete Sensitive Authentication Data... 13 How to remove sensitive authentication data... 13 Data Retention... 16 Key Management... 16 Access Control... 17 Implement Automated Audit Trails... 18 Securely Implement Wireless Technology... 19 Do Not Store Cardholder Data on Servers Connected to the Internet.... 20 Payment Application Updates... 20 Two-factor Authentication for Remote Access... 21 Remote Access Software Security... 21 Secure transmissions of cardholder data... 23 Encrypt non-console administrative access... 23 Security Implementation Guidelines Payment Card Industry Data Security Standard... 24 Build and Maintain a Secure Network... 24 Protect Cardholder Data... 24 Maintain a Vulnerability Management Program... 24 Implement Strong Access Control Measures... 24 Regularly Monitor and Test Networks... 24
- 3 - Maintain an Information Security Policy... 25 Network Segmentation... 25 Access Control... 25 Information Security Policy/Program... 26 Pre Installation Security Requirements... 27 Remote Access... 28 Wireless Access Control... 29 Transport Encryption (Software)... 29 Employee Training and Monitoring... 30 Encrypted Config Files... 31 Credit Card Storage... 31 Configure a Payment Gateway... 31 Communication between POS and MCM... 32 Merchant Connect Multi Installation... 32 Merchant Connect Multi Configuration... 32
- 4 - Introduction Scope and Target Audience This guide covers the Merchant Connect Multi Linux application and is intended for POS providers and merchants who wish to implement the Merchant Connect Multi in accordance with guidelines set forth by the Payment Card Industry (PCI). Recommendations This document outlines Tender Retail s recommendations on how to integrate Merchant Connect Multi (MCM) into a PCI-compliant environment, as per the standards and regulations set forth by the PCI-DSS Council. A merchant s PCI-compliancy remains the responsibility of the Merchant. This document provides PCI-compliant and best practice recommendations regarding installation, configuration and operation of Tender Retail s MCM software only.
- 5 - Payment Card Industry Data Security Standard (PCI-DSS) The Payment Card Industry Data Security Standard is a set of rules and requirements which help to protect the credit card data environment and prevent hacking and fraudulent use of cardholder data. PCI-DSS is governed by the PCI-DSS Council which was founded by Visa, Mastercard and American Express in 2006. The main objectives of the PCI-DSS are as follows: Build and Maintain a Secure Network Protect Cardholder Data Maintain a Vulnerability Management Program Implement Strong Access Control Measures Regularly Monitor and Test Networks Maintain an Information Security Policy All merchants who handle Visa payments are required to perform at least some level of validation. The URL below directs you to Visa s Cardholder Information Security Program (CISP) and has complete details and validation procedures. http://www.visa.com/cisp A qualified security assessor is the only one who can validate your PCI compliance. A current list of assessors is maintained by the PCI and can be found at this URL: https://www.pcisecuritystandards.org/pdfs/pci_qsa_list.pdf Please refer to https://www.pcisecuritystandards.org/ for a detailed list of the PCI specifications.
- 6 - Product Overview Merchant Connect Multi is a multi-threaded server based card authorization and draft capture software package. It processes transactions interactively with POS software and their applicable financial institution. Transaction based processing is used to accommodate electronic payment transactions. The transactions are either based on an ASCII file or on a socket connection from the host application (POS system) to Multi. The program supports various financial hosts and the majority of the financial and administrative processes, including purchase, void and refund of credit, debit, loyalty and gift cards. The application also handles all communication requirements of the PIN entry device. MCM does the following to ensure PCI compliance: All MCM standard receipts are PCI-complaint All log files do not store/retain card numbers Store and Forward (SAF) data files are stored in an encrypted format using high secure 3DES encryption Quarterly PCI audits including network audits, network scan from outside of local network, code review and code audit,
- 7 - Configuration Types and Authorization Flow using Merchant Connect Multi Centralized Solution Centralized Solution allows processing multiple transactions from several POS stations using one centralized MCM Server
- 8 - De-centralized Solution De-centralized Solution allows processing multiple transactions from single POS station using one dedicated MCM Server usually installed on the same computer along with POS application.
- 9 - Authorization Flow 1. The POS initiates a transaction with the MCM server. 2. MCM Server collects all required information including Card Data and encrypted PIN number (for Non-EMV transactions only). 3. The authorization transaction is sent over the Internet or Private Network to Card Processor. 4. The authorization response is sent from the Card Processor to MCM. 5. The transaction response is sent back to the POS. Product Support Tender Retail provides exstended development and 24/7 Production support. For all Production Support calls phone number is +1-877-808-5445
- 10 - Security Implementation Guidelines Security Best Practices There are practices that must be enforced by the merchant to remain compliant. Review the following merchant responsibilities, and reference the PCI DSS website at http://www.pcisecuritystandards.org for the description of secure networks. Networking Guidelines The Merchant Connect Multi must be installed in a trusted network segment, not the DMZ to avoid exposing data to corruption or theft. Tender Retail recommends that all servers and stations be located on a dedicated subnet (network) and protected from the Internet by a firewall. Wireless Connection The application is not a wireless application and has not been developed to use wireless technology. As such, it does not require a wireless network and is not written to operate on mobile devices. Furthermore, the application is not bundled with applications requiring wireless connectivity. Recommended deployment of the application and systems supporting the application is through a wired network. If you choose to deploy a wireless network infrastructure to support communications between deployed systems, or you connect a wireless network to the environment supporting the Titan application, you must do so in a manner compliant with the current PCI DSS standards. The secure deployment of a wireless network is solely your responsibility. In order for you to achieve PCI DSS compliance, the following guidelines must be followed for deployment of a wireless network: Wireless encryption keys must be changed from default at installation, and must be changed anytime anyone with knowledge of the keys leaves the company or changes positions; Default SNMP community strings on wireless devices must be changed; Default passwords/passphrases on access points must be changed; Firmware on wireless devices must be updated to support strong encryption for authentication and transmission over wireless networks; Other security-related wireless vendor defaults must be changed, if applicable. Wireless networks transmitting cardholder data or connected to the cardholder environment must use industry best practices to implement strong encryption for authentication and transmission.
- 11 - If you have wireless network deployed within your environment and it is not part of your cardholder network, a firewall is required between any wireless networks and the cardholder data environment. The firewall must be configured to deny or control any traffic from the wireless environment into the cardholder data environment. Remote Access For security reasons, never install hardware or software that is not required. Remote access is no exception. If it must be installed, remote access to the payment application must be authenticated with two-factor authentication. Ensure strong encryption is enabled and all users have unique user names and passwords. Beware of support service companies which use remote access. Merchants should not share passwords, even if more than one merchant is being supported. Tender Retail recommends to merchant to have individual merchant control the user accounts and passwords or obtain in writing that the password supplied is unique only to them. System Privileges Administrative access is required to install all Payment Processing applications in the installation directory, with "directories create" permissions and "file change" permissions. Password Safety Passwords for user accounts should be strong strings at least eight characters in length and should include uppercase and lowercase letters as well as numbers. Adding special characters like:?,!, *, etc. increases the level of security. Never make the password the same as the user name and avoid common passwords and phrases such as hello, password, and administrator. Do not use any vendor-provided, default passwords. Doing so will render your system vulnerable and violate PCI DSS R2. Log Data PCI DSS R10 requires that all log data be retained for a minimum of 12 months. Configure all log settings to ensure compliance. It may be necessary to incorporate an offline storage procedure to reduce the amount of disk space used to store log data and still comply with the DSS logging requirement.
- 12 - The Merchant Connect Multi Configuration screen includes Diagnostic Flags which allows creation of the log files for communication issues between Merchant Connect Multi, the Host and the PINPad. Creating diagnostic files is highly recommended as it allows system troubleshooting and become a part of PA-DSS requirements. Disabling of log files creating could make the merchant non-compliant.
- 13 - Security Implementation Guidelines Payment Application Data Security Standard Delete Sensitive Authentication Data The application utilizes 3DES with a programmatic generate 168-Bit key for securing the storage of the credit card number and expiration date in accordance with PCI DSS 3.4. This data is stored in the OUT subfolder only which is under MCM folder. The card data is not stored in any other location by the application. It is the customer s responsibility to delete sensitive authentication data stored by previous payment application versions. - Historical data must be removed (magnetic stripe data, card validation codes, PINs, or PIN blocks stored by previous versions of the payment application. Such removal is absolutely necessary to maintain PCI DSS compliance How to remove sensitive authentication data Although MCM doesn t store any (clear) cardholder data, according to PCI DSS Requirement, it is strongly recommended to remove any log and temporary files created by previous versions of MCM according to PA-DSS Requirement 1.1.4 There are 4 locations that could hold log and temporary files created by previous versions: Merchant Connect Multi folder LOG subfolder under Merchant Connect Multi folder OUT subfolder under Merchant Connect Multi folder
- 14 - The log and temporary files need to be carefully reviewed and deleted from these 3 locations. Such removal is absolutely necessary for PCI-DSS compliance. Next sensitive files have to be removed from the application folders: File Name Location Description <TID>.dtl Out Folder Details of Transactions <TID>_batchNum.dtl Out Folder Trans. details from previous unsettled batch <TID>.esf Out Folder Pre Authorization <TID>.lsr Out Folder Last Sales Record <TID>.pat Out Folder Pre Authorization Details <TID>.pre Out Folder Pre Authorization <TID>.prt Out Folder Temporary Pre Auth <TID>.rsf Out Folder Reversal for SAF / Related to <TID>.esf <TID>.stl Out Folder When.dtl file processed changes to this file. <TID>_000x.saf Out Folder Processed SAF File <TID>_DeclinedOffline_Date.csv Out Folder Declined Master Card Transaction tmskeys_<tid>.xml Out Folder EMV Keys <TID>.rct Out Folder Last transaction receipt <TID>.rcp Out Folder Last transaction response <TID>_YYYYMMDD.dg Log Folder MCM to PINPAd and to Host communication log <TID>_YYYYMMDD.log Log Folder Terminal Log File YYYYMMDD.log Log Folder List of Processed Transactions YYYYMMDD.rcp Log Folder Response Structures for processed transactions YYYYMMDD.rct Log Folder Receipts copies for all processed transactions multi_yyyymmdd.log Log Folder POS to MCM communication log Serial32_YYYYMMDD.log Log Folder MCM Driver functionality Log file tmskeys_<tid>_yyyymmdd.log Log Folder EMV Log file tmskeys_yyyymmdd.log Log Folder EMV Log file tmskeys_emv_yyyymmdd.log Log Folder EMV Log file Serial32_YYYYMMDD.log MCM Root Folder MCM Driver functionality Log file
- 15 - Software Vendor, Customers & Resellers/Integrators: Troubleshoot any problems per the PA-DSS Implementation Guide and PA-DSS Requirement 1.1.5.a. Collection of sensitive authentication data only when needed to solve a specific problem Storage of such data in a specific, known location with limited access Collection of only a limited amount of data needed to solve a specific problem Encryption of sensitive authentication data while stored Secure deletion of such data immediately after use Software Vendor, Customers & Resellers/Integrators: Delete any sensitive data per the PA-DSS. Delete any sensitive authentication data (pre-authorization) gathered as a result of troubleshooting the payment application. Sensitive authentication data (pre-authorization) must only be collected when needed to solve a specific problem Such data must be stored only in specific, known locations with limited access Only collect a limited amount of such data as needed to solve a specific problem Sensitive authentication data must be encrypted while stored Such data must be securely deleted immediately after use. This kind of data could be removed manually from Log folder. It has to be DoD standard delete that wipes the data. Reference: PA-DSS 1.1.4, 1.1.5 Tender Retail Support team usually requires next log files created by MCM during transaction processing for troubleshooting purposes: multi_date.log terminalid_date.dg date.log date.rcp date.rct All these files need to be removed from any customer and vendor storage places and emails after completion of troubleshooting process.
- 16 - Data Retention Cardholder data must be purged after it exceeds the customer-defined retention period. Merchant/POS vendor needs to control and maintain purging log and temporary files created by MCM in accordance with merchant-defined retention period according to PA-DSS Requirement. MCM windows based software provides a built-in trace / log file maintenance tool which allows controlling retention period. The Retention period should be reviewed or configured using Trace/Log File Maintenance option within the MCM Configuration Menu. Please refer to MCM User Guide for more details. The files under Linux based MCM have to be maintained manually. Please refer to Delete Sensitive Authentication Data section for the file list and locations. Reference: PA-DSS 2.1 Key Management MCM updates automatically old cryptographic material after expiration or during MCM software updates per PA-DSS Implementation Guide and PA-DSS Requirement. MCM uses Master and Working cryptographic keys to work with card information which has to be temporarily stored on the local disk. Master key will be used to encrypt and decrypt (3DES 168 bits) the Working key. The Master key is created by using 3 different components, which are stored separately in different locations. Multi recreates the Master key using 3 components when it is required. There is no assembled Master key stored on the machine. The Master key will have expiration date which is 1 year from creation. MCM has option to force regeneration Master key s components if or as required. Working key will be used for encryption and decryption (3DES 168 bits) of sensitive card information stored in any MCM file. The Working key will be created by using 2 different components. The components of the encrypted Working Key will be stored in different locations on the local machine and it will be recreated as required. The expiration period of Working key is 1 year. MCM has the option to force regeneration of Working key at the same time when Master key is forcefully rebuilt. Windows based MCM provides Generate New Keys command under Configuration menu which could be used to regenerate new keys manually prior to expiration and upon requirement. MCM manages Working key s history and storing previous Working key. Expired
- 17 - Working keys will be used for decryption of files created prior to the key expiration. Any new data will be encrypted using current valid Working key. Reference: PA-DSS 2.7 Access Control Use unique user IDs and secure authentication for administrative access and access to cardholder data. Do not use default administrative accounts for payment application logins. Assign secure authentication to default accounts (even if not used), and disable or do not use the accounts. Use secure authentication for the payment application and system whenever possible. Use trusted certificates and RSA tokens to create secure authentication to access the payment application, per PCI DSS Requirements 8.5.8 through 8.5.15. Ensure payment application supports customer s use of unique user IDs and secure authentication for payment application accounts/passwords, per PCI DSS Requirements 8.1 and 8.2. Establish and maintain unique user IDs and secure authentication per the PA- DSS Implementation Guide and PCI DSS Requirements 8.1 and 8.2. Use unique user IDs and secure authentication for access to PCs, servers, and databases with payment applications. 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. Software Vendor: Ensure payment application supports customer s use of unique user IDs and secure authentication for accounts/passwords if set by vendor to access PCs, servers, and databases, per PCI DSS Requirements 8.1, 8.2, and 8.5.8 8.5.15. Customers & Resellers/Integrators: Establish and maintain unique user IDs and secure authentication per the PA-DSS Implementation Guide and PCI DSS Requirements 8.1, 8.2, and 8.5.8 8.5.15. Changing strongly recommended default installation settings for unique user IDs and secure authentication will result in non-compliance with PCI DSS. Reference: PA-DSS 3.1, 3.2
- 18 - Implement Automated Audit Trails Establish and maintain PCI DSS-compliant logs per the PA-DSS Implementation Guide and PCI DSS Requirement 10. Application and system logs must be enabled, and disabling the logs will result in noncompliance with PCI DSS. Next log files are creating and rotating by MCM application every day and capture all events during processing transaction between MCM and POS and between MCM and Card Processor: Reference: PA-DSS 4.2 multi_date.log terminalid_date.dg date.log date.rcp date.rct
- 19 - Securely Implement Wireless Technology The application is not a wireless application and has not been developed to use wireless technology. As such, it does not require a wireless network and is not written to operate on mobile devices. Furthermore, the application is not bundled with applications requiring wireless connectivity. Recommended deployment of the application and systems supporting the application is through a wired network. If you choose to deploy a wireless network infrastructure to support communications between deployed systems, or you connect a wireless network to the environment supporting the Titan application, you must do so in a manner compliant with the current PCI DSS standards. The secure deployment of a wireless network is solely your responsibility. In order for you to achieve PCI DSS compliance, the following guidelines must be followed for deployment of a wireless network: Wireless encryption keys must be changed from default at installation, and must be changed anytime anyone with knowledge of the keys leaves the company or changes positions; Default SNMP community strings on wireless devices must be changed; Default passwords/passphrases on access points must be changed; Firmware on wireless devices must be updated to support strong encryption for authentication and transmission over wireless networks; Other security-related wireless vendor defaults must be changed, if applicable; and Wireless networks transmitting cardholder data or connected to the cardholder environment must use industry best practices to implement strong encryption for authentication and transmission. If you have wireless network deployed within your environment and it is not part of your cardholder network, a firewall is required between any wireless networks and the cardholder data environment. The firewall must be configured to deny or control any traffic from the wireless environment into the cardholder data environment. Reference: PA-DSS 6.1, 6.2
- 20 - Do Not Store Cardholder Data on Servers Connected to the Internet. Do not store cardholder data on Internet-accessible systems (for example, web server and database server must not be on same server). Store cardholder data only on servers not connected to the Internet. Merchants & Integrators: Establish and maintain payment applications so that cardholder data is not stored on Internet-accessible systems, per the PA-DSS Implementation Guide and PCI-DSS Requirement. Reference: PA-DSS 9.1 PCI DSS Requirement 1.3.4 Payment Application Updates The customer must ensure that they receive remote payment application updates from vendor securely, per the PA-DSS Implementation Guide and PCI DSS Requirements 1, 1.3.9, and 12.3.9. Receive remote payment application updates via secure modems, per PCI DSS Requirement 12.3. If computer is connected via VPN or other high-speed connection, receive remote payment application updates via a firewall or a personal firewall per PCI DSS Requirement 1 or 1.3.9. MCM does not support automatic remote update. All MCM updates will be delivered by Tender Retail through the secure Website using SSL encryption, via a firewall as per PCI- DSS Requirements. Reference: PA-DSS 10.1 PCI DSS Requirement 1, 1.3.9, 12.3, 12.3.9
- 21 - Two-factor Authentication for Remote Access Use two-factor authentication (user ID and password and an additional authentication item such as a token) if the payment application may be accessed remotely. If a merchant allows Tender Retail to remotely access MCM for troubleshooting purposes they must include features specified under PA-DSS Requirement 11.3.a. which include two-factor authentication for remote access to payment application, per the PA- DSS Implementation Guide and PCI-DSS Requirement 8.3. Two-factor authentication requires using RSA tokens or certificates along with user names and passwords. Reference: PA-DSS 11.2 PCI DSS Requirement 8.3 Remote Access Software Security Implement and use remote access software security features if remote access software is used to remotely access the payment application or payment environment. The application does not support remote access capabilities. However, the underlying Windows Operating System (O/S) does support remote access. You, as a merchant, may choose to utilize these remote access capabilities, but in order to maintain PCI DSS compliance only remote access technology supporting two-factor authentication (consisting of something you know, are or have) may be used. Two-factor authentication is required for remote access in order for you to maintain your PCI DSS compliance. In addition to the use of two-factor authentication, it is important to remember that the remote access capability should only be enabled when needed and disabled when no longer required. Furthermore, your remote access software must provide for the following features or configuration settings: You must ensure changes are made to the default setting in the remote access software; Remote access software must be configured to only allow access from specific IP addresses; Encrypted data transmissions such as IPSEC VPN, SSH, 128-Bit SSL v3.0 or must enforced; Access to customer passwords must be restricted to authorized personnel; Logging of remote access must be enabled;
- 22 - Systems must be configured so a remote user must establish a Virtual Private Network ( VPN ) connection via a firewall before access is allowed; Unique user IDs must be used for each user account; Authentication composed of passwords and two-factor authentication must be used for remote access; Remote access must not require or use any group, shared, or generic accounts or passwords; Passwords must change every ninety (90) days or less; Passwords must be a minimum of seven (7) characters; Passwords must contain both numeric and alphabetic characters; Password history of the last four (4) passwords must be kept and new passwords must be different than any of the last four (4) passwords; Account lockout must occur after six (6) invalid logon attempts; Remote access accounts must be locked out for no less than thirty (30) minutes or until reset by a system administrator; and Remote access sessions must timeout after no more than fifteen (15)minutes of inactivity. Note: All remote non-console administrative access to the payment application or servers in the environment must be encrypted utilizing SSH, VPN, SSL/TLS or other encryption technology in order to maintain PCI DSS compliance. Reference: PA-DSS 11.3
- 23 - Secure transmissions of cardholder data Implement and use SSL for secure cardholder data transmission over public networks, in accordance with PCI DSS Requirement 4.1 Software Vendor: Ensure payment application supports customer s use of secure transmissions of cardholder data over public networks, per PCI DSS Requirement 4. Customers & Resellers/Integrators: Establish and maintain secure transmissions of cardholder data, per the PA-DSS Implementation Guide and PCI DSS Requirement 4. Any files including PAN (customer card data) information have to be encrypted if they need to be sent through email or other means. Encrypt all PANs sent with end-user messaging technologies, per the PA-DSS Implementation Guide and PCI-DSS Requirement 4.2. Reference: PA-DSS 12.1 Encrypt non-console administrative access Encrypt non-console administrative access. Implement and use SSH, VPN, or SSL/TLS for encryption of any non-console administrative access to payment application or servers in cardholder data environment. Software Vendor: Ensure payment application supports customer s encryption of any non-console administrative access, per PCI DSS Requirement 2.3. Customers & Resellers/Integrators: Encrypt all non-console administrative access, per the PA-DSS Implementation Guide and PCI DSS Requirement 2.3. Reference: PA-DSS 13.1
- 24 - Security Implementation Guidelines Payment Card Industry Data Security Standard In 2006 American Express, Discover Financial Services, JCB, MasterCard Worldwide, and Visa International formed the Payment Card Industry Security Standards Council. The main purpose of the council is to produce and maintain the Data Security Standard (DSS). This is a set of rules and requirements that when followed will help prevent fraud, hacking, and other threats to private cardholder data. The main objectives of the PCI DSS are as follows: Build and Maintain a Secure Network Install and maintain a firewall configuration to protect cardholder data Do not use vendor-supplied defaults for system passwords and other security parameters Protect Cardholder Data Protect stored cardholder data Encrypt transmission of cardholder data across open, public networks Maintain a Vulnerability Management Program Use and regularly update anti-virus software Develop and maintain secure systems and applications Implement Strong Access Control Measures Restrict access to cardholder data by business need-to-know Assign a unique ID to each person with computer access Restrict physical access to cardholder data Regularly Monitor and Test Networks Track and monitor all access to network resources and cardholder data Regularly test security systems and processes
- 25 - Maintain an Information Security Policy Maintain a policy that addresses information security You can find and review the complete specification by visiting the URL below. https://www.pcisecuritystandards.org/tech/index.htm This guide is intended to help merchants implement the COMPANY applications in a way that is compliant with version 1.1 of the PCI DSS and PCI DSS Payment Application Environment Requirements Network Segmentation The PCI DSS requires that firewall services be used (with NAT or PAT) to segment network segments into logical security domains based on the environmental needs for internet access. Traditionally, this corresponds to the creation of at least a DMZ and a trusted network segment where only authorized, business-justified traffic from the DMZ is allowed to connect to the trusted segment. No direct incoming internet traffic to the trusted application environment can be allowed. Additionally, outbound internet access from the trusted segment must be limited to required and justified ports and services. Access Control The PCI DSS requires that access to all systems in the payment processing environment be protected through use of unique users and complex passwords. Unique user accounts indicate that every account used is associated with an individual user and/or process with no use of generic group accounts used by more than one user or process. Additionally any default accounts provided with operating systems, databases and/or devices should be removed/disabled/renamed as possible, or at least should have PCI DSS compliant complex passwords and should not be used. Examples of default administrator accounts include administrator (Windows systems), sa (SQL/MSDE). The PCI standard requires the following password complexity for compliance: Passwords must be at least 7 characters Passwords must include both numeric and alphabetic characters Passwords must be changed at least every 90 days New passwords cannot be the same as the last 4 passwords
- 26 - PCI user account requirements beyond uniqueness and password complexity are listed below: If an incorrect password is provided 6 times the account should be locked out Account lock out duration should be at least 30 min. (or until an administrator resets it) Sessions idle for more than 15 minutes should require re-entry of username and password to reactivate the session. These same account and password criteria must also be applied to any applications or databases included in payment processing to be PCI compliant Information Security Policy/Program In addition to the preceding security recommendations, a comprehensive approach to assessing and maintaining the security compliance of the payment application environment is necessary to protect the organization and sensitive cardholder data. The following is a very basic plan every merchant/service provider should adopt in developing and implementing a security policy and program: Read the PCI DSS in full and perform a security gap analysis. Identify any gaps between existing practices in your organization and those outlined by the PCI requirements. Once the gaps are identified, determine the steps to close the gaps and protect cardholder data. Changes could mean adding new technologies to shore up firewall and perimeter controls, or increasing the logging and archiving procedures associated with transaction data. Create an action plan for on-going compliance and assessment. Implement, monitor and maintain the plan. Compliance is not a one-time event. Regardless of merchant or service provider level, all entities should complete annual self-assessments using the PCI Self Assessment Questionnaire. Call in outside experts as needed. Visa has published a Qualified Security Assessor List of companies that can conduct on-site CISP compliance audits for Level 1 Merchants, and Level 1 and 2 Service Providers. MasterCard has published Compliant Security Vendor List of SDP-approved scanning vendors as well.
- 27 - Pre Installation Security Requirements Although MCM doesn t store any sensitive unencrypted financial data on the local Point of Sale (POS), it is strongly recommended that the following pre-installation security measures be completed to prevent unauthorized access to the server / POS resources and to protect the POS functionality: Update Operation System with latest security features and patches (Please refer to the Operation System provider for more details). Install and update latest version Antivirus, firewall and other security software required by Merchant PCI-DSS implementation policy. Update Antivirus definitions files on daily basis. Remove any non-relevant primary operation software which can access network and could create backdoor access to the system for unauthorized persons. Remove any non-required sharing permissions from local machine resources. Setup unique complex usernames and user permissions including complex passwords to access local resources according to PCI DSS Requirement 8.1-8.3 and 8.5.8 8.5.15 including disabling of any guest user accounts and disabling or renaming default administrative accounts.
- 28 - Remote Access The application does not support remote access capabilities. However, the underlying Windows Operating System (O/S) does support remote access. You, as a merchant, may choose to utilize these remote access capabilities, but in order to maintain PCI DSS compliance only remote access technology supporting two-factor authentication (consisting of something you know, are or have) may be used. Two-factor authentication is required for remote access in order for you to maintain your PCI DSS compliance. In addition to the use of two-factor authentication, it is important to remember that the remote access capability should only be enabled when needed and disabled when no longer required. Furthermore, your remote access software must provide for the following features or configuration settings: You must ensure changes are made to the default setting in the remote access software; Remote access software must be configured to only allow access from specific IP addresses; Encrypted data transmissions such as IPSEC VPN, SSH, 128-Bit SSL v3.0 or must enforced; Access to customer passwords must be restricted to authorized personnel; Logging of remote access must be enabled; Systems must be configured so a remote user must establish a Virtual Private Network ( VPN ) connection via a firewall before access is allowed; Unique user IDs must be used for each user account; Authentication composed of passwords and two-factor authentication must be used for remote access; Remote access must not require or use any group, shared, or generic accounts or passwords; Passwords must change every ninety (90) days or less; Passwords must be a minimum of seven (7) characters; Passwords must contain both numeric and alphabetic characters; Password history of the last four (4) passwords must be kept and new passwords must be different than any of the last four (4) passwords; Account lockout must occur after six (6) invalid logon attempts; Remote access accounts must be locked out for no less than thirty (30) minutes or until reset by a system administrator; and Remote access sessions must timeout after no more than fifteen (15)minutes of inactivity. Note: All remote non-console administrative access to the payment application or servers in the environment must be encrypted utilizing SSH, VPN, SSL/TLS or other encryption technology in order to maintain PCI DSS compliance.
- 29 - Wireless Access Control The PCI standard requires the encryption of cardholder data transmitted over wireless connections. The following guidelines must be followed for wireless remote access to payment application: Wireless encryption keys must be changed from default at installation, and must be changed anytime anyone with knowledge of the keys leaves the company or changes positions; Default SNMP community strings on wireless devices must be changed; Default passwords/passphrases on access points must be changed; Firmware on wireless devices must be updated to support strong encryption for authentication and transmission over wireless networks; Other security-related wireless vendor defaults must be changed, if applicable; and Wireless networks transmitting cardholder data or connected to the cardholder environment must use industry best practices to implement strong encryption for authentication and transmission. Transport Encryption (Software) The PCI DSS requires the use of strong cryptography and encryption techniques with at least a 128 bit encryption strength (either at the transport layer with SSL or IPSEC; or at the data layer with algorithms such as RSA or Triple-DES) to safeguard sensitive cardholder data during transmission over public networks (this includes the Internet and Internet accessible DMZ network segments). Additionally, PCI requires that cardholder information is never sent via email without strong encryption of the data. Software does not transmit card information via e-mail. The use of a properly installed 128 bit SSL certificate, available from your hosting provider or VeriSign, meets this requirement. Therefore during setting up Software you will need to apply an SSL Certificate. Please see SSL Certificate Installation Instructions to apply your certificate.
- 30 - Employee Training and Monitoring The greatest threat to your data comes from your own employees. Be sure to give your employees proper instruction with regard to your policies regarding cardholder data. Create a set of written policies and procedures to maintain the integrity of your secure environment. Restrict the number of employees who have access to the cardholder data to only those who have a business need. Each employee who has access to security application areas on the POS or servers such as places where card information is stored or Windows folder which holding parts of the encryption keys, needs to sign key custodian form which is required since data is retained temporarily by application (The template is below): Sample Key Custodian Form All Company staff that hold responsible authorized positions where they manage or handle encryption keys must sign the following document. As a condition of continued employment with Company, and as an employee that has access to key management tools and equipment, you are obligated to sign the following to indicate acceptance of your responsibility. The signatory of this document is in full employment with Company on the date shown below and has been afforded access to key management devices, software and equipment, and hereby agrees that, he or she 1. Has read and understood the policies and procedures associated with key management and agrees to comply with them to the best of his/her ability, and has been trained insecurity awareness and has had the ability to raise questions and has had those questions answered satisfactory; 2. Understands that non-compliance with the key management procedures can lead to disciplinary action including termination and prosecution. Exceptions to compliance only occur where such compliance would violate local, state,or federal law, or where a senior officer of the company or law enforcement officer has given prior authorization; 3. Agrees to never divulge to any third party any key management or related security systems, passwords, processes, security hardware or secrets associated with the Company systems, unless authorized by an officer of the Company or required to do so by law enforcement officers; and
- 31-4. Agrees to report promptly and in full to the correct personnel, any suspicious activity including but not limited to key compromise or suspected key compromise. Suspicious activity can include: signs of unauthorized equipment usage during evenings and weekends, phone requests from unidentifiable callers for access to secure information, unidentifiable files found on file servers, and unusual activity recorded in log files. I agree to the above and understand that this original copy will be held on my personnel record and kept by the company indefinitely. Signed: Print Name: Date: Encrypted Config Files The database.config and encryption.config files are saved in an encrypted form, so that your connection string and encryption key remain protected. Credit Card Storage When merchant does not require card details once a transaction has been successfully authorized, the card numbers need to be stored in partial format for reference only. Configure a Payment Gateway A payment gateway allows merchants to communicate with third party payment processors to handle credit card transactions for your merchant. There are two ways to configure MCM to communicate to financial institution: IP through public Internet IP frame through private VPN network
- 32 - MCM supports SSL for secure cardholder data transmission over public networks, in accordance with PCI-DSS Requirement 4.1. The PCI-DSS requires the use of strong cryptography and encryption techniques with at least a 128 bit encryption strength (either at the transport layer with SSL or IPSEC; or at the data layer with algorithms such as RSA or Triple-DES) to safeguard sensitive cardholder data during transmission over public networks. Establish and maintain secure transmissions of cardholder data, per the PA-DSS Implementation Guide and PCI-DSS Requirement 4. Communication between POS and MCM MCM supports customer s encryption of PANs according to PCI-DSS Requirement 4.2. PCI -DSS requires the use of strong cryptography and encryption techniques with at least 128 bit encryption strength (either at the transport layer with SSL or IPSEC) to secure sensitive cardholder data during transmission over networks. If cardholder data is not required for POS processes then it is strongly recommended to configure MCM with card information disabled in the response to POS (or masking). Merchant Connect Multi Installation Merchant Connect Multi (MCM) is installed using the MCM Installation kit which is delivered via mail (on CD) or may be downloaded directly from our support website at http://www.tender-retail.com. Windows version of MCM could be install using installation kit which is once received, double click the Setup.exe file to begin the installation wizard which will guide you through the rest of the installation process. Linux version is required manually creating MCM folder and coping all provided MCM application files. Merchant Connect Multi Configuration The CCTAG configuration file allows you to customize your merchant information, processor connectivity settings and various device settings. It is used for both Windows and Linux versions. Once configuration files are created, they can to be copied into Linux box.
- 33 - A client is a POS device or cash register that accepts card payments. Each client has data that is specific to it; some of this data is specific to the host processor, while some is related to the network and communications. Each client has a unique terminal ID and therefore its own CCTAG file. The data entered within the CCTAG file is saved using the CCTAG File Maintenance interface. Configuring several terminals requires serial loading of all configuration files, which were created for each client/terminal. Each Authorization Terminal ID must be unique when configured on the Merchant Connect Multi server. There are two ways to configure the Merchant Connect Multi server: by copying and loading a pre-configured CCTAG file (that was created on another server or copied during backup process) by creating and loading a new CCTAG configuration file (using CCTAG File Maintenance Interface) The following steps are required to start the Merchant Connect Multi configuration process: Loading a pre-configured CCTAG file 1. Run Multi.exe 2. Select Configuration
- 34-3. Select ADD Existing Files/Terminals 4. Choose an existing CCTAG configuration file under Open window 5. Press the Open button on the Open window 6. The Terminal configuration will be shown as loaded on the MCM main screen. 7. The Terminal information may then be reviewed and edited, if required by using the CCTAG File Maintenance interface Creating a New CCTAG file 1. Run Multi.exe 2. Select Configuration menu
- 35-3. Select Add New File/Terminal 4. At this point, the server will open the CCTAG File Maintenance interface. 5. Once all details have been reviewed (as we discuss below) and updated, select File and choose Save or Save As to store updated data and load it to the server
- 36 - Please refer to MCM Configuration Guide and MCM User Guide documentation to find more details on how to configure Merchant Connect Multi application.