PCI Guidance V19 - POS, Cash Registers, Restaurant

- 1 -

Proprietary and Confidential Information

Restaurant Manager PCI Guidance for

Software, Installation, Server Network, Wireless, & Operations

Versions 19

Last Update: 12/27/2013

Document OwnerJohn Raffenbeul

Product Specialist

Action Systems Inc

Copyright 2013 ASI Inc

- 2 -


NoticeTHE INFORMATION IN THIS DOCUMENT IS FOR INFORMATIONAL PURPOSES ONLY. ASI MAKES NO REPRESENTATION OR WARRANTY AS TO THE ACCURACY OR THE COMPLETENESS OF THE INFORMATION CONTAINED HEREIN. YOU ACKNOWLEDGE AND AGREE THAT THIS INFORMATION IS PROVIDED TO YOU ON THE CONDITION THAT NEITHER ASI NOR ANY OF ITS AFFILIATES OR REPRESENTATIVES WILL HAVE ANY LIABILITY IN RESPECT OF, OR AS A RESULT OF, THE USE OF THIS INFORMATION. IN ADDITION, YOU ACKNOWLEDGE AND AGREE THAT YOU ARE SOLELY RESPONSIBLE FOR MAKING YOUR OWN DECISIONS BASED ON THE INFORMATION HEREIN.

Nothing herein shall be construed as limiting or reducing your obligations to comply with any applicable laws, regulations or industry standards relating to security or otherwise including, but not limited to, PA-DSS and DSS.

The reseller and end user may undertake activities that may affect compliance. For this reason, ASI is required to be specific to only the standard software provided by it.

- 3 -


About this DocumentThis document describes the steps that must be followed in order for your ASI installations to comply with Payment Application – Data Security Standards (PA-DSS). The information in this document is based on PCI Security Standards Council Payment Application Data Security Stand-ards program (version 2.0 dated October, 2010).

ASI instructs and advises its customers to deploy ASI applications in a manner that adheres to the PCI Data Security Standard (v2.0). Subsequent to this, best practices and hardening meth-ods, such as those referenced by the Center for Internet Security (CIS) and their various “Bench-marks”, should be followed in order to enhance system logging, reduce the chance of intrusion and increase the ability to detect intrusion, as well as other general recommendations to secure networking environments. Such methods include, but are not limited to, enabling oper-ating system auditing subsystems, system logging of individual servers to a centralized logging server, the disabling of infrequently-used or frequently vulnerable networking protocols and the implementation of certificate-based protocols for access to servers by users and vendors.

You must follow the steps outlined in this Implementation Guide in order for your Res-taurant Manager installation to support your PCI DSS compliance efforts.

- 4 -


Revision Information

Name Title Date of Update Summary of Changes

Implementation Guide

Restaurant Manager PCI Guidance

12/27/2013Create document to reflect changes form PA-DSS 1.2.1 to 2.0

V19 NETePayRestaurant Manager PCI Guidance

12/27/2013Restaurant Manager added NETePay as a processing option

V19 RM Reports Admin Login Attempts 5/29/2013Added report to facilitate tracking admin-istrator logins

Note: This PA-DSS Implementation Guide must be reviewed on a yearly basis, whenever the underlying application changes or whenever the PA-DSS requirements change. Updates should be tracked and reasonable accommodations should be made to distribute or make the updated guide available to users. ASI will distribute the Information Guide to new customers via email notice, Dealer Services website, and documentation related to PA-DDS requirements.

- 5 -


Executive SummaryPayment Application version 2.0 has been PA-DSS (Payment Application Data Security Standard) certified, with PA-DSS Version 2.0. For the PA-DSS assessment, we worked with the following PCI SSC approved Payment Application Qualified Security Assessor (PAQSA):

Coalfire Systems, Inc.

361 Centennial Parkway Suite 150

Louisville, CO 80027

Coalfire Systems, Inc.

1633 Westlake Avenue N. Suite 100

Seattle, WA 98109

This document also explains the Payment Card Industry (PCI) initiative and the Payment Applic-ation Data Security Standard (PA-DSS) guidelines. The document then provides specific install-ation, configuration, and ongoing management best practices for using Payment Application as a PA-DSS validated Application operating in a PCI Compliant environment.

PCI Security Standards Council Reference Documents

The following documents provide additional detail surrounding the PCI SSC and related security programs (PA-DSS, PCI DSS, etc):

l Payment Applications Data Security Standard (PA-DSS)https://www.p-cisecuritystandards.org/security_standards/pa_dss.shtml

l Payment Card Industry Data Security Standard (PCI DSS)https://www.p-cisecuritystandards.org/security_standards/pci_dss.shtml

l Open Web Application Security Project (OWASP) http://www.owasp.org

Application SummaryPayment Application

Name:Restaurant Manager

Payment Application

Version:Version 19

Application Descrip-tion:

Restaurant Manager is a POS solution for the hospitality industry. End users will process customers order through RMPOS. Payment solutions may include integrated credit card processing. Restaurant Manager's RMCCWin is needed to process credit cards. RMCCWin is not directly inter-

https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml


https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml


http://www.owasp.org/

- 6 -


face to acquiring banks or payment server provider. RMCCWin relies upon the use of third party software to communicate with payment server pro-viders. Verifone's PCCharge and PAYWare PC, Mercury Payment Solutions and Datacap are the only payment processors ASI supports.

Application Target Cli-entele:

Full Service Restaurants, Bars ands Nightclubs, Quick Service Operations

Components of Applic-ation Suite

RMPOS: Restaurant Manager's RMPOS is the primary POS applic-ation that resides on the POS terminal. RMPOS is where all sales transactions occur including adding/deleting items from guest checks, payments, and guest check modifications.Employee clock in/out for time keeping also take place in RMPOS module .

RMWIN:Restaurant Manager's RMWIN is the back office application used administer POS functionality. RMWIN is where menu, employee, and function button setup occurs. In addition, RMWIN is the application used to configure POS prompts, enabling/disabling modules and functions, and system security. RMWIN is installed and resides on a single back end server.

RMCCWin: Restaurant Manager's RMCCWin is the application used to configure and process credit cards. RMCCWin is deployed and resides on a back end server.

RMReports: Restaurant Manager's RMReports module resides on the back end server and is used for reporting functionality.

RMInventory: Restaurant Manager's RMInventory resides on the back end server. RMInventory tracks the use of goods sold and pur-chased.

iWO: Restaurant Manager iWO is a wireless application that per-forms similar functionality to the standard POS module.

Required Third Party Payment Application

Software:

NETePay 5.0

Mercury Payment Systems

Datacap's Datatran 162 & DialLink Modem

Verifone's PCCharge version 5.9.3 SP8

Verifone's PAYWare PC version 1.2.2

Other Required Third Party Software:

Systems processing credit cards must use anti-virus software

Systems processing credit cards must use firewall software or hard-ware

Systems processing credit cards must two factor authentication soft-

- 7 -


ware for remote access.

Operating Systems:Restaurant Manager may be installed on the following operating systems: Windows XP Pro, Window 7 Pro, Windows Server 2003, Windows Server 2008 Windows 8

Application Func-tionality Supported:

Payment Processing Connections:

Credit card transactions are processed by first swiping the credit card on the card reader device. The track data/PAN/Token is first sent to the POS computer and then to RMCCWin on the back end server computer. Encryp-ted track data is sent to the acquiring payment server provider. Track data/PAN/Token is encrypted using VPN/SSL communication methods and sent from the credit card authorization server to the acquiring bank or pay-ment server provider. Authentication response is sent back to the parking system. If transaction has been granted then the PAN is stored encrypted within the back end computer.

Application Authentic-ation:

Systems using standard non encrypted MSR have credit card track data encrypted using a Triple-DES encryption algorithm on the back end server. Restaurant Manager will retain credit card information in PMT<mmyy>.DBF. Card information is purged at the beginning on each business session based on the business specified need to store credit card info (but no longer than the specified need).

Description of Ver-sioning Methodology:

ASI manages product baselines through a formal versioning pro-gram. Versioning allows developers, architects, and even business staff to assign and recognize differences between baselined outputs. As such, versions are applied to all deliverables within the project scope.

ASI observes the following guidance rules when assigning version numbers:

Major Version- Major version change may include changes greater than 30% to the codebase or add functionality to the system. Major versions are assigned “1.0” at release. Major changes may or may not have an impact on PA-DSS requirements.

Minor Version- Incremented whenever a significant change occurs to the baselined product. Minor versions may add functionality to

- 8 -


the system. Incremented upon release of a significant change. Minor changes

Build- Incremented upon implementation of a single minor change or collection of minor changes to a production solution product. Build changes typically involve bug fixes and no impact on PA-DSS requirements.

- 9 -


- 10 -


Difference between PCI Compliance and PA-DSS Val-idationAs a software vendor, our responsibility is to be “PA-DSS Validated.”

ASI has performed an assessment and certification compliance review with our independent assessment firm, to ensure that our platform does conform to industry best practices when handling, managing and storing payment related information.

PA-DSS is the standard against which Payment Application has been tested, assessed, and val-idated.

PCI Compliance is then later obtained by the merchant, and is an assessment of your actual server (or hosting) environment.

Obtaining “PCI Compliance” is the responsibility of the merchant and your hosting provider, working together, using PCI compliant server architecture with proper hardware & software configurations and access control procedures.

The PA-DSS Validation is intended to ensure that the Payment Application will help you achieve and maintain PCI Compliance with respect to how Payment Application handles user accounts, passwords, encryption, and other payment data related information.

The Payment Card Industry (PCI) has developed security standards for handling cardholder information in a published standard called the PCI Data Security Standard (DSS). The security requirements defined in the DSS apply to all members, merchants, and service providers that store, process or transmit cardholder data.

The PCI DSS requirements apply to all system components within the payment application envir-onment which is defined as any network device, host, or application included in, or connected to, a network segment where cardholder data is stored, processed or transmitted.

The 12 Requirements of the PCI DDSBuild and Maintain a Secure Network

1. Install and maintain a firewall configuration to protect data

2. Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data

3. Protect Stored Data

4. Encrypt transmission of cardholder data and sensitive information across pub-lic networks

- 11 -


Maintain a Vulnerability Management Program

5. Use and regularly update anti-virus software

6. Develop and maintain secure systems and applications

Implement Strong Access Control Measures

7. Restrict access to data by business need-to-know

8. Assign a unique ID to each person with computer access

9. Restrict physical access to cardholder data

Regularly Monitor and Test Networks

10. Track and monitor all access to network resources and cardholder data

11. Regularly test security systems and processes

Maintain an Information Security Policy

12. Maintain a policy that addresses information security

- 12 -


Considerations for the Implementation of Payment Application in a PCI-Compliant EnvironmentThe following areas must be considered for proper implementation in a PCI-Compliant envir-onment.

l Remove Historical Cardholder Data

l Sensitive Authentication Data requires special handling

l Set up Good Access Controls

l Properly Train and Monitor Admin Personnel

l Key Management Roles & Responsibilities

l PCI-Compliant Remote Access

l Use SSH, VPN, or SSLV3/TLS 1.0 or higher for encryption of administrative access

l Log settings must be compliant

l PCI-Compliant Wireless settings

l Data Transport Encryption

l PCI-Compliant Use of Email

l Network Segmentation

l Never store cardholder data on internet-accessible systems

l Use SSLV3 for Secure Data Transmission

l Delivery of Updates in a PCI Compliant Fashion

Remove Historical Sensitive Authentication Data (PA-DSS 1.1.4.a)Historical data must be securely deleted (magnetic stripe data, card validation codes, PINs, or PIN blocks stored by previous versions of the software) . Removal of historical data is absolutely necessary for PCI compliance and to satisfy the PA-DSS requirement 1.1.4.a (Remove Historical Sensitive Authentication Data –PA-DSS)

UNENCRYPTED DATACertain log files created in prior version up to version 15.1 may contained sensitive, unen-crypted card data. These log files pose a serious security threat and are listed below:

- 13 -


l ERROR.TXT

l CCAUDIT.TXT

l RMCCAUDT.TXT

l CCSWIPE.TXT

To prevent a security breach after an upgrade, it is imperative that these log files be deleted from the main RM folder as well as any backup folders, drives, CD’s, tapes, or any other backup media. These files should be deleted BEFORE upgrading to version 15.1.

ASI provides a utility called CCPurge.exe that erases these log files. In addition, CCPurge will erase any credit card information stored in database files PMT<mmyy>.DBF. CCPurge.exe can be downloaded from ASI’s web site, and should be executed in the main RMWIN folder as well as any backup folders.

Note: after upgrading to RM version 19, the system will continue logging to the above men-tioned files. However, all credit card information is masked and therefore does not pose a secur-ity risk. Hence, once a system is upgraded to version 19, these files can be retained only in the live rmwin directory on the system without posing a security risk.

Sensitive Authentication Data Requires Special Hand-ling (PA-DSS 1.1.5.c)The following guidelines must be followed when dealing with sensitive authentication data (swipe data, validation values or codes, PIN or PIN block data):

l Collect sensitive authentication data only when needed to solve a specific problem

l Store such data only in specific, known locations with limited access

l Collect only the limited amount of data needed to solve a specific problem

l Encrypt sensitive authentication data while stored

l Securely delete such data immediately after use

Purging of Cardholder Data (PA-DSS 2.1)PA-DSS 2.1 states "Software vendor must provide guidance to customers regarding purging of cardholder data after expiration of customer-defined retention period."

The following guidelines must be followed when dealing with cardholder data (PAN alone or with any of the following: expiration date, cardholder name or service code):

l A customer defined retention period must be defined with a business justification.

l Cardholder data exceeding the customer-defined retention period must be purged.

- 14 -


In addition, you must take steps to prevent inadvertent capture or retention of cardholder data. There are areas outside Restaurant Manager software that may capture typically are the OS paging system or system restore files. The section on OS Settings addresses this topic.

Purge Settings In Restaurant ManagerRestaurant Manager provides several options for logging credit card information. Restaurant Manager will automatically purge cardholder data. The end user may define a reasonable busi-ness period to retain cardholder data. At the end of the period Restaurant Manager will purge the data at session open. Please note that Restaurant Manager will not allow cardholder data to be retained more than 99 days. The options are located in Restaurant Manager BackOffice Module using the following steps:

l Click "Setup" > "Station Configuration" > "Admin Settings" button

l Enter complex Administrator Password when prompted

l Click "Miscellaneous" > "Credit Card Authorization Setup"

Each option is described below:

Credit Card Copy/Paste Options

Note: credit card data is masked at the POS when using the options below.

l Security Level to copy a credit card to the clipboard - This option defines the security level required to copy a credit card to the clipboard. Note: in order to copy credit cards from settled transactions, you must enable the option "Save CC Info in payment file." The system will only prompt for this password if it is HIGHER than the password required to access Misc, CC Options

l Security Level to paste a credit card to the clipboard - This option defines the security level required to paste a credit card from the clipboard.

l Timeout for credit card copy/paste operation(minutes) -This option defines the number of minutes that a credit will be available for pasting after it is copied to the clipboard. To avoid abuse, you should set this to the smal-lest possible value, just enough time to allow completing the desired oper-ation. Typically, 2 minutes should be ample, but the value can be increased up to a maximum of 30 minutes. Note: in order to copy credit cards from settled transactions, you must enable the option "Save CC Info in payment file"

l Allow pasting credit card once only - This option applies to the credit card copy/paste operation. If this option is enabled, then credit cards are removed

- 15 -


from the clipboard after they are pasted in the settlement screen. Therefore, cards that are copied to the clipboard can only be pasted once. But if this option is not enabled, then cards that are copied to the clipboard will stay there until they time out

l Copy to clipboard when deleting (normal settlement) - Allows copying credit card number to clipboard when deleting a credit card during normal settlement.

l Copy to clipboard when deleting (revise settlement) - Allows copying credit card number to clipboard when deleting a credit card during revise set-tlement

Processing Options (Credit Card logging)

l SAVE CC INFO IN PAYMENT FILE- This option is provided to facilitate locating and/or fixing credit card issues arising during the course of business. For example, if a customer calls to dispute a charge. Card numbers are saved in the database PMT<mmyy>.DBF. The stored card numbers are masked to reduce the security threat, but it is still advisable to retain the card inform-ation for the minimum time necessary (i.e., for as long as there is a business need, but no longer).

l NUMBER OF DAYS TO STORE CC INFO- Use this option to limit the number of days Restaurant Manager will retain credit card information in PMT<mmyy>.DBF. Card information older than the number of days specified in this option, are purged at the beginning of each session (i.e. business day). Set this to a value that represents the business need to store this info, but no longer.

CUSTOMER/FREQUENT DINER CREDIT CARDS

l SAVE/RESTORE CUSTOMER/FREQUENT DINER CREDIT CARD INFO- This option can be used to save and restore credit card information for repeat cus-tomers. It is primarily useful in delivery-style operations where customers place their order by phone and give their credit card information verbally. If you choose to enable this option, you must decide how long you wish to retain unused card information. Refer to the next option.

l NUMBER OF DAYS TO KEEP UNUSED CARD INFO- This option defines how long the system will retain credit card information after a customer’s last order. If a customer does not order again for the number of days specified, their credit information is automatically purged from the system.

- 16 -


The default setting is 90 days. Although you can enter a larger value, it is recommended that you set this option no bigger than 365 (1 year). Set this to a value that represents the business need to store this info, but no longer.

l SAVE/RESTORE SWIPED CARDS- This option controls whether “swiped” credit cards are retained for future use. Note that PCI standards dictate that POS systems cannot store full credit card swipes or track 2 information for any reason what so ever. Therefore, only the card number and expiration are stored for future use. That means if the card is used in the future, it will be processed as a manually entered card, and hence will be subject to higher fees. If you expect the cardholder to present the card on future visits, it is preferable to set this option to “NO” and swipe the credit card on each future visit in order to obtain the best discount rate on future credit card transactions.

l AUDIT BUTTON PRESSES- This option logs button presses to the credit card audit file CCAUDIT.TXT. None of the information is sensitive therefore it does not compromise credit card security when this option is enabled; however, it can result in a LOT of stored data; therefore, this option should only be used when additional diagnostics are required for troubleshooting purposes.

Windows OS Purge Settings There are several Windows settings that must be configured to prevent the system from inad-vertently capturing credit card (PAN) information. The main objective is to reduce the threat of the possibility of maleware stealing PAN information in virtual memory. This is done by clearing the system pagefile. sys at shutdown, disabling System Management of PageFile.sys, and dis-abling system restore. These settings only need be configured on all computers with an MSR attached or where credit data is entered manually. The following instructions are for Windows 7.

Clearing the System Pagefile.sys on Shutdown

Windows has the ability to clear the Pagefile.sys upon system shutdown. Doing so will purge all temporary data from the pagefile.sys (temporary data may include system and application pass-words, cardholder data (PAN/Track), etc.).

NOTE: Enabling this feature may increase windows shutdown time.

1. Click on the Windows "Start" and in the search box type in "regedit".

2. On the program list, right click on regedit.exe and select "Run as Administrator"

- 17 -


3. Navigate to HKEY_Local_Machine\System\CurrentControlSet\Control\Session Manager\Memory Management. Double click "ClearPafeFileAtShutdown".

4. Change Value data from 0 to 1

5. Click OK and close Regedit

- 18 -


NOTE: If the value does not exist, right click on the Memory Management folder, select "New" on the drop down menu select "DWORD (32-bit or 64 bit depending on OS) Value" and add the following:

o Value Name: ClearPageFileAtShutdown

o Value Type: REG_DWORD

o Value: 1

Disabling System Management of PageFile.sys

You will want to disable memory page swapping to the hard drive. The following steps will show you how to tweak virtual memory settings in Windows by disabling (pagefile.sys).

1. Right Click on Computer > Select "Properties"

2. Select "System Protection" on the top left list

3. Select the"Advanced" tab and click "Settings" under Performance section

- 19 -


4. Click the "Advanced"tab in the Performance Options window and click "Change" under Virtual Memory

5. In the Virtual Memory window: l Uncheck "Automatically manage page file size for all drives"

l Select "Custom Size"

l Enter the following for the size selections:

- 20 -


o Initial Size - as a good rule of thumb, the size should be equivalent to the amount of memory in the system.

o Maximum Size - as a good rule of thumb, the size should be equivalent to 2x the amount of memory in the system.

l Click "Set"

6. Return to default windows screen by clicking "OK" three times

7. Reboot the computer

Note: you may want to increase the size of your RAM to counter the effects of disabling page-file.sys

Disabling System Restore

The following steps describe how to disable system restore points. This is critical as a system restore point may

inadvertently capture cardholder data if it is not disabled and compromise your PCI DSS com-pliance.

1. Right Click on Computer and Select "Properties" on the pop up menu pop up.

- 21 -


2. Select "System Protection" on the top left list.

3. Click "Configure" under the System Protection tab.

- 22 -


4. Click to enable "Turn off system protection", click "Apply", and then click "OK" to close Sys-tem Protection window.

- 23 -


5. Click "OK" to close System Proprieties window.

6. Reboot computer.

Cardholder Data Encryption Key Management (PA-DSS 2.5.c and 2.6.a)In Restaurant Manager since version 15.1, all sensitive information such as passwords and credit card data are encrypted using a Triple-DES encryption algorithm. Like any other encryp-tion algorithm, Triple-DES uses an encryption key to encrypt and decrypt the data.

The encryption key is securely stored in the file KEY.DES, located in the RMWIN working folder. It is important that this file not be deleted or tampered with as it will cause all encrypted data in the system to become un-readable. You should also make sure to include this file in any sys-tem backups. Restoring a backup without this file would cause passwords and stored credit cards to be un-readable.

To ensure that credit card information is not compromised, ASI recommends changing the encryption key at least once per year.

A sample Key Custodian form for key custodians to acknowledge that they understand and accept their key custodian responsibilities must be signed. A sample of a Key Custodian Agree-ment is provided below:

- 24 -


The following key management functions must be performed per PCI DSS:

l Generation of strong cryptographic keys.

l Secure cryptographic key distribution.

l Secure cryptographic key storage.

l Cryptographic key changes for keys that reached the end of their cryptoperiod (for example, after a defined period of time has passed and/or after a certain amount of ciphertext has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines (for example, NIST Special Publication 800-57.

l Retire keys when the integrity of the key has been weakened.

l Replace known or suspected compromised keys.

l If retired or replaced cryptographic keys are retained, the application cannot use these keys for encryption operations.

l Manual clear-text key-management procedures require split knowledge and dual control of keys.

l Prevention of unauthorized substitution of cryptographic keys

- 25 -


Removal of Cryptographic Material (PA-DSS 2.7.a)Restaurant Manager encrypts cardholder data on versions 15.1 to 19. The following must be done on these versions:

l All cryptographic material (encryption keys and encrypted cardholder data) must be securely removed.

l To render data irretrievable you must: run the ccPurge.exe. This is an automated process in Restaurant Manager when performing upgrades on RM versions prior to 15.1.

l This removal is absolutely necessary for PCI DSS Compliance

l Re-encrypt historic data with new keys by using the process of generating a new key described below:

1. The session must be closed

2. Open Restaurant Manager Back Office Module

3. Click "Setup" and click "Backoffice" on the drop down menu.

4. Enter Administrator Password

5. Click Security Tab on Backoffice Configuration window.

6. Click "Generate new encryption key" button.

7. Click "Save changes" button

- 26 -


Important: It is mandatory that you generate a new encryption at the initial installation of the Restaurant Manager software and then at least once a year thereafter.

Setup Strong Access Controls (PA-DSS 3.1.a and 3.2)ASI Resellers, end users, and third party participants (i.e. outside network specialists) are advised to control access using unique usernames and PCI DSS compliant complex passwords, to any servers/computers, and databases with payment applications and cardholder data.

The PCI DSS requires that access to all systems in the payment processing environment be pro-tected 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.

PA-DSS 3.2: Control access, via unique username and PCI DSS-compliant complex passwords, to any PCs or servers with payment applications and to databases stor-ing cardholder data.

PA-DSS 3.1.a: You must assign strong passwords to any default accounts (even if they won’t be used), and then disable or do not use the accounts.

Authentication credentials are not generated or managed by Restaurant Manager. Instead, authentication credentials used by the payment application are provided for by Restaurant Man-ager. For both the completion of the initial installation and for any subsequent changes (for example, any changes that result in user accounts reverting to default settings, any changes to existing account settings, or changes that generate new accounts or recreate existing accounts), the following 10 points must be followed per PCI 8.1, 8.2, and 8.5.8-15:

1. The application must assign unique IDs for user accounts. (PCI DSS 8.1)

2. The application must provide at least one of the following three methods to authenticate users: (PCI DSS 8.2)

a. Something you know, such as a password or passphrase

b. Something you have, such as a token device or smart card

c. Something you are, such as a biometric

3. The application must NOT require or use any group, shared, or generic accounts or pass-words.(PCI DSS 8.5.8)

4. The application requires passwords to be changed at least every 90 days (PCI DSS 8.5.9)

5. The application requires passwords must to be at least 7 characters (PCI DSS 8.5.10)

6. The application requires passwords to include both numeric and alphabetic characters (PCI DSS 8.5.11)

- 27 -


7. The application keeps password history and requires that a new password is different than any of the last four passwords used. (PCI DSS 8.5.12)

8. The application limits repeated access attempts by locking out the user account after not more than six logon attempts. (PCI DSS 8.5.13)

9. The application sets the lockout duration to a minimum of 30 minutes or until an admin-istrator enables the user ID. (PCI DSS 8.5.14)

10. The application requires the user to re-authenticate to re-activate the session if the application session has been idle for more than 15 minutes.

These same account and password criteria from the above 10 requirements must also be applied to any applications or databases included in payment processing to be PCI compliant. Restaurant Manager, as tested in our PA-DSS audit, meets, or exceeds these requirements for the following additional required applications or databases:

l Verifone's PCCharge

l Verifone's PAYWare PC

l Datatran

Note: These password controls are not intended to apply to employees who only have access to one card number at a time to facilitate a single transaction. These controls are applicable for access by employees with administrative capabilities, for access to servers with cardholder data, and for access controlled by the application.

The following sections outline how you can configure Restaurant Manager to meet PCI DSS requirements

PasswordAll passwords in Restaurant Manager since version 15.1 are encrypted. In previous versions, it was possible to use DBU, or other database utility to view passwords stored in Employee.dbf and Config.dbf, these passwords are now encrypted. If DBU (or other utility) is used to change any of the passwords stored in these files, those passwords will be rendered unusable until they are reset.

Master Password

The “Master Password” in Restaurant Manager allows access to all back office as well as Point of Sale functions. It is highly recommended that the master password not be used (PA-DDS 3.1c & PCI DSS 8.5.8). By default, the Master password on a new system is 0000. When setting up a new system, you should change the Master password to something other than the default value. It is also recommended that you change the master password at least every 90 days.

- 28 -


Because the master password is encrypted, the program PASS0000.EXE, must not be used as in previous versions to version 15.1. After upgrading from a version prior to v15.1 and if the executable remains: it should be removed from the system. If you do execute PASS0000.EXE, or otherwise manually change or corrupt the master password on the system, it will render the master password unusable. (PA-DDS 3.2c). If this happens, you will only be able to reset the mas-ter password with assistance from ASI Tech Support. Open a help desk ticket with the subject, “Reset v19 master password”.

Administrator Passwords

Since version 15.1, Restaurant Manager relies on the concept of Administrators. They have access to settings and operations normal users do not. Those items include:

1. Set or Change master password, located in Setup -> Security Configuration screen. User must also be a level 9.

2. Set or Change other employee’s administrator password, accessible using “Edit Admin-istrator Password Info” button in Employee Setup. User must also be equal or higher security level than the one being changed.

3. Modify PCI Security Configuration settings, in new Setup -> Security Configuration. User must also be a level 9.

4. Access the BackOffice Configuration screen.

5. Access sensitive credit card configuration settings in RMCCWin.

6. Add or Delete employees from the database.

Choosing these options in the Restaurant Manager BackOffice or RMCCWIN will cause an admin password prompt to appear, or a notice that the user does not have adequate per-mission.

Admin passwords are set in the Restaurant Manager BackOffice under Employee Setup, click on Edit Administrator Password Info”.

- 29 -


NOTE: It is always the Administrator password of the LOGGED-IN user that is required. This can be confusing when an admin is trying to change the Administrator password of another Admin-istrator. It is their own password that should be entered, not the one of the employee he is edit-ing.

NOTE: You are allowed only six attempts to enter an administrator password. Failures to enter the correct administrator password will block additional attempts for thirty minutes (PCI DSS 8.5.13 & PCI DSS 8.5.14)

Administrator Passwords are Strong Passwords

A “strong” password is an industry term to denote that the password is complex enough to reduce the chances of it being guessed using brute force methods. The rules for strong pass-words are:

1. MUST be 7 characters or longer (PCI DSS 8.5.10)

2. MUST contain both letters and numbers (PCI DSS 8.5.11)

3. Should contain both upper and lower case letters

4. Should contain symbols (e.g. characters above numbers on keyboard)

5. Password should not be similar or contain the same numbers found in the employee pass-word.

The last 2 are not required, but add additional password security, and make an admin password quality “excellent”.

- 30 -


Creating the First Administrator Account

After installing Restaurant Manager, start Restaurant Manager BackOffice (rmwin.exe) and you will be immediately prompted to create the first Administrator account, a level 9 user with access to all PCI-sensitive settings in the system. ASI recommends this account be a user tied to the reseller. It is from this user account that the reseller can continue configuring the credit card settings, and creating additional Administrator passwords for store personnel.

Resellers may wish to restrict the level 9 security level for reseller use, and have store per-sonnel be level 8 and below. Administrators, by default, are defined as level 8 and above, con-figurable from within Restaurant Manager BackOffice.

Administrator Password Expiration

Admin passwords expire in 90 days by default. After expiration, the user can no longer gain access to the admin restricted areas of Restaurant Manager. That user needs to have his pass-word reset to regain administrator access.

- 31 -


EXPIRATION WARNING: The Restaurant Manager BackOffice program will warn of impending administrator password expirations upon BackOffice login. If any administrator passwords will expire within the next 10 days, or have already expired, an expiration dialog will appear listing the employees affected.

Resetting Administrator Passwords

If admin passwords are forgotten, or left to expire, they will need to be reset. That can be done through the following means:

1. By a fellow admin- Another admin at equal or higher security level who does still have access can change the password of the user whose admin password is unusable.

2. By the reseller – If all store administrators have forgotten their password or let them expire, then the reseller’s own admin user can be used to reset the admin password of the highest security level store employee to allow them to regain admin access.

3. By calling ASI – If all admin users have lost access, the only way to regain access is to call ASI Tech Support and get the Restaurant Manager Admin Daily Passcode and follow the instructions given by the ASI technician

4. Accessing the ASI web site- go to the Reseller page then Tech Support > Patches & Utilities > Daily Admin Password. Here you will find a link to get today’s daily passcode. In the entry fields, you will need to enter your name and the site’s name. The user is transported to a page with today’s Admin Passcode

After retrieving the Daily Passcode:

• Re-start Rmwin and enter in the code into the password field when prompted.

• Go to “Employee- Setup”, select the employee, and click on the [Edit Administrator Password Info] button to change the admin passcode.

Password fields left inactive for a period of 15 minutes will automatically time out. You will have to begin the process again if you exceed the time frame of inactivity (PCI DSS 8.5.15).

NOTE: New passwords cannot be the same as the last 4 passwords (PCI DSS 8.5.12).

PCI Compliant Settings

To be PCI compliant:

1. The default Password Expiration Days MUST be set to 90 or lower. 90 days is the default setting (PCI DSS 8.5.9).

2. All administrators MUST have their Expiration setting set to “System Default”. This is the default setting.

- 32 -


Note that Restaurant Manager allows expiration settings other than what PCI requires. This is to accommodate sites and countries that are not required to be PCI compliant (e.g. sites that do not accept credit cards). It is the responsibility of resellers, and ultimately store management to ensure that the store uses PCI compliant settings if required.

Properly Train and Monitor Admin PersonnelIt is the restaurant site's responsibility to institute proper personnel management techniques for allowing admin user access to cardholder data, site data, etc. You can control whether each individual admin user can see credit card PAN (or only last 4).

In most systems, a security breach is the result of unethical personnel. So pay special attention to whom you trust into your admin site and who you allow to view full decrypted and unmasked payment information.

Log Settings Must be Compliant (PA-DSS 4.1.b, 4.4.b)If the application enables logging and does not provide any configurability of the logging func-tion, then provide guidance as follows:

PA-DSS 4.1.b: Restaurant Manager has PA-DSS compliant logging enabled by default. This log-ging is not configurable and may not be disabled. Disabling or subverting the logging function of Restaurant Manager in any way will result in non-compliance with PCI DSS.

In addition, any third party software used for remote access or credit card processing must have logging turned on and configured per PCI DSS 10.2 and 10.3 as follows:

Implement automated assessment trails for all system components to recon-struct the following events:

l PCI DSS 10.2.1 All individual user accesses to cardholder data

l PCI DSS 10.2.2 All actions taken by any individual with root or administrative privileges

l PCI DSS 10.2.3 Access to all assessment trails

l PCI DSS 10.2.4 Invalid logical access attempts

l PCI DSS 10.2 5 Use of identification and authentication mechanisms

l PCI DSS 10.2.6 Initialization of the assessment logs

l PCI DSS 10.2.7 Creation and deletion of system-level objects.

Record at least the following assessment trail entries for all system components for each event from PCI DSS 10.2.x:

- 33 -


l PCI DSS 10.3.1 User identification

l PCI DSS 10.3.2 Type of event

l PCI DSS 10.3.3 Date and time

l PCI DSS 10.3.4 Success or failure indication

l PCI DSS 10.3.5 Origination of event

l PCI DSS 10.3.6 Identity or name of affected data, system component, or resource

PA-DDS 4.4.a and 4.4.b: Restaurant Manager facilitates centralized logging.

Restaurant Manager logs all administrator login attempts whether successful or not. Logging is recorded in the "pwlog.dbf". The log file records the following information:

l Application name trying to access (RMWIN, RMPOS, RMCCWin, etc).

l Password date- the date the password was used

l Password Time- the time the password was used

l Password station- the station the password was used (note: "0" is used when using the password from the server computer).

l Password Success- True if successful, false if unsuccessful

l Required Password- logs the specific security level need to access application (i.e. secur-ity level 0-9)

l Login Employee- employee number of employee initiating process

l Employee Password Number- Employee number belonging to password used. Note: there may be a difference from the Login employee and the Employee Password number. Example: Employee 2 may have activated the POS Main status screen but it would take employee 2's password (and security level) to complete a function.

l Password Buttons- Restaurant Manager logs the keystrokes of functions performed at POS.

Note: removing the "pwlog.dbf" from the rmwin directory will render your system PCI on com-pliant.

Restaurant Manager version19 has a reporting function for logging the use of Administrators password used at the POS, RM BackOffice module, and RMCCWin. Use the "Admin Login Attempts" report in the Restaurant Report Module for reporting purposes. The "Admin Login Attempts" report is included in the report module by default and is found under the Session Reports folder. Run the Report using the following steps:

1. Open the RMReport Module

- 34 -


l Use the report Interface icon in RM BackOffice Module

l Use the RMReports icon (Start > All Programs > RMWIN folder).

2. Enter Password when prompted

3. Double click "Session Reports" folder and navigate to "Admin Login Attempts" report.

4. Use the "Date" filter in middle column to select a report date range.

Note: use other filters (i.e Empl#) to limit data displayed as necessary.

5. Make sure Output is set to "Screen" and click "Output: Admin Login Attempts" button.

6. The report will appear on the screen. Click the "Diskette" icon in the upper right corner of the screen

7. Choose the destination and select the format you wish to save the report as using the "Save as Type" field. You can also rename the report in the "file name" field if necessary.

Note: You can choose "Printer" as output type in the RM Report Module to print the report to a printer. In this case, skip steps 6 & 7.

- 35 -


Services and ProtocolsThe application must only use or require use of necessary and secure e services, protocols, dae-mons, components. PCI requires that you list all required protocols, services and dependent soft-ware and hardware that are necessary for any functionality of the payment application, including those provided by third parties.

Restaurant Manager does not require the use of any insecure services or protocols. Here are the services and protocols that Restaurant Manager does require:

l Mercury Payment Systems - DSI Client

l Dataran- DSI Clients using SSL/TLS standards

l IP/Dial Bridge- DSI Client using SSL/TLS standards

l Verifone - SIMM DLL uses IPCharge gateway via HTTPS

l NETePay- DSI Client using SSL/TLS standards

You must use the installation guide for each software/hardware mentioned for proper install-ation.

- 36 -


PCI-Compliant Wireless Settings (PA-DSS 6.1.f and 6.2.b)Restaurant Manager does offer wireless technologies with the Write-On products. The fol-lowing guidelines for secure wireless settings must be followed per PCI DSS 1.2.3, 2.1.1 and 4.1.1:

However, in sites not using Write-On technology, a merchant may implement wireless access within the cardholder data environment. If such is the case, the following guidelines for secure wireless settings must be followed per PCI Data Security Standard 1.2.3, 2.1.1 ,4.1.1 and 11.1:

PCI DSS- 1.2.3: Perimeter firewalls must be installed between any wireless net-works and systems that store cardholder data, and these firewalls must deny or con-trol (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment.

PCI DSS 2.1.1:Change wireless vendor defaults per the following 5 points:

• Encryption keys were changed from default at installation, and are changed anytime anyone with knowledge of the keys leaves the com-pany 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 is updated to support strong encryption for authentication and transmission over wireless networks (for example, WPA/WPA2)

• Other security-related wireless vendor defaults, if applicable

Refer to manufactures specific instructions and guides to achieve compliance

PCI DSS 4.1.1: Industry best practices (for example, IEEE 802.11.i) must be used to implement strong encryption for authentication and transmission of cardholder data.

Note: The use of WEP as a security control was prohibited as of June 30, 2010.

Industry best practices are used to implement strong encryption for the following over the wireless network in the cardholder data environment (4.1.1):

l Transmission of cardholder data

- 37 -


l Transmission of authentication data

PCI DSS 11.1: Test for the presence of wireless access points and detect unau-thorized wireless access points on a quarterly basis.

l 11.1.a Verify that the entity has a documented process to detect and identify wireless access points on a quarterly basis.

l 11.1.b Verify that the methodology is adequate to detect and identify any unau-thorized wireless access points, including at least the following:

o WLAN cards inserted into system components

o Portable wireless devices connected to system components (for example, by USB, etc.)

o Wireless devices attached to a network port or network device l 11.1.c Verify that the documented process to identify unauthorized wireless

access points is performed at least quarterly for all system components and facilities.

l 11.1.d If automated monitoring is utilized (for example, wireless IDS/IPS, NAC, etc.), verify the configuration will generate alerts to personnel.

l 11.1.e Verify the organization’s incident response plan (Requirement 12.9) includes a response in the event unauthorized wireless devices are detected.

iWrite-On Handheld GuidelinesThe iWrite-On handheld devices run over a wireless network. Strict standards must be adhered to remain PCI compliance. The following sections outline the guidelines to run the iWrite-On in a cardholder safe environment.

Recommended HardwareRequired Specifications

l 802.11n

l WPA2 encryption (as opposed to just WPA)

l Gigabit port with gigabit networking to the server

Recommended Hardware

Basic Models

l Motorola WAP AP 6511(access point, to connect to existing router)

Pro Model for Larger Sites

- 38 -


l Ruckus Access Point: ZoneFlex 7363

l Optional Access Point Controller: ZoneDirector ZD1100

Wi-Fi Configuration Guidance (PCI DSS Requirements 2.1.1 & 4.1) PCI requirements for wireless networks are extensive. All the following services and settings are required. Note that some of the requirements are hardware dependent. It is possible that new or different hardware will be required in order to satisfy PCI requirements.

WPA Guidelines

The wireless infrastructure must use WPA2 encryption. WEP encryption is no longer allowed. Firmware on wireless devices must be updated to support strong encryption for authentication and transmission over wireless networks. Therefore, WPA2-capable wireless infrastructure (access point) is a requirement. On the recommended Motorola product, you will find the encryption options under Configuration page > Wireless > MyWireless. Settings on other wire-less APs or routers will vary. On some models you want to select the “WPA/WPA2-TKIP” option, on other models you will have to select WPA2 as Network Authentication and the select TKIP as Data Encryption type.

WPA-Capable Handheld Hardware

All handheld hardware must be WPA-enabled if any mobile MSRs are in use in the installation. Since the ASI custom driver for the Socket wireless card does not support WPA, no consumer handhelds with the Socket card can be used in an installation that is also using MSR-capable handhelds such as the iPod Touch with MSR attachment. If you add an iPodTouch with MSR to an existing installation, the entire site must be converted to WPA-capable handhelds in order to satisfy PCI compliance requirements.

1. Non-Default SSID – The SSID of the wireless network must be changed from the default setting from the manufacturer. On most wireless AP products, the SSID setting is on the Wireless Settings page for the wireless network. Change it to something that’s unique for each installation

2. Disable SSID Broadcast- The broadcast of the SSID in the beacon must be disabled. On Motorola products, uncheck "Broadcast SSID" found in under the Configuration page > Wireless > Wireless LAN.

3. MAC Address Filtering – MAC address filtering must be used on the wireless network to disallow all clients except those specifically listed as trusted handheld client hardware.

- 39 -


Firewall Guidance (PCI DSS 1.3.9)Firewall services must be installed to limit and protect access to the server machine from any wireless network that would otherwise have free access to the store’s wired network.

HARDWARE

Hardware must include Stateful Packet Inspection (SPI).

LOCATION

The firewall shall be placed between the wireless network and the physical network to which the server machine is connected. The goal is to prevent any unnecessary network traffic on the wireless network from gaining access to the wired network. Only necessary packets are allowed, using only necessary ports.

SETTINGS- PORT/SERVICE RESTRICTION

The Write-On handheld and Write-On Server process communicates through IP. The protocols it uses are HTTP (TCP port 9644). Therefore, only 9644 shall be allowed through the firewall. All others shall be disallowed.

Handheld ConfigurationACCESS TO HANDHELD SERVER FROM INTERNET (PCI DSS Requirement 2.4)

The Write-On Server application shall not be accessible from the Internet. Access shall be lim-ited only to the local network (subnet).

NO ACCESS ALLOWED (PORT 80 CLOSED, AND NO ALTERNATE PORT USED) –Port 80 on the server shall not be accessible from the Internet. Furthermore, no open port from the Internet shall map to the Write-On Server’s port 80

- 40 -


PCI Guidance for Internet Accessible Sys-temsThe Restaurant Manager server computer shall have restricted inbound and outbound Internet access though use of firewall services between the server machine and the Internet. Access shall be limited to those needed by Restaurant Manager and related applications, such as credit card authorization, automatic anti-virus updates, and network time synchronization as examples.

The server machine shall be used solely as a server and not for other user functions, especially Internet activities such as email or web browsing. Those should be done from a separate machine on a separate subnet with isolated access to the Internet.

Never Store Cardholder Data on Internet-Accessible Systems (PA-DSS 9.1.b)Never store cardholder data on Internet-accessible systems (e.g., web server and database server must not be on same server.)

PCI-Compliant Remote Access (PA-DSS 10.2)The PCI standard requires that if employees, administrators, or vendors are granted remote access to the payment processing environment; access should be authenticated using a two-factor authentication mechanism. The means two of the following three authentication meth-ods must be used:

1. Something you know, such as a password or passphrase

2. Something you have, such as a token device or smart card

3. Something you are, such as a biometric

PCI-Compliant Delivery of Updates (PA-DSS 10.3.1)ASI delivers patches and updates in a secure manner:

This section will describe how payment application updates and patches are delivered to the merchant. The method used must provide a secure chain of trust per requirements in PA-DSS 7.2.a, including:

l Timely development and deployment of patches and updates - ASI develops patches and updates on a regular basis. Historically, at least one patch or update occurs at least once per business quarter. Patches and updates will be part of a build. More than one build may be released in a business quarter when deemed necessary.

- 41 -


l Delivery in a secure manner with a known chain-of-trust - New versions builds are offered on the Patches and Utilities web page on the Dealer Services web site. Dealer must their unique user name and password to log onto the Dealer Services site to down-load the patch.

l Delivery in a manner that maintains the integrity of the deliverable - Resellers can download new builds directly on the sites computers and the execute the installation pack-age.

l Integrity testing of patches or updates prior to installation - ASI tests new build prior to general release. ASI will first test the build in house (alpha testing). ASI will then test the new build at a beta site.

As a development company, ASI keeps abreast of the relevant security concerns and vul-nerabilities in our area of development and expertise.

We do this by:

l Payment Applications Data Security Standard (PA-DSS)" https://www.p-cisecuritystandards.org/security_standards/pa_dss.shtml

l Payment Card Industry Data Security Standard (PCI DSS) https://www.p-cisecuritystandards.org/security_standards/pci_dss.shtml


l PCI related seminars

l Contacting Coalfire for clarification

Once we identify a relevant vulnerability, we work to develop & test a patch that helps protect Restaurant Manager against the specific, new vulnerability. We attempt to publish a patch within 30 days of the identification of the vulnerability. We will then contact resellers to encour-age them to install the patch. Typically, merchants are expected to respond quickly to and install available patches within 30 days.

ASI does not deliver software and/or updates directly to the end user. This is the responsibility of the reseller. Resellers have several options to deliver a new build:

l Remote access to customer networks and install the build directly from the Dealers Ser-vices website.

l On site and install the build directly from the Dealers Services website

l On site and install the build (obtained Dealers Services website) from an external device

For receiving updates via remote access, resellers must adhere to the following guidelines:

- 42 -


l Secure remote access technology use, per PCI Data Security Standard 12.3.9:

PCI DSS 12.3 Activation of remote access technologies for vendors only when needed by vendors, with immediate deactivation after use. Reseller must use a software with two factor authentication (i.e. Logmein Central) with logging capabilities enabled.

PCI-Compliant Remote Access (10.3.2.b)The PCI standard requires that if employees, administrators, or vendors are granted remote access to the payment processing environment; access should be authenticated using a two-factor authentication mechanism (username/ password and an additional authentication item such as a token or certificate).

In the case of vendor remote access accounts, in addition to the standard access controls, vendor accounts should only be active while access is required to provide service. Access rights should include only the access rights required for the service rendered, and should be robustly audited.

If users and hosts within the payment application environment may need to use third-party remote access software such as Logmein Central etc. to access other hosts within the payment processing environment, special care must be taken.

In order to be compliant, every such session must be encrypted with at least 128-bit encryption (in addition to satisfying the requirement for two-factor authentication required for users con-necting from outside the payment processing environment). Please note that ASI is recom-mending that Symantec pcAnywhere, Tight VNC, or Remote Desktop or similar products not be used to access accounts. However, if you choose to use one of these methods of remote access you should implement the following:

l Remote Desktop Top (RDP/Terminal Services)- use the high encryption setting on the server. Note: the default port 2289 used for RDP/Terminal Services must be changed.

l pcAnywhere/Tight VNC (or similar) – use symmetric or public key options for encryption.

Additionally, the PCI user account and password requirements will apply to these access meth-ods as well.

When requesting support from a vendor, reseller, or integrator, customers are advised to take the following precautions:

l Change default settings (such as usernames and passwords) on remote access software (e.g. VNC)

l Allow connections only from specific IP and/or MAC addresses

l Use strong authentication and complex passwords for logins according to PA-DSS 3.1.1 -

- 43 -


3.1.10 and PCI DSS 8.1,8.3, and 8.5.8 - 8.5.15

l Enable encrypted data transmission according to PA-DSS 12.1 and PCI DSS 4.1

l Enable account lockouts after a certain number of failed login attempts according to PA-DSS 3.1.8 and PCI DSS 8.5.13

l Require that remote access take place over a VPN via a firewall as opposed to allowing connections directly from the Internet

l Enable logging for auditing purposes

l Restrict access to customer passwords to authorized reseller/integrator personnel.

l Establish customer passwords according to PA-DSS 3.1.1 - 3.1.10 and PCI DSS Require-ments 8.1, 8.2, 8.4, and 8.5.

Remote Access (Recommended by ASI)The nature of our business requires remote access to a store network and server machine for support purposes. Such remote access is allowed, but only if proper protection and security methodologies are employed. Those methodologies include two-factor authentication and time-restricted access.

Below are two possible methods ASI offers for solutions regarding two factor authentication sat-isfaction:

LogMein Central (Preferred)

(PCI DSS Requirement 8.3) Access authentication shall employee two factors of protection. The built-in protection of the access software (such as LogMeIn Free, Pro, etc) which employs a unique username and complex password can be one factor of protection. But a second factor of protection shall also be used. ASI recommends using LogMeIn Central with individual security tokens (e.g. emailed passwords) or cell phone notifications to satisfy two factor authentications. LogMeIn Central provides preference settings under the Security tab where you define the authentication parameters for every time a client site is accessed for each user account.

In addition, you will need to configure the following in LogMeIn Central to satisfy PCI DSS cri-teria:

1. Unique user accounts. Users cannot share remote access credentials.

2. Accounts of terminated employees are immediately disabled.

3. Strong passwords at least 7 characters long with letters and numbers as min-imum complexity.

4. Remote access passwords must be changed every 90 days.

- 44 -


5. Automatic idle disconnect after 15 min of inactivity.

6. Logs are retained for at least one year, showing who remote controlled into what computer at what time and from what IP the connection originated.

7. Six incorrect login attempts on a user account locks out that account for a min-imum of 30 minutes in order to slow down brute-force guessing.

8. Remote access logs need to be reviewed regularly for abuse.

VPN with LogMein

(PCI DSS Requirement 8.3) Access authentication shall employee two factors of protection. The built-in protection of the access software (such as LogMeIn) which employs a unique username and complex password can be one factor of protection. But a second factor of protection shall also be used. In this method, ASI suggests using VPN with individual security tokens (e.g., Secure ID’s, certificates, or public keys). Therefore, access to a store would first require establishing a VPN connection, and then starting up a secure remote access connection (i.e. LogMeIn or sim-ilar) through the VPN.

i. VPN – access shall only be granted to users or vendors with business justification through a formal access granting process that is documented and tracked. In addi-tion to the unique (to the user) username and complex password required to access servers within the payment processing environment, VPN users will need to have individually assigned access tokens.

ii. LogMeIn or other access software (PCI DSS) – Access accounts shall be set up for every user (person) with access rights to the store.

Any “always-on” connections from a computer to a VPN should be secured by using a personal firewall (PCI DSS 1.3.9). The firewall should be configured to meet specific standards and not be alterable by employees.

Access Enabled Only During Update Time Period

(PCI DSS Requirement 8.5.6) Vendor access accounts shall be disabled except during the time period when access is required. Prior to the necessity for access, an onsite trusted individual will enable access for the person requesting access. Following the access session, all access accounts will then be disabled.

Restricting Inbound and Outbound Internet Access

The Restaurant Manager server computer shall have restricted inbound and outbound Internet access though use of firewall services between the server machine and the Internet. Access shall be limited to those needed by Restaurant Manager and related applications, such as credit

- 45 -


card authorization, automatic anti-virus updates, and network time synchronization as examples.

The server machine shall be used solely as a server and not for other user functions, especially Internet activities such as email or web browsing. Those should be done from a separate machine on a separate subnet with isolated access to the Internet.

Server/Workstation Hardening Guidance

Unnecessary and insecure services and protocols shall be removed or not installed on the server machine. This includes such services as NetBIOS, file-sharing, Telnet, unencrypted FTP, and others.

Data Transport Encryption (PA-DSS 11.1.b)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 SSLV3 or IPSEC; or at the data layer with algorithms such as RSA or Triple-DES) to safeguard cardholder data during trans-mission over public networks (this includes the Internet and Internet accessible DMZ network segments).

PCI DSS requirement 4.1: Use strong cryptography and security protocols such as secure sockets layer (SSLV3) / transport layer security (TLS 1.0 or higher) and Internet protocol security (IPSEC) to safeguard sensitive cardholder data during transmission over open, public networks.

Examples of open, public networks that are in scope of the PCI DSS are:

l The Internet

l Wireless technologies

l Global System for Mobile Communications (GSM)

l General Packet Radio Service (GPRS)

Refer to the Data Flow diagram for an understanding of the flow of encrypted data associated with Restaurant Manager.

PCI-Compliant Use of End User Messaging Tech-nologies (PA-DSS 11.2.b):Restaurant Manager does not allow or facilitate the sending of PANs via any end user mes-saging technology (for example, e-mail, instant messaging, and chat). Reseller shall instruct end users not to email any cardholder data as part of doing business with their customers.

- 46 -


Non-Console Administration (PA-DSS 12.1)Although Restaurant Manager does not support non-console administration and we do not recommend using non-console administration, should you ever choose to do this, must use SSH, VPN, or SSL/TLS for encryption of this non-console administrative access

Network SegmentationThe PCI DSS requires that firewall services be used (with NAT or PAT) to segment network seg-ments into logical security domains based on the environmental needs for Internet access. Tra-ditionally, 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 trus-ted 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.

Refer to the standardized Network diagram for an understanding of the flow of encrypted data associated with Restaurant Manager.

Maintain an Information Security ProgramIn 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:

l 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.

l Once the gaps are identified, determine the steps to close the gaps and protect card-holder data. Changes could mean adding new technologies to shore up firewall and peri-meter controls, or increasing the logging and archiving procedures associated with transaction data.

l Create an action plan for on-going compliance and assessment.

l Implement, monitor and maintain the plan. Compliance is not a one-time event. Regard-less of merchant or service provider level, all entities should complete annual self-assess-ments using the PCI Self Assessment Questionnaire.

l Contact an outside, certified PCI audit firm to conduct site surveys on an annual basis. l Call in outside experts as needed

- 47 -


ASI Reseller should visit the PCI Compliance web page on the Dealer Services website to view up to date information and additional tools to help clients.

Additional Source InformationThe following documents provide additional detail surrounding the PCI SSC and related security programs (PA-DSS, PCI DSS, etc):

l Payment Applications Data Security Standard (PA-DSS) https://www.p-cisecuritystandards.org/security_standards/pa_dss.shtml

l Payment Card Industry Data Security Standard (PCI DSS https://www.p-cisecuritystandards.org/security_standards/pci_dss.shtml






http://www.owasp.org/

- 48 -


Application System ConfigurationBelow are the operating systems and dependent application patch levels and configurations sup-ported and tested for continued PCI DSS compliance.

l Microsoft Windows 2003 Server, Windows 2008 Server, Windows XP Pro SP3 (No Longer Supported after April 2014), Windows 7 Pro, Windows 8 Pro. All latest updates and hot-fixes should be tested and applied.

l RAM: 4 GB RAM, Some configurations may require additional RAM

l Processor: Intel or AMD Processor 3 GHZ or faster

l Hard Drive: 500 GB of available hard-disk space

l Network Card

l TCP/IP network connectivity

l Battery Backup

l Antivirus

l Firewall: can be software or hardware

Note: Windows 2000 is no longer supported and is deemed PCI non compliant

Payment Application Initial Setup & ConfigurationThe following documents outline specific instructions for varying applications. All documents are posted on the Tech Notes and Manuals web page on the Dealer Services website. Resellers should become familiar with these documents to insure proper installation:

Installing the Payment Application

ASI has separate integration guides for each of the payment applications listed below:

l NETePay (not available on versions prior to v19)

l DataTran

l Mercury Payment Systems

l PAYWare PC

l PCChargeASI recommends does not provide specific instruction for the installation of the applications lis-ted above. Please refer to the software providers installation guide for installation instructions. These guide may be included with the software or found on the providers website.

- 49 -


Resetting Administrator Passwords

Resetting Administrator passwords is covered in the following documents:

l Version 19 Restaurant Manager Guides

l PCI Guidance

Updating Encryption Key on a Periodic Basis

Instructions for this are found in the following documents:

l PCI Guidance

l Read Me First

l Version 19 Installation Guides