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

Transcription

1 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: Please let us know if you have any questions or need any assistance.

2 UnifyPOS PA-DSS Implementation Guide Revision: 2.0 October, 2010 Copyright 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. Confidential Osprey Retail Systems, Inc. Page 1 of 25

3 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/ /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 and additional procedures had to be written to securely wipe sensitive cardholder data from older version once the customer was using /12/2010 Updated for PA-DSS version /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 The UnifyPOS installation routine now enables the Screen Saver and On Resume Password. Confidential Osprey Retail Systems, Inc. Page 2 of 25

4 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) Log Application Activity (2.4) Develop Secure Applications (2.5) Protect Wireless Transmissions (2.6) Test Applications To Address Vulnerabilities (2.7) Facilitate Secure Network Implementation (2.8) Never Store Cardholder Data on a Public-Facing Internet Connection (2.9) Facilitate Secure Remote Software Updates (2.10) Facilitate Secure Remote Application Access (2.11) Encrypt Sensitive Traffic Over Public Networks (2.12) Encrypt All Non-Console Administrative Access (2.13) Maintain Instructional Documentation and Training Programs for Customers, Resellers and Integrators (2.14) Operating System Information (3) PCI/PA-DSS Compliance Statement (3.1) Information Security Policy (4) Addressing Legacy Issues (5) Procedure For Removing Sensitive Historical Data (5.1) References, Acknowledgements (6) References (6.1) Acknowledgements (6.2) Confidential Osprey Retail Systems, Inc. Page 3 of 25

5 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 (v 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. Confidential Osprey Retail Systems, Inc. Page 4 of 25

6 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 and contact your bank, processor, or acquirer for more information. Confidential Osprey Retail Systems, Inc. Page 5 of 25

7 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 Office: Fax: Confidential Osprey Retail Systems, Inc. Page 6 of 25

8 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 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) 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 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. Confidential Osprey Retail Systems, Inc. Page 7 of 25

9 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 3 rd 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. Confidential Osprey Retail Systems, Inc. Page 8 of 25

10 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; Protect Stored Cardholder Data PA-DSS reference (2.1) Customers must purge cardholder data after defined retention period: UnifyPOS does NOT store cardholder data. PA-DSS reference (2.2) 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) 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 Confidential Osprey Retail Systems, Inc. Page 9 of 25

11 transaction id can be later used to perform a VOID (Cancel UnifyPOS transaction). PA-DSS reference (2.4) 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) Protect encryption keys: UnifyPOS does not store cardholder data and therefore does not use any cryptographic methods. PA-DSS reference (2.6) 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) Securely delete any cryptographic key material: UnifyPOS does not store cardholder data and therefore does not use any cryptographic methods Provide Secure Authentication Features PA-DSS reference (3.1) 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 , , 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. Confidential Osprey Retail Systems, Inc. Page 10 of 25

12 UnifyPOS end users are required to revoke system access for any terminated employee according to PCI standard UnifyPOS end users are required to remove inactive user accounts at least every ninety days according to PCI standard 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 UnifyPOS end users are required to communicate password procedures and policies to all users who have access to cardholder data according to PCI standard UnifyPOS end users are required to NOT use group, shared, or generic accounts and passwords according to PCI standard 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 UnifyPOS end users are required to setup UnifyPOS to use a minimum password length of at least seven characters according to PCI standard UnifyPOS end users are required to setup UnifyPOS to use numeric and alphanumeric characters in their password according to PCI standard UnifyPOS end users are required that a new password cannot be the same as the previous four passwords according to PCI standard PCI standard 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) 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) Encrypt application passwords: UnifyPOS stores encrypted application passwords. Confidential Osprey Retail Systems, Inc. Page 11 of 25

13 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 Log Application Activity PA-DSS reference (4.1) 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. Confidential Osprey Retail Systems, Inc. Page 12 of 25

14 o Cashier Authentication Failed when a cashier attempts to logon to the POS module this event is published. PA-DSS reference (4.2) 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 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) Confidential Osprey Retail Systems, Inc. Page 13 of 25

15 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) 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) 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) 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) 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. Confidential Osprey Retail Systems, Inc. Page 14 of 25

16 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 3 rd party applications via the internet, security features are implemented such as direct SSL socket communications and connection level certificates. PA-DSS reference (5.3) 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) 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. Confidential Osprey Retail Systems, Inc. Page 15 of 25

17 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 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. Confidential Osprey Retail Systems, Inc. Page 16 of 25

18 2.7. Test applications to address vulnerabilities PA-DSS reference (7.1, 7.2) Test for application vulnerabilities: In addition to on-going internal testing, Osprey Retail Systems, Inc. monitors outside security sources and product specific 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 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 Facilitate secure network implementation PA-DSS reference (8.1) 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 Confidential Osprey Retail Systems, Inc. Page 17 of 25

19 2.9. Never Store Cardholder Data on a Public-Facing Internet Connection PA-DSS reference (9.1) 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 Facilitate Secure Remote Software Updates PA-DSS reference (10.1) 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 ). 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). Confidential Osprey Retail Systems, Inc. Page 18 of 25

20 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. Confidential Osprey Retail Systems, Inc. Page 19 of 25

21 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 Encrypt Sensitive Traffic Over Public Networks PA-DSS reference (12.1, 12.2) 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 UnifyPOS does not communicate any sensitive data via , IM or chat. A UnifyPOS reseller should NEVER send sensitive data using any of these methods as well Encrypt All Non-console Administrative Access PA-DSS reference (13.1) Users and hosts within the payment application environment may need to use 3 rd 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. Confidential Osprey Retail Systems, Inc. Page 20 of 25

22 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 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. Confidential Osprey Retail Systems, Inc. Page 21 of 25

23 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: Examples of unsupported Operating Systems': Windows 98 Windows 98-SE Windows ME Windows XP SP1 As per vendor notices: Confidential Osprey Retail Systems, Inc. Page 22 of 25

24 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. Confidential Osprey Retail Systems, Inc. Page 23 of 25

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 and above). If prior data is not securely removed from the system during a PCI-compliant upgrade, the system will not be considered compliant 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. Confidential Osprey Retail Systems, Inc. Page 24 of 25

26 6. References, Acknowledgements 6.1. References This document references the following publications. PCI DSS version 1.2 released October 2008 PCI PA-DSS version 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 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. Confidential Osprey Retail Systems, Inc. Page 25 of 25