padss implementation guidemultimedia.3m.com/mws/media/995633o/tender-retail...installation,...

PA-DSS Implementation Guide

Copyright © August 2012, Tender Retail

All rights reserved.

PA-DSS Implementation Guide - 2 -

Suite 400 – 2 Lansing Square, Toronto, Ontario M2J 4P8 •P 416 498 1200 • F 416 498 0255 • www.tender-retail.com

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



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



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.



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.



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,



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



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.



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



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.



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.



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.



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



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



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.



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



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



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 non-

compliance 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:

• multi_date.log

• terminalID_date.dg

• date.log

• date.rcp

• date.rct

Reference:

PA-DSS 4.2



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:



changes positions;





• Other security-related wireless vendor defaults must be changed, if applicable;

and




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



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



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;



• 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



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



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



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



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.



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.



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.



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:



changes positions;





• Other security-related wireless vendor defaults must be changed, if applicable;

and




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.



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



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



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.



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’



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



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



Please refer to ‘MCM Configuration Guide’ and ‘MCM User Guide’ documentation to

find more details on how to configure Merchant Connect Multi application.

padss implementation guidemultimedia.3m.com/mws/media/995633o/tender-retail...installation,...

Documents