PA-DSS Implementation Guide 1.1 - rbchimneyandhearth.com · v RB Control Systems RB Control Systems v. 4.5 PA-DSS Implementation Guide Version 1.1 July 14, 2010 Confidential Information

v

RB Control Systems

RB Control Systems v. 4.5

PA-DSS Implementation Guide

Version 1.1

July 14, 2010

Confidential Information

The information contained in this document is confidential and has been prepared to establish internal policies and procedures. Distribution of this document outside of intended recipient is strictly prohibited. Do not copy or distribute without the permission of the Chief Technology Officer.

Document Owners

Vincent Ragosta

Developer

Copyright 2010, RB Control Systems

Proprietary and Confidential Information 2



Table of Contents

Notice ............................................................................................................................................................ 4

About this Document .................................................................................................................................... 5

Revision Information ..................................................................................................................................... 6

Executive Summary ....................................................................................................................................... 7

Application Summary ................................................................................................................................ 7

Typical Network Implementation ............................................................................................................ 10

Dataflow Diagram .................................................................................................................................... 12

Difference between PCI Compliance and PA-DSS Validation .................................................................. 14

Considerations for the Implementation of Payment Application in a PCI-Compliant Environment .......... 16

Remove Historical Sensitive Authentication Data (PA-DSS 1.1.4.a) ........................................................ 16

Sensitive Authentication Data requires special handling (PA-DSS 1.1.5.c) ............................................. 17

Purging of Cardholder Data (PA-DSS 2.1.a) ............................................................................................. 18

Removal of Cryptographic material (PA-DSS 2.7.a) ................................................................................ 19

Set up Good Access Controls (3.1.c and 3.2) ........................................................................................... 19

Properly Train and Monitor Admin Personnel ........................................................................................ 20

Key Management Roles & Responsibilities (PA-DSS 2.5) ........................................................................ 22

Log settings must be compliant (PA-DSS 4.2.b) ...................................................................................... 22

PCI-Compliant Wireless settings (PA-DSS 6.1.b and 6.2.b) ......................................................................... 22

Never store cardholder data on internet-accessible systems (PA-DSS 9.1.b) ......................................... 23

PCI-Compliant Delivery of Updates (PA-DSS 10.1) .................................................................................. 23

PCI-Compliant Remote Access (11.2 and 11.3.b) .................................................................................... 24

Data Transport Encryption (PA-DSS 12.1.b) ............................................................................................ 25

PCI-Compliant Use of End User Messaging Technologies (PA-DSS 12.2.b) ............................................. 25

Network Segmentation ........................................................................................................................... 26

Maintain an Information Security Program ................................................................................................ 26

Application System Configuration .............................................................................................................. 27

Payment Application Initial Setup & Configuration ................................................................................ 27

PA-DSS Implementation Guide Checklist ....................................................... Error! Bookmark not defined.

Notice THE INFORMATION IN THIS DOCUMENT IS FOR INFORMATIONAL PURPOSES ONLY. RB CONTROL

SYSTEMS MAKES NO REPRESENTATION OR WARRANTY AS TO THE ACCURACY OR THE COMPLETENESS

OF THE INFORMATION CONTAINED HEREIN. YOU ACKNOWLEDGE AND AGREE THAT THIS

INFORMATION IS PROVIDED TO YOU ON THE CONDITION THAT NEITHER RB CONTROL SYSTEMS NOR

ANY OF ITS AFFILIATES OR REPRESENTATIVES WILL HAVE ANY LIABILITY IN RESPECT OF, OR AS A

RESULT OF, THE USE OF THIS INFORMATION. IN ADDITION, YOU ACKNOWLEDGE AND AGREE THAT

YOU ARE SOLELY RESPONSIBLE FOR MAKING YOUR OWN DECISIONS BASED ON THE INFORMATION

HEREIN.

Nothing herein shall be construed as limiting or reducing your obligations to comply with any applicable

laws, regulations or industry standards relating to security or otherwise including, but not limited to, PA-

DSS and DSS.

The retailer may undertake activities that may affect compliance. For this reason, RB Control Systems

is required to be specific to only the standard software provided by it.



About this Document This document describes the steps that must be followed in order for your RB Control Systems POS

installations to comply with Payment Application – Data Security Standards (PA-DSS). The information in

this document is based on PCI Security Standards Council Payment Application Data Security Standards

program (version 1.2 dated October, 2008).

RB Control Systems instructs and advises its customers to deploy RB Control Systems’ applications in a

manner that adheres to the PCI Data Security Standard (v1.2). Subsequent to this, best practices and

hardening methods, such as those referenced by the Center for Internet Security (CIS) and their various

“Benchmarks”, should be followed in order to enhance system logging, reduce the chance of intrusion

and increase the ability to detect intrusion, as well as other general recommendations to secure

networking environments. Such methods include, but are not limited to, enabling operating system

auditing subsystems, system logging of individual servers to a centralized logging server, the disabling of

infrequently-used or frequently vulnerable networking protocols and the implementation of certificate-

based protocols for access to servers by users and vendors.

If you do not follow the steps outlined here, your RB Control System installations will not be PA-DSS

compliant.



Revision Information Version Name Title Date of

Update

Summary of Changes

1.0 Vincent

Ragosta

Developer July 12, 2010 Initial Release

1.1 Vincent

Ragosta

Developer July 14, 2010 Modifications to diagrams of typical

network implementation.

Note: This PA-DSS Implementation Guide must be reviewed on a yearly basis, whenever the underlying

application changes or whenever the PA-DSS requirements change. Updates should be tracked and

reasonable accommodations should be made to distribute or make the updated guide available to users.

RB Control Systems will distribute the IG to new customers via its website at

www.rbcontrolsystems.com.



Executive Summary Payment Application version 4.5 has been PA-DSS (Payment Application Data Security Standard)

certified, with PA-DSS Version 1.2. For the PA-DSS assessment, we worked with the following PCI SSC

approved Payment Application Qualified Security Assessor (PAQSA):

Coalfire Systems, Inc. 361 Centennial Parkway Suite 150

Louisville, CO 80027

Coalfire Systems, Inc. 150 Nickerson Street Suite 106

Seattle, WA 98109

This document also explains the Payment Card Industry (PCI) initiative and the Payment Application

Data Security Standard (PA-DSS) guidelines. The document then provides specific installation,

configuration, and ongoing management best practices for using Payment Application as a PA-DSS

validated Application operating in a PCI Compliant environment.

PCI Security Standards Council Reference Documents

The following documents provide additional detail surrounding the PCI SSC and related security

programs (PA-DSS, PCI DSS, etc):

• Payment Applications Data Security Standard (PA-DSS)

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

• Payment Card Industry Data Security Standard (PCI DSS)

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

• Open Web Application Security Project (OWASP)

http://www.owasp.org

Application Summary Payment Application

Name: RB Control Systems POS

Payment Application Version:

4.5

Operating System(s) Supported/Tested:

• Host Computer

o Windows XP Professional w/ SP2


o Windows 7 (Any Version)

o Windows Server 2003 (Any Version)

o Windows Server 2008 (Any Version)

• Client Computer

o Windows XP Home w/ SP2




o Windows XP Home w/ SP3


o Windows 7 (Any Version)

Database Software Supported/Tested:

• Host Computer

o Microsoft Access 2002 or higher for accessing

database

o Microsoft Access 2007 w/ SP1 (Full Edition or

Runtime)


Runtime)

• Client Computer


Runtime)


Runtime)

Components of Application Suite (i.e. POS, Back Office, etc.)

• PINPadTS, Terminal Services PINPad Processing v. 2.2.0

o PINPadTS is used to securely transmit PIN debit

information between Terminal Services clients and

the Terminal Server.

• RBCK, Remote Support Utility v. 4.10.01

o The RBCK Remote Support Utility utilizes the

UltraVNC single-click solution to create a secure

support session to the client’s computer.

• RBControlStartup, Program Bootstrap v. 4.05.03

o RBControlStartup is used to process updates and

launch the RB Control Systems POS program.

• RBSysMaint, RB Update Utility v. 3.0.0

o RBSysMaint is used to maintain the database files

through a compact and repair process. It also

downloads and processes updates for the RB

Control Systems POS program.

• RestoreStartup, Bootstrap Replacement v. 1.0.05

o RestoreStartup is used to replace the

RBControlStartup program in the event this

program is updated.

• WorkMultiStore, Multi-Store Database Updater v. 4.0.08

(Deprecated)

o The WorkMultiStore program is used to transmit

database records between a branch and main store

location. It is no longer used for new installations.

Other Required Payment Application Software:

None

Other Required Third Party Software:

NetePay (Required for NetePay credit card processing only)

• Alliance Data (Host-based MultiLane) v. 4.10

• FDMS North (Terminal-based MultiLane) v. 4.31

• Concord EFS (Host-based MultiLane) v. 4.01

• Fifth Third (Host-based MultiLane) v. 4.16

• Heartland (Terminal-based MultiLane) v. 4.14



• RBS Lynk (Terminal-based MultiLane) v. 4.30

• GPS (Terminal-based MultiLane) v. 4.14

• GPS (Host-based MultiLane) v. 4.14

• Nova (Host-based MultiLane) v. 4.16

• Nova (Terminal-based MultiLane) v. 4.16

• Paymentech (Host-based MultiLane) v. 4.14

• Paymentech (Terminal-based MultiLane) v. 4.14

• PPI (Host-based MultiLane) v. 4.12

• PPI (Terminal-based MultiLane) v. 4.11

• TSYS (Terminal-based MultiLane) v. 4.41

Application Description:

RB Control Systems POS is a point of sale and business

management application. Typical installations are at one business

location, but may span multiple locations through the use of

Microsoft Terminal Services.

Credit card processing is either integrated, via Mercury Payment

Systems, PPI, and Sterling or through the 3rd party NetePay

processing software.

Application Target Clientele:

Pool, spa, fireplace, pond and other retail areas.

Description of Versioning Methodology:

M.mm.rr

M = Major Release Number. A major release is a release where

new functionality is added on a broad scope. For example, version

4.0 centralized all database tables and added several new features

throughout the program. Version 3.0 added terminal services and

several other features.

mm = Minor Release Number. Minor releases are releases where

new functionality is added to the program, but only in a very

limited scope.

rr = Revision Number. A revision release is a release that contains

bug fixes.

4.01.12 should be read as: RB Control Systems Version 4, Release

1, Revision 12

List of Resellers/Integrators (If Applicable):

None



Typical Network Implementation The diagrams below illustrate the typical network implementation of the RB Control Systems POS.

If the merchant’s network is hosting one or more publically-accessible servers, such as a web server or e-

mail server, then these servers must be segregated from the cardholder data network through the

implementation of a network DMZ.

Specific requirements of a PA-DSS compliant network include:

1.3.1 Implement a DMZ to limit inbound and outbound traffic to only protocols that are necessary for

the cardholder data environment.

1.3.7 Place the database in an internal network zone, segregated from the DMZ.

2.2.1 Implement only one primary function per server.

Cardholder Data Network

`

RB Control

Systems POS

`

RB Control

Systems POS

`

RB Control

Systems POS

RB Control

Systems

Database /

RB Control

Systems POS*

`

RB Control

Systems Support

Technician

Internet

Router/Firewall

Outbound

UltraVNC

Connection

Router/Firewall

RB Control Systems

Deployment

Single Location

`

RB Control

Systems POS

*Some customers may choose to have the RB Control Systems POS program run on the same computer where the database resides.

The blue arrows represent a typical connection path for a support request. All support requests must be

initiated by the customer. These remote sessions are encrypted using RC4 encryption.

Your IT staff may need to make an exception in the firewall if outbound filtering is being performed.





Dataflow Diagram Per the PCI DSS, all sensitive cardholder data must be encrypted when transmitted over open, public

networks, such as the Internet.

The NetePay, Mercury, and Sterling credit card processing solutions utilize the DSIClientX protocol,

developed by Datacap Systems, Inc. (http://www.datacapsystems.com). This protocol utilizes the

Windows cryptographic services to ensure cardholder data is encrypted over public networks, such as

the Internet. The dataflow diagram for the flow of encrypted card holder data associated with RB

Control Systems POS is as pictured below:

Dataflow Diagram for NetePay Credit Card Processing

Step 4 is broken down into steps 4a and 4b. If a DialLink modem is installed and the merchant’s Internet

service is “down”, then the credit card processing will proceed via step 4a. The typical behavior is for

credit card processing to proceed via step 4b, across the Internet.



Dataflow Diagram for Mercury and Sterling Credit Card Processing

Step 4 is broken down into steps 4a and 4b. If a DialBridge modem is installed and the merchant’s

Internet service is “down”, then the credit card processing will proceed via step 4a. The typical behavior

is for credit card processing to proceed via step 4b, across the Internet.



The PPI credit card processing solution utilizes a proprietary payment system known as the PPI

PayMover payment platform. This platform utilizes the SSL protocol to ensure cardholder data is

encrypted over public networks, such as the Internet. The dataflow diagram for the flow of encrypted

card holder data associated with RB Control Systems POS is as pictured below:

Dataflow Diagram for PPI PayMover Credit Card Processing

1) User swipes sensitive

authentication data or keys

cardholder data*

Store Server Hosting RB Control Systems

POS database

4) If approved,

encrypted cardholder

data is stored in store

POS database**

2) Send sensitive credit card

information across Internet using

SSL connection`

POS

3) Decline/

Approval

transmitted to

store POS from

processor

PPI PayMover

Payment Platform

Internet

*If keyed, then the primary account number (PAN) and expiration date are encrypted by the DSIClientX protocol using Windows cryptographic services.

If swiped, then the track2 data is encrypted by the DSIClientX protocol using Windows cryptographic services.

This encrypted material is transmitted to the processor via steps 3 and 4.

**The RB Control Systems database stores an encrypted version of the primary account number (PAN) and expiration date in the RB Control Systems

POS database. Under no circumstances is sensitive authentication data stored by the RB Control Systems POS program.

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

We have performed an assessment and certification compliance review with our independent

assessment firm, to ensure that our platform does conform to industry best practices when handling,

managing and storing payment related information.

PA-DSS is the standard against which the RB Control Systems POS application has been tested, assessed,

and validated.

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

hosting) environment.



Obtaining “PCI Compliance” is the responsibility of the merchant and your hosting provider, working

together, using PCI compliant server architecture with proper hardware & software configurations and

access control procedures.

The PA-DSS Validation is intended to ensure that the RB Control Systems POS application will help you

achieve and maintain PCI Compliance with respect to how the RB Control Systems POS handles user

accounts, passwords, encryption, and other payment data related information.

The Payment Card Industry (PCI) has developed security standards for handling cardholder information

in a published standard called the PCI Data Security Standard (DSS). The security requirements defined

in the DSS apply to all members, merchants, and service providers that store, process or transmit

cardholder data.

The PCI DSS requirements apply to all system components within the payment application 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.

The 12 Requirements of the PCI DSS:

Build and Maintain a Secure Network

1. Install and maintain a firewall configuration to protect data

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

Protect Cardholder Data

3. Protect Stored Data

4. Encrypt transmission of cardholder data and sensitive information across public networks

Maintain a Vulnerability Management Program

5. Use and regularly update anti-virus software

6. Develop and maintain secure systems and applications

Implement Strong Access Control Measures

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

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

9. Restrict physical access to cardholder data

Regularly Monitor and Test Networks

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

11. Regularly test security systems and processes

Maintain an Information Security Policy

12. Maintain a policy that addresses information security



Considerations for the Implementation of Payment Application

in a PCI-Compliant Environment The following areas must be considered for proper implementation in a PCI-Compliant environment.

Sensitive Authentication Data requires special handling

Remove Historical Cardholder Data

Set up Good Access Controls

Properly Train and Monitor Admin Personnel

Key Management Roles & Responsibilities

PCI-Compliant Remote Access

Use SSH, VPN, or SSL/TLS for encryption of administrative access

Log settings must be compliant

PCI-Compliant Wireless settings

Data Transport Encryption

PCI-Compliant Use of Email

Network Segmentation

Never store cardholder data on internet-accessible systems

Use SSL for Secure Data Transmission

Delivery of Updates in a PCI Compliant Fashion

Remove Historical Sensitive Authentication Data (PA-DSS 1.1.4.a) RB Control Systems POS prior to v. 4.0:

Prior to version 4.0 of RB Control Systems, the program was storing sensitive credit card data in a non-

PCI compliant manner. As a result, it is critical that merchants permanently destroy any copies or

backups of the database files that were taken prior to the v. 4.0 release. In particular, any copies or

backups of the RBCSData.mdb and RBCSDataTempWorkSpaceReceipts.mdb database files should be

destroyed. Removal of such database files is absolutely necessary for the merchant to maintain PCI

DSS compliance. Please note, simply deleting the file is insufficient to ensure it cannot be recovered.

You must delete the file using a secure delete utility. For those files stored on magnetic media, such as a

hard drive, you can use the SDelete utility provided by Windows Sysinternals

(http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx) to securely delete these files. If the

backup was placed on a CD-ROM or DVD-ROM, it is suggested the media be physically destroyed.

RB Control Systems POS post v. 4.0:

Per our policy, all RB Control Systems customers who pay their support dues receive updates for the life

of the RB Control Systems POS program. Through the course of these updates, all sensitive credit card

data stored in the database files has been purged. If the customer is operating v. 4.5 of the program,

they can be assured that this data has been safely purged from the live version of the database files.

This does not include any copies or backups of the RBCSData.mdb and

RBCSDataTempWorkSpaceReceipts.mdb database files. These files should still be destroyed as outlined

above.



Sensitive Authentication Data requires special handling (PA-DSS 1.1.5.c) There are several data elements that can be obtained from a credit and debit card. These data elements

are summarized in the PCI DSS as follows:

Data Element

Storage Permitted Protection

Required

PCI DSS Req. 3, 4

Cardholder Data Primary Account Number Yes Yes Yes

Cardholder Name Yes Yes No

Service Code Yes Yes No

Expiration Date Yes Yes No

Sensitive

Authentication Data

Full Magnetic Stripe Data No N/A N/A

CAV2/CID/CVC2/CVV2 No N/A N/A

PIN/PIN Block No N/A N/A

The RB Control Systems POS program stores the primary account number and expiration date in

encrypted form and the cardholder name. As illustrated above, no sensitive authentication data should

be stored in the system for longer than it is required to complete a transaction. Requirements 3.1 and

3.2 of the PA-DSS address this issue:

3.1 “Keep cardholder data storage to a minimum. Develop a data retention and disposal policy.

Limit storage amount and retention time to that which is required for business, legal and/or

regulatory purposes, as documented in the data retention policy.”

3.2 “Do not store sensitive authentication data after authorization (even if encrypted).”

If cardholder data does need to be collected for troubleshooting purposes, then you must adhere to the

following:

• Collect the minimum amount of sensitive authentication data and only when needed to solve a

specific problem

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

• Encrypt sensitive authentication data while stored

• Securely delete any sensitive authentication data after the problem has been completed

Sensitive authentication data includes the 3 or 4 digits printed on the back of the credit card

(CAV2/CID/CVC2/CVV2) and the PIN/PIN Block. Under no circumstances should this information be

retained longer than needed to perform a specific task. For this reason, it is highly recommended that

the user never store this information, even on a temporary basis. The RB Control Systems program,

version 4.0 or greater, does not automatically store any sensitive authentication data.



Receipts

By default, the RB Control Systems POS will mask the credit card number that prints on both the

customer’s and merchant’s receipt. There is an option to print the full credit card number on the

merchant copy of the receipt. However, the merchant should consult with their credit card processor

and federal, state and/or local laws concerning the retention of cardholder data before enabling this

option.

This option is accessible from the Tools�Company Setup screen.

From this screen, click the “Credit Card Processing” tab and select

the appropriate merchant id. The system will prompt for your

administrative credentials. Once validated, you will see a list of

credit card processing options. Towards the bottom of the

screen, there is an option to mask the card number on the merchant’s receipt. If the merchant chooses

to print the cardholder data on their copy of the receipt, it is the merchant’s responsibility to ensure the

receipt is securely stored in accordance with all PA-DSS regulations.

Credit Cards on File

The only cardholder data that can be stored,

outside of credit card transactions and at the

merchant’s discretion, is the cardholder’s

primary account number and expiration date.

This information can be securely stored as part

of the RB Control Systems “credit card on file”

feature (P.O.S. �Customers�Add Id’s). All

primary account numbers and expiration dates

entered through this interface are stored in an

encrypted manner. No other credit card or

debit card data elements should be stored in

any part of the RB Control Systems program

by the user.

Purging of Cardholder Data (PA-DSS 2.1.a) The following guidelines must be followed when dealing with cardholder data (PAN alone or with any of

the following: expiry date, cardholder name or service code):

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

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

To reduce the merchant’s risk in the event of a compromise of encrypted cardholder data, it is strongly

recommended to purge credit card numbers from the database after a specified duration.

A purge duration can be specified by proceeding to the Tools�Company

Setup screen. From there, click the “Credit Card Processing” tab and select

the appropriate merchant id. The system will prompt you for your

administrative credentials. Once validated, you will see a list of credit card processing options. Please

note, the purge duration is applicable to ALL merchant ids, not just the one selected. Any records in the



database that are older than the specified duration will be purged. The purge process does not delete

any actual data, it simply masks the cardholder data. The system will check to see if any additional

records should be purged every time it is ran.

Lastly, it is a good idea to delete any credit cards on file that are

no longer in use. To delete a credit card on file, proceed to the

Add Id’s form (P.O.S. �Customers�Add Id’s). Select the card

from the “Customer Acct. Numbers” dropdown in the lower left

and then click the “Delete Id” button.

Removal of Cryptographic material (PA-DSS 2.7.a) Previous versions of RB Control Systems POS never used encryption and therefore there is no

cryptographic data to be securely removed as required by PA-DSS v1.2.

Set up Good Access Controls (3.1.c and 3.2) The PCI DSS requires that access to all systems in the payment processing environment be protected

through use of unique users and complex passwords. Unique user accounts indicate that every account

used is associated with an individual user and/or process with no use of generic group accounts used by

more than one user or process. The following should be followed:

Do not use administrative accounts for application logins (e.g., don’t use the “sa” account for

application access to the database).

Assign strong passwords to these default accounts (even if they won’t be used), and then

disable or do not use the accounts.

Assign strong application and system passwords whenever possible.

Create PCI DSS-compliant complex passwords to access the payment application, per PCI Data

Security Standard 8.5.8 through 8.5.15

Changing the “out of the box” settings for unique user IDs and secure authentication will result

in non-compliance with the PCI DSS

The PCI standard requires the following password complexity for compliance (often referred to as using

“strong passwords”):

Do not use group, shared, or generic user accounts (8.5.8)

Passwords must be changed at least every 90 days (8.5.9)

Passwords must be at least 7 characters (8.5.10)

Passwords must include both numeric and alphabetic characters (8.5.11)

New passwords cannot be the same as the last 4 passwords (8.5.12)



PCI user account requirements beyond uniqueness and password complexity are listed below:

If an incorrect password is provided 6 times the account should be locked out (8.5.13)

Account lock out duration should be at least 30 min. (or until an administrator resets it) (8.5.14)

Sessions idle for more than 15 minutes should require re-entry of username and password to

reactivate the session (8.5.15)

These same account and password criteria must also be applied to any applications or databases

included in payment processing to be PCI compliant. RB Control Systems POS, as tested to in our PA-DSS

audit, meets, or exceeds these requirements.

RB Control Systems POS must require unique usernames and complex passwords for all administrative

access and for all access to cardholder data.

[Note: These password controls are not intended to apply to employees who only have access to one

card number at a time to facilitate a single transaction. These controls are applicable for access by

employees with administrative capabilities, for access to servers with cardholder data, and for access

controlled by the application.]

Control access, via unique username and PCI DSS-compliant complex passwords, to any PCs or

servers with payment applications and to databases storing cardholder data.

RB Control Systems Default Login Credentials

For deployment and testing purposes, the RB

Control Systems program contains an

employee listed as “RB Control Systems.” For

security purposes, it is recommended that this

account’s access code be updated and the

account subsequently made inactive.

The system provides a default,

administrative account, admin. This

account should only be used for the

initial access to the employee setup

screen. The password on the default

administrative account should be

changed and subsequently made inactive.

Properly Train and Monitor Admin Personnel It is your responsibility to institute proper personnel management techniques for allowing admin user

access to cardholder data, site data, etc. You can control whether each individual admin user can view

credit card account information.

In most systems, a security breach is the result of unethical personnel. So pay special attention to whom

you trust with administrative credentials and who you allow to view full decrypted and unmasked

payment information.



To verify that administrative-level access is not being abused, it is important to periodically review the

RB Control Systems POS audit log reports (Reports�Audit Log Reports). This screen will list every form

that is accessed by an employee and all administrative access attempts (such as viewing a full credit card

account number). Any entry in light red indicates an unauthorized access attempt.

The columns found on this screen represent the following information:

Column Name Information

Id Unique id representing the audit entry

Date The date and time of the audit entry

Function The type of audit entry

Section The part of the program the audit entry originated from

Form Name The specific form the audit entry originated from

Employee The employee whose credentials were used

Administrator The administrator who granted access to this function

Register The RB register name that the access took place on

Notes Misc. notes regarding the audit. If this was a credit card

transaction, then this field will contain the response

received by the processor or processing software.

Failure Reason The reason for the failed access attempt

Network User The Windows username logged into the computer from

which the access took place

Most administrative functions, such as viewing a full credit card number, provide additional information

in the “Notes” column. For example, below is an audit entry that was made when a full credit card

number was viewed. It records the record number from the database that this entry was associated

with and the last 4 digits of the card number.

By clicking on, and subsequently hovering over, the “Notes” column, this additional information can be

viewed in its entirety. For example, below is the response from the processor that was recorded for a

credit card transaction.



Key Management Roles & Responsibilities (PA-DSS 2.5) The RB Control Systems POS program utilizes dynamically generated encryption keys for encrypting all

cardholder data. This relieves the administrative users from needing to periodically update the

encryption keys.

Log settings must be compliant (PA-DSS 4.2.b) RB Control Systems POS has PA-DSS compliant logging enabled by default. This logging is not

configurable and may not be disabled. Disabling or subverting the logging function of RB Control

Systems POS in any way will result in non-compliance with PCI DSS.

PCI-Compliant Wireless settings (PA-DSS 6.1.b and 6.2.b) RB Control Systems POS does not support wireless technologies. However, should the merchant

implement wireless access within the cardholder data environment, the following guidelines for secure

wireless settings must be followed per PCI Data Security Standard 1.2.3, 2.1.1 and 4.1.1:

1.2.3: Perimeter firewalls must be installed between any wireless networks and systems that store

cardholder data, and these firewalls must deny or control (if such traffic is necessary for business

purposes) any traffic from the wireless environment into the cardholder data environment.

2.1.1:

All wireless networks implement strong encryption (e.g. AES)

Encryption keys were changed from default at installation, and are changed anytime anyone

with knowledge of the keys leaves the company or changes positions

Default SNMP community strings on wireless devices were changed

Default passwords/passphrases on access points were changed



Firmware on wireless devices is updated to support strong encryption for authentication and

transmission over wireless networks (for example, WPA/WPA2)

Other security-related wireless vendor defaults, if applicable

4.1.1:

Industry best practices are used to implement strong encryption for the following over the

wireless network in the cardholder data environment (4.1.1):

o Transmission of cardholder data

o Transmission of authentication data

Payment applications using wireless technology must facilitate the following regarding use of

WEP:

For new wireless implementations, it is prohibited to implement WEP as of March 31, 2009.

For current wireless implementations, it is prohibited to use WEP after June 30, 2010.

Never store cardholder data on internet-accessible systems (PA-DSS

9.1.b) Never store cardholder data on Internet-accessible systems (e.g., web server and database server must

not be on same server.)

PCI-Compliant Delivery of Updates (PA-DSS 10.1) As a development company, we keep abreast of the relevant security concerns and vulnerabilities in our

area of development and expertise.

We do this by monitoring several security-related websites, primarily:

Microsoft – http://www.microsoft.com/technet/security/bulletin/advance.mspx

SANS Institute – http://www.sans.org

IEEE – http://www.ieee-security.org

OWASP – http://www.owasp.org

Once we identify a relevant vulnerability, we work to develop and test a patch that helps protect RB

Control Systems POS against the specific, new vulnerability. We attempt to publish a patch within <10

days of the identification of the vulnerability. We will then contact vendors and dealers to encourage

them to install the patch. Typically, merchants are expected to respond quickly to and install available

patches within 30 days.

We do not deliver software and/or updates via remote access to customer networks. Instead, software

and updates are delivered via FTP over SSL (FTPS). These packages are subsequently validated before

installation to ensure the update package has not been tampered with before the update proceeds.



PCI-Compliant Remote Access (11.2 and 11.3.b) The PCI standard requires that if employees, administrators, or vendors are granted remote access to

the payment processing environment; access should be authenticated using a two-factor authentication

mechanism (username/ password and an additional authentication item such as a token or certificate).

In the case of vendor remote access accounts, in addition to the standard access controls, vendor

accounts should only be active while access is required to provide service. Access rights should include

only the access rights required for the service rendered, and should be robustly audited.

If users and hosts within the payment application environment may need to use third-party remote

access software such as Remote Desktop (RDP)/Terminal Server, VNC, etc. to access other hosts within

the payment processing environment, special care must be taken.

In order to be compliant, every such session must be encrypted with at least 128-bit encryption (in

addition to satisfying the requirement for two-factor authentication required for users connecting from

outside the payment processing environment). For Remote Desktop/Terminal Server this means using

the high encryption setting on the server. Additionally, the PCI user account and password

requirements will apply to these access methods as well.

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

following precautions:

Change default settings (such as usernames and passwords) on remote access software

Allow connections only from specific IP and/or MAC addresses

Use strong authentication and complex passwords for logins according to PCI DSS 8.1, 8.3,

and 8.5.8-8.5.15

Enable encrypted data transmission according to PCI DSS 4.1

Enable account lockouts after a certain number of failed login attempts according to PCI DSS

8.5.13

Require that remote access take place over a VPN via a firewall as opposed to allowing

connections directly from the internet

Enable logging for auditing purposes

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

Establish customer passwords according to PCI DSS Requirements 8.1, 8.2, 8.4, and 8.5.

All RB Control Systems technicians and customers will utilize the UltraVNC Single Click utility. The

primary benefits of this remote support application are:

• Support for an encrypted connection.

• No installation needed. The remote support application is contained within a single 243KB

executable. It requires no installation, does not utilize the registry, and leaves no configuration

files on the system. When the technician disconnects, the program is terminated.

• It supports outbound connections only. The executable has been designed such that it will not

accept an inbound connection request. Thus, the application can only be used in a remote

support situation where the remote party permits someone to access their computer.



No other mechanism, except the UltraVNC Single Click, should be used to grant an RB Control

Systems’ technician remote access to your systems.

UltraVNC Single Click Connection Establishment

The remote support application can be started by double

clicking the red icon labeled “RB Support” on the user’s

desktop or clicking the red phone underneath the program’s

HELP menu. Once clicked, the user will be presented with

the screen on the left. This screen contains a listing of all

support technicians. By double clicking on a support

technician’s name, you will begin a remote support session

with that technician.

A red phone icon will appear in the system tray during

connection establishment and for as long as the

technician is remotely connected to the computer.

Data Transport Encryption (PA-DSS 12.1.b) The PCI DSS requires the use of strong cryptography and encryption techniques with at least a 128 bit

encryption strength (either at the transport layer with SSL or IPSEC; or at the data layer with algorithms

such as RSA or Triple-DES) to safeguard cardholder data during transmission over public networks (this

includes the Internet and Internet accessible DMZ network segments).

PCI DSS requirement 4.1: Use strong cryptography and security protocols such as secure sockets layer

(SSL) / transport layer security (TLS) and Internet protocol security (IPSEC) to safeguard sensitive

cardholder data during transmission over open, public networks.

Refer to the Dataflow diagram for an understanding of the flow of encrypted data associated

with the RB Control Systems POS application.

PCI-Compliant Use of End User Messaging Technologies (PA-DSS 12.2.b) The RB Control Systems POS does not allow or facilitate the sending of PANs via any end user messaging

technology (for example, e-mail, instant messaging, and chat).

Non-console administration (PA-DSS 13.1)

The RB Control Systems POS allows non-console administration, so you must use SSH, VPN, or SSL/TLS

for encryption of this non-console administrative access.



Network Segmentation The PCI DSS requires that firewall services be used (with NAT or PAT) to segment network segments into

logical security domains based on the environmental needs for internet access. Traditionally, this

corresponds to the creation of at least a DMZ and a trusted network segment where only authorized,

business-justified traffic from the DMZ is allowed to connect to the trusted segment. No direct incoming

internet traffic to the trusted application environment can be allowed. Additionally, outbound internet

access from the trusted segment must be limited to required and justified ports and services.

Refer to the standardized Network diagram for an understanding of the flow of encrypted

data associated with the RB Control Systems POS.

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



Application System Configuration Below are the operating systems and dependent application patch levels and configurations supported

and tested for continued PCI DSS compliance.

There are separate system requirements for single and multi-location stores and host and client

computers. The host computer is the computer designated for hosting the RB Control Systems database

files.

Host Computer

• Windows XP Professional (SP2 or higher), Windows Server 2003 or Windows Server 2008. All

latest updates and hot fixes should be tested and applied

• 512 MB of RAM minimum, 1GB or more recommended

• 100 Mbps or 1 Gbps TCP/IP network connection

• 10 GB of available hard disk space

• Microsoft Access 2002 or higher

• *Terminal Services requires Microsoft Office Volume License Key

Client Computer

• Windows XP Home (SP2 or higher), Windows XP Professional (SP2 or higher), or Windows 7. All

latest updates and hot fixes should be tested and applied

• 512 MB of RAM minimum

• 100 Mbps TCP/IP network connection

• 10 GB of available hard disk space

• Microsoft Office 2002 or higher

Payment Application Initial Setup & Configuration All initial configuration of the RB Control Software and optionally installed credit card processing

software will be performed by a certified RB Control Systems support technician.