Retail Pro 9 Series Users Guide -...

Retail Pro® 2009 PA-DSS/PABP Guide

Retail Pro International, LLC 400 Plaza Dr., Suite 200 Folsom, CA 95630 USA USA 1-800-738-2457 International +1-858-550-3355 www.retailpro.com

Retail Pro® 2009 PCI Implementation Guide

© 2009 Retail Pro International, LLC All rights reserved. 1

About this Guide This document explains how the use of Retail Pro® 8 and 9 helps retailers meet the Payment Card Industry (PCI) Data Security Standards.

If you believe the information presented here is incomplete or inaccurate, we encourage you to contact us at [email protected].

The software described herein is furnished under a license agreement.

Retail Pro International, LLC 400 Plaza Dr., Suite 200 Folsom, CA 95630 USA

USA 1-800-738-2457 International +1-858-550-3355

www.retailpro.com

Copyright © 2009 Intuit, Inc.® All rights reserved. Redistributed by Retail Pro International, LLC under license. Retail Pro International, LLC 400 Plaza Dr., Suite 200 Folsom, CA 95630 USA

USA 1-800-738-2457 International +1-858-550-3355 www.retailpro.com Trademarks

Retail Pro and the Retail Pro logo are registered trademarks and/or registered service marks in the United States and other countries. Oracle and Oracle 9i are registered trademarks and/or registered service marks of Oracle Corporation. All rights reserved. Other parties’ trademarks or service marks are the property of their respective owners and should be treated as such.

Document Revision History

03/06/2009 Original document released

03/30/2009 Document updated to include information for both PA-DSS and PABP

05/26/2009 Various updates.

08/28/2009 Added section “Ensure Secure Deletion of Deleted Data”



Table of Contents About this Guide ..................................................................................................................1 Introduction..........................................................................................................................4

About Retail Pro and PCI Data Security Standards.......................................................4 Installing Retail Pro .............................................................................................................5

Do Not Place Application Server and Web Server on Same Server or in DMZ ...........5 Firewalls.........................................................................................................................5

Configuring Retail Pro.........................................................................................................6 Setting up Employee Security........................................................................................6 Assigning Employee Security Permission ...................................................................10 Requiring Strong (Complex) Passwords......................................................................15 Application Audit Logging ..........................................................................................18 Configuring Retail Pro Preferences .............................................................................20

Storing Authentication Information...................................................................................22 Do Not Store Sensitive Authentication Data after Authorization................................22 Delete Non-PCI Compliant Auth Data and Crypt Keys ..............................................25 Sanitizing Card Numbers in Retail Pro 8.....................................................................25 Sanitizing Card Numbers in Retail Pro 9.....................................................................30 Logging the Viewing of Credit Card Numbers in V9..................................................33 Viewing Group Membership/Permission Lists in V9..................................................35 Logging the Viewing of Card Numbers in V8.............................................................37 Logging Changes to V8 “See Card Number” Permission ...........................................38 Securely Handling Customer Data Used for Debugging.............................................40

Other PA-DSS/PABP Compliance Measures....................................................................42 Protect Wireless Transmissions ...................................................................................42 Facilitate Secure Remote Software Updates................................................................43 Facilitate Secure Remote Access to Application .........................................................44 Use strong cryptography and encryption techniques ...................................................44 Never Send Unencrypted Personal Access Numbers by E-mail .................................44 Never Use Default Administrative Accounts for Application Logon .........................45 Changing the Default Sysadmin Password ..................................................................45

Protecting Cardholder Data................................................................................................46 Don’t Store Full Magnetic Stripe/CVV2 Data.............................................................46 Protect Stored Data ......................................................................................................47 Provide Secure Password Features ..............................................................................48



Log Application Activity .............................................................................................49 Build and Maintain Secure Applications and Network .....................................................50

Build Secure Applications ...........................................................................................50 Protect Wireless Transmissions ...................................................................................50 Test for Vulnerabilities ................................................................................................50 Build and Maintain Secure Networks ..........................................................................51 Never Store Cardholder Data on Server Connected to Internet...................................51 Secure Remote Access.................................................................................................51 Secure Remote Updates ...............................................................................................52 Encrypt Transmission of Credit Card Data..................................................................52 Ensure Secure Deletion of Deleted Data .....................................................................52

Data Security Do’s and Don’ts ..........................................................................................53 Do’s..............................................................................................................................53 Don’ts...........................................................................................................................53



Introduction About Retail Pro and PCI Data Security Standards When customers offer a credit card/bankcard at the point of sale, over the Internet, on the phone, or through the mail, they need to know that their account information is safe. The Payment Card Industry (PCI) Data Security Standards have been developed to address security and the risks associated when full magnetic stripe data or CVV2 values are stored during or after the authorization process by payment software applications. Visa developed the Payment Application Best Practices (PABP) to assist software developers and application providers in deploying secure software programs and help merchants to fully comply with PCI standards.

The security requirements for PCI compliance apply to all system and network components, server, or application that is included in or connected to the cardholder data environment. The cardholder data environment is that part of the network that possesses cardholder data or sensitive authentication data.

Note: Adequate network segmentation, which isolates systems that store, process, or transmit cardholder data from those that do not, may reduce the scope of the cardholder data environment.

Product Certification Status Retail Pro 8 and 9 are designed to meet the requirements of laid out within the PCI Standards. The products have been evaluated by an approved Qualified Payment Application Security Company (QPASC).

It is important to note that using a PA-DSS/PABP Certified application such as Retail Pro does not guarantee a retailer’s PCI Compliance since there are PCI requirements that must be met outside of the Payment Application itself.

This PA-DSS/PABP Implementation Guide contains recommendations for proper installation and operation of Retail Pro in a manner that will comply with PA-DSS/PABP requirements and support a merchant’s PCI DSS compliance efforts.

Where applicable, information specific to the requirements set forth by the PCI-DSS for PA-DSS vs. PABP are noted.

About this Guide The remainder of this guide is divided into the following sections: Section PA-DSS/PABP Requirements Description

Installing Retail Pro 9.0 Explains how to meet PA-DSS/PABP requirements related to installing and configuring Retail Pro.

Configuring Retail Pro 3.4, 4.2 Explains how to configure Retail Pro employee security and preferences to meet PA-DSS/PABP requirements.

Storing Authorization Data

1.1.1 through 1.1.5 Explains the steps needed to ensure customer data in Retail Pro 8 and Retail Pro 9 is stored securely.

Other PA-DSS/PABP Compliance Measures

3.1b, 3.1c, 6.0, 10, 11.2, 11.3, 12.1, 12.2

Miscellaneous information related to protecting wireless transmissions, secure remote updates, etc.



Installing Retail Pro Retail Pro is typically installed in a client-server environment. This section of the document explains the PCI Data Security Standards that need to be considered when planning/deploying the installation.

Do Not Place Application Server and Web Server on Same Server or in DMZ Reference: PA-DSS/PABP Requirements 9.0

In computer security, a demilitarized zone (DMZ), also known as demarcation zone or perimeter network, is a physical or logical subnetwork that contains an organization’s external services to a larger network, usually the Internet. The purpose of a DMZ is to add an additional layer of security to an organization’s Local Area Network (LAN).

To comply with PCI Data Security Standards,

Never install Retail Pro in the DMZ or any other zone that is directly routable to the Internet.

Make sure the database server and web server are on different servers.

Do not store cardholder data on Internet-accessible systems.

Firewalls Firewalls are computer devices that control computer traffic allowed into and out of a company’s network, as well as traffic into more sensitive areas within a company’s internal network. A firewall examines all network traffic and blocks those transmissions that do not meet the specified security criteria. Often, seemingly insignificant paths to and from the Internet can provide unprotected pathways into key systems. Firewalls are a key protection mechanism against unauthorized access.

When installing Retail Pro, make sure the firewall does the following:

Denies all traffic from “untrusted” networks and hosts, except for protocols necessary for the cardholder data environment

Restricts connections between publicly accessible servers and any system component storing cardholder data, including any connections from wireless networks

Controls traffic to/from the DMZ

Use and Regularly Update Anti-Virus Software PCI Data Security Standards require that you use anti-virus software on systems that store and/or transmit card data. In addition, the anti-virus software must be regularly updated.



Configuring Retail Pro Setting up Employee Security A key part of PCI compliance is ensuring that only authorized employees have access to the application and data stored in the database.

This section explains how to configure Retail Pro to maximize security and prevent unauthorized access to cardholder data.

There are four primary aspects of employee security that you will need to configure for maximum PCI compliance.

Changing the Default Sysadmin Password: The password for the sysadmin user must be changed immediately after the first use of Retail Pro.

Assigning Retail Pro Security Permissions: User groups only have access to those areas and features of the program for which they are granted permission. One feature that must be strictly controlled is the “See Credit Card” permission to see the full credit card number for customer credit cards. In addition, you must strictly control who can create/copy/delete groups and add/remove users to a group.

Whenever a change is made to a PCI-related permission (specifically, any and all changes related to the “See Credit Card Numbers” permission, adding/removing users for a group, deleting a group, etc.), Retail Pro makes an entry in the audit log.

Requiring Strong Passwords: The use of strong (complex) passwords is required for PCI compliance. Strong passwords must be a minimum of seven characters in length and contain a mix of letters, numbers, and special characters

Activating User Account Auditing: PCI compliance requires that an audit log be kept; therefore, you must configure Retail Pro to automatically log actions such as user logons (successful and unsuccessful), password changes, and changes to employee security groups.

Important! Turning off or not enabling audit logging results in non-compliance.



Changing the Default Password for Sysadmin User (Retail Pro 8) 1. Launch Security Administrator (SecAdmin.exe).



2. Select the Users tab, and then double-click the Sysadmin user.

Result: The User Properties dialog is displayed.

3. Type the new password in the User Password field.

Retype the new password in the Confirm Password field.

4. Click OK.

5. Click the Save button.

6. Select File > Exit.

Changing the Default Password for Sysadmin User (Retail Pro 9) 1. Select Employee Mgmt > Employees from the Home Screen.

2. Select the Sysadmin User, and then click Form View.

3. Enter a new Password, and then enter it again in the Confirm Password field.

4. Click Save.



Designating Retail Pro 9 Users as Sysadmin Users Retail Pro 9 employee records have a System Administrator checkbox. If the checkbox is selected, the employee is automatically granted access to all areas of the program. Only designate a user as a sysadmin user if it is absolutely necessary.

To designate users as sysadmin users:

1. Select Employee Mgmt > Employees from the Home Screen.

2. Select or create an employee.

3. Select the Sysadmin checkbox, and then click Save.



Assigning Employee Security Permission You can control user access to Retail Pro on a feature-by-feature basis. One of your first tasks after installing Retail Pro should be to set up employees and groups, and assign security permissions to those groups. The employees assigned to each group only have access to the features and areas for which permission has been granted.

In both v8 and v9, retailers must tightly control the permission that allows group members to view the full credit card number of customer credit cards in the customer record. If this security permission is selected, group members can see the entire card number on receipts and customer records.

Configuring Employee Security in Retail Pro 8 To configure employee security in Retail Pro 8:

1. Select Tools > Sec Admin from the Retail Pro Home Screen.

Result: The Security Administrator Login dialog displays.

2. Enter your User Name and Password, select a Language and then click Login.

Result: Security Administrator launches. By default, the Users tabbed page is selected.



3. Select the Groups tab.

Result: A list of your employee groups displays on the left. A drop-down list on the right allows you to select individual security areas.

4. Select the Group for which you want to view card numbers from the list on the left.

5. In the Area drop-down list, select RPRO.

Result: The list of security permissions for the core Retail Pro program displays.

6. Click the next to Retail Pro v.8 to display a list of sub-areas.

7. Select the System node to the display the list of system-related security permissions. Select or clear the checkbox for the System Preferences permission, as necessary.

A user assigned this permission can change the setting for encrypting stored credit card numbers (System Preferences > Point of Sale > EFT), so it should be strictly controlled.

8. Select the POS node to display the list of POS-related security permissions. Select or clear the EFT – See card number permission, as necessary.

If selected, group members can see the full card number when performing EFT transactions.

If cleared, group members will see only the last four digits of the card number. The rest of the numbers will display as xxxx…

9. Select File > Save or click the Save button.

10. Select File > Exit to close Security Administrator.



Showing/Hiding Card Numbers in Retail Pro 8 By default, card numbers are masked (except for the last four digits) after you run the Credit Card Maintenance tool (See Sanitizing Card Numbers in V8); however, employees who belong to a group that is assigned the See Card Number EFT – See card number security permission can view the full card number, if necessary, when working with receipts, sales orders, and customer records.

If you belong to an employee group that is assigned the See Card Number permission, click the Show Card button to display the entire card number.

(You can then click Hide Card to hide the card again.)

If you don’t belong to an employee group that is assigned the security permission, then the Show Card/Hide Card button is not enabled and you can only see the masked card number.

Sample Retail Pro 8 Credit Card Tender:



Configuring Employee Security in Retail Pro 9 To configure employee security in Retail Pro 9:

1. Select Employee Mgmt > Groups from the home screen.

2. Select the Group with which you want to work, and then click the Form View button.

3. Select the Permissions tab.

4. Select Retail Pro 9 > System, and then select (or clear) the System Preferences permission.

A user assigned this permission can change the setting for encrypting stored credit card numbers, so it should be strictly controlled.

5. Select Retail Pro 9 > POS, and then select (or clear) the See Credit Card Numbers permission.

Click the Save button.

Showing/Hiding Card Numbers in Retail Pro 9 Employees who belong to a group that is assigned the See Card Number security permission can view the full card number, if necessary, when working with receipts, sales orders, and customer records.

If you belong to an employee group that is assigned the See Card Number permission, click the Show Card button to display the entire card number.

(You can then click Hide Card to hide the card again.)

If you don’t belong to an employee group that is assigned the security permission, then the Show Card/Hide Card button is not enabled and you can only see the masked card number.



Sample Retail Pro 9 customer record with full card number displayed:

If a user with permission clicks Show Card, the full card number is displayed.



Requiring Strong (Complex) Passwords Reference: PA-DSS/PABP Requirements 3.4

The use of strong passwords is required for PCI compliance. You can configure Retail Pro employee security so that complex, or strong, passwords are required.

In addition to requiring the use of strong passwords, you must define a number of other settings that help prevent access to the system by unauthorized users.

Auto-generate a strong password for new employees.

Have passwords expire and require change at least every 90 days (with a grace period before expiration), and prevent previous passwords from being reused for a given period of time. The new password cannot be the same as any of the last four passwords.

Lock the user account after a pre-specified number of login attempts (not more than six attempts), with a lockout duration of 30 minutes or until an administrator enables the user.

Require the user to re-enter the password to reactivate a terminal that has been idle for more than 15 minutes.

Assign strong application and system passwords whenever possible For PCI Compliance, you must change default System account passwords and assign strong passwords whenever possible. For example, you must change the default Windows password, database password, etc. See the “Never Use Administrative Accounts for Application Logon” section of this document.



When you enable strong passwords, the passwords for users must meet the following requirements:

Not contain all or part of the user's account name

Be at least seven characters in length

Contain characters from three of the following four categories:

o English uppercase characters (A through Z)

o English lowercase characters (a through z)

o Base 10 digits (0 through 9)

o Non-alphanumeric (e.g. !, $, %)

You define settings for individual groups, and the settings then apply to all members of the group.

To enable strong passwords (v8)

1. Launch Security Administrator (SecAdmin.exe) from the \Retail\SecAdmin\ folder.


3. Select the group with which you want to work, and then select the Policy tab.

Result: A list of user security features is displayed.

4. Double click the Enforce Strong Password field, or select the field and press <F4>.

Result: The Enforce Strong Password dialog is displayed.

5. Select Enable, and then click OK.

6. Click the Save button and then exit Security Administrator.

Result: Members of the group are now subject to strong password requirements.



To enable strong passwords (v9):

1. Select Employee Mgmt > Groups from the Home Screen.

2. Select the group for whom strong passwords will be enabled.

3. Click Form View (<Alt+V>) to display the record in Form View.

4. Click the Policy tab.

Result: A list of user security features is displayed.

5. Double click the Enforce Strong Password field, or select the field and press <F4>.

Result: The Enforce Strong Password dialog is displayed.

6. Select Enable, and then click OK.

7. Click Save (<Alt+S>).

Result: Members of the group are now subject to strong password requirements.



Application Audit Logging Reference: PA-DSS/PABP Requirements 4.2

PCI Data Security Standards require that applications implement an automated audit trail to track and monitor access (e.g., user login, activities, access to unencrypted credit card reports, etc.).

When launching Retail Pro, all users must log on using a valid username/password combination (defined in each employee’s record). In this way, Retail Pro always knows “who” is using the system at any one time.

Sample Retail Pro 9 logon screen:

For PCI compliance, you must enable user account auditing options. When these options are set, anytime a user tries to log on (successful or unsuccessful), makes changes to passwords, or edits security groups, Retail Pro will log the activity. These activities can then be viewed using the appropriate Audit report.

To set user account auditing (v8):

1. Launch Security Administrator (SecAdmin.exe) from the \Retail\SecAdmin\ folder.


3. Select the group with which you want to work, and then select the Policy tab.

4. Result: A list of user security features is displayed.

5. Double click the Account Auditing field, or select the field and press <F4>.

Result: The Account Auditing dialog is displayed.

6. Select Enable Account Auditing, select the events to audit, and then click OK. Event Description

Log successful logon attempts If selected, a log entry is made whenever a user attempts to logon.

Log failed logon attempts If selected, a log entry is made whenever an unsuccessful logon attempt is made.

Log user password changes If selected, a log entry is made whenever a user changes his/her password.

Log user/group changes If selected, a log entry is made whenever a user makes any changes to employee user or group records.

7. Click the Save button (<Alt+S>), and then exit Security Administrator.



To set user account auditing (v9):

1. Select Employee Mgmt > Groups from the Home Screen.

2. Select the group for whom strong passwords will be enabled.

3. Click Form View (<Alt+V>) to display the record in Form View.

4. Click the Policy tab.

Result: A list of user security features displays.

5. Double click the Audit Logon Events field, or select the field and press <F4>.

Result: The Account Auditing dialog displays.

6. Select Enable Account Auditing, select the events to audit, and then click OK. The available events are:

Event Description

Log successful logon attempts If selected, a log entry is made whenever a user attempts to logon.

Log failed logon attempts If selected, a log entry is made whenever an unsuccessful logon attempt is made.

Log user password changes If selected, a log entry is made whenever a user changes his/her password.

Log user/group changes If selected, a log entry is made whenever a user makes any changes to employee user or group records.

7. Click Save (<Alt+S>).



Audit Reports (V9) To view the log information, launch and run the appropriate Audit report using Retail Pro Report Viewer. (RPRO9Reports.exe)

Configuring Retail Pro Preferences PCI Compliance requires that credit card numbers stored in the database be encrypted. Both Retail Pro 8 and Retail Pro 9 have an option in System Preferences for storing encrypted card numbers.

To store encrypted card numbers (v8):

1. Select Options > System Preferences from the home screen.

2. Select Point of Sale > EFT.

3. Select the checkbox for “Store encrypted card numbers.”

4. Select Save from the side menu.

If selected, Retail Pro will store the entire card number in an encrypted format on database records.

If not selected, Retail Pro will store only the last four digits of the card number (prefixed with twelve zeroes) in an encrypted format. Because the first 12 digits are zeroes and the last four digits are encrypted, this setting also is PCI compliant. Important! Please note that both settings are PCI compliant. Without storing credit card data, you can’t associate credit cards with customers, and some of the features in receipts won’t work without the credit card number. However, if card numbers are not stored, then the system can never be “hacked” and the numbers stolen. This may impact insurance rates for the company, and possibly processor costs.

Reference: See Appendix B. Preferences of the Retail Pro 8 User’s Guide for more information on Retail Pro Preferences.



To store encrypted card numbers (v9):

1. Select Options > System Preferences from the home screen.

2. Select Local Preferences > Point of Sale > Tenders > Credit Card.

3. Select the checkbox for “Store encrypted card numbers.”

4. Select Update from the side menu.

If selected, Retail Pro will store the entire card number in an encrypted format on database records.

If not selected, Retail Pro will store only the last four digits of the card number (prefixed with twelve zeroes) in an encrypted format. Because the first 12 digits are zeroes and the last four digits are encrypted, this setting also is PCI compliant. Important! Please note that both settings are PCI compliant. Without storing credit card data, you can’t associate credit cards with customers, and some of the features in receipts won’t work without the credit card number. However, if card numbers are not stored, then the system can never be “hacked” and the numbers stolen. This may impact insurance rates for the company, and possibly processor costs.

Reference: See Appendix B. Preferences of the Retail Pro 9 User’s Guide for more information on Retail Pro Preferences.



Storing Authentication Information Do Not Store Sensitive Authentication Data after Authorization Reference: PA-DSS/PABP Requirement 1.1

Data security standards require that when a customer swipes a card at point of sale, the application not store sensitive authentication data after the authorization is received. That is, the full information contained in the stripe (along with CVV2 data) should pass directly to the processor without being stored in the Retail Pro database.

The data that MUST NOT be stored includes:

Full track data

Card Validation Values (CVV)

Personal Identification Numbers (PIN)

When a customer’s credit card is swiped at point of sale in both v8 and v9, Retail Pro passes the data in the magnetic stripe to the EFT processor (via the processor gateway). At no point is the full stripe and CVV2 information stored in the Retail Pro database.

When displaying card numbers, Retail Pro masks account numbers. The first 12 digits are displayed as asterisks (*). The last four digits are displayed.

When storing card numbers in the Retail Pro database, the only card information stored is cardholder name, credit card name and type, credit card number, and expiration date.

Note: Retailers must make sure that the Retail Pro server on which cardholder data is stored is not connected to the Internet.

PCI Data Security Standards require that payment applications mask the display of full credit card data where appropriate (POS screens/printouts, logs, report screens, etc.).

Administrators and other relevant users can be assigned a security permission that allows them to see the full card number by clicking a button.



Sample Retail Pro 9 credit card tender:

In Retail Pro 9, all but the last four digits of credit card numbers are masked at point of sale.



Sample Retail Pro 9 customer record:

Credit card numbers are also masked on customer records. A user with sufficient security rights can click Show Card to view the entire card number.



Delete Non-PCI Compliant Auth Data and Crypt Keys Reference: PA-DSS/PABP Requirement 1.1.4 – 1.1.6

PCI Data Security Standards require that you delete sensitive information that may be stored in previous versions of Retail Pro. Specifically, you must delete:

Primary Account Numbers (PANs) stored by previous versions of the software.

PA-DSS/PABP Requirement 1.1.4

Earlier versions of Retail Pro did not store sensitive authentication data (track data, card validation values, and PIN block data); however, previous versions did store unencrypted Primary Account Numbers (PANs). Retail Pro provides a utility to clean up this data (Ccmaintv2.exe). See the following section “Sanitizing Card Numbers in Retail Pro 8” for instructions on using Ccmaintv2.exe.

Cryptograph key material or cryptogram stored by previous versions of the software.


For Retail Pro 8, running Ccmaintv2.exe will re-encrypt card data in PCI-compliant format. For Retail Pro 9, running the “Re-encrypt all card numbers in entire database” option will re-encrypt card data in PCI-compliant format.

Log files, debugging files, and other data sources to ensure that magnetic stripe data, CVV values, and PINs are not stored on systems.


See the “Securely Handle Customer Files Used for Debugging” section.

Sanitizing Card Numbers in Retail Pro 8 Reference: PA-DSS/PABP Requirements 1.1.4 and 1.1.5

Retail Pro has developed a tool (Ccmaintv2.exe) that will automatically encrypt credit card numbers on receipts, sales orders, and customer records in Retail Pro 8.

To ensure PCI data security compliance, you should run this tool at each of your Retail Pro 8 installations.

The Credit Card Maintenance Tool (CcMaintv2.exe) goes through your Retail Pro records and encrypts credit card numbers (except the final 4 digits) on specific types of records that you want processed. You can convert receipts, sales orders, and customer records (current data files and, optionally, archived customers and sales orders).

You run the tool from the command line and use various parameters to specify which records to convert.

Important! CcMaintv2.exe must be placed in the \Rpro folder.

Note: You should run this tool at each of your Retail Pro installations. Only one instance of the Credit Card Maintenance tool is allowed to run on your machine at one time.



Upgrade to PCI Compliant Version of Retail Pro Before running the Credit Card Maintenance tool, upgrade your Retail Pro installation(s) to a PCI-compliant version. With a PCI-compliant version installed, Retail Pro can begin encrypting card information. Temporarily, you will have both encrypted and non-encrypted data (new data encrypted, old data not encrypted). When a PCI-compliant version is installed at all installations, run the Credit Card Maintenance tool to convert the old data.

Delete Archived Batch and Secure Doc Files Before running the Credit Card Maintenance tool, you must safely and securely delete your archived credit card batch and Secure Doc files because the conversion tool does not encrypt those files.

There are several outside tools available to securely delete data, for example, SDelete and Eraser. NOTE: Retail Pro does not recommend or endorse these companies. If you require further assistance, refer to the help file provided with the tool or contact an IT professional.

The table below lists the files that must be deleted and where the files are located. File Location

Archived Batch Files …\Rpro\EFT\<year> and will be named <4-digit year><2-digit month><2-digit day>.<2-digit incremental identification number><1-character processor identifier>. Example: 20050512.01P

Secure Doc Files …\Retail\Rpro\SecurDoc

EFT_PCC_YYMMDD or EFT_RBS_YYMMDD

…\Retail\Rpro\LogFiles

Polling Considerations Polling does not encrypt or decrypt data. This is one reason why it is important to install a CISP-compliant version of Retail Pro® at the Main station and at all Remote stations. If you run the conversion tool at the Main, then poll with non-encrypted data from a Remote (either because you don’t have a CISP-compliant version installed, or because you have old polling transmissions files generated from before the change was put in place), when they poll to the Main, the Main will have both non-encrypted and encrypted receipts. The tool can be run again at the Main later, but it is better to get all the CISP-compliant versions of Retail Pro running, and then run the Credit Card Maintenance tool.

Run the conversion tool (CcMaintv2.exe) at each Retail Pro 8 installation where you want credit card numbers encrypted.

The utility reads through your receipts, sales orders, and customer records and encrypts the numbers. After conversion, only employees with sufficient security rights can view complete credit card numbers.

Important! Run the utility from the command prompt only; do not manually open the CcMaintv2.exe file.



Exit Retail Pro before Running Utility Exit Retail Pro before you run the utility. The utility should run in a safe mode to ensure that no other utilities or processes are running.

To run the Credit Card Maintenance utility:

1. Exit Retail Pro.

2. Select Start > Run from your Windows menu.

Result: The Run dialog displays.

3. Type cmd, and then click OK.

Result: The Command Line dialog displays.

4. In the command prompt, change the directory to the drive where your Retail Pro installation is located. For example, if your installation is on the C drive, type C: and press <Enter>.



5. Change the directory to the location of your Retail\Rpro by typing cd retail\rpro in the Command prompt.

6. To convert files, type ccmaintv2.exe WS:nn /txxxxx in the command prompt, and press <Enter>. The nn is your two-digit workstation number; xxxxx is the list of parameters you choose from the help list above.

For example, if you type in the command prompt ccmaintv2.exe WS:01 /tcrs the utility will convert your customers, archived customers, and sales orders.

At the end of the conversion, a screen popup will display information about the number of total files scanned and the number of files that have been processed.

Available parameters The following is a list of all the parameters that you can use with the Credit Card Maintenance Tool. Parameter Description

/? Displays the Help screen.

Ws:## Specifies the Workstation Number. When passing the ws: parameter, make sure that two conditions are met: 1) The workstation folder exists and has configuration files 2) The workstation setup indicates the path to your history files AS IT IS SEEN FROM THE CLIENT COMPUTER. (For example, if workstation 1 is set for network drive with history being in X:\RPRO, and workstation 2 is set for local drive D:\RETAIL\RPRO, use workstation 1 when running from workstation, and workstation 2 when running from the server). Supply the same workstation number as you would normally use in Rpro8.exe when running on the same computer.



Parameter Description

/t:c Processes customer records.

/t:r Processes archived customer records.

/t:s Processes sales order records.

/t:a Processes archived sales order records.

/t:i Processes invoice records.

/t:crsai Processes all records. (Combines all file type parameters.)

/u Blocks the status UI indicator while processing.

/b:YYYYMMDD Beginning date range for invoices (ignored for other records).

/e:YYYYMMDD Ending date range for invoices (ignored for other records).

/m:c Mode = Clear First 12 digits are changed to 1. For example, 5454545454545454 becomes 1111111111115454.

/m:e Mode = Encrypt Ccmaintv2.exe will re-generate encryption keys and re-encrypt each and every credit card it will find, regardless of whether it was already encrypted or not.

/c:[path to \ecm folder] This parameter takes a list of paths to ECM folders (i.e. those folders where Ecm.exe and EcmProc.exe are located). If you have multiple ECM installs pointing to the same 8-series data, you need to pass those paths separated by a comma (no blank spaces in between), e.g. "/c:d:\ecm,d:\ecm_extra,d:\ecm_backup". You can surround the entire /C: parameter with quotation marks to make sure it's all parsed as single parameter.



Sanitizing Card Numbers in Retail Pro 9 Reference: PA-DSS/PABP Requirement 1.1.5

Retail Pro’s Technician’s Toolkit enables technicians to quickly and easily sanitize all the credit and debit card account information in the Retail Pro 9 database. Specifically, Technician’s Toolkit includes options for:

Truncating/removing credit card information on sales orders, receipts, and customers.

Re-encrypting all credit and debit card numbers for the entire database.

Which Option Should I Use? You must run the re-encryption OR truncation/removal option. It is always safer to remove credit card information rather than keep it even in encrypted form, but if you choose to keep card information, you must run the re-encrypt process at least once to stay PCI compliant.

After the re-encryption process is run, all new documents created by Retail Pro will use the new encryption scheme.

Communication Note about Re-Encrypting Card Numbers For performance reasons, re-encrypting records in the database does not flag them to be re-polled, so EACH database (HQ, mains, remotes, etc.) has to re-encrypt credit cards individually. Failure to do so might leave some credit cards encrypted with the old keys, and these credit cards will be sent to other databases through polling.



When to Run Re-Encrypt Again (After First Running) There are two cases when you would need to re-run the Re-encrypt all credit/debit card numbers for entire database procedure:

1. Your database was compromised and you (or credit card companies) want to be sure that your entire database is re-encrypted with new keys.

Or

2. You used ECM to import customers/invoices/sales orders XML files generated by older versions of ECM or Retail Pro (e.g. you want to re-import old XML files for some reason). You need to perform re-encryption to make sure that all imported credit cards are encrypted with new keys.

To sanitize card numbers in Retail Pro 9:

1. Select Tools > Tech Toolkit from the Retail Pro Home Screen.

2. Select Data Maintenance > Miscellaneous.

Select options for truncating credit card numbers on sales orders (SOs), receipts, and customer records, or for re-encrypting all credit/debit card numbers for entire database, and then click Start.

Truncate credit card on SO You can truncate card numbers that are stored on unfilled and/or filled sales orders based on separate date ranges (the Created Date on the SO). You can also remove card expiration dates.

When truncating card numbers on sales orders, the credit card information is truncated in the Terms field on the SO. If one or more deposits were made by credit card, the card numbers are truncated in the Tender field. Selection Description

Include Select the Include checkbox to enable options for truncating credit card numbers on sales orders.

Truncate CC# except last 4 digits

If selected, credit card numbers are truncated so that only the last four digits are stored in sales orders.

Remove expiration date If selected, credit card expiration dates are removed from sales orders.

Unfilled/Filled SOs Select which sales orders will have credit card numbers truncated. You can select unfilled sales orders and/or filled sales orders. Unfilled sales orders have a remaining quantity due. Filled sales orders do not have a remaining quantity due. Unfilled SO: Select a date range (in the Begin Date and End Date fields) of unfilled sales orders to include. Filled SO: Select a date range (in the Begin Date and End Date fields) of filled sales orders to include.



Truncate credit card on receipts You can truncate card numbers that are stored on receipts based on a date range you enter (the Created Date on the receipt). You can also remove card expiration dates. Selection Description

Include Select the Include checkbox to enable options for truncating credit card numbers on receipts. Select a date range (in the Begin Date and End Date fields) of receipts to include.


If selected, credit card numbers are truncated so that only the last four digits are stored on receipts.

Remove expiration date If selected, credit card expiration dates are removed from receipts.

Remove customer credit card number You can truncate the credit card numbers in customer records for one or more of the following customer types.

Inactive customers

Secured customers

Global customers

Selection Description

Include Select the Include checkbox to enable options for truncating credit card numbers on customer records. Select a date range (in the Begin Date and End Date fields) of receipts to include.


If selected, credit card numbers are truncated on the selected records so that only the last four digits are stored on receipts.

Remove expiration date If selected, credit card expiration dates are removed from the selected customer records.

Inactive Customers If selected, card numbers are truncated on the records of inactive customers.

Security Level If selected, card numbers are truncated on customer records assigned to the selected Security Level.

Global Customers If selected, card numbers are truncated on customer records that are marked as Global (available to all subsidiaries).

Re-encrypt all credit/debit card numbers for entire database If you decide that you do want to keep card information in the database, you must re-encrypt the card numbers using Retail Pro’s PCI-compliant encryption code.

Select the Re-encrypt all credit/debit card numbers for entire database checkbox, and then click Start.

Technician’s Toolkit will apply the new encryption code to all card numbers in the database.



Logging the Viewing of Credit Card Numbers in V9 Any time a user clicks the “Show Card” button to view a customer’s entire credit card number, the action will be logged, whether or not the user has permission to view card numbers and whether or not the “Log Event” checkbox is selected for the permission.

Retailers and technicians can view these logs from the Audit Log table in the SQL Shell area of Technician’s Toolkit.

The audit log also records all users who are assigned to a group that has the permission to see credit card numbers turned on or off for the group. In other words, the log records when a user is given the permission to use the show card button or has this permission taken away and who made the change to this permission.

This change provides an added level of security for customers and helps retailers comply with Payment Card Industry Data Security Standards (PCI DSS).

To view log information for the Show Card button:

1. Launch Technician’s Toolkit, and select the SQL Shell node.

2. Select AUDIT_LOG_V from the list of table views.

3. Locate the log entry that you want to view, and then double-click in the Comments field.

Result: A pop-up is displays the SID for the customer or receipt, and the last four digits of the card number.

4. Click the “X” to close the pop-up.

Select a log entry, and then double-click in the Comments field to display the log memo.



The screen below shows the contents of the Comments field to log a situation in which the “Show Card” button was selected in the Customer module.

This shows the contents of the Comments field to log a situation in which the “Show Card” button was selected in the Receipts module.

Reference: See Chapter 9. Customer Management and Chapter 10. Recording Sales and Returns of the Retail Pro 9 User’s Guide.

When a credit card number is seen from Receipts area, the Comment field of the log will save the INVC_SID and last 4 digits of the card number.

When a credit card number is seen from Customers area, the Comment field of the log will save the CUST_SID and last 4 digits of the card number.



Viewing Group Membership/Permission Lists in V9 The ability to view card numbers is controlled via employee and group security; therefore, Retail Pro records all changes to employee and group security settings, including changes to the “See Card Number” permission, via the following Group List reports:

Group- Employees List (displays list of employees and the security groups to which the employee is assigned

Group- Permission List (displays all permissions assigned/unassigned to each group)

To access the Employee Group reports:

1. Launch Report View (RPro9Reports.exe), which is located in the \RetailPro9\ folder.

2. Click the Reports button to display the list of reports.

3. Expand the List reports node, and then select Group: Employees List or Group: Permission List.

4. Click the Run button to run the report.

5. Select filter criteria for the report, and then click OK.

Filter Criteria screen for Group: Employee List report:



Group: Employee List Report Fields Report Field Description

Group Name The name of the employee group.

Employee Name The name of the employee assigned to the group.

Active Employee The employee’s active status.

Group: Permission List Report Fields Report Field Description

Group Name The name of the employee group.

Application Name The name of the application for which the group has permission.

Application Area The area of the application for which the group has permission.



Logging the Viewing of Card Numbers in V8 In Retail Pro 8.6, when a user with permission to see card numbers clicks the Show Card button, a high-security receipt is automatically created to record the event.

These high-security receipts can be viewed in List View and Form View. Each receipt captures the following information:

The user who clicked the button

The date/time the action occurred

The last four digits of the card number

The customer ID of the customer

Please note that there is no preference option for this high-security receipt type; the creation of high-security receipts for the viewing of card numbers cannot be disabled.

Sample High Security Receipt Created by Viewing a Card Number:

The name of the user who clicked the Show Card button.

The last four digits of the card number that was viewed and the customer’s Cust ID.



Logging Changes to V8 “See Card Number” Permission Whenever a change is made involving the POS > EFT – See Card Number permission, Security Administrator generates a log entry to record the action.

A log entry is generated if the See Card Number permission is changed for a user in ANY way:

The permission is enabled/disabled for a group with assigned users

A user is assigned to a group that has the permission set

A user is removed from a group that has the permission set

A group that has the permission set is deleted; therefore, the permission is disabled for members of the deleted group

A separate log entry is made for each member of the group. In this way, retailers have a record of all changes to this security permission and the user(s) affected by the change.

Sample log file generated by changes to the “See Card Number” permission:



Each log entry includes the following information:

Field Description

Application The name of the application: SecAdmin.exe

OSUser The user’s Window’s username.

AppUser The name of the Retail Pro user who made the change.

HostName The name of the computer on which the action was performed.

Operation The operation performed on the permission: Enable or Disable.

Action The permission name (EFT – See card number).

User The Retail Pro user name of the employee (group member) whose permission status was changed.

Employee The name of the employee (group member) whose permission status was changed.

Group The name of the user group to which the change was made.

Comment A description of the action.



Securely Handling Customer Data Used for Debugging Reference: PA-DSS/PABP Requirement 1.1.6

In this section of the document are instructions for resellers/integrators on collecting, storing, handling and deleting sensitive debug or troubleshooting files, as specified in section 1.1.6a of PA-DSS/PABP.

The following practices must be observed:

1. Customer data transmitted to our network must be encrypted during transport. Retail Pro provides a Secure-FTP server (SFTP) solution as well as a secure HTTPS server to receive sensitive customer data, such as PANs. Please note that Retail Pro still has an FTP server for normal file transfers; this means a BP may have two logins, one for each server. Access to SFTP login information is restricted to the SFTP administrators. BPs/clients sending data will need an SFTP compatible client (FileZilla) and outbound network access over SFTP ports.

2. Customer data must be immediately moved from the SFTP server to a server with no Internet connection. Retail Pro’s IT department deploys a server on a separate firewalled network segment with no Internet routing to or from that network segment. An event driven script will run upon the completion of a file upload to the SFTP server that transfers the customer data from the SFTP server to this isolated file server and then removes the data off the SFTP server.

3. Secure Storage of data and removal of data from the network is required upon resolution of customer issues. A data administrator, appointed from each department, has access to copy sensitive data off the isolated file server and onto test equipment necessary to debug or repair the client problem. Upon completion of testing, the data administrator is responsible for ensuring the data is removed from the test equipment using a Secure Delete Utility such as Eraser. Auditing will be enabled on the isolated file server so that authentication and file modification activities are thoroughly logged. The data must also be removed from the isolated file server immediately upon completion of testing. Customer data is not allowed to be stored on laptops, thumb drives, or other forms of portable media.

References: See the Tech Memo titled Uploading Customer Data Using SFTP/HTTPS, available at http://documentation.retailpro.com



Secure Customer Data Management Using SFTP:



Other PA-DSS/PABP Compliance Measures Protect Wireless Transmissions Reference: PA-DSS/PABP Requirement 6.1

Networks that rely on wireless signals to communicate with each other carry a greater security risk than wire-bound connections. Compliance with PCI Data Security Standards requires that wireless security measures, including intrusion detection systems and encryption, be in place to protect from hacking attempts.

Wireless transmissions of cardholder data must be encrypted, over both public and private networks by using Wi-Fi Protected Access (WPA) technology (if WPA capable), or VPN or SSL at 128-bit. Compliance also forbids relying exclusively on WEP to protect confidentiality and access to a wireless LAN.

There should be a system in place to rotate shared keys.

Together, these steps help prevent the most common types of wireless attacks:

Eavesdropping – An attacker can gain access to a wireless network just by “listening” to traffic. Eavesdropping is very easy in the radio environment, as any radio transmission can be freely and easily intercepted by nearby devices or laptops. The sender or intended receiver has no means of knowing if the transmission has been intercepted or not.

Trust problems – If your wireless LAN is part of your enterprise network, then a compromise of your wireless LAN may lead to the compromise of your enterprise network. An attacker with a rogue access point can fool a mobile station into authenticating with the rogue access point, thereby gaining access to the mobile station. The only protection against these types of attacks is an efficient authentication mechanism.

Denial of Service (DOS) – A DOS attack is an attempt to prevent legitimate users of a service from using that service. Due to the nature of radio transmission, the wireless LANs are vulnerable to Denial of Service attacks and radio interference. Such attacks can be used to disrupt a business’ operations or used to gather additional information to use with another type of attack.

Man-in-the-middle – Packet spoofing (fake IP address) and impersonation are also valid threats, whereby traffic is intercepted midstream and then redirected by an unauthorized individual for malicious purposes.



How to Meet the Requirement If you implement Retail Pro over a wireless network, the wireless network must be segmented away from the payment network with a firewall and the wireless network must be set up in compliance with PCI DSS requirements. Never rely exclusively on wired equivalent privacy (WEP) to protect confidentiality and access to a wireless LAN

Specifically, for wireless networks transmitting cardholder data, verify the following:

WEP keys were changed from default at installation and are changed anytime anyone with knowledge of the keys leaves the company or changes positions

Default SSID was changed

Broadcast of the SSID was disabled

Default SNMP community strings on access points were changed

Default passwords on access points were changed

WPA or WPA2 technology is enabled if the device is WPA-capable

Facilitate Secure Remote Software Updates Reference: PA-DSS/PABP requirement 10

Retail Pro does not conduct remote install of patches onto customer systems. Software patches/updates must be obtained and installed by customers.

Secure Modem Use For PCI-DSS compliance, retailers should:

Only turn on the modem when needed for downloads. Turn it off immediately after the download is complete.

Configure the download to automatically disconnect after a period of inactivity.

When accessing cardholder data via modem, do not store the data on local hard drives, floppy disks, or other external media.



Facilitate Secure Remote Access to Application Two-Factor Authentication Mechanism Reference: PA-DSS/PABP Requirement 11.2, 11.3

PCI Compliance requires that applications be able to run with two-factor authentication mechanism including during remote access.

Retail Pro does not require the use of remote access, but if the BP/Integrator wants to conduct the install by connecting to the merchant system, you must use secure remote access methods.

Use technologies such as RADIUS or TACACS with tokens, or VPN with individual certificates.

To verify that two-factor authentication is implemented for all remote network access, observe an employee (for example, an administrator) connecting remotely to the network and verify that both a password and an additional authentication item are required.

If the remote access is an "always on" port network technology (like VPN, PCAnywhere, etc.) there should be a firewall protecting the card network from the Internet. In addition, anyone connecting to their network (like a Retail Pro Business Partner) needs to have a personal firewall installed on the systems they are connecting from (this would help prevent viruses from moving into a retailer’s card network from a BP network if a VPN technology is used).

Use strong cryptography and encryption techniques Reference: PA-DSS/PABP Requirement 12.1

Compliance with PCI Data Security Standards requires that sensitive information be encrypted during transmission over the Internet, because it is easy and common for a hacker to intercept and/or divert data while in transit.

We recommend the use of strong cryptography and encryption techniques (at least 128 bit) such as Secure Sockets Layer (SSL), Point-to-Point Tunneling Protocol (PPTP), or Internet Protocol Security (IPSEC) to safeguard sensitive cardholder data during transmission over public networks.

Never Send Unencrypted Personal Access Numbers by E-mail Reference: PA-DSS/PABP Requirement 12.2

PCI Compliance requires that unencrypted personal access numbers (PANs) are never sent by e-mail. If you are sending e-mail using the E-mail feature available in the Customer module, it is important that you never include card information in the e-mail.



Never Use Default Administrative Accounts for Application Logon Reference: PA-DSS/PABP Requirements 3.1b and 3.1c

For PCI Compliance, you must change default system account passwords whenever possible (Windows, Database, applications, etc.) and use “strong” passwords. Do not use default administrative account passwords and usernames on any other required software or OS accounts.

Changing the Default Sysadmin Password Hackers (external and internal to a company) often use default passwords and other default settings to compromise systems. These passwords and settings are well known in hacker communities and easily determined via public information.

To combat this, group, shared, or generic accounts and passwords must not be used.

The default username and password for logging into Retail Pro is:

Username: sysadmin

Password: sysadmin

The password for the sysadmin user must be changed immediately after the first use of Retail Pro.

Note: The sysadmin user has full system administrator permissions (all permissions). You can have more than one system administrator. To activate sysadmin privileges for a user, select the System Administrator checkbox in the Employee record.



Protecting Cardholder Data Don’t Store Full Magnetic Stripe/CVV2 Data PCI Data Security Standards require that when a customer’s card is swiped at point of sale, the full magnetic stripe or CVV2 data not be stored. That is, the full information contained in the stripe (along with CVV2 data) should pass directly to the processor without being stored in the database.

When a customer’s credit card is swiped at point of sale, Retail Pro® passes the data in the magnetic stripe (and any CVV2 data) to the EFT processor (via the processor gateway). At no point is the full stripe and CVV2 information stored in the Retail Pro® database.

In addition, Retail Pro® does not store the PVV number on debit cards.

The only card information that Retail Pro® stores is cardholder name, credit card name and type, card number, and expiration date.

Note: Make sure that the server on which cardholder data is stored is not connected to the Internet.

Sample customer record:

Credit card numbers are also masked on customer records. A user with sufficient security rights can click Show Card to view the entire card number.



Protect Stored Data Compliance with PCI Data Security Standards requires retailers to: protect whatever credit card data is stored in the database.

Retail Pro® does this by masking account numbers, rendering the full account number unreadable. Only the last four digits are displayed. The first 12 digits are displayed as asterisks (*).

Administrators and other relevant users can be assigned a security permission that allows them to see the full card number by clicking a Show Card button.

In addition, Retail Pro and its processors protect encryption keys for PINNED debit card transactions.



Provide Secure Password Features PCI Data Security Standards require that retail software systems force users to log on using a unique name and complex (or secure) password.

Regular passwords, which can consist of any number of letters or digits, can often be reproduced (for example, when an employee uses “password” or “123” as a password). Secure passwords must meet much stricter requirements.

Retail Pro contains a setting that enables you to require secure passwords. When using secure passwords, the following restrictions are in effect:

Not contain all or part of the user's account name

Be at least six characters in length

Contain characters from three of the following four categories:

English uppercase characters (A through Z)

English lowercase characters (a through z)

Base 10 digits (0 through 9)

Nonaphanumeric (e.g. !, $, %)



Log Application Activity Logging mechanisms and the ability to track user activities are critical. The presence of logs in all environments allows thorough tracking and analysis when something does go wrong. Determining the cause of a compromise is very difficult without system activity logs.

PCI Data Security Standards require systems to log all access by individual users (especially those with administrative privileges), and be able to link those activities to individual users.

When launching Retail Pro®, all users must log on using a valid username/password combination (defined in each employee’s record). In this way, Retail Pro® always knows “who” is using the system at any one time.



Build and Maintain Secure Applications and Network Build Secure Applications Compliance with PCI Data Security Standards requires applications be based on secure coding guidelines such as the Open Web Application Security Project guidelines.

Retail Pro® and the payment processors it uses to process EFT transactions meet these requirements.

Protect Wireless Transmissions Networks that rely on wireless signals to communicate with each other carry a greater security risk than wire-bound connections. Compliance with PCI Data Security Standards requires that wireless security measures, including intrusion detection systems and encryption, be in place to protect from hacking attempts.

Wireless transmissions of cardholder data must be encrypted, over both public and private networks by using Wi-Fi Protected Access (WPA) technology (if WPA capable), or VPN or SSL at 128-bit. Compliance also forbids relying exclusively on WEP to protect confidentiality and access to a wireless LAN.

How Retail Pro® Meets the Requirement Not applicable to Retail Pro® because Retail Pro® 8 does not support wireless transmissions.

Test for Vulnerabilities Unscrupulous individuals use security vulnerabilities to gain access to systems. PCI Data Security Standards require all systems to have current software patches to protect against unscrupulous employees, hackers, and viruses.

Fortunately, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques, which Retail Pro® and its payment processors’ developers follow.

The Retail Pro® and its payment processors development teams have systems in place to identify newly discovered security vulnerabilities, test for vulnerabilities, and deploy security patches and updates in a timely manner, as required by PCI Data Security Standards.



Build and Maintain Secure Networks PCI Data Security Standards require that systems be implemented in a secure network environment. Compliance also requires that the system not interfere with use of network address translation (NAT), port address translation (PAT), traffic filtering network devices, anti-virus protection, patch or update installation, or use of encryption.

Often, seemingly insignificant paths to and from the Internet can provide unprotected pathways into key systems. Networks need to be protected by firewalls from unauthorized access from the Internet, whether for e-commerce, employees’ Internet-based access via desktop browsers, or employees’ e-mail access.

Retailers are ultimately responsible for the security of their own network and for creating a secure network environment that does not interfere with the network operations listed above.

Vulnerabilities are continually being discovered by hackers/researchers and introduced by new software. Retail Pro® and its payment processors are tested frequently to ensure security is maintained over time and through changes.

Use and Regularly Update Anti-Virus Software PCI Data Security Standards require that systems that store and/or transmit card data must utilize anti-virus software to protect systems from malicious software.

Never Store Cardholder Data on Server Connected to Internet PCI Data Security Standards require that cardholder date not be stored on a server connected to the Internet.

Retailers are ultimately responsible for ensuring that the server on which Retail Pro® is running is not connected to the Internet.

Secure Remote Access Retail Pro® updates are delivered via a secure web site; however, you will still need to turn on modems and configure a personal firewall as suggested above.

PCI Data Security Standards also require that if employees, administrators, or vendors can access the application remotely, access should be authenticated using a 2-factor authentication mechanism. The application should allow for technologies such as RADIUS or TACACS with tokens, or VPN with individual certificates.

Retail Pro® and its payment processors follow these guidelines.



Secure Remote Updates PCI Data Security Standards require that if software updates are delivered via remote access into customers’ systems, software vendors should tell customers to turn on modem only when needed for downloads, and to turn off immediately after download completes. Alternatively, if delivered via VPN or other high-speed connection, software vendors should advise customers to properly configure a personal firewall product to secure “always-on” connections.

Retail Pro® delivers software updates via secure web site.

Encrypt Transmission of Credit Card Data Compliance with PCI Data Security Standards requires that sensitive information be encrypted during transmission over the Internet, because it is easy and common for a hacker to intercept and/or divert data while in transit.

PCI Data Security Standards requires the use of strong cryptography and encryption techniques (at least 128 bit) such as Secure Sockets Layer (SSL), Point-to-Point Tunneling Protocol (PPTP), or Internet Protocol Security (IPSEC) to safeguard sensitive cardholder data during transmission over public networks.

Retail Pro® and its payment processors utilize the above techniques when transmitting data.

PCI Data Security Standards also require encryption of all stored payment data using triple DES encryption, which Retail Pro® and its payment processers do.

Ensure Secure Deletion of Deleted Data The Retail Pro application provides the necessary protection of customer data and the transactions associated with them through its PCI certified functionality and encryption methods. This, however, does not provide protection for data which has been deleted from the hard drive, e.g., temporary backups, exports of data, or any other means by which data was stored unsecured on the hard drive.

Sanitizing data requires more than dragging files to a trash bin, reformatting or partitioning a computer. To ensure no trace of the deleted data has been left behind users should completely overwrite all contents of a deleted file(s) by using a data sanitization utility.

It is recommended Retail Pro users employ a file deletion management system or process to account for the secure deletion of data. There are a number of file deletion programs available specifically designed to identify and permanently purge your computer of previously deleted files. These solutions can be downloaded from the Internet, purchased online or at retail outlets.



Data Security Do’s and Don’ts Do’s

Ensure all aspects of a computer or network of computers that involve cardholder data should have the highest level of anti-virus software.

Assign employee access to payment data on a need-to-know basis.

Change employee passwords regularly.

Ensure employee security policy is understood by all your employees.

Limit access to computing resources and cardholder information to only those individuals whose job requires such access.

Change default passwords and security settings. Hackers often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known in hacker communities and easily determined via public information. Always change the vendor-supplied defaults before you install a system on the network (for example, passwords, Simple Network Management Protocol [SNMP] community strings, and elimination of unnecessary accounts).

Note: Using Retail Pro’s security features will enable you to comply with the Do’s and Don’ts listed here.

Don’ts Never store payment data on a web server or cache anywhere in memory related to a web

server. Payment data may only be stored in a separate, secure database, with at least one external firewall.

Never store Card Identification (CID) information. (A CID may be maintained only to obtain authorization, in order to process a payment.)

Never store track data from the magnetic stripe on the back of the Card.

Retail Pro 9 Series Users Guide -...

Documents

Transcript of Retail Pro 9 Series Users Guide -...