Siriusware PA-DSS Implementation Guide v.4 · PA-DSS. Salesware must be configured as specified...

accesso Siriusware Payment Application Data Security Standards (PA-DSS)

Implementation Guide for Salesware v4.4

Version history .................................................................................................................................................... 3

Introduction ........................................................................................................................................................ 3

Application Summary ................................................................................................................................................ 5

Typical Dataflow Diagram – Point of Sale ................................................................................................................. 7

Typical Dataflow Diagram – eCommerce .................................................................................................................. 8

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

Considerations for the implementation of payment application in a ................................................................. 10

PCI-Compliant Environment .............................................................................................................................. 10

Summary of requirements (detail below) .......................................................................................................... 10

accesso Siriusware Salesware Requirements Detail ........................................................................................... 12

Sensitive historical data (PA-DSS 1.1.4 & 2.3 & 2.7, PCI DSS 3.2 & 3.4) ................................................................. 12

Responsible: Client .............................................................................................................................................................. 12

Procedures .......................................................................................................................................................................... 12

Sensitive data for troubleshooting (PA-DSS 1.1.5, PCI DSS 3.2) ............................................................................. 14

Responsible: accesso Siriusware/Client .............................................................................................................................. 14

Procedures .......................................................................................................................................................................... 14

Purge cardholder data after client-defined retention period (PA-DSS 2.1, PCI DSS 3.1) ....................................... 14


Procedures .......................................................................................................................................................................... 15

Mask PAN when displayed (PA-DSS 2.2, PCI DSS 3.3) ............................................................................................. 16


Procedures .......................................................................................................................................................................... 16

Access control (PA-DSS 3.1 & 3.2, PCI DSS 8.1 & 8.2 & 8.5) ................................................................................... 16


Automated audit trail (PA-DSS 4.1-4.4, PCI DSS 10.1-10.3, 10.5.3) ........................................................................ 18


accesso Siriusware Implementation Guide for Salesware v4.4 - 2

Responsible: accesso Siriusware/Client .............................................................................................................................. 18

Procedures .......................................................................................................................................................................... 18

Wireless transmissions (PA-DSS 6.1 & 6.2, PCI DSS 1.2.3 & 2.1.1 & 4.1.1) ............................................................. 18


Procedures .......................................................................................................................................................................... 19

Network segmentation (PA-DSS 9.1, PCI DSS 1.3.7) ............................................................................................... 19


Procedure ............................................................................................................................................................................ 20

Remote access - Client access to system (PA-DSS 10.1 & 10.2, PCI DSS 8.3) ......................................................... 20


Procedures .......................................................................................................................................................................... 20

Remote access – accesso Siriusware access to system (PA-DSS 10.3, PCI DSS 1 & 12.3.9) .................................... 21

Responsible: accesso Siriusware & Client ........................................................................................................................... 21

Procedures .......................................................................................................................................................................... 21

Sending data over public networks (PA-DSS 11.1 & 11.2, PCI DSS 4.1 & 4.2) ........................................................ 21


Procedures .......................................................................................................................................................................... 21

Procedures .......................................................................................................................................................................... 23

Salesware PCI DSS compliant implementation and use (PA-DSS 13.1 & 13.2) ....................................................... 23


Procedures .......................................................................................................................................................................... 24

No Procedures Required – For Reference Only .................................................................................................. 24

Unnecessary services and protocols (PA-DSS 5.4, PCI DSS 2.2.2) ........................................................................... 24


Procedure ............................................................................................................................................................................ 24

Protect encryption keys (PA-DSS 2.5 & 2.6, PCI DSS 3.5 & 3.6) .............................................................................. 25

Responsible: accesso Siriusware ......................................................................................................................................... 25

Procedure ............................................................................................................................................................................ 25

Information security policy/program ................................................................................................................. 25

Salesware application implementation and configuration ................................................................................. 26

More Information .............................................................................................................................................. 26



Version history • Reviewed/updated for Salesware v4.4: December 2014 • Reviewed/updated for Salesware v4.3: August 2013 • Reviewed/update to PCI 2.0 for Salesware v4.2: December 2012 • Reviewed/updated: October 2011 • Reviewed/updated: September 2010 • Reviewed/updated: July 2010 • Reviewed/updated: July 2009 • Initial creation: September 2008

Note: This guide and associated training materials are subject to change. accesso SiriuswareSM reviews PA-DSS annually and when software or PA-DSS requirements change.

Important: The requirement numbers below refer to PA-DSS version 2.0 (October 2010) and PCI DSS version 2.0 (October 2010).

The information contained in this document is confidential and the sole and exclusive property of accesso Siriusware. This information is only for the use of the recipient. accesso Siriusware prohibits distribution outside of the intended recipient and the affiliated organization.

Introduction

Payment Application Data Security Standards (PA-DSS) is a set of industry security standards that assist software vendors with creating and maintaining secure payment applications. Systems that 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. PA-DSS assures merchants and their clients that their point-of-sale systems are not storing prohibited credit card data and are PCI-compliant. The PCI DSS requirements apply to all system components within the payment application environment, which is defined as any network device, host, or application, included in, or connected to, a network segment where cardholder data is stored, processed or transmitted.

The following high-level 12 Requirements comprise the core of the PCI DSS:

Build and Maintain a Secure Network 1. Install and maintain a firewall configuration to protect data 2. Do not use vendor-supplied defaults for system passwords and other security parameters



Protect Cardholder Data 1. Protect stored cardholder data 2. Encrypt transmission of cardholder data across public networks

Maintain a Vulnerability Management Program 1. Use and regularly update anti-virus software or programs 2. Develop and maintain secure systems and applications

Implement Strong Access Control Measures 1. Restrict access to cardholder data by business need-to-know 2. Assign a unique ID to each person with computer access 3. Restrict physical access to cardholder data

Regularly Monitor and Test Networks 1. Track and monitor all access to network resources and cardholder data 2. Regularly test security systems and processes

Maintain an Information Security Policy 1. Maintain a policy that addresses information security for employees and contractors

This document describes how to implement and use accesso Siriusware’s Salesware system in a PCI DSS compliant manner. This guide is to be distributed to each new accesso Siriusware client during implementation of Salesware. Compliance is a joint effort – this document delineates accesso Siriusware and client responsibilities in meeting PCI DSS implementation requirements. See the end of this document for links to more information on PCI DSS and PA-DSS. Salesware must be configured as specified below to be compliant with PCI DSS.

Salesware v4.4 has been PA-DSS certified with PA-DSS v2.0. For the PA-DSS assessment, accesso Siriusware worked with the following PCI SSC approved Payment Application Qualified Security Assessor (PAQSA):

Coalfire Systems, Inc. 361 Centennial Parkway Suite 150 Louisville, CO 80027



Application Summary

Payment Application Name: Salesware

Payment Application Version: Version 4.4

Application Description:

Since 1989 accesso Siriusware has been providing clients with excellence in ticketing and admission systems that deliver all the essential features required at every point of sale in a customizable, integrated Enterprise Solution.

Application Target Clientele: Salesware is targeted at any merchant who issues tickets for access to merchant venues, including ski resorts, museums and theme parks and attractions.

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

Software modules include Ticketing & Admissions, Memberships & Passes, Reservations, Group Scheduling, Retail, Food Service, Gift Cards, Kiosks, eCommerce, and much more. Salesware consists of Sales, which is the front-end POS application, SysManager, a configuration utility, and ReportManager, a reporting utility.

Required Third Party Payment Application Software:

For integrated credit card processing, purchase of a third party payment processor is required.

Database Software Supported: Microsoft SQL Server 2005/2008/2012

Other Required Third Party Software: None

Operating System(s) Supported:

Salesware is operating system agnostic and no special configuration is required for any Microsoft Windows operating system. All operating systems must be supported by Microsoft and updated with the latest service packs. See accesso Siriusware’s documentation Salesware System Architecture and Specifications for detailed requirements.



Application Functionality Supported

Select one or more from the following list:

POS Suite POS Admin Shopping Cart & Store Front

POS Face-To-Face

Payment Middleware

Others (Please Specify):

POS Kiosk Payment Back

Office

POS Specialized

Payment Gateway/Switch

Payment Processing Connections:

Credit card is swiped at the POS. Authorization request is sent to third party server, which sends the request to the processing bank. The bank returns success/decline to the third party server, which in turn sends it to the POS.

Application Authentication Access to Salesware and its databases is handled with secure authentication using unique usernames and complex passwords, stored in an encrypted form in the SQL database.

Description of Versioning Methodology:

Major Releases (e.g. 5.0, 6.0)

Major releases will occur when substantial architecture or enhancements that may or may not affect PA-DSS, warrant a new product version.

Minor Releases (e.g. 4.1, 4.2)

Update Releases will occur when minor architecture changes occur, modifications are done that may or may not affect PA-DSS requirements, or updated development tools are used which require an on-site or off-site implementation support.

Update Releases (e.g. 4.1.01, 4.1.02)

Update Releases will occur periodically to address the bug fixes, enhancements, and general maintenance of the code. Update releases never include any changes that affect PA-DSS requirement status. These are service pack releases containing minor changes.

List of Resellers/Integrators (If Applicable): None



Typical Dataflow Diagram – Point of Sale



Typical Dataflow Diagram – eCommerce



Difference between PCI Compliance and PA-DSS Validation

As a software vendor, our responsibility is to be “PA-DSS Validated.”

We have performed an assessment and certification compliance review with our independent assessment firm, to ensure that our platform does conform to industry best practices when handling, managing and storing payment related information.

PA-DSS is the standard against which Payment Application has been tested, assessed, and validated.

PCI Compliance is then later obtained by the merchant, and is an assessment of the actual server (or hosting) environment.

Obtaining “PCI Compliance” is the responsibility of the merchant and the hosting provider, working together, using PCI compliant server architecture with proper hardware & software configurations and access control procedures.

The PA-DSS Validation is intended to ensure that the Payment Application will help clients achieve and maintain PCI Compliance with respect to how Payment Application handles user accounts, passwords, encryption, and other payment data related information.

The Payment Card Industry (PCI) has developed security standards for handling cardholder information in a published standard called the PCI Data Security Standard (DSS). The security requirements defined in the DSS apply to all members, merchants, and service providers that store, process or transmit cardholder data.

The PCI DSS requirements apply to all system components within the payment application environment, which is defined as any network device, host, or application, included in, or connected to, a network segment where cardholder data is stored, processed or transmitted.



Considerations for the implementation of payment application in a

PCI-Compliant Environment

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

• Sensitive Authentication Data requires special handling • Remove Historical Cardholder Data • Set up Good Access Controls • Properly Train and Monitor Admin Personnel • Key Management Roles & Responsibilities • PCI-Compliant Remote Access • Use SSH, VPN, or TLS 1.0 or higher for encryption of administrative access • Log settings must be compliant • PCI-Compliant Wireless settings • Data Transport Encryption • PCI-Compliant Use of Email • Network Segmentation • Never store cardholder data on internet-accessible systems • Use TLS for Secure Data Transmission • Delivery of Updates in a PCI Compliant Fashion

Summary of requirements (detail below)

Below is a summary of what is required to ensure a Salesware implementation is PCI DSS compliant. Note that many of these requirements address configuration of the client’s network – these are the client’s responsibility. For more detail on each item, refer to the section below with the same title.

Sensitive historical data Previous versions (prior to version 4.0.56) of Salesware may store historical data in a non-compliant manner. Run the ReEncrypt utility on all historical data, including data on backup tapes. Also securely delete archived local tables.

Sensitive data for troubleshooting accesso Siriusware never collects sensitive authentication data (swipe data, validation values or codes, PIN or PIN block data) for troubleshooting. accesso Siriusware’s log files never contain sensitive authentication data.

Purge cardholder data after client-defined retention period All cardholder data stored is automatically purged after the client defined retention period.



Mask PAN when displayed The full PAN is never displayed without appropriate security. The client sets the role-based security based on an internal policy.

Access control Access to Salesware and its databases must be handled in a secure fashion. Salesware has controls in place to prevent the system from being configured in a non-PA-DSS compliant manner. All users of the system are forced to adhere to the PA-DSS standards for passwords. In addition, client staff should follow secure methods when setting usernames and passwords for access to SQL databases and operating systems.

Wireless transmissions If Salesware salespoints (or other applications) are connected via a wireless network, the wireless network must be configured using strong encryption based on industry-tested and accepted algorithms, key lengths, and proper key-management practices (see NIST Special Publication 800-57 for more information).

Network segmentation Servers containing cardholder data must never be connected to the Internet.

Remote access Salesware applications that are run remote from the Local Area Network must be connected in a secure manner using encryption and other techniques.

Sending data over public networks Use of strong encryption and security protocols is required when transmitting data over public networks.

Non-console administration (desktop sharing) accesso Siriusware support staff may use desktop sharing to diagnose and resolve issues – this must be configured and used in a compliant manner.

Salesware PCI DSS compliant implementation and use accesso Siriusware’s products are PCI DSS compliant. The client is responsible for configuring, maintaining, and using accesso Siriusware’s products and their network in a manner consistent with this document.



accesso Siriusware Salesware requirements detail

Sensitive historical data (PA-DSS 1.1.4 & 2.3 & 2.7, PCI DSS 3.2 & 3.4)

Responsible: Client

Description Previous versions (prior to version 4.0.56) of Salesware may store historical data in a non-compliant manner. accesso Siriusware has developed a utility (ReEncrypt) to remove magnetic stripe data, card validation codes, PINs and PIN blocks, and cryptographic key material that may have been stored by previous versions. This is available for download from accesso Siriusware and must be run on the current database and all previous databases, including those on client back-up tapes. Rendering sensitive historical data irretrievable is required by PCI DSS; accesso Siriusware’s suggested method is for the client to use the ReEncrypt utility. Rendering cryptographic materials irretrievable when no longer needed is a requirement of PCI DSS.

Procedures

Current accesso Siriusware SQL database (prior to version 4.0.56): 1. Download the c_ReEncrypt_xxxx.exe file from the accesso Siriusware Information Portal to a folder

of choice. 2. Double click the c_ReEncrypt_xxxx.exe file to extract all files. It will prompt clients to unzip to a

specific folder. Clients can use any folder, but they may want to create a new folder (e.g. Siriusware\ReEncrypt) because the ReEncrypt utility creates _log.txt and _release.txt files.

3. Create a folder called “BeforeReEncrypt”. 4. Perform a full backup of the database to the above folder. 5. Upgrade the database to at least SiriusSQL 4.0.56. 6. Run the ReEncrypt.exe file. The client needs to enter the name of the database if it is something other

than SiriusSQL, and the client will need to enter the “sa” password. Additionally, e-commerce clients that use the ActPswdField setting in their web.config file will need to enter the value of their ActPswdField setting into the indicated field on the ReEncrypt utility so that e-commerce group member passwords are moved to the new accounts.passwords field. After the client has entered the necessary information, click the ReEncrypt utility.

Warning: The client can only run the ReEncrypt utility once on the database. After running the ReEncrypt utility, a detailed error report is displayed and is available in ReEncrypt_log.txt. Please review this information if any errors or warnings were received after running the ReEncrypt utility. Review the “Possible Causes” and “Recommendation” for each warning/error before contacting accesso Siriusware Client Support. Clients that are concerned with the results of running the ReEncrypt utility should contact accesso Siriusware Client Support.



7. After the client has confirmed that the system is operating as expected, securely delete all files in the folder “BeforeReEncrypt”.

Note: accesso Siriusware suggests using sDelete (as described below) to securely delete the files.

accesso Siriusware SQL database(s) on backup tapes (prior to version 4.0.56) To run the ReEncrypt utility on databases stored on backup tapes, each database must be restored, attached to SQL, upgraded to at least SiriusSQL 4.0.56, and the utility run as described above. Then the database should be detached and the backup tape recreated (the old backup tape should be overwritten). This must be done on every accesso Siriusware SQL database stored on any backup tape to be PCI DSS compliant.

Warning: Be careful not to overwrite the live data when attaching an old database – when attaching the database, use a name other than SiriusSQL.

Important: Databases prior to Salesware v4.0 are not SQL databases and this utility cannot be used on them. These need either to be deleted from backups or converted to SiriusSQL 4.0.56 in order to run the ReEncrypt utility.

Current accesso Siriusware local salespoint tables (prior to version 4.0.56): The first time version 4.0.56 (or later) Sales is run, the local tables containing sensitive data are archived to a folder named “…Sales\PABP_archive” and the tables automatically recreated. The client must securely delete the files in the folder “…Sales\PABP_archive” on each salespoint to eliminate sensitive information stored in local tables and be compliant with PCI DSS. To do this:

1. Download the free Microsoft sDelete utility and batch file from accesso Siriusware portal (sDelete.zip): http://portal.siriusware.com/informationportal/Downloads/PA-DSS/tabid/116/Default.aspx

2. Unzip sDelete.zip any folder 3. Double-click the “sDeleteAuto.bat” to securely delete the archived files

Note: the batch file executes the following commands: c: copy sdelete.exe "\Program Files\Siriusware\Sales" cd \Program Files\Siriusware\Sales sDelete PABP_Archive\*.* rd PABP_Archive del sdelete.exe

http://portal.siriusware.com/informationportal/Downloads/PABP/tabid/116/Default.aspx



Sensitive data for troubleshooting (PA-DSS 1.1.5, PCI DSS 3.2)

Responsible: accesso Siriusware/Client Description accesso Siriusware never collects sensitive authentication data (swipe data, validation values or codes, PIN or PIN block data) for troubleshooting. accesso Siriusware’s log files never contain sensitive authentication data. accesso Siriusware’s support is done internally (accesso Siriusware has no resellers or integrators that provide support).

Procedures

accesso Siriusware accesso Siriusware never collects sensitive authentication data or cardholder data for any reason.

Client Never share sensitive authentication data with accesso Siriusware. We recommend that clients do not collect sensitive authentication data, but if the data is collected, the following procedures must be followed:

• Collect sensitive authentication data only when needed to solve a specific problem • Store such data only in specific, known locations with limited access • Collect only the limited amount of data needed to solve a specific problem • Encrypt sensitive authentication data while stored • Securely delete such data immediately after use

Purge cardholder data after client-defined retention period (PA-DSS 2.1, PCI DSS 3.1)

Responsible: Client

Description All cardholder data stored must be automatically purged after the client defined retention period. accesso Siriusware’s product (v 4.1 and above) provides an automated mechanism to purge this data, both in the server database and in local salespoint tables. This mechanism purges data in the following database and local tables:



cc_trans.card_no cc_trans.exp_date cc_trans.cardholder cc_trans.rec_in cc_trans.rec_out sh_save.pmthistory guests.cc_swipe guests.cc_number gst_actv.details (no longer used for cardholder data, but was in the past) ww_sales.sale_text

Procedures

Client Use SysManager > Preferences > Miscellaneous > Sales to enter auto pruning settings for cardholder data for both local and server data based on the client defined retention period.

The local infrastructure can retain cardholder data due to backups, cached data or restore points.

• Backups of the server or local data may contain cardholder data that is not automatically purged (as it is not live data). It is client responsibility to delete or purge server and local PC backups based on the client retention period.

• Pagefile.sys may contain cached data. Therefore, it is advisable to encrypt Pagefile.sys: • From a COMMAND prompt with administrator rights, type:

fsutil behavior set EncryptPagingFile 1

• To verify it is encrypted, from a COMMAND prompt, type:

fsutil behavior query EncryptPagingFile

• The system should return EncryptPagingFile = 1

Operating system restore points can contain previous versions of user files, which may include local salespoint tables. To prevent this, the client must either delete all restore points based on the retention period or turn off system protection. Use Control Panel > System > System Protection > Configure to turn off system protection or delete restore points.



Mask PAN when displayed (PA-DSS 2.2, PCI DSS 3.3)

Responsible: Client

Description The first six and last four digits of the PAN are the maximum number of digits to be displayed. However, with appropriate role-based security, employees with a legitimate business need are able to display the full PAN.

Procedures

Client Create an internal documented policy addressing legitimate business needs to display the full PAN. Ensure appropriate role-based security is configured so only those employees with a legitimate business need are able to display the full PAN.

Access control (PA-DSS 3.1 & 3.2, PCI DSS 8.1 & 8.2 & 8.5)

Responsible: Client

Description Access to Salesware and its databases must be handled with secure authentication using unique usernames and complex passwords. Salesware requires unique usernames and complex passwords. Administrator access and access to cardholder data is controlled by role-based security. Clients and resellers/integrators are advised that changing out of the box installation settings for unique user IDs and secure authentication will result in non-compliance with PCI DSS. Upon first installation of Salesware, the system requires changing the password for administrative access.

Procedures • Default accounts: Do not use default accounts to access Salesware, the SQL database, or operating

systems. Examples include “ADMIN” (Salesware), “Administrator” (Windows systems), and “sa” (SQL). Assign a complex password to these accounts, then disable or never use these accounts. Salesware ships with one default user named “ADMIN”. ADMIN has all security rights – the system will require the client to change the ADMIN password the first time the user logs into SysManager.

• Usernames and passwords: For access to Salesware, SQL database(s), and operating systems, client staff must: • Use unique usernames for each employee • Use complex passwords:

• Use a minimum password length of eight characters



• Use passwords that contain both numeric and alphabetic characters • Change passwords at least every 90 days • Not use a password that has been used previously

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

access to cardholder data, site data, etc. The client can control whether each individual admin user can see credit card PAN (or only last 4).

• In most systems, a security breach is the result of unethical personnel. Therefore, pay special attention to whom the users that are trusted into the admin site and allowed to view full decrypted and unmasked payment information.

Configuration • Salesware - Inactivity timeout: Ensure the inactivity timeout (Idle application lock) is set to 15 minutes or

less. This requires the user to re-enter the password to re-activate the session if it has been idle longer than 15 minutes. To configure this for all applications, use SysManager > Preferences > Operators > Misc and set the “Idle application lock” to 15 minutes or less.

Note: Sales has an .INI setting that allows the client to make the salespoint inactivity timeout more restrictive than the global setting (if set to more minutes than the global setting, it will use the more restrictive global setting). To configure a salespoint, add the following to Sales32c.INI.

[Preferences] AutoLogout=14

• Salesware - New passwords should be unique: Ensure that new passwords are unique by setting the number of old passwords to disallow to at least four. To configure this to at least four, use SysManager > Preferences > Operators > Misc and set the “Password History Reuse Limit” to 4 or more. The setting “Minimum Password age in days before change allowed” prevents a user from quickly cycling through 4 passwords and returning to the original for a specific number of days.

• Salesware - Lock the account after failed login attempts. Lock the account (username) after not more than six failed attempts for a minimum of thirty minutes (or until an administrator resets it). • To configure the number of failed login attempts (not more than six) use SysManager > Preferences >

Operators > Misc and set the “Number of failed login attempts before lock” to 6 or less. • To configure the number of minutes to lock it out (minimum of thirty) use SysManager > Preferences >

Operators > Misc and set the “Minutes to keep operator login locked” to 30 minutes or more.

Note: If set to 0, the account is locked indefinitely (until a system administrator releases it).



• Salesware - Passwords must be changed at least every 90 days: Ensure users must change their passwords at least every 90 days. To do this use SysManager > Preferences > Operators > Misc and set the “Maximum Password Age” to 90 days or less.

• Salesware - Grant users only “Read & execute” permissions to Sales32c.INI (only necessary for versions prior to 4.1., as it is the default on installations of versions 4.1 and later): Each salespoint has a setting file called, Sales32c.INI. Salesware users should not be able to alter this file. The network administrator should ensure that Salesware users have only read access to this file on each salespoint. In general, as a local administrator, alter the security properties of the file so that Salesware users have “Read & execute” permissions only (not Full control, Modify, or Write).

Automated audit trail (PA-DSS 4.1-4.4, PCI DSS 10.1-10.3, 10.5.3)

Responsible: accesso Siriusware/Client

Description All audit trails in Salesware are logged automatically into the centralized SQL database. The logging cannot be disabled. Client centralized logging is facilitated by export from the SQL database to a standard log format, then import into a centralized external log server.

Procedures • To review the log: Using SQL Server Management Studio, query the accesso Siriusware database (table

SP_LOG) for the log entries of interest, right click the the output grid, choose Save Results As, and select CSV format. Note that the table ACT_TYPE contains numeric activity types and descriptions; numeric activity types are recorded in SP_LOG. After export, import into the centralized external log server.

• To ensure the log is not tampered with: • Ensure access to SQL is limited to only those that require access. • Enable Windows Security Event logging so that DELETEs and UPDATEs to the SP_LOG table are logged

to the event log. Periodically review the Security Event log to ensure that unauthorized DELETEs and UPDATEs have not occurred. For more information, see http://technet.microsoft.com/en-us/library/cc280663.aspx.

Wireless transmissions (PA-DSS 6.1 & 6.2, PCI DSS 1.2.3 & 2.1.1 & 4.1.1)

Responsible: Client

Description Salesware applications can be connected at a client site via a wireless network. If the client chooses to connect salespoints (or other applications) via wireless the following procedures must be followed per PCI DSS Requirements 1.2.3, 1.4, 2.1.1, and 4.1.1.

http://technet.microsoft.com/en-us/library/cc280663.aspx

http://technet.microsoft.com/en-us/library/cc280663.aspx



Procedures

Implement wireless according to industry best practices (e.g., IEEE 802.11i) to implement strong encryption for authentication and transmission: The strong encryption should be based on industry-tested and accepted algorithms, key lengths, and proper key-management practices (see NIST Special Publication 800-57 for more information).

Encrypt transmissions: Update the firmware on wireless devices to support strong encryption for authentication and transmission over wireless networks (for example, WPA/WPA2). Do not use wired equivalent privacy (WEP) – it is prohibited to use WEP after June 30, 2010.

Change defaults: Change wireless vendor defaults, including:

• Encryption keys (also change these anytime anyone with knowledge of the keys leaves the company or changes positions)

• SNMP community strings on wireless devices • Passwords/passphrases on access points • Other security-related wireless vendor defaults

Install firewalls per PCI DSS Requirements 1.2.3 & 1.4. • Perimeter firewall: Install perimeter firewalls between any wireless networks and the cardholder data

environment (SQL Server and ProtoBase PC, or other processor equipment). 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.

• Personal firewall: Install personal firewall software on any PC or device with direct connectivity to the Internet.

Network segmentation (PA-DSS 9.1, PCI DSS 1.3.7)

Responsible: Client

Description Salesware does not require and PCI DSS does not allow the SQL database server and the web server to be on the same 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.



Procedure Servers containing cardholder data (in SQL database(s) and in the ProtoBase or other processor PC) must never be accessible on the Internet. Specifically, the web server and the database server must not be on the same server. A simplified high-level diagram of an expected network configuration for a web based payment application environment is included below:

Remote access - Client access to system (PA-DSS 10.1 & 10.2, PCI DSS 8.3)

Responsible: Client

Description Salesware salespoints, SysManager, and ReportManager are normally on the client’s Local Area Network (LAN). Client remote access to the accesso Siriusware software is rarely needed. In the event that it is required, accesso Siriusware clients must use a two-factor authentication mechanism as described in PA-DSS Requirement 10.1.

Procedures

Client • Remote salespoints: These must be connected to SalesEZ (on the LAN) via a VPN connection using a two-

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

• SysManager/ReportManager stations: If these applications need to be run from a remote location, we suggest running them on the LAN and using desktop sharing via Windows Remote Desktop or other remote access. Alternatively, they can be connected via a VPN connection that uses a two-factor authentication mechanism. The choice of remote access software is up to the client – clients must ensure the remote access software supports security features required by PCI and must enable them: • Ensure the software selected uses encrypted data transmission according to PCI 4.1, encrypts

passwords using strong cryptography, and blocks repeated access attempts. It should also require password expiration, minimum password lengths, and strong passwords and disallow using the same password when changing.

• Configure the software so that passwords must be changed every 90 days, require a minimum of seven character passwords that must contain both numeric and alphabetic characters, and new passwords cannot be the same as the previous four.

• Change default settings (i.e. change default passwords and disable generic usernames). • Use a unique username/password for each user. • If the software allows, clients should:

• Allow connections only from specific MAC addresses • Incorporate two-factor authentication



Remote access – accesso Siriusware access to system (PA-DSS 10.3, PCI DSS 1 & 12.3.9)

Responsible: accesso Siriusware & Client

Description Updates to Salesware are normally downloaded from accesso Siriusware’s Information Portal by the client. On rare occasions for diagnostics and support, updates may be delivered via client-initiated remote access. The Salesware application does not provide or require a specific remote access technology and therefore does require restricting remote access to a specific IP or MAC address.

Procedures • Normal updates: new releases are posted by accesso Siriusware to our Information Portal and notification

is sent to clients via email. Clients should review the “What’s New” document before installing new releases, then download and install the update as described in the “What’s New” release documentation.

• Diagnostic and support updates: on rare occasions, accesso Siriusware support personnel may request performing an update via client-initiated remote access, with immediate deactivation after use. See the procedures under Non-console administration (desktop sharing). Clients must turn on remote access only when needed for downloads of updates by accesso Siriusware personnel. Client must turn off/deactivate remote-access immediately after the download completes.

• Firewall: For either of the above, ensure a firewall is in use per PCI DSS Requirement 1 or 1.3.9.

Sending data over public networks (PA-DSS 11.1 & 11.2, PCI DSS 4.1 & 4.2)

Responsible: Client

Description Sensitive cardholder data is transmitted over public networks (i.e. the Internet) when a purchase is made using the Salesware eCommerce module. Some clients may have remote sites that use the Internet or other open, public networks, to connect Salesware to the central server. Use of strong cryptography and security protocols is required when using public networks.

Procedures

eCommerce & TLS Purchase, installation, and use of a transport layer security (TLS) certificate is required. The PCI DSS requires the use of strong cryptography and encryption techniques with at least a 128 bit encryption strength (either at the transport layer with TLS or IPSEC; or at the data layer with algorithms such as RSA or Triple-DES) to safeguard sensitive cardholder data during transmission over public networks (this includes the Internet and Internet accessible DMZ network segments).



eCommerce & SSL SSL should never be used for Secure Data Transmission. To ensure this, SSL should be disabled in IIS. To disable SSL on the IIS server, follow these steps (for IIS 5.0 and above):

1. Click Start, click Run, type regedit and click OK. 2. In Registry Editor, navigate to:

HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0

3. Right-click the the SSL 2.0 key, select New + Key. 4. Name the new key Server and hit Enter. 5. On the Edit menu, select New + DWORD (32-bit) Value. 6. Type Enabled as the key name and hit Enter. 7. Ensure that the value in the Data column is 0×00000000 (0). 8. Repeat these steps for SSL 3.0. 9. Reboot the system.

eCommerce and null sessions Null sessions should be completely disabled on the web server to prevent certain types of attacks. To do this on Windows Server 2008:

• Open the Group Policy Editor (in Administrative tools) and navigate to Computer Configuration\Windows Settings\SecuritySettings\Local Policies\SecurityOptions.

• For the 6 policies listed below that control what information can be accessed via Null Sessions, disable policy 1 and 4, enable policy 2 and 3, and specify empty lists for policy 5 and 6. 1. Network access: Allow anonymous SID/Name translation 2. Network access: Do not allow anonymous enumeration of SAM accounts 3. Network access: Do not allow anonymous enumeration of SAM accounts and shares 4. Network access: Let Everyone permissions apply to anonymous users 5. Network access: Named Pipes that can be accessed anonymously 6. Network access: Shares that can be accessed anonymously

eCommerce & ww.dll The network traffic between ww.dll (located in the DMZ) and the third party credit card server (e.g. Fusebox) must be encrypted using technologies such as TLS.

Remote salespoints Use of a VPN with two-factor authentication or a secure protocol such as Internet Protocol Security (IPSEC) and transport layer security (TLS) is required.

Remote SysManager/ReportManager It is recommended that these be run on the local LAN and accessed via desktop sharing (see “Remote Access”).



Never send Primary Account Number (PAN) by end-user messaging technologies (email, instant messaging, chat) Salesware never sends Primary Account Numbers (PANs) by end-user messaging technologies. Client staff must never send a primary account number (credit card number) by end-user messaging technologies.

Non-console administration (desktop sharing) (PA-DSS 12.1, PCI DSS 2.3)

Responsible: Client and accesso Siriusware

Description accesso Siriusware support staff uses desktop sharing for remote incident support using TeamViewer. The connection is initiated by the client at accesso Siriusware’s request, using an outbound connection from the client. All data transferred is encrypted using RSA public/private key exchange and AES (256 Bit) session encoding. accesso Siriusware does not require unsolicited access to a client site.

Procedures

Client If client is to use non-console administration, they must use SSH, VPN, or TLS for encryption of non-console administrative access.

Sharing a client’s desktop for remote support using TeamViewer: • Client: Download the TeamViewer application from http://www.siriusware.com/teamviewer/ to the desktop.

Double-click TeamViewerqs.exe and tell the accesso Siriusware support staff person the ID displayed. After the remote session is complete, deactivate (close) the TeamViewer application.

• accesso Siriusware: Start TeamViewer.exe, enter the Client’s ID in “Create Session” and click “Connect to partner”.

Salesware PCI DSS compliant implementation and use (PA-DSS 13.1 & 13.2)

Responsible: Client

Description accesso Siriusware’s products are PCI DSS compliant. The client is responsible for configuring, maintaining, and using accesso Siriusware’s products and their network and other infrastructure in a manner consistent with this document and following operational guidelines within this document. accesso Siriusware does not use resellers and integrators; accesso Siriusware will ensure its implementation staff understands how to configure Salesware in a compliant fashion.

http://www.siriusware.com/teamviewer/



accesso Siriusware will distribute this guide to each client and ask that they acknowledge receipt and understanding. This guide is subject to change and accesso Siriusware will review it annually or whenever the software or PA-DSS requirements change.

Procedures • Infrastructure configuration: Client must ensure their network and other infrastructure is configured as

described in this document prior to implementation of the Salesware software at the client site. Client must ensure the network is maintained in a manner consistent with this document.

• Salesware configuration: Client must ensure that Salesware is configured, maintained, and used in a manner consistent with this document.

• Operations: Client must ensure their staff follows operational guidelines in this document while using the Salesware system.

No procedures required – for reference only

Unnecessary services and protocols (PA-DSS 5.4, PCI DSS 2.2.2)

Responsible: Client

Description Salesware requires the TCP/IP protocol. Other protocols and insecure services are not required. For reference, the TCP/IP ports used by default are as follows. These can be altered via Salesware configuration settings. Note that some Salesware applications require an ODBC connection to the SQL database. By default, the port is dynamically determined, but can be specified via Windows Control Panel/Administrative Tools/ODBC Data Sources.

Web SSL 443 SalesEZ 4203 BookEZ 4204 SalesEZ-Training 4205 BookEZ-Training 4206 RentEZ 4207 RentEZ-Training 4208 ProtoBase 4209 TallyEZ 4213 TallyEZ-Training 4214 Apropos listener 4215 PMS Server 10005

Procedure None required



Protect encryption keys (PA-DSS 2.5 & 2.6, PCI DSS 3.5 & 3.6)

Responsible: accesso Siriusware

Description accesso Siriusware uses dynamic encryption keys; therefore, access to keys is not necessary for clients.

Procedure None required

Information security policy/program

In addition to the security requirements above, 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 the 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. Visa 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. MasterCard has published a Compliant Security Vendor List of SDP-approved scanning vendors as well.



Salesware application implementation and configuration

The accesso Siriusware Salesware Suite requires significant planning and configuration before launching in a production environment. The accesso Siriusware implementation team will guide clients through this process. For a successful implementation both accesso Siriusware and the company (Client) need to dedicate time and resources to accomplish the various tasks. A summary of typical implementation tasks are:

• accesso Siriusware conducts a Business Process Review meeting to better understand the business needs and define an implementation plan.

• Client purchases and installs appropriate network infrastructure and hardware, adhering to PCI requirements and accesso Siriusware’s requirements documented in the Salesware System Architecture and Specifications guide.

• Client purchases and implements a third party credit card processing system. • accesso Siriusware and client configure the database appropriate for client’s business needs. • Client obtains and installs a TLS certificate (eCommerce module only). • accesso Siriusware and client install the system and complete configuration. • Client changes default passwords, creates users, and assigns access rights as appropriate. • accesso Siriusware trains client on use of the system. • Client conducts end-to-end testing, ensuring system operates as expected, including credit card

transactions. • Client goes live with system.

More Information

Payment Card Industry Data Security Standards (PCI DSS): https://www.pcisecuritystandards.org/security_standards/index.php

Payment Application Data Security Standards (PA-DSS): https://www.pcisecuritystandards.org/security_standards/documents.php?association=PA-DSS

List of Validated Payment Applications: https://www.pcisecuritystandards.org/approved_companies_providers/vpa_agreement.php

Information on Visa’s Cardholder Information Security Program (CISP): http://usa.visa.com/merchants/risk_management/cisp_overview.html

https://www.pcisecuritystandards.org/security_standards/index.php

https://www.pcisecuritystandards.org/security_standards/documents.php?association=PA-DSS

https://www.pcisecuritystandards.org/approved_companies_providers/vpa_agreement.php

http://usa.visa.com/merchants/risk_management/cisp_overview.html

Siriusware PA-DSS Implementation Guide v.4 · PA-DSS. Salesware must be configured as specified...

Documents

Transcript of Siriusware PA-DSS Implementation Guide v.4 · PA-DSS. Salesware must be configured as specified...