3M SelfCheck Self-Pay Software. Implementation Guide

Transcription

1 3M SelfCheck Self-Pay Software Implementation Guide

2 3M SelfCheck Self-Pay Software Implementation Guide, a 3M All rights reserved. 3M is a trademark of 3M. Microsoft, Windows, Vista, and Excel are either registered trademarks or trademarks of Microsoft Corporation in the United States and other countries. ICVERIFY is a registered trademark of ICVERIFY Incorporated in the United States and other countries.

3 Table of Contents Introduction...5 Application Summary...5 Credit Card Processor...5 Understanding PCI DSS and PA-DSS...6 Build and Maintain a Secure Network...6 Protect Cardholder Data...6 Maintain a Vulnerability Management Program...6 Implement Strong Access Control Measures...6 Regularly Monitor and Test Networks...6 Maintain an Information Security Policy...6 Relationship Between PCI DSS and PA-DSS Validation...7 Network and System Configurations...8 Local ICVERIFY Configuration...8 Remote ICVERIFY Configuration...9 Network and System Configuration Details...10 WSUS Server...10 Kaseya Server...10 Windows Update Server...10 ICVERIFY Master Station...11 Payment Gateway...11 Logging Server...11 Credit Card Processing Workflow for ICVerify...12 Local ICVERIFY Configuration...12 Remote ICVERIFY Configuration...13 PA-DSS Requirements...14 REQ 1: Do not retain full magnetic stripe, card verification code or value (CAV2, CID, CVC2, CVV2) or PIN block data...14 PA-DSS Delete sensitive authentication data stored by previous payment application versions PA-DSS Delete any sensitive authentication data (pre-authorization) gathered as a result of troubleshooting the payment application REQ 2: Protect Stored Cardholder Data...15 PA-DSS 2.1 Purge cardholder data after customer-defined retention period...15 PA-DSS 2.5. Protect keys used to secure cardholder data against disclosure and misuse...15 PA-DSS 2.6. Implement key management processes and procedures for cryptographic key used for encryption of cardholder data PA-DSS 2.7. Render irretrievable cryptographic key material or cryptograms stored by previous payment application versions...16 REQ 3: Provide Secure Authentication Features...16 PA-DSS 3.1 Use unique user names and secure authentication for administrative access and access to cardholder data M, All rights reserved. 3

4 PA-DSS 3.2 Use unique user names and secure authentication for access to PCs, servers, and databases with payment applications...16 REQ 4: Log Payment Application Activity...18 PA-DSS 4.1 Implement automated audit trails...18 PA-DSS 4.4. Facilitate centralized logging...19 REQ 5: Develop Secure Payment Applications...21 PA-DSS 5.4 Use only necessary and secure services, protocols, components, and dependent software and hardware, including those provided by third parties...21 REQ 6: Protect Wireless Transmissions...21 PA-DSS 6.1 Securely implement wireless technology PA-DSS 6.2 Secure transmissions of cardholder data over wireless networks...22 REQ 9: Cardholder data must never be stored on a server connected to the Internet...22 PA-DSS 9.1 Store cardholder data only on servers not connected to the Internet...22 REQ 10: Facilitate secure remote software updates...22 PA-DSS Any remote access into the payment application must be performed securely...22 REQ 11: Encrypt sensitive traffic over public networks...24 PA-DSS Secure transmissions of cardholder data over public networks PA-DSS Encrypt cardholder data sent over end-user messaging technologies REQ 12: Encrypt all non-console administrative access...24 PA-DSS Encrypt non-console administrative access REQ 13: Maintain instructional documentation and training programs for customers, resellers and integrators...25 PA-DSS Develop, maintain, and disseminate a PA-DSS Implementation Guide(s) for customers...25 PA-DSS Maintain and review PA-DSS Implementation Guide Revision Information M, All rights reserved. 4

5 Introduction This implementation guide discusses the credit card security features of the SelfCheck Self-Pay Software. The guide explains how customers can secure the SelfCheck Self-Pay Software in order to be Payment Card Industry (PCI) compliant. Information contained in this document applies to the PCI Payment Application Data Security Standard (PA- DSS) data security regulations and guidelines, version 2.0, as of October The following documents provide additional detail surrounding the PCI Security Standards Council (SSC) and related security programs (PA-DSS, PCI DSS, etc): Payment Applications Data Security Standard (PA-DSS) Payment Card Industry Data Security Standard (PCI-DSS) Open Web Application Security Project (OWASP) Application Summary Name: Application Version: 1.0 Operating Systems: SelfCheck Self-Pay Software SelfCheck Systems: 8410, 8420, 8422 and Application Description: Credit Card Processor Microsoft Windows Vista 32-bit, Microsoft Windows 7 64-bit The SelfCheck Self-Pay Software is an application that facilitates credit card payments between applications and ICVERIFY software. The application transfers cardholder data from the ID Tech Magnetic Reader to the ICVERIFY software. Name: First Data ICVerify for Windows Accreditation: Document References: PA-DSS accredited software application First Data ICVerify 4.2 PA-DSS Implementation Guide located at First Data ICVerify for Windows 4.2 Software Developer s Kit Guide located at M, All rights reserved. 5

6 Understanding PCI DSS and PA-DSS As a business that accepts credit cards for payments, the library must be PCI-DSS compliant. PCI-DSS Compliance is an industry-mandated security standard that applies to businesses that handle, process or store credit card information. The need for PCI stems from the fact that over the years, there have been data security breaches, and credit card information was compromised. When data security breaches occur, the impacts can be far-reaching for the individuals and merchants involved. The PCI-DSS standard requires merchants to: 1. Achieve and maintain compliance. 2. Not store information such as CVV2, CVC2 and CID track data from the magnetic strip or PIN data. If permitted, credit card information, such as Primary Account Number (PAN), card holder name and expiration date may be stored. However, certain security standards are required. To be PCI compliant, the library must meet the following 12 PCI requirements. Build and Maintain a Secure Network 1. Install and maintain a firewall configuration to protect data. 2. Do not use vendor-supplied defaults for system passwords or other security parameters. Protect Cardholder Data 3. Protect stored data. 4. Encrypt transmission of cardholder data and sensitive information across public networks. Maintain a Vulnerability Management Program 5. Use and regularly update anti-virus software. 6. Develop and maintain secure systems and applications. Implement Strong Access Control Measures 7. Restrict access to cardholder data by businesses. Make data available only on a need-to-know basis. 8. Assign a unique ID to each person with computer access. 9. Restrict physical access to cardholder data. Regularly Monitor and Test Networks 10. Track and monitor all access to network resources and cardholder data. 11. Regularly test security systems and processes. Maintain an Information Security Policy 12. Maintain a policy that addresses information security M, All rights reserved. 6

7 Relationship Between PCI DSS and PA-DSS Validation As an application that processes credit cards for payment, 3M SelfCheck Self-Pay software is required to be PA-DSS compliant. PA-DSS ensures that payment applications have implemented security controls identified by the payment card industry as critically important to safeguarding private information shared in the processing of credit cards (cardholder data). Use of a PA-DSS compliant application does not imply security in the processing of cardholder data. Nor does it imply that the library is PCI DSS compliant. The PA-DSS compliant application must be implemented into a PCI DSS compliant environment, according to the PA-DSS Implementation Guide provided by the payment application vendor (per PA-DSS Requirement 13.1). Requirements for the Payment Application Data Security Standard (PA-DSS) are derived from the Payment Card Industry Data Security Standard (PCI DSS) Requirements and Security Assessment Procedures. These documents details the requirements to become PCI DSS compliant. The document also details what a payment application must support in order to facilitate a customer s, and in this case, library s, PCI DSS compliance. Secure payment applications, when implemented in a PCI DSS compliant environment, reduce the potential for security breaches leading to compromises of sensitive authentication data and cardholder data. Sensitive authentication data includes: magnetic stripe data, card verification codes and values (CAV2, CID, CVC2, CVV2), PINs and PIN blocks. Cardholder data includes: primary account number (PAN), cardholder name, expiration date and service code M, All rights reserved. 7

8 Network and System Configurations Self-Pay software can be installed in one of two network and system configurations: Local ICVERIFY configuration Remote ICVERIFY configuration This section describes each, though implementation flexibility means neither description may match your site's configuration exactly. Local ICVERIFY Configuration The following diagram depicts a typical network configuration for Self-Pay software operating in a local ICVERIFY implementation, that is, one in which ICVERIFY is installed on the SelfCheck system. This eliminates the need to install and maintain another server, called the ICVERIFY Master Station, required for a remote ICVERIFY configuration. (See Network and System Configuration Details on page 10 for a detail description of each server.) M, All rights reserved. 8

9 Remote ICVERIFY Configuration The following diagram depicts a typical network configuration for Self-Pay software operating in a remote ICVERIFY configuration. This requires an ICVERIFY Master Station server, which is located behind a firewall. In this configuration, cardholder data is not stored on the SelfCheck system, but on the ICVERIFY Master Station. The library administers a single instance of ICVERIFY, as opposed to ICVERIFY running on each SelfCheck system. (See Network and System Configuration Details on page 10 for a detail description of each server.) M, All rights reserved. 9

10 Network and System Configuration Details WSUS Server This server is a repository of Windows operating system hotfixes, patches and update packages that have been tested and verified. These packages can be applied to any SelfCheck Systems using Windows Update. This server is owned, maintained and operated by 3M. Location: Requests: Address: Port: 80 Protocol: Kaseya Server Saint Paul, Minnesota Outbound only ssdsus1.3m.com TCP This server is used by the Software Support team to service SelfCheck systems remotely. This server is owned, maintained and operated by 3M. For more information, see Location: Requests: Address: Port 1: Protocol 1: Port 2: 5721 Saint Paul, Minnesota Outbound only trackandtraceservice.3m.com TCP using 256 bit AES encryption. Protocol 2: TCP using 256 bit AES encryption.port 3 1 : 443 Protocol 3 1 : TCP using 256 bit AES encryption. Note, the Kaseya Server is FIPS , Common Criteria and ISO certified. Windows Update Server This server provides update and patch packages used to update Windows. Requests: Address: Port : 445 Protocol: Outbound only *.windowsupdate.com SSL 3.0 using RSA 2048 bit certificate. 1 1 This address and port is a fallback when the other address and port are inaccessible M, All rights reserved. 10

11 ICVERIFY Master Station This server is used to process credit card payments using ICVERIFY. For more information, see the ICVERIFY PA-DSS Implementation Guide at integrators/. Requests: Outbound only Port 1: 139, 445 Protocol 1: SMB Port 2: Protocol 2: Payment Gateway SSL 3.0 using RSA 1024 bit certificate. This server is used by ICVERIFY Master Station to process credit card payments. Logging Server PCI requires a single server to collect logs from all system involved with Cardholder Data. This includes the SelfCheck system and ICVERIFY Master Station. (See PA-DSS 4.4. Facilitate centralized logging section for more details.) M, All rights reserved. 11

12 Credit Card Processing Workflow for ICVerify This section provides detail diagrams and descriptions on how the cardholder data flows through the Self-Pay and ICVERIFY software when a transaction is processed. Local ICVERIFY Configuration Workflow Steps 1. The 3M SelfCheck QuickConnect Interface Software requests a credit card payment from the 3M SelfCheck Self-Pay Software. 2. The 3M SelfCheck Self-Pay Software retrieves magnetic stripe data from the ID Tech Magnetic Card Reader when the card is swiped. 3. The 3M SelfCheck Self-Pay Software creates an XML based request using the magnetic stripe data. The XML request is then encrypted by sending it ICVERIFY software using TCP and SSL 3.0. The encrypted text is then saved to a transaction directory. 4. The ICVERIFY software decrypts the request file and generates another request, which is sent to the Payment Gateway using TCP and SSL. 5. The Payment Gateway processes the transaction and sends a response to the ICVERIFY software using TCP and SSL. The ICVERIFY software then encrypts the response into an Answer file and saves the file in a transaction directory. 6. The 3M SelfCheck Self-Pay Software detects the Answer file and decrypts it by sending it to the ICVERIFY software using TCP and SSL The SelfCheck Self-Pay Software then parses the XML based Answer file and sends the response to the 3M SelfCheck QuickConnect Interface Software M, All rights reserved. 12

13 Remote ICVERIFY Configuration Workflow Steps 1. The 3M SelfCheck QuickConnect Interface Software requests a credit card payment from the 3M SelfCheck Self-Pay Software. 2. The 3M SelfCheck Self-Pay Software retrieves the magnetic stripe data from the ID Tech Magnetic Card Reader when the card is swiped. 3. The 3M SelfCheck Self-Pay Software creates an XML based request using the magnetic stripe data. The XML request is transferred to the ICVERIFY Master Station using TCP and SSL 3.0, where it is encryted. The encrypted request is then saved to the ICVERIFY Master Station Windows shared folder as a file. 4. The ICVERIFY Master Station decrypts the request file and generates another request, which is sent to the Payment Gateway using TCP and SSL. 5. The Payment Gateway processes the transaction and sends a response to the ICVERIFY Master Station using TCP and SSL. The ICVERIFY Master Station then encrypts the response into an Answer file and saves the file to the ICVERIFY Master Station Windows shared folder. 6. The 3M SelfCheck Self-Pay Software detects the Answer file and decrypts it by sending it to the ICVERIFY Master Station using TCP and SSL The SelfCheck Self-Pay Software then parses the XML based Answer file and sends the response to the 3M SelfCheck QuickConnect Interface Software M, All rights reserved. 13

14 PA-DSS Requirements To ensure the SelfCheck Self-Pay Software is PA-DSS compliant, all applicable requirements detailed below must be completed. Note that there are several additional PCI requirements in the PA DSS standard that apply to libraries, not software design and implementation. Please note, SelfCheck Self-Pay Software depends on the ICVERIFY software. The ICVERIFY software is accredited PA-DSS software with its own PA-DSS Implementation Guide that must be followed. For more information, see the ICVERIFY PA-DSS Implementation Guide at REQ 1: Do not retain full magnetic stripe, card verification code or value (CAV2, CID, CVC2, CVV2) or PIN block data PA-DSS Delete sensitive authentication data stored by previous payment application versions. This requirement is not applicable to the SelfCheck Self-Pay Software because the SelfCheck Self-Pay Software does not store sensitive data on the system s hard drive. PA-DSS Delete any sensitive authentication data (pre-authorization) gathered as a result of troubleshooting the payment application. The SelfCheck Self-Pay software does not store sensitive data on the system's hard drive. When library employees collect sensitive data (e.g. cardholder's name and number) from a customer to resolve an issue, 3M recommends the following: Collect sensitive authentication only when needed to solve a specific problem. Store such data only in specific, known locations with limited access. Limit data collection to only the data needed to solve a specific problem. Encrypt sensitive authentication data while stored. Securely delete sensitive authentication data after being used M, All rights reserved. 14

15 REQ 2: Protect Stored Cardholder Data PA-DSS 2.1 Purge cardholder data after customer-defined retention period. The SelfCheck Self-Pay Software stores cardholder data in a Request file that is saved in the ICVERIFY Master Station shared folder. The ICVERIFY software is responsible to read and securely delete the Require file, however, the SelfCheck Self-Pay Software has a fall back mechanism. If the ICVERIFY software does not delete the Request file within 10 seconds, the SelfCheck Self-Pay software securely deletes the Request file. The Request File is deleted in accordance with the DoD M standard. The SelfCheck Self-Pay software secure delete is implemented using the following algorithm: Pass 1: Writes random characters to the file and verifies the write. Pass 2: Writes all zeroes to the file and verifies the write. Pass 3: Writes all ones to the file and verifies the write. Pass 4: Writes one and then zero repeatedly to the file and verifies the write. Pass 5: Writes zero and then one repeatedly to the file and verifies the write. Pass 6: Writes random characters to the file and verifies the write. Deletes the file. In the extremely rare case that both applications fail to delete the request files, the request files can be securely deleted manually using sdelete. To securely delete a file using sdelete, follow the steps below: 1. Download sdelete from 2. Extract the sdelete.zip file. 3. Press window + r. 4. Type cmd, then press Enter. 5. Navigate to the sdelete folder using cd. 6. Type sdelete.exe -a -p 6 <file-or-directory-to-delete> where <file-or-directory-to-delete> is the file or directory to securely delete. When the library collects cardholder data (e.g. account number with customer name, expiration date or service code) they must define a retention period. Cardholder data that exceeds this retention period must be security deleted or purged. Electronic copies can be deleted using sdelete and the steps detailed above. PA-DSS 2.5. Protect keys used to secure cardholder data against disclosure and misuse. This requirement is not applicable to the SelfCheck Self-Pay Software because the SelfCheck Self-Pay Software does not manage encryption keys. Encryption keys are managed by the ICVERIFY software. For more information, please see the ICVERIFY PA-DSS Implementation Guide at M, All rights reserved. 15

16 PA-DSS 2.6. Implement key management processes and procedures for cryptographic key used for encryption of cardholder data. This requirement is not applicable to the SelfCheck Self-Pay Software because the SelfCheck Self-Pay Software does not manage encryption keys. Encryption keys are managed by the ICVERIFY software. For more information, please see the ICVERIFY PA-DSS Implementation Guide at PA-DSS 2.7. Render irretrievable cryptographic key material or cryptograms stored by previous payment application versions. This requirement is not applicable to the SelfCheck Self-Pay Software because the SelfCheck Self-Pay Software does not manage encryption keys. Encryptions keys are managed by the ICVERIFY software. For more information, please see the ICVERIFY PA-DSS Implementation Guide at REQ 3: Provide Secure Authentication Features PA-DSS 3.1 Use unique user names and secure authentication for administrative access and access to cardholder data. This requirement is not applicable to SelfCheck Self-Pay software because the software does not store or allow users to manage credit card data on the system s hard drive. Users are managed using the ICVERIFY software. For more information, please see the ICVERIFY PA-DSS Implementation Guide at PA-DSS 3.2 Use unique user names and secure authentication for access to PCs, servers, and databases with payment applications. Libraries must require unique user credentials and restrict privileged access to systems and devices. During the installation process, Windows is configured to enforce the following security policies: Passwords are required to be changed every 90 days. Passwords must be at least 7 characters. Passwords must contain numeric, lower case alphabetic, upper case alphabetic and non-alphanumeric characters. New passwords must not match the last 4 passwords. User accounts are locked out after 6 failed attempts. User accounts are locked out for 30 minutes or until an administrator unlocks the user account. User account sessions that are inactive for more than 15 minutes are required to re-enter the password M, All rights reserved. 16

17 WARNING! These policies could be changed by an administrator user account or by joining the system to a Windows domain. Ensure that these policies are not weakened when these changes are applied to the system. 3M configures the Windows operating system to come with two users: Name 3mtech library Description This user is an administrator user. This user is allowed to change security settings; manage users; install software and hardware; and access all files on the computer. This user is a non-administrator user that is automatically logged on when the computer is started. This user can run applications that interact with SelfCheck Self-Pay Software. (e.g. SelfCheck QuickConnect Interface). WARNING! The library user should never run the SelfCheck Self-Pay software. The 3mtech and library user must be assigned to a single library employee, and the password must be changed when the SelfCheck Self-Pay Software is installed. To change user passwords, complete the following steps. Change library user password. 1. Request the library password from 3M Software Support. 2. Connect a USB Keyboard and Mouse utilizing the connections in the rear of the PC. 3. Scan the Administrator Card using the Barcode Reader or RFID pad. 4. Select Shutdown App. 5. Hold ctrl + alt + delete. 6. Click the Change a password... link 7. Enter the Old password, new New password and Confirm password, then click the Next arrow button. 8. Click OK when the Your password has been changed prompt appears. Set library user as auto login user. 1. Hold windows + r. 2. Type netplwiz, then press Enter. 3. Select the Library user. 4. Uncheck User must enter a user name and password to use this computer, then click Apply. 5. Complete the Password and Confirm Password fields, then click OK. Change 3mtech user password. 1. Click the Windows button, then hold alt + shift and select Switch User. 2. Select 3mtech, or type 3mtech in the User Name field. 3. Enter the old password in the Password field M, All rights reserved. 17

18 4. Click OK when The user s password must be change before appears. 5. Enter the new password in New Password and Confirm Password fields, then click the Next arrow button. 6. Sign out. The 3mtech user account must be used to create other user accounts on the system. Each employee that uses the system must have their own user account. REQ 4: Log Payment Application Activity PA-DSS 4.1 Implement automated audit trails. Audit logs are provided in the Event Logs. This includes audit logs from both the SelfCheck Self-Pay software and Windows. The Windows logs are provided by changes to audit policy when SelfCheck Self-Pay software is installed. The following auditing has been enabled for successful and failed attempts. Audit Account Logon Events Audit Account Management Audit Directory Services Access Audit Logon Events Audit Object Access to the Windows directory and the Self-Pay Software application directory Audit Policy Change Audit Privilege Use Audit Process Tracking Audit System Events For more information on Windows built in audit policies, please see Audit Policy Settings Under Local Policies\Audit Policy at WARNING! The audit policy could be changed by an administrator user account or by joining the system to a Windows domain. Ensure that these policies are not fully or partially disabled when these changes are applied to the system. Libraries can view these audit logs by completing the following steps. 1. Open the Event Viewer. 2. Expand Windows Logs and click Security. 3. Click Filter Currently Logs in the right panel. 4. Select Security-Auditing under the Event sources: drop down and click OK. Audit logs are also generated by the ICVERIFY software. For more information, please see the ICVERIFY PA- DSS Implementation Guide at M, All rights reserved. 18

19 PA-DSS 4.4. Facilitate centralized logging A centralized server to store logs is required. The SelfCheck Self-Pay Software and Windows logs can be captured and stored to a centralized server using the Event Log. The following table describes what the logs contain and where to find them in the Event Log. Source Description Location SelfCheck Self-Pay Software Logs Windows Logs These logs contain events that are logged by the SelfCheck Self-Pay sofware. They contains errors, warning and other information that the software has encountered while running. These logs contain Windows audit information. Windows Logs > Application with Source = 3M SelfCheck Windows Logs > Security with Source = Microsoft Windows security auditing. These Event Logs can be collected using many technologies. One such technology is called Nxlog.xlog. The steps below describe how to capture logs from the Self-Pay software and Windows, Note, the Nxlog server must be setup before the steps below can be executed. See the for more information. 1. Download and install 2. Navigate to C:\Program Files (x86)\nxlog\conf in Windows. 3. Rename nxlog.conf to nxlog.conf.backup. 4. Create a new text file named "nxlog.conf" and copy the following text into the file. ## This is a sample configuration file. See the nxlog reference manual about the ## configuration options. It should be installed locally and is also available ## online at ## Please set the ROOT to the folder your nxlog was installed into, ## otherwise it will not start. #define ROOT C:\Program Files\nxlog define ROOT C:\Program Files (x86)\nxlog Moduledir %ROOT%\modules CacheDir %ROOT%\data Pidfile %ROOT%\data\nxlog.pid SpoolDir %ROOT%\data LogFile %ROOT%\data\nxlog.log M, All rights reserved. 19

20 <Input in> Module im_msvistalog Exec if $SourceName!~ /(?i)microsoft-windows-security-auditing 3m selfcheck/ drop(); </Input> <Output out> Module om_tcp Host <ip-address> Port <port-number> </Output> <Route 1> Path in => out </Route> Where <ip-address> is the nxlog server's IP address. And <port number> is the nxlog server TCP port number. 5. Press WIN + R. 6. Type services.msc, then press Enter. 7. Find nxlog in the Services (local) list and right click Restart. 8. Open C:\Program Files (x86)\nxlog\data\nxlog.log and verify the file does not contain any ERROR from entries from last the INFO nxlog-ce-<x.x.x> started entry M, All rights reserved. 20

21 REQ 5: Develop Secure Payment Applications PA-DSS 5.4 Use only necessary and secure services, protocols, components, and dependent software and hardware, including those provided by third parties. The SelfCheck Self-Pay software uses the following software and hardware versions. Software: ICVerify for Windows NET Framework 4.5 Microsoft Windows Hardware: ID Tech MiniMag II Card Reader NEC AccuSync AS192WN 3M MicroTouch M150 PC Vista 32-bit, 7 64-bit REQ 6: Protect Wireless Transmissions PA-DSS 6.1 Securely implement wireless technology. 3M recommends you do not use wireless technologies with SelfCheck Self-Pay software. If you do use wireless technology, ensure that the following steps are taken. 1. 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. 2. Change wireless vendor defaults, including but not limited to: a) Default wireless encryption keys b) Passwords c) SNMP community strings 3. Ensure wireless device security settings are enabled for strong encryption technology for authentication and transmission. 4. Ensure firmware is updated to support strong encryption for authentication and transmission. 5. Ensure other security-related wireless vendor defaults were changed, if applicable. 6. Change the encryption keys anytime anyone with knowledge of the keys leaves the company or changes positions M, All rights reserved. 21

22 PA-DSS 6.2 Secure transmissions of cardholder data over wireless networks. If the library uses wireless technology, ensure that the following steps are followed. 1. 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. 2. Change wireless vendor defaults, including but not limited to: a) Default wireless encryption keys b) Default wireless encryption passwords and SNMP community strings c) Default wireless SNMP community strings 3. Ensure wireless device security settings are enabled for strong encryption technology (WPA or WPA2) for authentication and transmission. 4. Update the firmware on wireless devices to support strong encryption for authentication and transmission over wireless networks. 5. Change default passwords or passphrases on access points. 6. If applicable, change other security-related wireless vendor defaults. REQ 9: Cardholder data must never be stored on a server connected to the Internet PA-DSS 9.1 Store cardholder data only on servers not connected to the Internet. The SelfCheck Self-Pay Software saves encrypted cardholder data on the ICVERIFY Master Station shared folder. Because the ICVERIFY Master Station contains cardholder data it must NOT be accessible via the internet. It is also highly recommended that a firewall is placed between the ICVERIFY Master Station and other computers within the network. REQ 10: Facilitate secure remote software updates PA-DSS Any remote access into the payment application must be performed securely. Libraries will have to use network or personal firewalls (e,g, Windows Firewall) to protect the SelfCheck system when connected to the network. These firewalls must be configured to be always on. Kaseya Updates to the SelfCheck Self-Pay Software can be applied remotely using Kaseya. Kaseya is an IT systems management tool used by the 3M Software Support team to remotely access customer SelfCheck systems. Kaseya requires two-factor authentication to sign in. This means users are required to provide unique user names, strong complex password, and passcode when signing in to Kaseya. The passcode is a combination of the user PIN and a token generated from an AuthAnvil USB device or mobile application M, All rights reserved. 22

23 Kaseya has been configured with the following security policy: Passwords are required to be changed every 90 days. Passwords must contain at least 10 characters. Passwords must include numeric, lower case alphabetic, upper case alphabetic and non-alphanumeric characters. New passwords must not match the last 3 passwords. User accounts are locked out after 5 failed login attempts. Locked user accounts are locked out for 1 minutes or until an administrator unlocks the user account. User account sessions that are inactive for more than 15 minutes are required to re-enter the password. When a remote connection is established to the SelfCheck system, a library employee must accept the remote connection. WARNING! When Libraries use remote access technologies, they should be activated only when needed and immediately deactivated after use. Remote connections to Kaseya can be disabled by completing the following steps. 1. Right click on icon in the System Tray. 2. Select Disable Remote Control. Kaseya can be completely disabled by stopping the Kaseya Agent service. Complete the following steps to disable the service. 1. Press Windows + R. 2. Type services.msc in the Open: text box, then click OK. 3. Right click on Kaseya Agent and select Stop.Windows Server Update Service (WSUS) 3M has developed a process to help ensure that your SelfCheck system receives the latest Microsoft updates in a timely manner. A 3M server hosted in St. Paul, Minnesota runs Microsoft Windows Server Update Services. The server continually receives a list of available updates from Microsoft. The list of available patches is then reviewed by 3M and tested on 3M products to ensure compatibility. Once the patches are validated to ensure compatibility, 3M notifies customers through using the contact information provided when the system was purchased. If this contact information is out of date, please contact 3M Software Support. After the notice has been sent, 3M enables the patch on the WSUS server. Then the patch becomes available to download to the Client system. The client systems then download the available updates during the day. At 3 AM the Important Updates are installed. Note, most updates require a reboot and security vulnerabilities are not patched until the SelfCheck system is restarted. If a library wishes to change this update policy, please contact 3M Software Support for more information M, All rights reserved. 23

24 REQ 11: Encrypt sensitive traffic over public networks PA-DSS Secure transmissions of cardholder data over public networks. Local ICVERIFY Configuration When using the Local ICVERIFY Configuration, the Self-Pay software does not transmit cardholder data over a public network. The ICVERIFY software, however, does transmits cardholder data over the public network. For more information about how ICVERIFY software transmits cardholder, see the ICVERIFY PA-DSS Implementation Guide located at Remote ICVERIFY Configuration In the Remote ICVERIFY configuration, cardholder data is transmitted over the public network. The Self-Pay software communicates with the ICVERIFY Master Station using ICVERIFY s Request and Answer files. This means the SelfCheck Self-Pay software communicates with ICVERIFY software using two techniques described below. Text Encryption and Decryption Service on ICVERIFY Master Station SelfCheck Self-Pay software uses the ICVERIFY Master Station to encrypt Request file text and decrypt Answer file text. This communication is securely handled by TCP using SSL 3.0. Request and Answer Files Request and Answer files are encrypted text stored in a shared Windows folder on the ICVERIFY Master Station. The SelfCheck Self-Pay software creates and writes the request file, and reads and deletes the Answer file. This means the SelfCheck Self-Pay software must have read, write and delete permissions to this shared folder. Other user permissions must be restricted. For more information on how to secure ICVERIFY Request and Answers Files, see the ICVERIFY PA-DSS Implementation Guide located at PA-DSS Encrypt cardholder data sent over end-user messaging technologies. The SelfCheck Self-Pay software does not use end user messaging technologies to transfer cardholder data. It is not recommended that libraries used such technologies to transfer cardholder data, however, if libraries choose to, use strong cryptography. REQ 12: Encrypt all non-console administrative access PA-DSS Encrypt non-console administrative access. Windows Remote Desktop has been disabled. This means that access to Windows has been limited to physical access or remote access using Kaseya. If remote access is enabled in Windows, strong encryption must be used by using technologies such as SSH, VPN or SSL/TLS M, All rights reserved. 24

25 REQ 13: Maintain instructional documentation and training programs for customers, resellers and integrators. PA-DSS Develop, maintain, and disseminate a PA-DSS Implementation Guide(s) for customers. The SelfCheck Self-Pay Implementation Guide is disseminated to customers who meet all of the following criteria. 1. The customer has purchased the SelfCheck Self-Pay software. 2. SelfCheck Self-Pay is configured to accept payments using credit cards and ICVerify is the payment processor. PA-DSS Maintain and review PA-DSS Implementation Guide. This Implementation Guide will be updated or reviewed when the following occurs: Annually. SelfCheck Self-Pay software has been updated. PCI-DSS or PA-DSS has been changed and updates to Implementation Guide are required M, All rights reserved. 25

26 Revision Information Date Version Description Author 3/9/ Initial version. Joshua Gossett Althea Rupert 4/6/ Changed the document template. - Changed SelfCheck Self-Pay Software application version from 1.2 to Rewrote PA-DSS 2.1 section. - Added protocol and encryption algorithm to ICVERIFY Master Station, Kaseya and Update Agent connections. - Added protocol to WSUS Server. - Added disable Kaseya Agent steps. - Added hardware specification. - Update Requirement 4 section to include more information about Windows and SelfCheck Self-Pay logs. Also, added additional information about Nxlog. - Rewrote section 12.1, , and Removed Update Agent Server from document. - Added Windows Update Server to document. - Added firewall paragraph to section Applied minor text changes to introduction. 4/9/ Changed the PA-DSS version from 3.0 to 2.0 in introduction. - Change delete passes in PA-DSS 2.1 section. - Added users description to PA-DSS 3.2 section. 4/9/ Cleaned up wording REQUIREMENT 10 section. - Rewrote section Discuss policies used by customer that write down sensitive data to resolve issues. - Added to section 2.1. Added more details on cardholder data retention period when merchants are resolving customer issues. - Added more details to section 3.2. Included steps to reset the library user password and added more details on the library user. 4/16/ Added recommendation to 6.1 to not use wireless technologies. - Added another bullet to section 6.2 about changing password and passphares on access points. - Added warning to section 10.3 about activating and deactivating remote access technologies. - Added security technology examples to section /17/ Reworded various sections to correct grammar, spelling, etc. 5/12/ Added another requirement to PA-DSS 6.1 section. - Added another requirement to PA-DSS section 6/26/ Added warning that disabling audit logs will break PCI- DSS compliance. Joshua Gosssett Rick Reinhart Joshua Gossett Joshua Gossett Joshua Gossett Rick Reinhart Sue Nelson Sue Nelson M, All rights reserved. 26

27 Date Version Description Author 7/14/ Added Local ICVERIFY configuration to Network and System Configurations and Credit Card Processing Workflow for ICVerify sections. - Reworded the PA-DSS 4.4. Facilitate centralized logging section to clarify how to implement centralized logging. - Style changes throughout Joshua Gossett Ed Mertz M, All rights reserved. 27