Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
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.
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 v1.2 Implementation Guide Version: 2.0
Confidential Osprey Retail Systems, Inc. Page 2 of 25
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.
PA-DSS v1.2 Implementation Guide Version: 2.0
Confidential Osprey Retail Systems, Inc. Page 3 of 25
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
PA-DSS v1.2 Implementation Guide Version: 2.0
Confidential Osprey Retail Systems, Inc. Page 4 of 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.
PA-DSS v1.2 Implementation Guide Version: 2.0
Confidential Osprey Retail Systems, Inc. Page 5 of 25
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.
PA-DSS v1.2 Implementation Guide Version: 2.0
Confidential Osprey Retail Systems, Inc. Page 6 of 25
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
PA-DSS v1.2 Implementation Guide Version: 2.0
Confidential Osprey Retail Systems, Inc. Page 7 of 25
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)
Validated Architecture:
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 v1.2 Implementation Guide Version: 2.0
Confidential Osprey Retail Systems, Inc. Page 8 of 25
PA-DSS references (1.1.5)
Validated Architecture:
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.
PA-DSS v1.2 Implementation Guide Version: 2.0
Confidential Osprey Retail Systems, Inc. Page 9 of 25
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)
Validated Architecture:
Customers must purge cardholder data after defined retention period:
UnifyPOS does NOT store cardholder data.
PA-DSS reference (2.2)
Validated Architecture:
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).
PA-DSS reference (2.3)
Validated Architecture:
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
PA-DSS v1.2 Implementation Guide Version: 2.0
Confidential Osprey Retail Systems, Inc. Page 10 of 25
―transaction id‖ can be later used to perform a VOID (Cancel UnifyPOS
transaction).
PA-DSS reference (2.4)
Validated Architecture:
Disk Encryption meets PCI DSS 3.4.1: UnifyPOS does not store cardholder
data and therefore does not use disk encryption.
PA-DSS reference (2.5)
Validated Architecture:
Protect encryption keys: UnifyPOS does not store cardholder data and therefore
does not use any cryptographic methods.
PA-DSS reference (2.6)
Validated Architecture:
Implement key management processes and procedures: UnifyPOS does not
store cardholder data and therefore does not use any cryptographic methods.
PA-DSS reference (2.7)
Validated Architecture:
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
PA-DSS reference (3.1)
Validated Architecture:
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.
PA-DSS v1.2 Implementation Guide Version: 2.0
Confidential Osprey Retail Systems, Inc. Page 11 of 25
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.
PA-DSS reference (3.2)
Validated Architecture:
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.
PA-DSS reference (3.3)
Validated Architecture:
Encrypt application passwords: UnifyPOS stores encrypted application
passwords.
PA-DSS v1.2 Implementation Guide Version: 2.0
Confidential Osprey Retail Systems, Inc. Page 12 of 25
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
PA-DSS reference (4.1)
Validated Architecture:
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.
PA-DSS v1.2 Implementation Guide Version: 2.0
Confidential Osprey Retail Systems, Inc. Page 13 of 25
o Cashier Authentication Failed – when a cashier attempts to logon to the
POS module this event is published.
PA-DSS reference (4.2)
Validated Architecture:
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
PA-DSS reference (5.1)
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)
Validated Architecture:
PA-DSS v1.2 Implementation Guide Version: 2.0
Confidential Osprey Retail Systems, Inc. Page 14 of 25
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.
PA-DSS reference (5.1.2)
Osprey Retail Systems, Inc. development and test environments are separate from the
production environment and are in two physically different locations.
PA-DSS reference (5.1.4)
Validated Architecture:
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.
PA-DSS reference (5.1.5)
Validated Architecture:
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.
PA-DSS reference (5.1.6)
Validated Architecture:
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.
PA-DSS reference (5.1.7)
Validated Architecture:
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.
PA-DSS v1.2 Implementation Guide Version: 2.0
Confidential Osprey Retail Systems, Inc. Page 15 of 25
PA-DSS reference (5.2)
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.
PA-DSS reference (5.3)
Validated Architecture:
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)
PA-DSS reference (5.4)
Validated Architecture:
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.
PA-DSS v1.2 Implementation Guide Version: 2.0
Confidential Osprey Retail Systems, Inc. Page 16 of 25
2.6. Protect Wireless Transmissions
PA-DSS reference (6.1, 6.2)
Validated Architecture:
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.
PA-DSS v1.2 Implementation Guide Version: 2.0
Confidential Osprey Retail Systems, Inc. Page 17 of 25
2.7. Test applications to address vulnerabilities
PA-DSS reference (7.1, 7.2)
Validated Architecture:
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
PA-DSS reference (8.1)
Validated Architecture:
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
PA-DSS v1.2 Implementation Guide Version: 2.0
Confidential Osprey Retail Systems, Inc. Page 18 of 25
2.9. Never Store Cardholder Data on a Public-Facing Internet
Connection
PA-DSS reference (9.1)
Validated Architecture:
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
PA-DSS reference (10.1)
Validated Architecture:
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).
PA-DSS v1.2 Implementation Guide Version: 2.0
Confidential Osprey Retail Systems, Inc. Page 19 of 25
2.11. Facilitate Secure Remote Application Access
PA-DSS reference (11.1, 11.2, 11.3)
Validated Architecture:
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.
PA-DSS v1.2 Implementation Guide Version: 2.0
Confidential Osprey Retail Systems, Inc. Page 20 of 25
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
PA-DSS reference (12.1, 12.2)
Validated Architecture:
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
PA-DSS reference (13.1)
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.
PA-DSS v1.2 Implementation Guide Version: 2.0
Confidential Osprey Retail Systems, Inc. Page 21 of 25
2.14. Maintain Instructional Documentation and training programs
for customers, resellers and integrators.
PA-DSS reference (14.1, 14.2)
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.
PA-DSS v1.2 Implementation Guide Version: 2.0
Confidential Osprey Retail Systems, Inc. Page 22 of 25
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
PA-DSS v1.2 Implementation Guide Version: 2.0
Confidential Osprey Retail Systems, Inc. Page 23 of 25
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.
PA-DSS v1.2 Implementation Guide Version: 2.0
Confidential Osprey Retail Systems, Inc. Page 24 of 25
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.
PA-DSS v1.2 Implementation Guide Version: 2.0
Confidential Osprey Retail Systems, Inc. Page 25 of 25
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.