LexisNexis Credit Card Processing Implementation Guidance

 Lexis® Credit Card Processing
Version 1.05
Credit Card Security Standards
Implementation Guidance
Company Confidential.
Copyright © 2013 LexisNexis.
All rights reserved.
Table of Contents
Introduction
3
Version Methodology
3
Implementation Guide Revision History
3
Application Summary and Information
4
About Credit Card Security
4
Our Responsibility
4
PCI Compliance – What Is It
5
Merchant Risk and Liability
5
Requirements of the PCI-DSS
5
LCCP Features and the PCLaw Interface
6
Network Configuration Overview
7
Environmental Considerations
8
Basic Workstation and Environment
8
Access Control
8
Remote Access Control
10
Wireless Access Control
11
Logging
12
Security of Transmitted Data
12
Storage
13
Office Policies and Procedures
13
Company Confidential.
Copyright © 2013 LexisNexis.
All rights reserved.
2 of 14
Introduction
In response to the requirements to protect cardholder data as set and maintained by the Payment Card Industry Security Standards Council (PCI SSC), LexisNexis® Practice Management provides you with version 1.06 of the Lexis® Credit Card Processing (LCCP) application. This version has been Payment Application Data Security Standard (PA-DSS) certified by the following PCI SSC approved Payment Application Qualified Security Assessor (PA-QSA):
Coalfire Systems, Inc.
150 Nickerson Street, Suite 106
Seattle, WA 98109
The purpose of this document is to demonstrate to our PA-QSA how Lexis Credit Card Processing implements the requirements of the PA-DSS.
Version Methodology
LexisNexis employs a version methodology with the following format: “ Major.MinorRevisionHotfix.”
Once a release has been made public, the version number is rolled in preparation for the next release. The format for version numbers used is “Major.MinorRevisionHotfix. The Major, Minor, and Revision fields are numbers, and the Hotfix field is a letter (e.g., 1.05a). Feature changes are reflected in either a major or minor version depending on the scope. Together, this is the version marketed; in the above example, 1.0 is the market version. Planned fixes are reflected in the Revision field. For a new release the Revision is 0. Unplanned/hotfixes are reflected in the Hotfix field (i.e., indicated by an "a"). All fixes are cumulative, meaning that a newer fix always contains the previous changes. The program displays the full version to allow users to verify that the latest fixes have been applied.
Note
Revision and Hotfixes will not affect PCI Compliance: Changes that affect PCI Compliance will be done at Major.Minor version.
The Minor version is usually incremented in steps of “.01,” however, if the release has some semi-major enhancements, the Minor version may skip to the next full point (“.1”).
Changes at the Major level may or may not impact PA-DSS requirements. Changes at the Minor or Revision level would only be very minor changes or defect fixes, and would never impact PA-DSS requirements.
Implementation Guide Revision History
Version
Revision
Date
Description
1.03
1st Edition
March 20, 2009
Completed Implementation Guide per PA-DSS requirements
1.04
2nd Edition
July 01, 2010
Completed annual review ; no changes
1.04
3rd Edition
June 03, 2011
Completed annual review ; no changes
1.05
4th Edition
July 16, 2012
Clarification of the versioning methodology
1.05
5th Edition
July 19, 2013
Completed annual review ; documentation update per PADSS requirements
Company Confidential.
Copyright © 2013 LexisNexis.
All rights reserved.
3 of 14
Application Summary and Information
For detailed procedures on these and other PCLaw features, consult the program help files.
Name of Application
Lexis Credit Card Processing (LCCP)
Credit Card Server
PayPros® (formerly known as PPI) - hosted
Back Office / Host Application
PCLaw or other trusted application
Setup Process
Installation Wizard bundled with host application
Operating System Support
Windows XP, Windows Vista, Windows 7, Windows 8
About Credit Card Security
Payment Card Industry Security Standards Council (PCI SSC) was formed to align and standardize security requirements and audit procedures, as well as processes. The council is currently made up of members from the following payment brands:
• American Express
• Discover Financial Services
• JCB International
• MasterCard Worldwide
• Visa, Inc.
The role of the organization is to maintain regulated PCI standards, including the PA-DSS and the Payment Card Industry Data Security Standard (PCI-DSS). PCI-DSS was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. With the introduction of the PCI-DSS, all merchants, vendors, and service providers are required to, among other things, have appropriate security policies and procedures in place.
PCI compliance is achieved by adhering to a set of strict security requirements published in PCI-DSS which is focused on storing, processing, and/or transmitting cardholder data in a secure manner.
Merchants are responsible for ensuring security standards are followed in a PCI-compliant network environment as prescribed by the PCI-DSS; software vendors are responsible for providing software to merchants that follow the guidelines provided in the PA-DSS.
Our Responsibility
LexisNexis Practice Management values their customers and wants to offer the highest quality software. The Lexis Credit Card Processing application was designed with the PA-DSS and PCI-DSS in perspective. Our goal is to provide you with the value of a PA-DSS certified application in which to process your credit card payments.
However, PCI Compliance is obtained by you, the merchant, and is based on your hosting environment, inclusive of all software or hardware components accessed or otherwise used in the transfer, storage, processing of credit card data. We have taken great steps to ensure our Lexis® Credit Card Processing application facilitates the PCI compliance process, not hinders it.
Company Confidential.
Copyright © 2013 LexisNexis.
All rights reserved.
4 of 14
PCI Compliance – What Is It
All businesses which transmit, store, process, or otherwise handle credit card data must do so in a secure environment to ensure the highest standard of precautions. The Payment Card Industry Data Security Standards (PCI-DSS) outlines the requirements for PCI compliance.
As a software vendor, we are required to follow the guidelines provided by the Payment Application Data Security Standards (PA-DSS); providing businesses (merchants) with a secure application in which to handle credit card payments. As a merchant, you are required to follow the guidelines as prescribed in the PCI-DSS.
It is critical that you follow the guidelines provided in this document and review the PCI-DSS for the latest changes to achieve and maintain PCI-compliance, thereby safeguarding sensitive cardholder data from hackers and potential fraud.
Merchant Risk and Liability
Fines and fees are associated with non-compliance which may also result in termination of your merchant services by the each credit card provider. Therefore, for overall validation of your compliance effort, you should consult individual credit card providers and/or a qualified security assessor.
Requirements of the PCI-DSS
When you elect to accept payment by credit card, you must consider the following high-level requirements excerpted from the PCI-DSS:
Build and Maintain a Secure
Network
Requirement 1: Install and maintain a firewall configuration to protect data. Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters. Requirement 3: Protect stored data. Protect Cardholder Data
Requirement 4: Encrypt transmission of cardholder data and sensitive information across public networks. Maintain a Vulnerability
Management Program
Requirement 5: Use and regularly update anti-virus software. Requirement 6: Develop and maintain secure systems and applications. Requirement 7: Restrict access to data by business need-to-know. Implement Strong Access
Control Measures
Requirement 8: Assign a unique ID to each person with computer access. Requirement 9: Restrict physical access to cardholder data. Regularly Monitor and Test
Networks
Maintain an Information
Security Policy
Requirement 10: Track and monitor all access to network. Requirement 11: Regularly test security systems and processes. Requirement 12: Maintain a policy that addresses information security.
Company Confidential.
Copyright © 2013 LexisNexis.
All rights reserved.
5 of 14
LCCP Features and the PCLaw Interface
Lexis Credit Card Processing (LCCP) allows merchants to receive payments in PCLaw® (or other host application) from clients and/or customers using their credit card. Using a fast and secure process, you can use a card reader for automatic authorization or, if necessary, enter card details manually.
PCLaw is used as a host application to interface with LCCP. For example, merchant account configuration is maintained by LCCP but is accessed using a PCLaw feature. Credit card payments can be received using the PCLaw Receive Payment, Trust Receipt, Firm Receipt, General Retainer, and Quick Bill features.
Although LCCP is capable of processing a request to modify a transaction, PCLaw has been configured to not allow modifications to existing credit card transactions. You may only create a credit card payment entry (using a receipt feature) or void an already processed transaction.
The Credit Card Listing is a report provided by LCCP to display details for every transaction entered in the host application. This feature allows you to monitor all credit card transactions that have been processed. It is made available from the Report menu in PCLaw.
The Merchant Account Service Center provides a portal to view batch information to perform reconciliation procedures. PCLaw has no knowledge of credit card data. No data is stored. You are advised to avoid storing any cardholder data in PCLaw.
For detailed step-by-step procedures on these and other PCLaw features, consult the PCLaw help files and/or training documentation.
Company Confidential.
Copyright © 2013 LexisNexis.
All rights reserved.
6 of 14
Network Configuration Overview
Company Confidential.
Copyright © 2013 LexisNexis.
All rights reserved.
7 of 14
Environmental Considerations
Basic Workstation and Environment
You should maintain the latest vendor-supplied updates for all software and operating systems. Systems and applications should include Windows, LCCP, firewall, as well as but not limited to anti-virus. Critical updates must be applied within 30 days of release.
You should install and use anti-virus software and maintain updates regularly. Do not exclude directories or file extensions for any scans.
To help reduce the environmental security breaches, as well as the impact of the PCI-DSS review process to your business, network segmentation is recommended.
Segments are security domains that can be sectioned with the use of firewalls, VPN, etc. You may also want to configure a dedicated and independent internet connection for the specific workstation processing and transmitting cardholder data
To segment your network, implement firewalls, VPN, etc. between LCCP workstations and/or other payment applications and databases. Workstations beyond the inner firewall should be configured as “untrusted”.
Maintain updates to both software and hardware components of your firewall. Actively restrict ports and supervise activity on a regular basis. Refer to the section on Auditing and Logging for further information.
Segregate individual workstations from your entire network to reduce risk of possible exploits. You should configure network devices, operating systems, applications, including firewalls and routers, etc. should be reconfigured to use non-default device names, ports, SSID, network keys, as well as username and password combinations. LCCP recommends you avoid the use of laptops to install LCCP or synchronize with an LCCP workstation.
Access Control
One of the requirements of PCI-DSS is that all systems involved in the payment process (all workstations, servers, peripherals, etc. that are used in the cardholder environment) be secured.
Secure authentication refers to the following considerations:
• Do not allow shared user accounts or passwords.
• Change passwords every 90 days.
• Make passwords a minimum of 7 characters in length.
• Passwords must be alpha-numeric.
• Allow passwords to be reused only after at least 4 different passwords have been created.
• Lock out users after 6 failed attempts at login.
• Lock out should be for a minimum 30 minutes.
• Require users to re-login if idle for more than 15 minutes.
For additional and more detailed instruction, refer to the definition of secure and strong authentication in sections 8.5.8 – 8.5.15 of the PCI-DSS guide.
Company Confidential.
Copyright © 2013 LexisNexis.
All rights reserved.
8 of 14
PCI-DSS requires you create unique usernames and strong, complex passwords; specifically, Windows, Windows operating system user accounts and passwords.
LCCP provides you with a security module that is separate from the host application. No default accounts are included in the application and unique security-related credentials should be secured. The application also requires unique username and passwords for administrative access. User accounts are created in LCCP, groups and group accounts do not exist. You should never share usernames and passwords.
Disabling the default and required installation settings of the application regarding the use of unique logon credentials results in non-compliance with the PCI-DSS. Refer to the section on Risk and Liability for information on non-compliance.
These rules apply to all personnel who have access to individual card transactions, as well as employees who have administrative capabilities to access servers with cardholder data and access to the application features.
Additionally, you must control access to operating systems and databases on your network via unique usernames and PCI-compliant complex passwords. This includes any workstation or server and all databases with payment applications and cardholder data. Do not use the administrative user for the operating system or the username Admin or Administrator.
Customers, resellers, and integrators are strongly advised to avoid using administrative accounts for daily operations in the application.
Passwords require the following criteria, which LCCP enforces:
• Expire every 90 days and cannot be reused.
• Must contain a minimum of 8 characters.
• Must contain a combination of letters, numbers, and symbols.
Make usernames and passwords unique from all other applications, devices, peripherals, as well as workstation and server operating systems. Grant rights to applications and databases for only those employees who require access.
Once the Credit Card Processing application is installed, you are prompted to create the administrative user, which allows you to create additional users and enter and/or modify merchant account details.
Create only as many usernames and password combinations as necessary and no other users or staff members should have access to create, modify, or delete logon credentials.
Also, you should only install LCCP on stations that require it. Secure the perimeter of any workstation or server with cardholder data or the payment application by the use of firewalls.
Do not allow the administrative user in the application be a local administrator of the workstation. Usernames cannot be reused if deleted. After 4 unsuccessful attempts at login, the user is locked out for 30 minutes. Administrative operations require a login every time and after a fifteen minute period of inactivity.
In addition to creating users and passwords, no two users should use the same login credentials and users should not use the same username and password combination from any other application.
• Do not share logon credentials for a workstation or LCCP.
• Do not create LCCP credentials that are unnecessary.
• Remove all unused logon credentials from all other applications, devices, and operating systems.
Company Confidential.
Copyright © 2013 LexisNexis.
All rights reserved.
9 of 14
• Do not use admin accounts for daily operations.
Access to the LCCP application is further controlled by locking out a user after 4 unsuccessful attempts for 30 minutes or until the administrator unlocks the account. Certain features of the LCCP require administrative login credentials to access. Fifteen minutes of inactivity closes the feature and will require the administrator to re-enter login credentials.
You should maintain controlled access to all usernames, passwords, device details and configuration, as well as other authentication information to any hardware and software component of your network.
Although LCCP has created controls to assist you with compliance within the application, LCCP is still available to any users able to log into the system. To ensure the application cannot be accessed by unauthorized users, you should create unique logon credentials for each user, as well as creating credentials that are different among all other applications and the operating system.
You can minimize the risks resulting from a breach in security to an operating system by ensuring usernames and passwords are not the same for the individual applications and databases associated to credit card data.
It is solely the merchant’s responsibility to ensure these guidelines are strictly adhered to with respect to your Windows operating system configuration, its accounts, and the associated permissions.
To achieve and maintain PCI compliance, these access control rules must be followed for all applications and databases on your network, including those on servers, as well as workstations.
Remote Access Control
Sensitive information must be encrypted during any transmission over networks. Use strong cryptography and security protocols to secure cardholder data if accessed remotely across public networks. Secure protocols include SSL/TLS and IPSEC.
LCCP does not allow for non-console administration and cannot be accessed remotely. Features must be accessed via a trusted host application. There are no internal procedures that allow LCCP to be contacted remotely. That is to say, connections are not made remotely, automatic or otherwise, to access a merchant’s site for updates or any other maintenance.
If a business need arises where remote access to process credit cards is required, you must use two-factor authentication. Two-factor authentication denotes that two methods must be used in order to successfully verify the authenticity of the user logging into the network and/or LCCP system.
Two-factor authentication must be used for remote access to ANY machine on the trusted network.
Authentication methods include username/password combinations, token or certificates, and biometric scanners.
LCCP does not recommend remote connections to minimize the impact of your PCI-DSS review.
Usernames and passwords should follow the PCI-compliant complex rules as identified in this guidance.
If you choose to connect remotely, configure remote connections to require a VPN connection via a firewall before logon credentials can authorize access. Only allow connections to the network from specific known IP or MAC addresses. Additional considerations regarding the software used to gain access remotely include:
• The user must change default settings in the remote access software.
• The user must enable encrypted data transmission.
Company Confidential.
Copyright © 2013 LexisNexis.
All rights reserved.
10 of 14
• The user must enable account lockout after failed login attempts.
• The user must enable logging in the remote access software.
• The user must restrict access to customer passwords to authorized personnel only.
You must enable remote-access technologies only when needed for downloads from the application
vendor and disable remote-access technologies immediately after the download is complete.
Our support policy is to not perform any remote access, however, if it is required, for troubleshooting purposes or visual confirmation, a shared web session is engaged upon by both merchant site and support site on a thirdparty web portal, called WebEx.
If a client is found to use LCCP, a remote session is not permitted and therefore not initiated.
For further information and specific details regarding security settings that may apply to a remotely accessed session to your merchant environment, refer to the PCI-DSS sections 4.1, 8.1, 8.4, and 8.5.
Wireless Access Control
PCI requires that cardholder data be encrypted if it is to be transmitted over a wireless connection.
Additional requirements include:
• Firewall/port filtering.
• Use of encryption methods including VPN, SSL/TPS at 128-bit, WEP* at 128-bit, and WPA.
• Avoid using vendor-supplied default logon credentials.
• Use MAC address filtering at access points to specific known devices.
Verify that the perimeter firewalls adequately control any traffic from the wireless environment to the cardholder data environment. All wireless networks must implement strong encryption mechanisms (AES, etc.). Default passwords, encryption keys, SNMP community strings, and other security related wireless vendor defaults must be changed. Firmware for all wireless devices should be upgraded to support strong encryption for the purposes of authentication and transmission over wireless networks. For best practices, refer to IEEE802.1i.
LCCP does not recommend using WEP encryption. However, the original requirements prescribed by PCI-DSS if using WEP encryption, aside from 128-bit encryption, are as follows (see warning below):
• Two-factor authentication must be used.
• If automated WEP key rotation is implemented, the rotation should occur every ten to thirty minutes.
• If automated WEP key rotation is not implemented, the keys should be changed manually, at least annually, as well as when key personnel leave the firm /change position within the firm.
Warning
Do not use WEP encryption for wireless implementations after March 31, 2009; where already in place, encryption type must be changed to an alternate by June 30, 2010. Any violations of these requirements or failure to perform the necessary checks result in non-compliance.
Company Confidential.
Copyright © 2013 LexisNexis.
All rights reserved.
11 of 14
Logging
LCCP is installed by default with application logging enabled; disabling this feature results in non-compliance. Transactional data is logged, as well as event data. Logging information includes:
• User identification.
• Type of event (audit, message, error, etc.).
• Date and time.
• Success or failure of the event.
• Where the event originated from.
• Name of the affected area (data, system component, or resource).
Disabling any application or network logging will result in non-compliance and should not be performed. An event is recorded to the log for the following:
• When the audit logs are initialized.
• All login attempts.
• When any feature in the application is accessed.
• When administrative login credentials are used.
• When administrative features are used.
• Any access to audit event logs.
• Any invalid login attempts.
• Which authentication methods are used to gain access.
• Creation or deletion of system level objects.
• Any logical access attempts.
In addition to the application logging provided by LCCP, audit logs for all network devices, applications, and systems, including anti-virus, operating system, firewalls, should be enabled to provide the ability to track and analyze access to your environment and systems. You should audit events such as; logon events, policy changes, system events, and account management changes.
Logs should be reviewed daily.
Security of Transmitted Data
Within LCCP, strong encryption methods are used to protect data. PCI-DSS requires you do not send cardholder information via e-mail (or over the internet) without using cryptography and/or encryption methods.
Do not use e-mail, instant messaging applications, or other messaging technology to transmit sensitive cardholder data.
LCCP does not send data through any form of media other than Paygateway.dll. Paygateway.dll, provided by PayPros®, handles the encryption/decryption across the internet to PayPros® servers. It is a digitally certified application module.
Company Confidential.
Copyright © 2013 LexisNexis.
All rights reserved.
12 of 14
This data is transmitted using SSL. If you are transmitting data over the internet, it must be encrypted with secure encryption transmission technology like SSL, VPN, or IPSEC. Failure to do so results in non-compliance.
Although strongly not recommended, if you choose to send cardholder data over the internet in any form, you must consider whether any products of the encryption process are stored. Removal is mandatory to achieve and maintain PCI-DSS compliance.
Storage
LCCP does not store cardholder data to prevent possible physical access; therefore, there are no electronic storage concerns. The transmission of data is fully encrypted using with strong techniques and include key identifiers that, once decrypted, must be subsequently validated by the receiving application process. There is no storage of historical sensitive cardholder or authentication data.
Do not record on paper any cardholder data to enter later. This piece of paper would need to be stored in a physically secure location. Moreover, the piece of paper would have to be shredded, incinerated, or pulped so the data cannot be reconstructed.
You should collect a minimum of sensitive data and only when needed to solve a specific issue. It must be stored securely (encryption methods) with limited access. It also must be deleted securely, whereby the data cannot be reconstructed, when no longer needed.
You are responsible to secure the data until it has been completed deleted.
Routers and other network devices should have physical barriers to prevent unauthorized tampering.
The application does not store any sensitive authentication data, such as, magnetic stripe data, card verification values of CVC, CCV, CCV2, or CID, PAN, PIN or PIN block, security codes, or expiration data, nor does it leave any cryptographic material on any station; therefore, removal is not required.
LCCP only stores the following information cardholder name and the last four digits of the credit card number.
Transactional data includes order ID, batch ID, amount, tax amounts, and authorization number. We recommend you do not store cardholder data on any system, paperless or otherwise, however, you specifically must not store data on any internet-accessible systems. An example of a violation is where the database server and web server are located on the same machine.
Office Policies and Procedures
Review your current policies. Create usage guidelines for laptops, PDAs, remote access, e-mail and internet usage. Create a policy for handling security incidents within and without your firm. Ensure all employees are educated of the security policy changes and of security issues and concerns.
Educate your employees how to detect fraudulent cards using card security features. You should test every external application that stores, process or is used in the transmission of credit card data. Tests should include:
• Penetration testing.
• Application and network testing.
• Internal vulnerability scans.
You should also consider the use of intrusion detection systems. Wireless access points require special consideration. See the section on Wireless Access Control for detailed information.
Company Confidential.
Copyright © 2013 LexisNexis.
All rights reserved.
13 of 14
Company Confidential.
Copyright © 2013 LexisNexis.
All rights reserved.
14 of 14
">