PCI PABP Training Module

The purpose of this training module is to educate Micro$ale resellers and users on the best methods for setting up and maintaining an environment for the Micro$ale POS System that will securely protect the sensitive cardholder data used during payment processing based on the standards created by the Payment Card Industry.

Setting up systems using these standards also helps prevent and detect unauthorized access to a system and establishes good forensic evidence that can be used to determine what happened, how it happened, and who was involved in the event of a compromise.

This Training Module is also intended to help us all develop repeatable, documented best practices.

Payment Card Industry Data Security Standard

Systems which process payment transactions necessarily handle sensitive cardholder account information.

The Payment Card Industry (PCI) has developed security standards for handling sensitive 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 environment 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.

PCI DSS Core Requirements

Build and Maintain a Secure Network1. Install and maintain a firewall configuration to protect data2. Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data3. Protect Stored Data4. Encrypt transmission of cardholder data and sensitive information across public networks

Maintain a Vulnerability Management Program5. Use and regularly update anti-virus software6. Develop and maintain secure systems and applications

Implement Strong Access Control Measures7. Restrict access to data by business need-to-know8. Assign a unique ID to each person with computer access9. Restrict physical access to cardholder data

Regularly Monitor and Test Networks10. Track and monitor all access to network resources and cardholder data11. Regularly test security systems and processes

Maintain an Information Security Policy12. Maintain a policy that addresses information security

Access Control

Unique user accounts (user names) indicate that every account used is associated with an individual user and/or process. Additionally, any default accounts provided with operating systems, databases and/or devices should be removed, disabled, or renamed as possible, or at least should be given PCI DSS compliant complex passwords and then not be used. Examples of such default administrator accounts not to use include the Windows “administrator” and SQL/MSDE “sa”.

Complex Passwords must be at least 7 characters long, they must include both numeric and alphabetic characters, they must be changed at least every 90 days, and new passwords can not be the same as the last 4 passwords that were used.

The PCI DSS requires that administrative access and access to cardholder data in the payment processing environment be protected through the use of unique user names and complex passwords. Default accounts should not be used, and application logins should not have administrative privileges.

Furthermore, accounts should be locked out for at least 30 minutes (or require administrator reset) if an incorrect password is provided 6 times, and sessions idle for more than 15 minutes should require re-entry of username and password to reactivate the session.

Wireless Network Devices

In order to facilitate the safest environment to protect cardholder data, do NOT process payments across a wireless network. Process all payments from wired terminals protected by firewall services. Micro$ale does not recommend and will not support wireless transmission of cardholder data.

(6.1.c) If customer could implement the payment application into a wireless environment, instruct customers and resellers/integrators on PCI DSS-compliant wireless settings, per PCI Data Security Standard 1.3.9, 2.1.1 and 4.1.1.•If the application can not be installed in a wireless environment, specify that it is not possible and not supported.

The PCI standard requires the encryption of cardholder data transmitted over wireless connections. The following items identify the PCI standard requirements for wireless connectivity to the payment environment:•Firewall/port filtering services should be placed between wireless access points and the payment application environment with rules restricting access•Use of appropriate encryption mechanisms such as VPN, SSL/TPS at 128 bit, WEP at 128 bit, and/or WPA•If WEP is used the following additional requirements must be met:

•-Another encryption methodology must be used to protect cardholder data•-If automated WEP key rotation is implemented key change should occur every ten to thirty minutes•-If automated key change is not used, keys should be manually changed at least quarterly and when key personnel leave

•Vendor supplied defaults (administrator username/password, SSID, and SNMP community values) should be changed•Access point should restrict access to known authorized devices (using MAC Address filtering)

Support Guidelines Storage and Handling of Sensitive Data

There may be times when you must collect credit card data files and log filesto assist with support. Micro$ale encrypts sensitive data while stored, butsupport technicians must follow these additional guidelines to insure datasecurity: only collect sensitive data when necessary for a specific issue, storethat data in a known, secure location with limited access, collect only thespecific data that is necessary for the issue at hand, and securely delete thesensitive data immediately after use.

Support sessions should also be logged using Trouble Tickets so that thereis an audit trail showing who was involved, what was done, date, and time.

(1.1.6) Sensitive Credit Card data handling and storage considerations:Resellers/integrators must collect sensitive authentication only when needed to solve a specific problem•Resellers/integrators must store such data only in specific, known locations with limited access•Resellers/integrators must collect only the limited amount of data needed to solve a specific problem•Resellers/integrators must encrypt sensitive authentication data while stored•Resellers/integrators must securely delete such data immediately after use.

Micro$ale does NOT support the transmission of cardholder data via email, and customers should be instructed to NEVER send cardholder data via email.

Log Functions

(4.2.b) If application log settings are configurable by the customer and customers or resellers/integrators are responsible for implementing logging, examine PABP Implementation Guide prepared by the vendor to verify that customers are instructed on how to set PCI DSS-compliant log settings.

Implement automated audit trails to reconstruct the following events, for all system components:•All individual user accesses to cardholder data•All actions taken by any individual with root or administrative privileges•Access to all audit trails•Invalid logical access attempts•Use of identification and authentication mechanisms•Initialization of the audit logs•Creation and deletion of system-level objects.

Record at least the following audit trail entries for each event, for all system components:•User identification•Type of event•Date and time•Success or failure indication•Origination of event•Identity or name of affected data, system component, or resource.

Micro$ale automatically logs all functions involving access to cardholder data and all functions requiring Administrative access including viewing the logs themselves. Log settings are NOT configurable by the customer. The main purposes for logging these events are to prevent or detect unauthorized access and to provide good forensic evidence to reconstruct what occurred in the event of a compromise. Logged information is stored in an encrypted database.

Baseline System Configuration and Merchant Account Requirements

Below are the operating systems and dependent application patch levelsand configurations supported and tested for continued PCI DSS compliance:• Microsoft Windows 2000 Service Pack 4, Windows XP Professional with

Service Pack 2, Windows Server 2003, Windows Embedded for Point of Service. All latest updates and hot-fixes should be tested and applied.

• 1.0 GHz CPU, 2.0 GHz or faster recommended• 512 MB of RAM minimum, 1 GB or higher recommended• 500 MB of available hard-disk space• TCP/IP network connectivity.• Current Anti-virus protection

Merchant Account Setup:

•Credit card batch settlement must be initiated daily by the customer. Host-initiated and timed batch settlements are not supported by Micro$ale.

•Merchant accounts must also be setup to use Merchant Category Code 5812 for restaurants with gratuity capabilities.

Be sure to install anti-virus software, run regular virus scans on each system, and update virus definitions regularly for optimal protection.

Network Segmentation

Processor

Internet Router with Firewall Services Switch

Backoffice Computer

POS1

POS2

Ethernet Remote Kitchen Printer

Ethernet Remote Bar Printer

POS workstationFile server that stores shared data

Used for reports and data entry

POS workstation

The PCI DSS requires that firewall services be used (with NAT or PAT) tosegment network segments into logical security domains based on theenvironmental needs for internet access. A simplified high-level diagramof an expected network configuration is included here:

Never store cardholder data on internet-accessible systems.

(9.1.b) If customer could store cardholder data on a server connected to the Internet, instruct customers and resellers/integrators that they must not store cardholder data on Internet-accessible systems (e.g., web server and database server must not be on same server.)

Transport Encryption and Encryption Key Management

Encryption keys for sensitive data are generated using an algorithm value computed from one unique, static value and one random, dynamic value that changes with each successful batch. This encryption key gets changed every day after the credit card batch settlement is confirmed during the Daily Close Out process.

The encryption key can also be changed on demand using the Clear Batch administrator function in Micro$ale if there is evidence of an encryption key compromise.

Micro$ale uses SSL for secure transmission of cardholder data across the Internet. The PCI DSS requires the use of strong cryptography and encryption techniques with at least a 128 bit encryption strength (either at the transport layer with SSL or IPSEC; or at the data layer with algorithms such as RSA or Triple-DES) to safeguard sensitive cardholder data during transmission over public networks. PCI also requires that cardholder information is never sent via email without strong encryption of the data.

Remote Access and Support Considerations

Remote access is the ability to connect and interact with a remote network or computer as if you were directly connected to that remote network or computer.

The best policy to ensure the safest and most secure environment for payment processing is to not allow remote connections to merchant sites.

However, there may be times when you must connect remotely to a client site for support. Ensure that any such remote connection is initiated by an outbound connection that does not require firewall port enablement. The customer requesting support must monitor the system environment while the remote connection is active.

Also, implement the following security features with regard to remote access software:

•Change all default settings when installing remote access or remote control software including usernames and passwords.•Use unique passwords for each customer. •Allow connections from only specific (known) MAC or IP addresses•Use strong authentication or complex passwords for logins•Enable encrypted data transmission•Enable account lockout after a certain number of failed login attempts•Configure the system so a remote user must establish a Virtual Private Network (VPN) connection via a firewall before access is allowed.•Enable logging functions.•Restrict access to customer passwords to authorized personnel only.•Implement two-factor authentication for remote access to the network requiring unique usernames, strong passwords, and an additional item such as a certificate, token, or VPN with individual certificates.

Router, Firewall, and Authentication Protectionand Secure Modem Use

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.

A network router with firewall services must be used to protect all systems connected to the Internet. Change the default password for the router when it is installed, and change it again at regular intervals not longer than 3 months. Use unique passwords for each client, and restrict access to these passwords to authorized personnel only. Do not enable any port forwarding for remote connections or unnecessary services.

When connecting via dial-up using a modem and phone line, ensure that the customer only connects or turns on the modem when it is needed and that the modem is turned off or disconnected immediately after the update is complete.

Non-Console Administration

Micro$ale, as an application, does not require or use third-party remote access software (non-console administration).

Users and hosts within the payment application environment may need to use third-party remote access software such as Remote Desktop (RDP)/Terminal Server, pcAnywhere, etc. to access other hosts within the payment processing environment.

However, 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 connecting from outside the payment processing environment). For RDP/Terminal Services this means using the high encryption setting on the server, and for pcAnywhere it means using symmetric or public key options for encryption.

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

Definition of Two-Factor Authentication for Access

In identifying and authorizing users for access, you must use of two of the three authentication methods below to constitute valid two-factor authentication:

•Something you know, such as the User ID/Password combination•Something you have, such as a Digital Certificate or RSA token•Something you are, such as a Biometric ID mechanism

Note that two different sets of a single method (e.g., two User ID/Password combinations) do not create a valid two-factor authentication scenario.

It is also important to note that both methods of authentication must uniquely identify a specific person or user, not a group of people or users.

Traditional scenarios supported and expected for two-factor remote access include the use of User ID/Password at the network or computer level in combination with a Certificate or RSA SecureID used to authorize an encrypted VPN connection.

Cost-Effective Solutions That Can Meet PABP/ PCI Requirements Without Enabling “Full” Remote Access

Implementing two-factor authentication can be difficult and costly. There are other options available by providing connectivity needed to support customers without creating a “full” remote access solution. Remote access is the ability to connect and interact with a remote network or computer as if you were directly connected to that remote network or computer. “Full” remote access implies that this access is available at will (no action required by the customer), and some level of network communication is allowed to or through a firewall.

When considering alternative solutions, the following principles must be addressed to ensure that the solution provides needed controls without enabling “full” remote access:

•Ensure that remote connectivity can be traced to a specific service request (this would allow identification of the support technicians involved and the customer requesting support). •Ensure that the solution does not allow “on demand” or “always on” access. Remote access must be turned on by the customer requesting support only when needed, and it must be disabled as soon as the task is completed.•Ensure the solution uses robust (at least 128 bit) encryption for all communications.•Ensure that the solution does not allow for the exchange of credentials.•Mandate that the customer environment must be monitored while access is enabled.•Ensure that the connection is enabled by an outbound connection that does not require firewall port enablement.

Remote Access via UltraVNC SC

One example of a Remote Access solution that can be implemented to meet these requirements is UltraVNC SC (http://www.uvnc.com/). The Remote Access must be configured to require the customer to initiate the access and to connect to a specific IP address or range for support connectivity, and all support personnel involved must be tracked in support logs or trouble tickets.

UltraVNC SC does not require installation and does not require firewall port enablement at the customer location. The connection can only be initiated by the customer requesting support. No incoming connections are supported, no unattended service connections are possible, and the UltraVNC SC module can only connect to the IP address you have predefined in the module itself.

Micro$ale Software Updates

We strive to correct software bugs as soon as they are discovered and make patches available as quickly as possible. We are committed to releasing patches for any known vulnerabilities within 30 days after discovery.

Micro$ale dealers will be notified by phone and/ or email when a necessary patch is made available, and the patch will be transferred directly to them via secure remote access, or an upgrade CD will be sent if secure remote access is not available.

Micro$ale dealers are then responsible for going onsite or connecting via remote access to update their customers. Micro$ale direct end users will be notified by phone when a necessary patch is available, and the update will be transferred directly to the customer site and installed remotely, or an upgrade CD will be sent if secure remote access is not available.

When implementing Micro$ale updates remotely, technicians must apply the same security and logging procedures discussed previously.

Upgrade Concerns

Primary goals when upgrading to a new version:

•Smooth transition into the new version

•Ability to reverse the upgrade if there are any problems

•Removal of all legacy cardholder data and cryptographic materials

Before Upgrading:1. Settle all pending credit card batches. UNBATCHED CHARGES WILL BE LOST AND IRRECOVERABLE!2. Run a Daily and Weekly Closeout.3. Close the Time Records for the current payroll period.4. Print any desired historic sales reports5. Make backups of pertinent data6. Have the new license file and key ready (if applicable).7. Have the converted employee and menu files ready.8. Have the Upgrade setup files for the current version available in case you need to reverse the upgrade.

Upgrades From Versions 1 – 3

These older versions cannot be upgraded, but the employee and menu data can be saved and converted to be used with the new install of version 7.

1. Contact Micro$ale Support if you need assistance converting the employee and menu files.

2. Copy Install CD or Upgrade files to each hard drive. This will ensure that you have access to resources for setup and support in case the CD is lost or damaged or to reverse an upgrade.

3. Install version 7 on the new hardware as a new install.

4. Copy the converted employee and menu files into each Micro$ale directory.

5. Configure the remaining settings as you would a brand new install.

6. When everything is finished, run a Financial Database Reset on each terminal to remove the sales data generated during setup, testing, and training.

Upgrade Procedures from versions 1 – 3:

Upgrades From Versions 4 – 7

Upgrade Procedures from versions 4 – 7:1. Make a backup copy of each Micro$ale directory on a flash drive.2. Copy Install CD or Upgrade files to each hard drive.3. Copy a blank Chk-Stat.mdb, CheckNo.mdb, Financial.mdb, and Approvals.mdb to all terminals EXCEPT the

file server(s) to remove extraneous legacy sales data.4. Run setup.exe from the version 7 Upgrade folder on each terminal.5. Delete files with the .lic extension in the Micro$ale directory. Copy the new license file to each terminal. 6. If you received a new hardware key, install the new drivers and attach the new key.7. Start Micro$ale to initiate the automatic database update, but then exit back to Windows immediately.8. Run the EmployeeUpdate.exe (only for versions earlier than 5.4.x) 9. Run Menu Conversion.exe (only for versions earlier than 5.4.x) 10. Start Micro$ale.  Verify and Save the Register Options on each terminal (*see note below).

Save each sales tax, discount, gratuity, and service charge. 11. Run tests to ensure all terminals are communicating: make sure you can ring up and tender orders,

save employees and menu items, close audits, and run sales reports and closeouts without errors.  Run a test credit card charge for each card type, settle the test batch, and verify deposits with the bank.

12. Run the Legacy Clean function of the DatabaseUtility.exe program to remove all legacy cardholder data and cryptographic material from previous versions for PCI compliance.

13. After all tests are done, compact the databases on each terminal to make good backup (.bak) copies of the database files.

NOTE:If you are upgrading from a version earlier than 5.4.x, we recommend that you replace the Register Options.mdb with a blank one, and reconfigure the settings.

Reversing Upgrades

You must have the backup copy of each Micro$ale directory that you made and the upgrade setup.exe file for the previous version that you upgraded from in order to reverse the upgrade.

1. Uninstall all instances of Micro$ale from the Add/ Remove programs section of the Control Panel.

2. Delete the remaining Micro$ale directory from C:\Program Files\

3. Restore the backup copy of the Micro$ale directory that you made for that terminal.

4. Run setup.exe from the old version Upgrade folder to re-register Micro$ale with Windows.

5. Repeat steps 3 and 4 for each terminal in the system.

Implementation of the System Must Not Allow for the

Preservation of Historical Data from Credit Cards Remove Sensitive Data Stored by Previous Software Versions

(1.1.4) Delete any magnetic stripe data, card validation values or codes, and PINs or PIN block data stored by previous versions of the software.•historical data must be removed (magnetic stripe data, card validation codes, PINs, or PIN blocks stored by previous versions of the software) – removal is absolutely necessary for PCI compliance

An important part of the Micro$ale upgrade process is removing any and all historical cardholder data that may be leftover from credit card processing using the old version. Such removal is absolutely necessary for PCI compliance. All Micro$ale files from past and current versions are stored in the directory C:\Program Files\Micro$ale\. Before running live charges through the upgraded system, run the Legacy Clean Removal Tool in the DatabaseUtility.exe program, or manually search for and delete any and all files with the following names: Approvals.mdb, Approvals.bak

Last Batch.mdb, Last Batch.bakDTBatch.mdb, DTBatch.bakTerminalname Batch.mdb, Terminalname Batch.bak

(where Terminalname is the Windows network name of the computer)

Ensure that all backups of these files that were created are also securely deleted.

Micro$ale does not and cannot store card validation values or codes, PINs, or PIN block data.

Current Encryption Required for Sensitive Data

Remove Cryptographic Key Material Stored by Previous Software Versions

(1.1.5 & 6) Delete any cryptographic key material or cryptogram stored by previous versions of the software. This could be cryptographic keys used for computation or verification of cardholder data or sensitive authentication data.

•remove historical cryptographic material - removal is absolutely necessary for PCI compliance

Again, it is important during the upgrade process to remove all legacy cryptographic material from previous versions. Such removal is absolutely necessary for PCI compliance. All Micro$ale files from past and current versions are stored in the directory C:\Program Files\Micro$ale\. Before running live charges through the upgraded system, run the Legacy Clean Removal Tool in the DatabaseUtility.exe program, or manually search for and delete any and all files with the following names:

CCEncrypter.exeApprovals.mdb, Approvals.bakLast Batch.mdb, Last Batch.bakSitenameAddress.71x (encrypted license file)

(where SitenameAddress is the merchant business name and address)

Ensure that all backups of these files that were created are also securely deleted.

Legacy Data Removal for Upgrades

Run the DatabaseUtility.exe in the Micro$ale directory, click on the Removal Tools pull-down menu, and select Legacy Clean. This will display all legacy files containing old cardholder data or cryptographic material.

Click the Select All button to mark all files for removal, and click Remove Files. All selected files will be deleted from the local Micro$ale directory.

You must run the DatabaseUtility.exe program at each terminal to ensure all legacy cardholder data and cryptographic materials have been removed from the system.

Such removal is absolutely necessary for PCI compliance.

Test Accounts

Ensure all test accounts, test card numbers, and test charges are removed from the system prior to a new installation.

Ensure all test accounts, test card numbers, and test charges are removed before releasing or implementing software updates or patches.

Furthermore, ensure that “live” credit card account numbers are not used with a test merchant account, and vice versa.

Information Security Policy/ Program

In addition to the preceding security recommendations, a comprehensive approach to assessing and maintaining the security compliance of the payment application environment is necessary to protect the organization and sensitive cardholder data.

The following is a very basic plan every merchant/service provider should adopt in developing and implementing a security policy and program:

•Read the PCI DSS in full and perform a security gap analysis. Identify any gaps between existing practices in your organization and those outlined by the PCI requirements.

•Once the gaps are identified, determine the steps to close the gaps and protect cardholder data. Changes could mean adding new technologies to shore up firewall and perimeter controls,

or increasing the logging and archiving procedures associated with transaction data. •Create an action plan for on-going compliance and assessment.•Implement, monitor and maintain the plan. Compliance is not a one-time event. Regardless of merchant or service provider level, all entities should complete annual self-assessments using the PCI

Self Assessment Questionnaire. •Call in outside experts as needed. Visa has published a Qualified Security Assessor List of companies

that can conduct on-site CISP compliance audits for Level 1 Merchants, and Level 1 and 2 Service Providers. MasterCard has published a Compliant Security Vendor List of SDP-approved scanning vendors as well.

Review Summary

This Training Module and accompanying PABP Implementation Guide are to be reviewed and updated at least annually, when new software versions are released, and when there are changes in the requirements set forth by the Payment Card Industry.

PCI-PABP Implementation Guidance PABP Training ModuleDate last reviewed: 7/11/2008 Date last reviewed: 7/11/2008Reviewed By: Steve Theroux Reviewed By: Steve TherouxDate last modified: 7/11/2008 Date last modified: 7/11/2008Modified By: Steve Theroux Modified By: Steve Theroux

More Information:

A copy of the Payment Card Industry (PCI) Data Security Standard from VISA’s security website is available at the following Internet address:https://www.pcisecuritystandards.org/tech/download_the_pci_dss.htm

Additional information for merchants from VISA is available at the following Internet address:http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp_merchants.html?it=il|/business/accepting_visa/ops_risk_management/cisp.html|Merchants