Overview

The Payment Card Industry Security Standards Council (PCI SSC), the association of card payment brands such as VISA and MasterCard, issue the cardholder data security standards used by the credit card payment industry. ChargeLogic Payments has been validated under several versions of the PA-DSS standard, the security standard for software payment applications. The PCI SSC is issuing a new software standard, the PCI Secure Software Standard, in 2019. As part of the security standards, software vendors must provide guidance, not only on the setup of their software, but on environmental security and dependencies, even if those are the responsibility and in the control of the merchant. Besides the ChargeLogic Payments specific secure implementation described here [LINK], there are other aspects that a merchant should consider into account during an implementation of payment software, as described below. 

Administrative Accounts 

Administrative accounts should be assigned a strong password and disabled or not used. In addition, strong passwords should be used wherever possible, both in the application and in other systems or applications.  

Access Control 

Customers and resellers/integrators are strongly advised to control access, via unique user ID and PCI DSS-compliant secure authentication, to any PCs, servers, and databases with payment applications and cardholder data.  

Password Policies 

Passwords should be protected from unauthorized use. All users should be able to be identified with a unique username before they can access system components or cardholder data. In addition to a unique username, a password, token device, or biometric device must be used for authentication. All passwords should be encrypted during transmission and storage on all system components. Control the addition, deletion, and modification of user IDs, credentials, and other identifier objects. Verify user identities before performing password resets. First-time passwords should be unique per user and should be changed immediately after the first use. Access for terminated users should be revoked immediately. Inactive user accounts should be removed at least every 90 days. Accounts used by vendors for remote maintenance should be enabled only when needed. Passwords policies should be distributed to all users who have access to cardholder information. Do not use group, shared, or generic accounts/passwords.  Passwords should be at least 8 characters in length and contain both numeric and alphabetic characters. When resetting passwords, the previous four passwords should not be used. Accounts should be locked for at least 30 minutes or disabled after at most six failed authentication attempts. After at most 15 minutes of inactivity, users should be required to authenticate. 

Activity Logging 

Logs should not be disabled and doing so will result in non-compliance with PCI DSS. 

Change Log 

The Change Log should be set up to track changes to tables containing cardholder data. Specifically, all access to the EFT Transaction table and the Customer Credit Card table should be logged. 

System Log 

Individual user access to cardholder data, all actions taken by administrative users, access to audit trails, invalid logical access attempts, use of identification and authentication methods, initialization of all audit logs, and creation and deletion of system-level objects should be logged for all system components. The log should include the user identifier, the type of event, the date, the time, an indication of success or failure, the origin of the event, and the identity of the affected data, system component, or resource. 

The Event Viewer is the Windows-provided auditing solution; its use satisfies requirements of PA-DSS compliance. See the instructions to set up Event Viewer on Business Central: https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/monitor-server-events-windows-event-log  

Debugging Logs 

If debugging logs are ever enabled, for troubleshooting or otherwise, and these logs include the Protected Account Number (PAN), these logs must be protected and disabled as soon as the troubleshooting/business purpose is completed. 

Build and Maintain a Secure Network 

There are specific requirements that must be in place to satisfy PCI Compliance regulations.  

• A firewall is required between any wireless networks and the cardholder data environment. 

• The firewall must be configured to deny or control any traffic from the wireless environment into the cardholder data environment. 

• Wireless networks, transmitting cardholder data or connected to the cardholder environment, must use industry best practices to implement strong encryption for authentication and transmission. WEP (Wired Equivalent Privacy) is now prohibited. 

• For wireless environments connected to the cardholder data environment or transmitting cardholder data, the following changes to wireless vendor defaults must be implemented: 

• Change encryption keys from their default settings at installation and any time anyone with knowledge of the keys leaves the company or changes position. 

• Change default SNMP community strings. 

• Change default passwords/pass phrases. 

• Update firmware on wireless devices. 

• Support strong encryption for authentication and transmission over wireless networks. 

• Change all other security related wireless vendor defaults. 

Personal Firewalls 

A personal firewall should be installed on any mobile and/or employee-owned computers with direct connectivity to the Internet that are used to access the organization’s network. 

Security

Two-factor authentication must be used to access the application remotely. Access should be restricted to authorized personnel. All security features of the remote access software should be implemented. This includes, but is not limited to, requiring TLS authentication for RDP connections. Secure web-based services such as GoToMeeting may be used for remote access, with voice authentication serving as the second factor. 

Administrative Access 

An SSH or SSL/TLS encrypted connection should be used when performing non-console administration. 

Data Transmission over Public Networks 

Strong encryption should be used when transmitting cardholder data. 

Support Requirements for Solution Centers 

Only collect sensitive authentication data (SAD), including magnetic stripe data, PIN and encrypted PIN block, and card validation values or codes, when needed to solve a specific problem. Any storage of such data would be at the direction of the merchant through customization for diagnostic purposes; however, ChargeLogic does not include the capability to store this data. Any SAD that is collected must be encrypted utilizing strong cryptography and stored in specific, known locations with limited access. Only collect the limited amount of data necessary to solve a specific problem. Securely delete the data immediately after use.