pabp implementation guide - dcrs solutions · the payment application best practices (pabp). the...

UnifyPOS v10 PA-DSS Implementation Guide

The Payment Card Industry’s (PCI) Payment Application Data Security Standards (PA-DSS) require Osprey Retail Systems (ORS) to produce a document for customers, with instructions, notes and pointers on how to properly implement UnifyPOS in a secure manner.

DCRS has posted this UnifyPOS v10 PA-DSS Implementation Guide

on the DCRS website (in Services and PCI sections) (or contact DCRS for a copy).

Although ORS and DCRS Solutions are not required to educate our customers on cardholder security requirements, as responsible vendors, we absolutely want to make our customers aware that the cardholder industry has published security related standards that all Merchants are required to follow, per agreements with their Credit Processors. If compromised and found to be non-compliant, Merchants can incur significant fines/penalties, etc. In addition to reviewing the UnifyPOS v10 PA-DSS Implementation Guide, our customers should also visit the Payment Card Industry Security Standards Council (PCI-SSC) web site, and become familiar with these standards and requirements, available at:

PCI-SSC: https://www.pcisecuritystandards.org/index.shtml

Please let us know if you have any questions or need any assistance.

https://www.pcisecuritystandards.org/index.shtml

PA-DSS v1.2 Implementation Guide Version: 2.0

Confidential Osprey Retail Systems, Inc. Page 1 of 25

UnifyPOS PA-DSS Implementation Guide

Revision: 2.0 October, 2010

Copyright 1990-2011 Osprey Retail Systems, Inc. The information contained herein is provided “As Is” without warranty of any kind, express or implied, including but not limited to, the implied warranties of merchantability and fitness for a particular purpose. There is no warranty that the information or the use thereof does not infringe a patent, trademark, copyright, or trade secret. Osprey Retail Systems, Inc. shall not be liable for any direct, special, incidental, or consequential damages resulting from the use of any information contained herein, whether resulting from breach of contract, breach of warranty, negligence, or otherwise, even if Osprey Retail Systems, Inc. has been advised of the possibility of such damages. Osprey Retail Systems, Inc. reserves the right to make changes to the information contained herein at anytime without notice. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Osprey Retail Systems, Inc.



PA-DSS Implementation Guide

Owner: Roger Blanchard

Audience: UnifyPOS Resellers and UnifyPOS Merchants

Version / Status: 2.0

Location: New Bedford, MA

Updated: 02/22/2008 Last Printed: 02/22/2008

05/19/2008 Added additional content under section 2.3 as

requested by VISA through CSO

9/30/2008 Added additional instructions under section 5.1 in

regards to a secure wipe procedure. Some

resellers/end users did not follow the instructions

when migrating to 10.193 and additional

procedures had to be written to securely wipe

sensitive cardholder data from older version once

the customer was using 10.193.

10/12/2010 Updated for PA-DSS version 1.2

11/29/2010 Added content under section 2.1 that outlines

having to disable WindowsXP restore points since

it is a potential risk.

3/22/2011 Updated content under section 2.3 that outlines

PCI standard 8.5.15. The UnifyPOS installation

routine now enables the Screen Saver and On

Resume Password.



Table of Contents Payment Systems Security (1) ......................................................................................................... 4

Introduction (1.1) ......................................................................................................................... 4

Visa CISP Overview (1.2) .............................................................................................................. 4

The PCI Industry Standard (1.3) ................................................................................................... 4

Payment Application Data Security Standards (1.4) .................................................................... 5

Understanding “PA-DSS” versus “PCI Compliance” (1.5) ............................................................. 5

Independent PA-DSS Auditing Firm (1.6) ..................................................................................... 6

UnifyPOS Security Validation (PA-DSS) (2) ..................................................................................... 7

Do Not Store Magnetic Stripe, CVV/CVC2 or Pin Block (PVV) Data (2.1) ..................................... 7

Protect Stored Cardholder Data (2.2) ........................................................................................... 9

Provide Secure Password Features (2.3) .................................................................................... 10

Log Application Activity (2.4) ...................................................................................................... 12

Develop Secure Applications (2.5) .............................................................................................. 13

Protect Wireless Transmissions (2.6) ......................................................................................... 16

Test Applications To Address Vulnerabilities (2.7) ..................................................................... 17

Facilitate Secure Network Implementation (2.8) ....................................................................... 17

Never Store Cardholder Data on a Public-Facing Internet Connection (2.9) ............................. 18

Facilitate Secure Remote Software Updates (2.10) ................................................................... 18

Facilitate Secure Remote Application Access (2.11) .................................................................. 19

Encrypt Sensitive Traffic Over Public Networks (2.12) ............................................................... 20

Encrypt All Non-Console Administrative Access (2.13) .............................................................. 20

Maintain Instructional Documentation and Training Programs for Customers, Resellers and

Integrators (2.14) ........................................................................................................................ 21

Operating System Information (3) ................................................................................................ 22

PCI/PA-DSS Compliance Statement (3.1) ................................................................................... 22

Information Security Policy (4) ...................................................................................................... 23

Addressing Legacy Issues (5) ......................................................................................................... 24

Procedure For Removing Sensitive Historical Data (5.1) ............................................................ 24

References, Acknowledgements (6) .............................................................................................. 25

References (6.1) .......................................................................................................................... 25

Acknowledgements (6.2) ............................................................................................................ 25



1. Payment Systems Security

1.1. Introduction

Systems which process payment transactions necessarily handle sensitive cardholder

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

In April 2000, Visa began a proactive approach to payment security by announcing the

Cardholder Information Security Program (CISP) as a standard for securing Visa

cardholder data. Effective since June 2001, CISP compliance has been required for all

entities that store, process or transmit Visa cardholder data. Starting September 30, 2008

this program advances to the Payment Application Data Security Standard (PA-DSS).

This document is designed to provide Osprey Retail Systems, Inc. resellers and customers

with instructions, notes and pointers on how to implement UnifyPOS (v10.193.xxxxx and

higher) into a CISP/PCI compliant system.

1.2 Visa CISP Overview

When customers offer their bankcard at the point of sale, over the Internet, on the phone,

or through the mail, they want assurance that their account information is safe. That is

why USA Visa has instituted the Cardholder Information Security Program (CISP).

Mandated since June 2001, the program is intended to protect Visa cardholder data—

wherever it resides—ensuring that members, merchants and service providers maintain

the highest information security standard.

1.3 The PCI Industry Standard

To achieve compliance with CISP, merchants and service providers must adhere to the

Payment Card Industry (PCI) Data Security Standard, which offers a single approach to

safeguarding sensitive data for all card brands. This Standard is a result of collaboration

between Visa and MasterCard and is designed to create common industry security

requirements, incorporating the CISP requirements. Other card companies operating in

the U.S. have also endorsed the PCI Data Security Standard within their respective

programs.



1.4 Payment Application Data Security Standards (PA-DSS)

PA-DSS is the Council-managed program (Payment Card Industry Security Standards

Council or PCI SSC) formerly under the supervision of the Visa Inc. program known as

the Payment Application Best Practices (PABP). The goal of PA-DSS is to help software

vendors and others develop secure payment applications that do not store prohibited data,

such as full magnetic stripe, CVV2 or PIN data, and ensure their payment applications

support compliance with the PCI DSS. Payment applications that are sold, distributed or

licensed to third parties are subject to the PA-DSS requirements. In-house payment

applications developed by merchants or service providers that are not sold to a third party

are not subject to the PA-DSS requirements, but must still be secured in accordance with

the PCI DSS.

1.5 Understanding “PA-DSS” vs. “PCI Compliance”

As a software vendor, our responsibility is to be ―PA-DSS Compliant‖.

We have performed an audit and certification compliance review with an independent

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

Handling, managing and storing payment related information.

Note: We want to reiterate that obtaining ―PCI Compliance‖ falls on you (the merchant)

and your UnifyPOS reseller, working together, using PCI compliant server architecture

with proper hardware & software configurations and access control procedures.

We have tested and certified to the PCI SSC ―Payment Application Data Security

Standards‖ (PA-DSS), to ensure that when you load UnifyPOS into an environment

equivalent to our recommended PCI ready environment, that our application is also

following best practices, helping you achieve PCI Compliance easily with respect to how

UnifyPOS handles user accounts, passwords, encryption, and other payment data related

information.

After installation and initial certification to PCI standards, you should then follow our

recommended operational guidelines, defined later in this document, to ensure continued

best practices for management of your storefront.

Visa U.S.A. specifies different levels of compliance requirements, driven mostly by the

annual transaction volume of your storefront. You should read the documentation

provided by Visa to determine the level of PCI Compliance required for your business.

Depending on annual transaction volume, CISP requirements range from completing a

self-assessment questionnaire to engaging an independent security assessor for

conducting annual on-site security audits. See www.visa.com/cisp and contact your bank,

processor, or acquirer for more information.



Notes on fines: As quoted from Visa's website ―If a merchant or service provider does

not comply with the security requirements or fails to rectify a security issue, Visa may:

Fine the acquiring member

Impose restrictions on the merchant or its agent

Permanently prohibit the merchant or its agent from participating in Visa

programs

Members receive protection from fines for merchants or service providers that have been

compromised but found to be CISP-compliant at the time of the security breach.

Members are subject to fines up to $500,000 per incident for any merchant or service

provider that is compromised and not CISP-compliant at the time of the incident.‖

Note: The CISP requirements for your systems do not change, and must be validated, no

matter if you use an in-house product like UnifyPOS, or a Visa approved online service

provider such as VeriSign®.

For example, the requirement for unique usernames and strong passwords does not

change and is even a missing feature on some of the CISP listed Internet gateways.

Before being validated, you must ask your staff if the entire system is conforming to the

requirements or just the service provider themselves.

1.6 Independent PA-DSS Auditing Firm

Osprey Retail Systems, Inc. worked with the following Visa USA approved certification

firm on our PA-DSS Certification:

Chief Security Officers, LLC

9821 N 95th Street

Suite 105

Scottsdale, AZ 85258

Office: 888.237.3899

Fax: 480.275.4818



2. UnifyPOS Security Validation (PA-DSS)

The following sections outline the validation used against UnifyPOS. It also outlines

configuration with secure implementation as defined by the PCI SSC Payment

Application Data Security Standard Requirements.

Note: This document references the PCI SSC PA-DSS document v1.2.1 released July

2009.

2.1. Do NOT retain full magnetic stripe, card validation code or value

(CAV2, CID, CVC2, CVV2) or Pin Block Data

One of the main goals of CISP/PCI/PA-DSS is to prevent the risks associated when full

magnetic stripe data or card validation values are stored after authorization by payment

applications. UnifyPOS does not store full magnetic stripe, card validation values or Pin

Block data post-authorization anywhere within the application.

PA-DSS references (1.1, 1.1.1, 1.1.2, 1.1.3)

Validated Architecture:

Incoming transaction data: Once UnifyPOS receives sensitive authentication data

(typically from a MSR and/or Pin Pad), it is forwarded to a payment processing

application (PcCharge, WinEPS, Datacap Control) and subsequently erased.

Transaction logs: UnifyPOS does not store sensitive authentication data in

transaction logs.

History files: UnifyPOS does not store sensitive authentication data in history

files.

Debug logs: UnifyPOS does not output sensitive authentication data in debug

logs.

Audit logs: UnifyPOS does not store sensitive authentication data in audit logs.

Database schemas and tables: UnifyPOS does not store sensitive authentication

data inside the database.

PA-DSS references (1.1.4)


Depending on their configuration, prior versions of the UnifyPOS application

(4.189 and earlier) may have stored sensitive cardholder data on the PC. This data

MUST be wiped clean from the database it was stored in for the merchant to be

PCI compliant when upgrading to a PCI-compliant version of the software

(UnifyPOS 10.193 and above). If prior data is not securely removed from the

system during a PCI-compliant upgrade, the system will not be considered

compliant. Please see section 5 for instructions on how to remove the sensitive

cardholder data.



PA-DSS references (1.1.5)


UnifyPOS does NOT store any sensitive authentication data in the database or log

files. The following guidelines MUST be followed in regards to using any

sensitive authentication data:

o UnifyPOS resellers should only collect sensitive authentication data only

when needed to solve a specific problem.

o UnifyPOS resellers MUST store such data only in specific, known

locations with limited access.

o UnifyPOS resellers MUST collect only the limited amount of data needed

to solve a specific problem.

o UnifyPOS resellers MUST encrypt sensitive authentication data while

stored.

o UnifyPOS resellers MUST securely delete such data immediately after

use.

NOTE REGARDING “DROP FILE” INTEGRATIONS: The use of ―drop files‖

communications with 3rd

Party Payment Applications (PcCharge Payment Server) should

be considered the least secure method. While ―drop files‖ provides an easy way for quick

administration, legacy application integration and system testing, this technique has a

much higher security implications.

The first risk identified is the ability of an attacker to gain root control over a machine

and scan the shared directory for incoming and outgoing files. This risk must be

mitigated via operating system and file system security measures.

The second risk identified is when a physical disk is examined outside of the operating

system. Examples would be removing a hard drive and performing a forensic analysis, or

booting the computer with a CDROM that contains a base OS and forensic tools. In

theory an attacker or even a technical eBay shopper could peruse old files that were

intentionally deleted on the physical disk.

Since payment applications can communicate sensitive data such as full magnetic stripe

data, card numbers and CVV2 values, it becomes imperative to look at if, how and why

any ―disk based‖ communications happen. If disk based files are written and contain

sensitive data then we highly recommend you look at alternate security measures that

help improve the security posture of your disk based communication systems.

Some of the more modern alternatives would be to deploy an additional layer of security

around your /Trans directory such as an encrypted file system or implementing a

temporary/memory-resident file system.



For the reasons above the use of this method has been dropped from UnifyPOS. Instead

an IP based method has been added which is much more robust and secure, and all new

integrations will use the IP method (dependent on protocol/toolkits used) or COM.

NOTE REGARDING “Windows XP Restore Points”:

Visa has identified a potential insecurity issue with the Restore Point option in Windows

XP. According to Visa, while there is no specific vulnerability in the restore point itself,

there is a high probability that the c:/pagefile.sys (or root directory) page file on the

windows system could contain cardholder information, including full track data.

As such, it is recommended that the restore point option on Windows XP be disabled by

following the instructions outlined by this KB article;

http://support.microsoft.com/kb/310405‖

2.2. Protect Stored Cardholder Data

PA-DSS reference (2.1)


Customers must purge cardholder data after defined retention period:

UnifyPOS does NOT store cardholder data.



Mask displayed account numbers: UnifyPOS immediately masks the PAN

(primary account number) as well as expiration date upon a subsequent

authorization and stores this masked information in the electronic journal as well

as a history database (only the last four digits of the PAN are NOT masked).

It is the policy of Osprey Retail Systems, Inc. that no credit card information will

be stored in the UnifyPOS database as well as any log files. If a merchant needs

the full PAN and expiration date this can be obtained from any of the payment

applications currently supported by UnifyPOS (PcCharge Payment Server,

WinEPS or Mercury Payment Systems via a Datacap Control).



Encrypt stored sensitive data: UnifyPOS does not use encryption to store

sensitive data as NO sensitive data is stored in the UnifyPOS database(s) as well

as any log file.

In UnifyPOS there is NO need to store any credit card information at ALL as each

of the payment processing applications currently supported return a unique

―transaction id‖ which UnifyPOS stores in the electronic journal. This

http://support.microsoft.com/kb/310405



―transaction id‖ can be later used to perform a VOID (Cancel UnifyPOS

transaction).



Disk Encryption meets PCI DSS 3.4.1: UnifyPOS does not store cardholder

data and therefore does not use disk encryption.



Protect encryption keys: UnifyPOS does not store cardholder data and therefore

does not use any cryptographic methods.



Implement key management processes and procedures: UnifyPOS does not

store cardholder data and therefore does not use any cryptographic methods.



Securely delete any cryptographic key material: UnifyPOS does not store

cardholder data and therefore does not use any cryptographic methods.

2.3. Provide Secure Authentication Features



Require unique/strong usernames and passwords for administrative access:

UnifyPOS provides multi-level username and password facilities for both

administrative and general application access.

Allow complex passwords: UnifyPOS provides for a complex password.

UnifyPOS can mandate/regulate the use of strong passwords as defined in the PCI

standard 8.5.8 – 8.5.11, 8.5.13, 8.5.14. This feature can be setup under the System

Parameters Screen 3. Please review the latest UnifyPOS manual for detailed

instructions.

UnifyPOS resellers/end users are responsible for removing default administrative

accounts that ship with the UnifyPOS application.



UnifyPOS end users are required to revoke system access for any terminated

employee according to PCI standard 8.5.4.

UnifyPOS end users are required to remove inactive user accounts at least every

ninety days according to PCI standard 8.5.5.

UnifyPOS end users are required to only enable accounts used by

vendors/resellers for remote maintenance only during the time period needed

according to PCI standard 8.5.6.

UnifyPOS end users are required to communicate password procedures and

policies to all users who have access to cardholder data according to PCI standard

8.5.7.

UnifyPOS end users are required to NOT use group, shared, or generic accounts

and passwords according to PCI standard 8.5.8.

UnifyPOS end users are required to setup UnifyPOS to force system users to

change their password at least every 90 days according to PCI standard 8.5.9.

UnifyPOS end users are required to setup UnifyPOS to use a minimum password

length of at least seven characters according to PCI standard 8.5.10.

UnifyPOS end users are required to setup UnifyPOS to use numeric and

alphanumeric characters in their password according to PCI standard 8.5.11.

UnifyPOS end users are required that a new password cannot be the same as the

previous four passwords according to PCI standard 8.5.12.

PCI standard 8.5.15 requires that if a session has been idle for more than 15

minutes, require the user to re-enter the password to re-activate the terminal. This

requirement can be enabled by utilizing the Windows Screen Saver and setting the

Wait time to 15 minutes and enabling the ―On resume, password protect‖ option.

During the UnifyPOS installation routine this is set automatically as this standard

MUST be enforced. If the end user disables this feature they will not be

considered PCI compliant.



UnifyPOS requires a unique user name but it is the responsibility of a UnifyPOS

reseller/end user to enable the use of complex password for access to PC's,

Servers, and databases where payment applications reside.

The OpenEdge database that ships with UnifyPOS has a default SQL DBA

account. It is the responsibility of the UnifyPOS reseller/end user to add a new

SQL DBA account and delete the default account. For instructions on how to add

a new SQL DBA account please refer to the UnifyPOS ―How To‖ guide.



Encrypt application passwords: UnifyPOS stores encrypted application

passwords.



The encryption function performs a one-way encoding operation that you cannot

reverse. It is useful for storing scrambled copies of passwords in a database. It is

impossible to determine the original password by examining the database.

2.4. Log Application Activity



Log access by individual users: UnifyPOS utilizes the windows event logging

for logging individual user access to the Back Office module as well as POS

module. Any event published to the windows event viewer will automatically

contain the following information in addition to application specific data:

o Date of event

o Time of event

o Source of event (UnifyPOS)

o Type of event (audit failure, audit success, information, warning or error)

o Category (not used)

o EventId (not used)

o Computer where event occurred

UnifyPOS publishes the following events to the windows event viewer to log

individual user access:

o User Logon – when a user successfully logons to the back office module

this event is published and the following information is logged: unique

employee number, employee user name, employee first name, employee

last name and system security level number the user is assigned to.

o User Logoff - when a user logoffs from the back office module this event

is published and the following information is logged: unique employee

number, employee user name, employee first name and employee last

name.

o User Authentication Failed – when a user attempts to logon to the back

office module but the user credentials are incorrect this event is published

and the following information is logged: user name used to try and logon.

o User Account Locked - when a user attempts to logon to the back office

module and an incorrect password is entered three times the user account

is locked and this event is published with the following information:

unique employee number and user name

o Cashier Logon - when a cashier successfully logons to the POS module

this event is published and the following information is logged: unique

employee number, employee first name, employee last name and the POS

security level the cashier is assigned to.

o Cashier Logoff - when a cashier logoffs from the POS module this event is

published and the following information is logged: unique employee

number, employee first name and employee last name.



o Cashier Authentication Failed – when a cashier attempts to logon to the

POS module this event is published.



Implement an automated audit trail: In addition to the user access logging

mentioned above the following additional events are published:

o Employee Record Changed – when an employee record is changed the

event is published and the following information is logged: type of record

change (CREATE, DELETE or UPDATE), unique employee number

from the record that was changed and data elements from the user who

made the change (unique employee number, user name, first name and last

name).

o System Security Level Record Changed - when a system security level

record is changed the event is published and the following information is

logged: type of record change (CREATE, DELETE or UPDATE), unique

level number from the record that was changed and data elements from the

user who made the change (unique employee number, user name, first

name and last name).

o POS Security Level Changed - when a POS security level record is

changed the event is published and the following information is logged:

type of record change (CREATE, DELETE or UPDATE), unique level

number from the record that was changed and data elements from the user

who made the change (unique employee number, user name, first name

and last name).

The disabling of the windows event viewer logging should not be done and will

result in non-compliance with PCI DSS.

UnifyPOS does not allow the disabling of the above mentioned PCI events.

2.5. Develop Secure Applications


Osprey Retail Systems, Inc. develops software applications in accordance with PCI DSS

and based on industry Best Practices and includes information security throughout the

software development life cycle. Sample SDLC documents have been provided to CSO

for review.

PA-DSS reference (5.1.1)




All changes/patches are tested via QA: Osprey Retail Systems, Inc. tests all

application changes internally via set QA procedures prior to releasing any code

into a beta or production release. The results from the QA testing are documented

thoroughly.


Osprey Retail Systems, Inc. development and test environments are separate from the

production environment and are in two physically different locations.



Live PAN’s are not used for testing and development, or are sanitized before

use: Osprey Retail Systems, Inc. never uses live PAN’s for development or

testing as test cards are provided by our payment application partners.

When a reseller is installing a system it is understandable that from time to time

an installer may run a live PAN’s (typically their own card) to make sure the

payment application is properly running. In this case the transaction should

immediately be cancelled as to VOID the credit card authorization.



Removal of test data and accounts before production systems become active:

The UnifyPOS production database is cleared of any test data and/or accounts

before becoming active.



Non essential application accounts, usernames and passwords are removed

prior to release: The UnifyPOS reseller and/or the merchant should delete any

unused user accounts before going live.



Custom code review: As per documented coding policy and procedures, all

software developed by Osprey Retail Systems, Inc. complies with industry best

practices and standards.

UnifyPOS resellers that develop their own ―add-on‖ applications as well as

merchants are responsible for developing external applications that adhere to the

standards as outlined in PA-DSS ref 5.1.




Develop all web payment applications (Internet-based) based on secure coding

guidelines.

Note: Osprey Retail Systems, Inc. does not develop web based payment applications.

However, in the few cases UnifyPOS does integrate with 3rd

party applications via the

internet, security features are implemented such as direct SSL socket communications

and connection level certificates.



Software change control procedures: As per documented coding policy the

proper software change control procedures are followed by Osprey Retail

Systems, Inc. Included in these procedures (but not limited to) are:

o Customer impact analysis (PCI standard 6.4.1)

o Management sign-off (PCI standard 6.4.2)

o Thorough testing of operational functionality (PCI standard 6.4.3)

o Back-out procedures (PCI standard 6.4.4)



Removal of unnecessary and insecure services, applications and protocols:

UnifyPOS is designed as a client/server application and relies on the OpenEdge

Runtimes to be installed on each PC running the UnifyPOS application. The only

network protocol that is required to run UnifyPOS is TCP/IP.

If using the UnifyPOS wireless module Microsoft Internet Information Server

(IIS) MUST be installed and configured properly on the UnifyPOS server as the

wireless infrastructure uses IIS. The UnifyPOS server should be inside the

merchants firewall and should NOT be used to host a web server.

All unnecessary and insecure services and protocols (e.g., NetBIOS, file-sharing,

Telnet, FTP server, HTTP server, etc.) should be disabled on the PC running the

UnifyPOS System. The UnifyPOS PC should never be used to host a public FTP

or HTTP (Web) server.

Protocols and Ports can be disabled from the Windows Firewall and the Hardware

Firewall. Services can be disabled from Control Panel => Administrative Tools

=> Services.



2.6. Protect Wireless Transmissions

PA-DSS reference (6.1, 6.2)


Use Encryption for wireless applications: The PCI standard requires the

encryption of cardholder data transmitted over wireless connections as well as for

the secure implementation of a wireless network. The following items identify the

PCI standard requirements for wireless connectivity to the payment environment:

o Per PCI DSS Requirement 1.2.3 you must install perimeter firewalls

between any wireless networks and the cardholder data environment, and

configure these firewalls to deny or control (if such traffic is necessary for

business purposes) any traffic from the wireless environment into the

cardholder data environment.

o Firewall/port filtering services should be placed between wireless access

points and the payment application environment with rules restricting

access (PCI requirement 1.3.8).

o A personal firewall should be installed on all systems with direct

connectivity to the Internet (PCI requirement 1.3.9).

o Use of appropriate encryption mechanisms such as VPN, SSL/TPS at 128

bit, WPA and/or WPA2 (PCI requirement 4.1).

o WEP is now prohibited from being used for new wireless installations as

well existing wireless installations.

o If the wireless network is WPA-capable then WPA or WPA2 technology

should be enabled (PCI requirement 2.1.1)

o Vendor supplied defaults (administrator username/password, SSID, and

SNMP community values) should be changed (PCI requirement 2.1.1)

o Access point should restrict access to known authorized devices using

MAC Address filtering (PCI requirement 4.1.1).

o SSID broadcast must be disabled.



2.7. Test applications to address vulnerabilities



Test for application vulnerabilities: In addition to on-going internal testing,

Osprey Retail Systems, Inc. monitors outside security sources and product

specific email lists to check for product vulnerabilities. If a vulnerability is found

in the UnifyPOS system, it will be entered into the issue tracking system at which

point it will be reviewed, assigned, worked and deployed per the Osprey Retail

Systems, Inc. SDLC process.

o Osprey Retail Systems, Inc. subscribes to the Progress Software

Corporation email alert list and reviews all alerts for all technology used

by the UnifyPOS application such as:

OpenEdge Database

OpenEdge AppServer

SonicMQ

SonicESB

o Osprey Retail Systems, Inc. subscribes to the SANS NewsBites and

reviews the semiweekly article as it relates to computer security.

o Osprey Retail Systems, Inc. subscribes to the Microsoft Technical

Security Notifications as it relates to Windows OS security issues.

2.8. Facilitate secure network implementation



Facilitate secure network implementations: UnifyPOS can run on a network

with: o NAT (network address translation)

o PAT (port address translation)

o Traffic-filtering devices

o Anti-Virus Software

o Encryption

o OS path installation

For optimum system performance the following folders should be omitted from

the anti-virus scan:

o Progress

o OpenEdge\Wrk

o Program Files\ORS\UnifyPOS



2.9. Never Store Cardholder Data on a Public-Facing Internet

Connection



Provide payment applications and data separation facilities: UnifyPOS

provides the ability to be fully separated from both the application and the

database. For example, UnifyPOS does not require the client (requesting POS)

application or the database (required for storage and parameters) to be located on

the same system as the payment server.

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. (PCI

section 1 covers firewall requirements).

UnifyPOS does not store any cardholder data in the UnifyPOS database but

MUST be installed inside the firewall.

The supported payment applications supported by UnifyPOS (PcCharge Payment

Server or WinEPS) MUST also be installed inside the firewall and should not be

installed on a machine running any public facing web server.

2.10. Facilitate Secure Remote Software Updates



Provide Secure software updates: UnifyPOS supports a software update via an

Installshield executable file. This software update is located on the Osprey Retail

Systems, Inc. website and is available to all resellers. Osprey Retail Systems, Inc.

recommends that the reseller load this software update on their FTP site and allow

the merchant to ―download‖ the software update.

In the event that a reseller must deliver this software update via remote access the

merchant should only turn on their modem when told to do so by the reseller and

immediately turn it off after the reseller is done installing the software update

(PCI requirement 12.3.9). If the merchant is using a VPN or some other type of

high-speed connection a firewall MUST be installed and configured properly (PCI

requirement 1.3.9).



2.11. Facilitate Secure Remote Application Access

PA-DSS reference (11.1, 11.2, 11.3)


Facilitate Secure remote access to payment application: o UnifyPOS can run with the use of a two-factor authentication mechanism.

Two-factor authentication is defined as something you have (e.g.

smartcard or token) and something you know (e.g. PIN or

biometric). These two factors must be presented in conjunction

with one another to authenticate to a network or system.

o Osprey Retail Systems, Inc. makes it a policy to NEVER connect into a

remote system for any reason (installation, configuration, upgrades, etc.).

It is the UnifyPOS reseller’s responsibility to support the merchant.

o In the event a reseller needs access to a merchant’s UnifyPOS application

Osprey Retail Systems, Inc. recommends using remote management

software such as GotoMeeting or WebEx as this requires the merchant to

initiate the connection to a proxy server.

o For those resellers who use pcAnywhere for remote access it must be

setup properly in order to meet the requirement for PCI DSS compliance

(PCI standard 8.3, 8.4, 8.5). The following procedures must be followed

when using pcAnywhere:

The default settings created by pcAnywhere during installation are

not secure. All default settings generated by pcAnywhere must be

changed before the system goes live (for example, change default

passwords and create unique passwords for each user).

Access to logon information and passwords must be limited to

authorized personnel. This includes both store personnel (Owner,

Area Managers) and UnifyPOS reseller support personnel.

Allow connections only from specific (known) IP/MAC addresses.

Use strong authentication and complex passwords for logins,

according to PCI DSS Requirements (PCI standard 8.1, 8.2, 8.4,

8.5).

In addition, the following pcAnywhere configuration is required

when allowing Remote Desktop access to the host system:

pcAnywhere should not be configured to launch

automatically when Windows starts. Instead, the

pcAnywhere shortcut should be used to manually launch a

host when a connection is needed.

The pcAnywhere host connection object should be set to

cancel the Host after any session ends. If a re-connection is

needed, the host will need to be launched manually again

by someone on-site.

There should be a dedicated pcAnywhere Caller for each

person who has access to the host remotely.



Strong passwords and unique logins must always be used

for remote access.

The host should be configured to use the Symmetric

encryption level and the option to Deny Lower Encryption

Level should be checked.

Under Log In Options, the option to limit the number of

login attempts per call should be checked and the limit

should be set at 3.

pcAnywhere logging should be enabled by going to Edit =>

Preferences => Event Logging and checking the box for

Enable Event Logging and Record in Local NT Event Log.

Under the Select Events button, choose Select All to record

all types of events.

2.12. Encrypt Sensitive Traffic Over Public Networks



Provide Strong encryption for data transmission over public networks:

UnifyPOS does NOT send sensitive data over a public network as this is provided

by a payment processing application (PcCharge Payment Server, WinEPS or

Mercury Payment Systems via a Datacap Control) that use strong encryption via

SSL when transmitting sensitive data over the Internet.

Never communicate sensitive data via unencrypted e-mail: UnifyPOS does not

communicate any sensitive data via e-mail, IM or chat. A UnifyPOS reseller

should NEVER send sensitive data using any of these methods as well.

2.13. Encrypt All Non-console Administrative Access


Users and hosts within the payment application environment may need to use 3rd

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.



2.14. Maintain Instructional Documentation and training programs

for customers, resellers and integrators.


Osprey Retail Systems, Inc. reviews the documented UnifyPOS PA-DSS

Implementation Guide on a yearly basis and makes the appropriate changes

according to the latest PA-DSS requirements.

The UnifyPOS PA-DSS Implementation Guide is freely available to all resellers

on the ORS website at www.ospreyretailsystems.com

The UnifyPOS PA-DSS Implementation Guide is included in the latest UnifyPOS

manual.

The standard UnifyPOS reseller training program has been updated to cover how

to implement UnifyPOS in a PA-DSS compliant manner.

http://www.ospreyretailsystems.com/



3. Operating System Information

3.1. PCI/PA-DSS Compliance Statement

The current version of UnifyPOS is developed and deployed to support the Microsoft

Windows operating system.

As per current PCI requirements, a validated application must execute from a System that

is supported by the manufacturer, to include up-to-date security related patches and

enhancements (PCI standard 6.1).

If you are unsure of which operating systems are valid, please reference the current

Operating System Manufacturers support page.

Example for Microsoft: http://www.microsoft.com/windows/lifecycle/default.mspx

Examples of unsupported Operating Systems':

Windows 98

Windows 98-SE

Windows ME

Windows XP SP1

As per vendor notices: http://www.microsoft.com/windows/support/endofsupport.mspx

http://www.microsoft.com/windows/lifecycle/default.mspx

http://www.microsoft.com/windows/support/endofsupport.mspx



4. 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. The PCI SSC 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.



5. Addressing Legacy Issues Depending on their configuration, prior versions of the UnifyPOS application (4.189 and

earlier) may have stored sensitive cardholder data on the PC. This data MUST be wiped

clean from the database it was stored in for the merchant to be PCI compliant when

upgrading to a PCI-compliant version of the software (UnifyPOS 10.193 and above). If

prior data is not securely removed from the system during a PCI-compliant upgrade, the

system will not be considered compliant.

5.1. Procedure for Removing Sensitive Historical Data

In order to meet the requirements for PCI compliance all sensitive cardholder data must

be securely removed from the system. The following steps outline the procedure for

removing all sensitive cardholder data from the UnifyPOS database(s):

Use PciWipeSrvr.r user procedure provided by Osprey Retail Systems, Inc. to

delete any historical sensitive cardholder data in the server’s pos database as well

as histlog database.

From User Procedures run PciWipeSrvr.r which will scan the appropriate tables in

the UnifyPOS server’s database(s) and securely wipe the sensitive cardholder

data.

This procedure can also be initiated from the command line using the following

syntax: prowin32 –pf start.pf –p pscommand –param PciWipeSrvr

This procedure can take quite a while to run depending on how many months of

transaction history are being stored in the histlog database.

Once this procedure is complete this database can then be copied to all the

registers as to replace their local copy of the database in case this sensitive

cardholder data had been copied to each local register.

If the server’s database is either too large to copy or the reseller/end user does not

wish to shutdown their server’s database(s) a local copy of the secure wipe

procedure has been written called PciWipeLoc.r. Please Note: This procedure

should NOT be run on the server or on a back office terminal that does NOT

run POS. From User Procedures run PciWipeLoc.r which will scan the appropriate tables in

the UnifyPOS local database(s) and securely wipe the sensitive cardholder data.

This procedure can also be initiated from the command line using the following

syntax: prowin32 –pf start.pf –p pscommand –param PciWipeLoc

Although the histlog database is only used on the server and is not even needed on

each local register some resellers in the past have copied this database from the

server to each local register. In order to make sure that no sensitive cardholder

data is stored on each local register this database MUST be deleted as it is not

used.



6. References, Acknowledgements

6.1. References

This document references the following publications.

PCI DSS version 1.2 released October 2008

PCI PA-DSS version 1.2.1 released July 2009

UnifyPOS Installation and Configuration Guides

6.2. Acknowledgements

Osprey Retail Systems, Inc. software products actively use, support and promote the

Progress Software OpenEdge development environment located at www.progress.com

UnifyPOS, UnifyHOST and UnifyMESSENGER are registered trademarks of Osprey

Retail Systems, Inc. All Rights Reserved.

Windows is a registered trademark of Microsoft Corporation. All rights reserved.

All other trademarks and copyrights are property of their respective owners. All rights

reserved.

http://www.progress.com/

pabp implementation guide - dcrs solutions · the payment application best practices (pabp). the...

Documents