Monsoon Commerce Implementation Guide. Monsoon Commerce Payment Module Version 1.0

Transcription

1 Monsoon Commerce Payment Module Version 1.0

2 Table of Contents Revision history...3 Attribution...3 Introduction...1 What are PCI SSC and PCI DSS?...1 What is PA-DSS certification?...2 PCI compliance and validation...2 About the Monsoon Commerce Payment Module...2 PA-DSS and the Payment Module...3 Considerations for existing Stone Edge Users...8 Identifying database backups and cleansing credit card data...8 Data migration tool The effect of tokenization Best practices All users Third-party integrators Deployment of software Software updates Distribution of hotfixes Prepare the environment Enable SSL 128-bit encryption SQL Server setup requirements Set access policies Disable system restore Protect encryption keys Set up password-protected screensavers Monitoring, auditing, and logging events Product installation Review the system requirements Download the installer Execute the Stone Edge installer Configure the Payment Module Execute a payment transaction Data migration (previous users) Launch and configure Stone Edge Customer Support Overview Connecting to the customer s desktop Using the SDelete utility Audit the secure location of customer data Contact information Technical product information Product name and version Supported operating systems Supported databases Supported hardware Resellers/Integrators Typical customer Scope of PA-DSS assessment Product overview and workflow Page ii

3 Software dependencies Service dependencies Protocols Appendix A Obsolete Parameters Revision history The contents of this guide are reviewed and updated at least once per year. 1.7 November. 25, 2014 Clarify that SQL Authentication is not required for V7.1, PA-DSS. Updated Payment Module installer instructions. 1.6 July 7, 2014 Added installation step of downloading Ghostscript for PDFWriter. Updated Knowledge Base links. 1.5 December 18, 2013 Added information about the $0.01 transaction charged and voided by AuthNet during the customer recording process 1.4 September 4, 2013 Corrected text in Force encryption of database communications 1.3 April 4, 2013 Added the version number to the title page. 1.2 February 11, 2013 Miscellaneous Updates for PCI Compliance 1.1 January, Updates for Cybersource Gateway 1.0 December, Initial publication. Attribution The information regarding Microsoft software has been borrowed heavily from the Implementation Guide for PCI Compliance for Microsoft Dynamics Retail Management System, under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported license. Page iii

4 Introduction Introduction The Monsoon Commerce Payment Module (Payment Module) is a standalone payment processing application provided with Stone Edge Version 7.1 and higher. Its purpose is to help merchants comply with the Data Security Standards (DSS) for Card Holder Data (CHD) security, as set forth by the Payment Card Industry Security Standards Council (PCI-SSC). The Payment Module was designed to meet all of the requirements for Payment Application Data Security Standard (PA-DSS) Version 2.0. This document also includes information about cleansing cardholder data stored by previous versions of Stone Edge, as another milestone on the path to PCI DSS compliance. What are PCI SSC and PCI DSS? In 2006, major financial companies American Express, Discover Financial Services, JCB, MasterCard Worldwide, and Visa International formed the Payment Card Industry Security Standards Council (PCI SSC). The purpose of the council was to create Payment Card Industry Data Security Standards (PCI DSS) to reduce fraud and other threats to cardholder data. The main objectives of the PCI DSS are listed below, along with examples of steps that can be taken by merchants and/or their vendors to meet those objectives: Build and Maintain a Secure Network o Install and maintain a firewall to protect cardholder data o Do not use the vendor-supplied defaults for system passwords or other security parameters Protect Card Holder Data o Secure stored cardholder data o Encrypt the transmission of card holder data across open, public networks Maintain a Vulnerability Management Program o Use and regularly update anti-virus software o Develop and maintain strong systems and applications Implement Strong Access Control Measures o Restrict access to card holder data to need to know basis o Assign a unique ID to each person that has computer access o Restrict physical access to cardholder data Regularly Monitor and Test Networks o Track and monitor all access to network resources and card holder data o Regularly test security systems and processes Maintain an Information Security Policy o Maintain a policy that addresses information security More information can be found at Page 1

5 What is PA-DSS certification? Software development companies that distribute applications which handle or store credit card information must seek Payment Application Data Security Standards (PA-DSS) Certification as proof that the application can be implemented in accordance with the PCI-DSS guidelines. The PCI Security Standards Council itself does not require nor validate an application s compliance with the PA-DSS. PA-DSS certification is obtained through a Payment Application Qualified Security Assessor (PA- QSA). Qualified security assessors (QSA) provide validation of PA-DSS compliance. A list of qualified security assessors verified for payment application review is maintained by the PCI-SSC at: PA-DSS review of the Monsoon Commerce Payment Module for PA-DSS v2.0 certification has been performed by the following PA-QSA(s): Payment Software Company, Inc. (PSC) 591 W. Hamilton Avenue, Suite 200 Campbell, California US Contact Information: Phone: Fax: pscinfo@paysw.com Website: For more information about PA-DSS, visit PCI compliance and validation The PCI Security Standards Council itself does not require nor validate a merchant s compliance with their Data Security Standards. Individual payment processors, such as MasterCard or Visa, may require compliance with PCI DSS, depending on the volume of transactions processed annually. Check with your processor to determine your required level of compliance. QSAs provide validation of PCI Compliance. A list of qualified security assessors is maintained by the PCI at About the Monsoon Commerce Payment Module The Monsoon Commerce Payment Module (Payment Module) was designed using the latest information for secure coding techniques in accordance with PCI-DSS and PA-DSS requirements, and is annually subjected to PA-DSS certification by a Qualified Security Assessor (QSA). Page 2

6 The role of the Payment Module is to handle all aspects of payment processing for Stone Edge V7.1 and higher, regardless of whether the transactions are for ecommerce orders, Point of Sale orders or manually entered orders. When Stone Edge needs to process a credit or debit card transaction, it calls the Payment Module s API which provides the interface for accepting the card data, submitting it to the payment gateway and receiving the gateway s response. The Payment Module then returns the response data (which does not include any card data) and code control back to Stone Edge. The Payment Module is able to process manually keyed or swiped card transactions without the need to permanently store the cardholder s sensitive information. This is accomplished through the process of tokenization whereby the cardholder data is sent to the payment gateway in return for a token that permits the Payment Module to work with existing transactions and execute additional transactions against the customer s account without the presence of the customer s card information. The token is unique to the merchant and is useless to other parties that seek to acquire customer card information for illegitimate purposes. This interaction between the Payment Module and Stone Edge eliminates the need to store PAN (Primary Account Number) data in the Stone Edge store data file (database), thereby removing the Stone Edge application from the scope of PA-DSS certification. Merchants using these applications in tandem take a step closer towards becoming PCI compliant. Be aware, however, that the installation of the Monsoon Commerce Payment Module with Stone Edge V7.1 alone is not sufficient for a merchant to achieve PCI-DSS compliance. Other components of your environment must be reviewed and modified to adhere to PCI DSS, such as hardware, network and operating system configurations. Information about securing these areas is discussed later in this document. PA-DSS and the Payment Module PA-DSS Requirement 1: Card holder information, such as the card security code (CVV2), data from the card s magnetic stripe or any data from PIN entry devices used for Debit Card transactions is not stored in the Payment Module s database, system logs or debug logs. The Payment Module exceeds this requirement by also encrypting these data points while the information is maintained within RAM memory to prevent the information from being accessible should the PC write information from RAM memory to the Windows Swap File on hard drive. PA-DSS Requirement 2: The Payment Module does not store Primary Account Numbers (PAN) in its database or within the system log or debug logs. The PAN is only maintained within RAM memory for the life of the transaction and while in memory this data point is encrypted to prevent access to the information should the PC write information from RAM memory into the Windows Swap File on hard drive. At the completion of a transaction, the first six and last four digits of the PAN are recorded with the transaction information for customer reference purposes. The only location where a user of the Payment Module has access to the full PAN is at the Payment Terminal when hand keying a PAN or swiping a card to process a single transaction. Access to bulk card account numbers is not available to any user of the Payment Module. Page 3

7 Since the full PAN is not stored, the Payment Module does not need to support the encryption mechanisms identified within this requirement, thus, isolating the merchant from all cryptographic key management and data purging activities. PA-DSS Requirement 3: The Payment Module has its own User Security System which is able to track and restrict each employee s level of access to the application and its functions. A unique User ID and Password must be assigned to each employee who requires access to the Payment Module. User passwords are not maintained within the Payment Module s database. Passwords are run through a proprietary hashing algorithm prior to evaluation and storage within the system. The Payment Module requires the use of an Administrators group which is established when the system is initially launched. The first user of the application is prompted to enter a User Name and PCI compliant Password to gain access to the application, and is assumed to be a member of the Administrators group. Additional user accounts (Admin or non-admin) can be added after the initial administrator account is defined. Specific permissions for non-admin accounts can be granted when the account is added, or they can be edited at a later date. A second administrator account, MCTech, is also created when the Payment Module is initially launched and is exclusively for the use of Monsoon Commerce technical support staff. This account is disabled by default and cannot be used by Monsoon Commerce support staff until a local administrator enables it. This account uses a password algorithm that requires a new password daily. The password is generated through the use of a proprietary password application which is only available to Monsoon Commerce technical support staff. The use of this administrator account eliminates the need for the Monsoon Commerce support personnel to acquire the end user s login credentials when testing or debugging the Payment Module. At the completion of support activities, the local administrator is instructed to deactivate the account, preventing any unauthorized access by Monsoon Commerce technical support staff. Payment Module passwords follow PCI DSS guidelines, whereby users must change their passwords periodically (minimum of 30 days to a maximum of 90 days). Reuse of previous passwords is restricted to a minimum of four (default) to a maximum of six previous passwords. Invalid login attempts are also limited to a user-defined number between a minimum of three to a maximum of six (default) before an account is locked out. The lockout period is also defined by the user and can be a minimum of 30 minutes (default) to a maximum of two hours. An administrative account can override the lockout condition by resetting the password for the account. At least two local administrative User IDs should be created in the event an Administrator gets locked out. User account information for Payment Gateway access is also maintained within the Payment Module. Sensitive credentials are stored in an encrypted format when stored in the database. When these credentials are used to process transactions, they are transmitted to the payment gateway utilizing the https protocol, which must employ 128 bit SSL 3.0 encryption standards. Settings to establish this level of security are configured within Internet Explorer or other browser software and are detailed in the Enable SSL 128-bit Encryption section. Note: The use of the Stone Edge security system is still optional, however, its use is highly recommended. PA-DSS Requirement 4: The Payment Module employs an Event logging system which records user and system activity in both the Payment Module s database and in the workstation s Windows Event Log. For details on what information is recorded in the Payment System s log, Page 4

8 see the section, Monitoring, Auditing and Logging. PA-DSS Requirement 5: Monsoon Commerce ensures that all developers who contribute to the production of the Payment Module are trained in the most current secure coding standards and constantly seek to remain abreast of the latest security concerns. Any code changes undergo mandatory code review by trained personnel prior to it being released to our Quality Assurance group. The release code is also tracked through the use of a digital signature to ensure that changes have not occurred throughout the chain of ownership from the initial developer to the end user. The Payment Module is not distributed with any test accounts or data. The creation of the Payment Module s database is scripted at initial startup and does not create testing accounts for use by the end user. End users also must ensure that if they perform any testing of the Payment Module that they do so using test payment gateway accounts and test PANs. The most commonly used test card numbers are listed below, and can be used with any expiration date in the future. Remember that Payment Gateway sandbox (test) accounts should never be considered secure and should never be tested using live account numbers: Visa: (yes, valid card number) MasterCard: Discover: American Express: Should you wish to test other card issuers (JCB, Diner s Club, etc.), contact the issuer directly for test account numbers honored by the banking system. Changes to the Payment Module program code are tracked internally by a ticketing system, and requires a review and signoff by multiple departments to ensure the system is stable and secure prior to being released. New releases of the Payment Module are distributed as a complete replacement of the original product code base. There are no patch installations for code updates. Page 5

9 PA-DSS Requirement 6: It is not recommended to run the Payment Module in an environment that employs a wireless network. Performance will be degraded as the system s database grows. If this recommendation is disregarded, PCI requires that you: o Install a firewall between any wireless networks and systems that store cardholder data and configure the firewall to deny or control the traffic from the wireless portion of the environment into the portion of the network where cardholder data resides. o Use strong encryption for all wireless networks, such as AES. o Use WPA/WPA2 rather than WEP. o Ensure firmware on wireless devices is updated to support strong encryption for authentication as well as for transmission over wireless networks. o Change the default settings on your wireless router or modem. Some examples of settings to change are, encryption keys, default service set identifier (SSID), passwords or passphrases of access points, etc. Change your encryption keys when employees with knowledge of them leave the company. PA-DSS Requirement 7: Monsoon Commerce actively reviews the latest information pertaining to application security vulnerabilities from the following sources: SANS: The SANS Institute s top 25 application vulnerabilities: Microsoft: Banned API calls for the Windows Operating System: OWASP: Open Web Application Security Project s Top 10 web application vulnerabilities: Should vulnerabilities be identified from the above lists or internal requirements that may impact the Payment Module or one of its dependencies, the Monsoon Commerce QA and Development teams create a case ticket to investigate whether the vulnerability affects the security of the Payment Module. Test cases are developed jointly by those groups and are performed by the QA team to determine the Payment Module s susceptibility to the vulnerability. If the vulnerability is confirmed, a new case ticket is issued to the Development team to make corrections to the code. Upon completion of the code modifications, the QA team executes the previous test case to ensure the successful remediation of the vulnerability prior to update release to the public. All program updates are distributed as a complete code replacement for the Payment Module. Patching a portion of the installation is not supported by Monsoon Commerce at this time. Code releases are digitally signed by the development team to ensure code validity throughout the QA process and the installer build. End users can verify the code installer s authenticity via a digital signature applied to the installer prior to public distribution. PA-DSS Requirement 8: The Payment Module does not require special considerations when installing it within a secured network environment. The Payment Module communicates with payment gateways using Port 80 (http protocol) and Port 443 (https protocol) and does not require opening any inbound ports in the firewall. The Payment Module does not require disabling anti-virus applications, however, depending on performance requirements, certain anti-virus vendors may be recommended by Monsoon Page 6

10 Commerce. PA-DSS Requirement 9: The Payment Module and Stone Edge do not require their databases to reside on a Web server or in the DMZ (demilitarized zone) of your local network. Although the Payment Module and Stone Edge do not store sensitive cardholder data, the Payment Module does maintain your gateway access credentials; therefore, every effort should be made to protect these credentials and other customer information such as names, addresses, addresses and phone numbers. It is highly recommended that the applications databases are located behind a firewall on a dedicated database PC or server which has limited user access. PA-DSS Requirement 10: Remote access directly to the Payment Terminal is not supported. Remote access to the client PC on which the Payment Module resides via Terminal Services, GoToMyPC, etc., is not recommended or supported by Monsoon Commerce. Cardholder data transmitted between the client PC and the terminal PC could be subject to interception and is not recommended according to PCI guidelines. If this type of connection is a requirement, then the merchant must take all available precautions to ensure that client to terminal communications are encrypted and that two-factor authentication is used to validate the user. Verify this requirement with your QSA prior to implementation. Remote access to the client PC on which the Payment Module resides may be necessary for Monsoon Commerce technical support for testing or troubleshooting purposes. Monsoon Commerce uses Citrix s GoToAssist application for user support. This application encrypts client/terminal communications and offers two-factor authentication for support personnel validation and requires the merchant to grant access to the support session before the GoToAssist session is initiated. For more information regarding GoToAssist go to PA-DSS Requirement 11: The Payment Module does transmit cardholder data over public networks and/or the Internet; therefore, it is required that you implement 128-bit SSL (Secure Socket Layer) encryption between the client PC and the credit card gateway. Settings regarding Internet communications are configured within Microsoft s Internet Explorer or other browser application. More information is available in the Enable SSL 128-bit Encryption section of this document. Encrypted communications require outgoing access to Port 443 (https protocol). The Payment Module does not allow users to view or send full cardholder data via or other messaging technologies. The Payment Module does retain the first six and last four digits of the Primary Account Number (PAN) and the card expiry date for customer service account identification purposes; however the central 3-6 digits of the PAN are unavailable. PA-DSS Requirement 12: The Payment Module does not support Web-based or remote administration, including non-console administrative access. If you plan to use these methods, review them with your QSA prior to implementation. PA-DSS Requirement 13: Monsoon Commerce provides this Implementation Guide as well as an online Knowledge Base for users to review prior to installing the Payment Module. Documentation is reviewed for each application release, or annually at a minimum, to ensure Page 7

11 the content is relevant to the current application release and PA-DSS/PCI-DSS requirements. Monsoon Commerce does not employ resellers or integrators, therefore training documentation for third party vendors is not provided. Considerations for existing Stone Edge Users Identifying database backups and cleansing credit card data Older versions of Stone Edge stored card holder information in the store data file (database). While Stone Edge, V7.1 and higher, provides a utility for cleansing cardholder data from the production database, you must not overlook the cardholder data stored in any archive, backup, or road trip data files. Be sure to cleanse or delete those files that may be stored offsite as well as onsite. Cleansing or complete removal of this data is absolutely necessary for PCI DSS compliance. By default, backups of MS Access store data files created by Stone Edge are located in the folder specified by the Order group system parameter ArchiveLocation. If you are using an SQL database, consult SQL Server Management Studio settings to determine the location of database backups (.bak files), as Stone Edge does not make backups of SQL databases. 1. Create a list of affected files and decide whether to cleanse the cardholder information from these files, or forensically delete the files from your hard drive, in accordance with PCI DSS requirements. Depending on the version of Stone Edge, the naming convention of backup files differs slightly: Stone Edge Version 7.0+ uses the format: StoneEdgeDataBUYYYYMMDD Stone Edge Versions 5.9 and lower use the format: OrderManagerDataBUYYYYMMDD 2. For files to be deleted, be sure to use an application that securely removes the file contents from your hard drive. An example of a secure delete application is the free Microsoft SysInternals Suite (sdelete function), which overwrites the data on the physical disk drive. More information can be found at the following URL. a. Copy the file sdelete.exe to the C:\Windows\System32 folder on your computer. b. Open a command prompt. c. To delete a single file, type: sdelete p # \\fileserver\foldername\filename For example, to securely delete a file called Store A Orders.mdb that resides on a server named Server1, in a folder named CustomerData, you would type: sdelete p 7 \\Server1\CustomerData\ Store A Orders.mdb Page 8

12 The p # switch indicates the number of times the physical location of the data is overwritten. In this example, the program makes seven passes. The file extension must be included as part of the filename. File names with spaces must be surrounded by quotation marks. Those who prefer a graphical user interface rather than a command prompt can use an application called Eraser. It can be downloaded, installed and configured in a matter of minutes from the following URL: 3. For production or backup database files to be retained (SQL or Access), a data migration tool is provided when the application is installed. You must manually run the tool against these database files to ensure PCI compliance. See Data Migration in the Product Installation section for more information. 4. Historical paper documents such as invoices or reports may also contain sensitive cardholder data, such as PAN. These documents must be maintained in a secure location or they should be destroyed in an appropriate manner, such as cross-cut shredding. 5. Order information from shopping carts which pass cardholder data to Stone Edge must be checked for residual order files that may contain unencrypted cardholder data. a. File locations specified by the Order group system parameters NewOrderLocation or ArchiveLocation may contain substantial amounts of payment information. Forensically remove these files with a secure file deletion utility like Eraser or sdelete. b. Also review the Security group system parameter DeleteDownloadTextFiles. If this parameter is set to TRUE, Stone Edge deletes the files it downloads from the shopping cart. The deletion is performed by the Windows operating system installed on the given PC, which does not actually remove the file contents from the hard drive; it only removes the filename from the drive s indexing system. The contents of the file remain on the drive until the operating system writes new data to that location, making it possible to retrieve the file contents using drive recovery software. Setting parameter DeleteDownloadTextFiles to FALSE makes it easier to locate and remove files that contain unsecured payment information. To ensure remnants of order files previously deleted by Stone Edge are removed from the hard drive, use the freeware application Eraser to overwrite data in unused disk space. You are able to schedule a task to automatically perform this function on an ongoing basis. 6. Users of the CyberSource payment gateway who installed a version of the Simple Order API Client for ASP having a version earlier than v5.0.0 may have a CyberSource log file on the root of the c:\ drive of their computer which will likely contain card account numbers. The file is named cybs.log and is a hidden file. This file must be forensically removed from each PC where CyberSource payments have been processed. Should an earlier release of the Simple Order API Client for ASP be installed, the user must uninstall the earlier release, then download and install the latest release of the API from CyberSource s website. As of this publication, the most current release is v5.0.0 and can be found under the Developer Download section of the CyberSource website. This release can generate log files depending on the Payment Account Setting UseLog, however, the logs created now show only the first six and last four digits of the card account number. Page 9

13 Data migration tool The migration tool populates the new Payment Module database with active transactional data currently stored in the selected Stone Edge database after cleansing the Primary Account Number (PAN) from all locations in the Stone Edge database. The cleansing process retains the first six and last four digits of the PAN, X filled to the original card length, which is permissible according to PA-DSS requirement 2.2. The Payment Module itself does not store the full PAN for any transactions it receives during the data migration process; however, if the user employs a gateway that supports a customer information management system, the Payment Module can attempt to record the customer s card information at the gateway and retrieve a token to be used for future transactions against the customer s account. Once the cleansing of the Stone Edge database and data migration to the Payment Modules database is complete, Stone Edge is able to process credit and debit transactions through the Payment Module. See Data Migration in the Product Installation section for more information. The data migration tool must be run to remove any magnetic stripe data, card verification codes, PINs, or PIN blocks stored by previous versions of the Stone Edge application. Removal of this data is absolutely necessary for PCI DSS compliance. When the Switch Stores feature attaches the program to an un-cleansed database, the user is notified the database is not PCI compliant. At that time, you must run the Data Migration Tool against that database before credit or debit payment transactions can be performed through the Payment Module. If you have manually stored cardholder data in the Notes or any other text field in the Stone Edge database, you are not PCI compliant. The data migration tool only cleanses locations where the program stores PAN data. Therefore, you are responsible for removing or cleansing the PAN from any other fields. The effect of tokenization A merchant s ability to run new credit card transactions may be limited by the specific credit card processors and/or shopping cart systems they utilize with the Payment Module and Stone Edge. Merchants must ensure that the gateways offering a Customer Management System are also supported by their shopping cart. If a shopping cart does not support the customer management capability of the gateway and the gateway does not support the use of previous transaction identifiers for new payments, then the tokenization feature will NOT be available to the merchant. If this is the case, the merchant is limited to the use of an existing transaction generated by the shopping cart. Payment capture and credit is available for existing transactions; however, new transactions require the merchant to contact the cardholder to obtain their credit card information. The Payment Module also supports the concept of multiple captures against a single authorization, provided the payment gateway supports this feature. Payment Gateways currently supported by the Payment Module: AuthorizeNet AIM Does NOT support tokenization AuthorizeNet CIM Supports tokenization through a Customer Management System Page 10

14 CyberSource Supports tokenization through a Customer Management System USAePay CGI Does NOT support tokenization USAePay XML API Supports tokenization through a Customer Management System and through the use of previous transaction identifiers Additional Payment Gateways may become available in subsequent releases of the Payment Module, depending upon user demand, PCI compliance and shopping cart support. Best practices All users This section contains some best practices that help the merchant move towards compliance with the PCI Data Security Standard (PCI DSS). To be sure that you are fully compliant, read and implement all of the requirements outlined at 1. Prohibit the use of default administrative accounts. a. The Payment Module does not provide a default user account at initial startup the initial administrator account must be created prior to using the application. b. SQL Express or SQL Server, when using mixed authentication, includes the sa or System Administrator account. This account must be disabled to maintain PCI compliance. For information on disabling the sa account see the section Manage SQL Server without using the sa account, in this document, or 2. Prevent the use of group, shared, and generic accounts in SQL Server/SQL Express. See PCI DSS Requirement for a procedure to identify this activity. 3. Limit access to any PC, servers and databases where payment applications or cardholder data resides by using unique User IDs and using secure authentication methods whenever possible. 4. Control access to the Payment Module, SQL Server/SQL Express, and Stone Edge by assigning unique User IDs to all employees that use those applications as part of their job requirements. Do not use the same password for your Stone Edge User ID as you do for your Payment Module User ID. 5. Review event logs periodically for unauthorized access or other suspicious activities. 6. Remote access is not recommended for the Payment Module or Stone Edge. a. If you still choose to use remote access, you must use two-factor authentication (User ID with a password or other authentication item, such as a smart card, token or PIN) to be PCI compliant. Utilities such as GoToMyPC are not recommended as they do not utilize two-factor authentication. Be sure to change the default settings in the remote access software, such as a default password. b. Only allow access from known (specific) IP or MAC addresses. c. Use strong authentication and complex passwords for logins, according to PCI DSS Requirements 8.1, 8.3, and d. Enable encrypted data transmission. PCI DSS Requirement 4.1 e. Configure the remote access software so that the user must establish a VPN (Virtual Private Network) connection through a firewall before access is allowed. Page 11

15 7. Turn on the logging features. a. The Payment Module s internal logging system is on at all times and cannot be disabled. b. Activate the Windows Event Log and activate SQL Server/SQL Express Logging. 8. Restrict authorized integrators/contractors access to merchant passwords. 9. Establish merchant passwords according to PCI DSS Requirements 8.1, 8.2, 8.4, and 8.5. The Payment Module requires that passwords meet the defined requirements in PA-DSS V Be sure to keep up with the latest security updates for your operating system and components, especially your browser software. 11. If you purchase a Stone Edge generic shopping cart license, you must ensure your integration script does not send cardholder data to Stone Edge in order downloads from the shopping cart in order to be PCI compliant. 12. Stone Edge only supports integrations with shopping cart systems that cleanse the Primary Account Number (PAN) and/or supports the use of tokens instead of cardholder data in order to process payment transactions. In other words, Stone Edge and the Payment Module do not need the PAN to process a transaction. a. If your shopping cart provides the option to send credit card data in the order download, you must disable that option at the shopping cart to be PCI compliant. b. If the Shopping Cart provides the PAN in the order download without providing the user with a way to disable it, Stone Edge imports the order information, but not the PAN, into its database. However, order files containing the unencrypted PAN may remain on your computer s hard drive. To remain PCI compliant, these files must be forensically removed after order import. Refer to the Identifying database backups and cleansing credit card section of this document for suggested tools. 13. Collect sensitive authentication data only when absolutely necessary to solve a specific problem. 14. Collect only the limited amount of data needed to solve a specific problem. 15. Store such data only in specific, known locations with limited access. 16. Encrypt sensitive data while it is stored on your network. 17. Sensitive data must be securely deleted immediately after use. Failure to implement the security steps outlined in this section means your system does not comply with PCI DSS requirements. Third-party integrators Third-parties that develop and troubleshoot custom code or provide installation services on the behalf of others should also adhere to the following best practices for PCI Compliance: Collect only the minimum amount of data required to resolve a specific problem Sensitive authentication data should only be collected when absolutely necessary to resolve a specific problem Sensitive data should be stored in a specific, known location to which access is limited to those individuals that are working to resolve the problem Sensitive data must be encrypted while it is stored Sensitive data must be forensically deleted immediately after the problem is resolved Page 12

16 Deployment of software Software updates Updates to the software are distributed via an Installer that replaces the entire set of application libraries. To obtain a copy of the new release of the application, the customer must login to a secure website and download the installer. ( Payment Module installer files are digitally signed by Monsoon Commerce and indicate the publisher at the time of installation. If the installer file does not identify the publisher as Monsoon Commerce, discontinue the installation and contact Monsoon Commerce support. (stoneedgesupport@monsooncommerce.com) The Implementation Guide (this document) is reviewed and updated as necessary when a new release of the software is distributed. It is included in the Documentation subfolder of the program installation folder and is also available in the online Knowledge Base. Distribution of hotfixes Hotfixes are not distributed. Prepare the environment Enable SSL 128-bit encryption All payment gateways require communications via the Internet to take place using the HTTS protocol employing Secure Socket Layer (SSL) 128 bit encryption to protect the communications between the merchant s PC and the credit card processor s server. This is configured through Internet Explorer settings. 1. Launch Internet Explorer. 2. Go to Tools > Internet Options > Advanced. 3. Select the check box Use SSL 3.0 in the list of Settings. 4. Click Apply. 5. Click OK. SQL Server setup requirements This section discusses the SQL Server 2005 R2, SQL Server 2008 R2 and SQL Server 2012 setup steps required for PCI compliance. You can obtain information regarding hardening SQL Server/Express for PCI Compliance through the following article: The Payment Module uses SQL Server or SQL Express for its back end database. You may use an existing instance of SQL Server/SQL Express in which to create and maintain that database, or you can create a new instance of SQL specifically for the Payment Module. To comply with PA-DSS/PCI DSS, complete all of the following procedures on the computer where the SQL Server software is installed. Be sure to confirm all settings match those shown below. Page 13

17 Select the service account 1. In SQL Server Configuration Manager, click SQL Server Services. 2. Right-click the correct instance and then select Properties. 3. In the Built-in account box, select Network Service, and then click OK. Switch to mixed-mode server authentication 1. In SQL Server Management Studio, open the Object Explorer, right-click the instance, and then select Properties. 2. On the Security page, under Server authentication, select SQL Server and Windows Authentication mode, and the click OK. This does not mean that the databases for Stone Edge and the Payment Module are required to use SQL Authentication. In fact, it is recommended to use Windows authentication unless there is a valid business reason to do otherwise. This step merely allows the business owner the option of using SQL Authentication. Manage SQL Server without using the sa account Completing this section helps to satisfy Requirement 2 of the PCI Security Standard. 1. Open SQL Server Management Studio Object Explorer, and then expand the folder of the correct instance. 2. Set up a new administrator account: a. Right-click the Security folder, point to New, and click Login. b. On the General page, type a unique login name, select SQL Server authentication, and provide a strong password. c. On the Server Roles tab, select sysadmin, and then click OK. 3. Disable the sa account by expanding the Security folder, expanding the Logins folder, and then completing these steps: a. Right-click the account name, and then click Properties. b. Click the Status page, select Disabled, and then click OK. OR c. Run the sp_setautosapasswordanddisable procedure within SQL Server Mgmt Studio. As the name suggests, this procedure will set a random value for the sa account password then disables the account. It is recommended to re-run this procedure at regular intervals to prevent attempts to reactivate the account. Force encryption of database communications. 1. In SQL Server Configuration Manager, expand SQL Server Network Configuration. 2. Right-click the protocols for the Payment Module instance, and then click Properties. 3. On the Flags tab, select Yes for the Force Encryption option, and then click OK. When the Force Encryption option for the database engine is set to Yes, all client/server communication is encrypted and clients that cannot support encryption are denied access. Restart the SQL Server and put the changes into effect 1. In SQL Server Configuration Manager, click SQL Server Services. 2. Right-click SQL Server (<instance name>), and then click Restart. Page 14

18 Set access policies Set policies to manage access to workstations, the Payment Module, and Stone Edge. Complete steps 1-4 on each computer where those applications are installed. Step 5 is a global function of the Payment Module that only needs to be done once on a single workstation. 1. Disable the local Administrator account 2. Set up a password policy for Windows 3. Setup a domain password policy 4. Setup a local password policy 5. Setup a password policy for the Payment Module. Disable the local Administrator account This account is disabled by default in Windows 7. Setup a password policy for Windows users Requirements through specify password and account security regulations for people with administrative access to the payment application. You can meet these requirements by establishing a password policy for Windows users. Policy settings that meet the requirements are set out in the following table. The policies in the table reflect the minimal requirements for PCI compliance. More stringent settings can be used. Policy Enforce password history Maximum password age Minimum password length Password must meet complexity requirements Account lockout duration Account lockout threshold Security setting 4 passwords remembered 90 days 7 characters Enabled 30 minutes 6 invalid logon attempts Periodically check PCI Data Security Standards for any changes to the latest password requirements. Setup a domain password policy If you are running the Payment Module on a domain, contact the domain administrator to establish group policies for the domain. For more information about managing password policy via group policies, see Working with Group Policy objects at Setup a local password policy If you are running the Payment Module in a workgroup, you must complete the following procedure on each computer in the network. 1. Click Start, and then click Control Panel. Page 15

19 2. View the full list of Control Panel items. Depending on your operating system, do this either by switching to Classic View or by clicking Small icons in the View by box. 3. Click or double-click Administrative Tools, and then double-click Local Security Policy. 4. Expand the Account Policies folder, and then change the settings under Password Policy and Account Lockout Policy as needed to meet the requirements in the table above. Set up a password policy for employees that use the Payment Module The default User ID and password settings in the Payment Module meet the PCI minimum standards, but you can change them to be more stringent by going to Main Menu > Settings. It is not possible to change the length of the password or the complexity requirements. Refer to the online Knowledge Base for Version 7.1 for more details. Policy Default setting Minimum password length 8 characters Password must meet complexity requirements Must contain at least one character from each of the following categories: upper case, lower case, number, and special etc.) Session Timeout (inactivity before logout) 15 minutes Max Login Attempts (failed) 6 Lockout Duration (amount of time to wait after 30 minutes failed login attempt) Password Duration (expiration) 90 days Password Reuse (number of previous passwords 4 to track)) The count of failed login attempts is reset on successful login. Password age is calculated from the date when the password was last changed. Disable system restore System Restore is a Windows feature that helps you restore the files on your computer to an earlier point time. The restore points saved by this feature are not considered secure by the PCI SSC. For Windows 7 1. On the Start menu, right-click Computer, and then select Properties. 2. Click System protection. 3. Select the C: drive, click Configure, select Turn off system protection, and then click OK. Protect encryption keys Monsoon Commerce Payment Module does not store PAN data and therefore does not use encryption keys to secure it, making the protection of encryption keys out of scope for PCI compliance. Page 16

20 Set up password-protected screensavers At each register (workstation), change the settings so that a screensaver comes on when the register has been inactive for a maximum of fifteen minutes (900 seconds), or less. The screensaver should require the employee to enter their Windows password to unlock the screen. In the C:\Windows\System32 folder, locate the name of the screen saver (.scr) file that you want to use. For Windows 7 1. Click Start, type mmc into the search box, and press Enter. 2. On the File menu, click Add/Remove Snap-in and then, if you are running Windows XP, click Add. 3. Select group Policy Object Editor, click Add, click Finish, and then click Close or OK. 4. Expand Local Computer Policy, expand User Configuration, expand Administrative Templates, expand Control Panel, and then click Personalization (in Windows 7) or Display (in other operating systems). 5. Double-click Force specific screen saver (in Windows 7) or Screen executable name (in other operating systems), select Enabled, type the path and name for the screen saver (.scr) file that you selected in step 1, and then click OK. 6. Double-click Password protect the screen saver, select Enabled, and then click OK. 7. Double-click Screen Saver timeout, select Enabled, type 900 or less, and then click OK. Completing this procedure on each computer helps to satisfy Requirement of the PCI DSS. The Payment Module The Payment Module has a user definable automatic logout feature that has a minimum of five minutes to a maximum of fifteen minutes. Should the workstation be idle for the given period, the user is logged out of the Payment Module (but not Stone Edge) and is required to log back in the next time a transaction is executed. Monitoring, auditing, and logging events Failure to enable the tools used to produce an audit trail of all activity related to sensitive data results in noncompliance with PCI DSS. Most of the items discussed in this section pertain to Requirement 10 of the PCI DSS. The Payment Module logs activity in its own database and in the Windows Event Log. For the Windows Event Log to be populated with the Payment Module s activities, the Windows Event Log must be enabled on each PC running the Payment Module. You can centralize the collection of Windows Event Log information on a single server for your convenience by using a tool such as Snare, or by reviewing the directions in this article. Enable windows event logging The following steps help you to comply with PCI DSS Requirements 10.2 and 10.3, and should be performed on all computers. For Windows 7 Page 17

21 1. Click Start, type Event Viewer into the search box, and press Enter. 2. Expand the Windows Log s folder. 3. Right-click Security and select Properties. 4. In the Maximum log size box, type Select Overwrite events as needed, and then click OK. Configure the auditing of files, objects and audit-policy changes Changes to each computer s audit policy can be recorded by implementing the following procedures on all computers. If your computers are on a domain, be sure to check with the Domain Administrator to ensure that local audit policies are not overwritten by domain policies. For Windows 7 1. Click Start, type Local Security Policy into the search box, and press Enter. 2. Double-click Audit account logon events and select both the Success and Failure check boxes. 3. Click OK. 4. Double-click Audit account logon events and select both the Success and Failure check boxes. 5. Click OK. 6. Double-click Audit object access and select both the Success and Failure check boxes. 7. Click OK. 8. Double-click Audit policy change and select both the Success and Failure check boxes. 9. Click OK. Enable audit access to system files and folders Depending on the operating system, different system file and folders need to be audited. Although the Payment Module and Stone Edge do not store any sensitive cardholder data, if you want to audit changes made to system files and folders, follow the procedure below for each file or folder in the list for your operating system. 1. In Windows Explorer, right-click the folder name, and then click Properties. 2. On the Security tab, select Advanced. (If Advanced is not visible, click Folder Options on the Tools menu. Click the View tab and clear the Use simple file sharing check box.) 3. Click the Auditing tab. (If a security message appears, click Continue.) 4. Click Add. 5. In the Enter the object name to select box, type Everyone, and the click Check Names. 6. If the name is valid, click OK. 7. In the Apply onto box, make sure that This folder, subfolders and files is selected. 8. In the Access list, select both the Successful and Failed check boxes for the following privileges, and then click OK. Create files/write data Create folders/append data Delete subfolders and files Delete Read Permissions Change permissions Page 18