PA DSS Implementation Guide

Important Notice

After October 29, 2019, SalesPad will no longer be supporting CardControl. Additionally, the application will cease to be a PA-DSS validated solution as of this date, and therefore CardControl customers would no longer be PCI compliant.

Instead, SalesPad Desktop now offers built-in credit card processing via Nodus PayFabric. If you have questions or want more information on our credit card processing services, please contact your sales rep.

---

About this Document

This document describes the steps that must be followed in order for your CardControl installations to comply with Payment Application – Data Security Standards (PA-DSS). The information in this document is based on PCI Security Standards Council Payment Application Data Security Standards program (version 3.0 dated November, 2013).

Sales Pad, LLC instructs and advises its customers to deploy SalesPad Solutions applications in a manner that adheres to the PCI Data Security Standard (v3.0). Subsequent to this, best practices and hardening methods, such as those referenced by the Center for Internet Security (CIS) and their various “Benchmarks,” should be followed in order to enhance system logging, reduce the chance of intrusion and increase the ability to detect intrusion, as well as other general recommendations to secure networking environments. Such methods include, but are not limited to, enabling operating system auditing subsystems, system logging of individual servers to a centralized logging server, the disabling of infrequently-used or frequently vulnerable networking protocols and the implementation of certificate-based protocols for access to servers by users and vendors.

Sales Pad, LLC disseminates this documents to all customers that have purchased CardControl. This document is available publicly, online at this address (link).

You must follow the steps outlined in this Implementation Guide in order for your CardControl installation to support your PCI DSS compliance efforts.

Revision Information

Name	Title	Date of Update	Summary of Changes
Blake Meinke	Developer	2/26/12	Document Creation
Dustin Chilson	Developer	10/19/13	2.0 Updates
Brock Flewelling & Donovan Moore	Developer	4/7/15	3.0 Updates
Avery Martin	Developer	9/1/15	3.0 Revisions
Jarrett Weber	Technical Writer	10/12/15	Format Update
Sarah Schaefer	Technical Writer	10/12/15	Minor edit
Christian Hartford	Technical Writer	5/8/20	Updated PCI/PA DSS links

 

Note: This PA-DSS Implementation Guide (IG) must be reviewed on a yearly basis, whenever the underlying application changes or whenever the PA-DSS requirements change. Updates should be tracked and reasonable accommodations should be made to distribute or make the updated guide available to users. Sales Pad, LLC will distribute the IG to new customers via URL links distributed to the end-user at the time of purchase and upon request.

This document also explains the Payment Card Industry (PCI) initiative and the Payment Application Data Security Standard (PA-DSS) guidelines. The document then provides specific installation, configuration, and ongoing management best practices for using CardControl as a PA-DSS validated Application operating in a PCI Compliant environment.

Note: As of version 3.0.12.0, the 'Disable TLS 1.0' setting must be set to True in order to fulfill PCI requirements. Earlier versions will need to upgrade in order to remain compliant.

PCI Security Standards Council Reference Documents

The following documents provide additional detail surrounding the PCI SSC and related security programs (PA-DSS, PCI DSS, etc):

• PCI Security Standards Council Document Library (PA DSS) 
• PCI Security Standards Council Document Library (PCI DSS)
• Open Web Application Security Project (OWASP) http://www.owasp.org

Application Summary

Payment Application Name:	CardControl
Payment Application Version:	3.0.x.x
Application Description:	CardControl allows users to securely process credit card payments through multiple transactional gateways. CardControl can be out-of-the-box integrated an ERP system such as Microsoft Dynamics GP with/without SalesPad GP or QuickBooks with/without SalesPad ERP.
Application Target Clientele:	Users of Microsoft Dynamics GP 2010, Microsoft Dynamics GP 2013, and users of SalesPad GP. Users of QuickBooks and SalesPad ERP.
Clientele Description:	CardControl is designed to be used by small to large merchants, ranging from local, national, or global. CardControl contains multi-language support for multi-regional usage. CardControl supports out-of-the-box integration with multiple ERP systems, including, but not limited to, Dynamics GP and SalesPad ERP. Therefore, CardControl is designed industry unspecific and can be applied in any type of customer channel (E-commerce, brick-and-mortar, etc). Merchants using CardControl typically operate on a mixed-usage basis, that is, a combination of mail order, telephone order, and web orders. CardControl supports both card-present and card-not-present transactions.
Components of Application Suite (i.e. POS, Back Office, etc.)	End User Computer Deployed Applications CardControl.exe: Credit card processing application, with a windows Graphical User Interface (GUI). Additions.exe: Plugin applications that give users the ability to launch the primary CardControl application from within Dynamics GP/QuickBooks and SalesPad GP/ERP. Handles no sensitive data. Server Deployed Applications CardControlWebRest: Rest interface to the CardControl Application Programming Interface (API) hosted within Microsoft Internet Information Services (IIS). Communicates with the CardControlWebSoap application. CardControlWebSoap: Soap interface using Microsoft Windows Communication Foundation (WCF) hosted in IIS. Contains all processing utilities of the CardControl.exe application without the GUI.
Required Third-Party Payment Application Software:	Authorize.NET Payment Gateway (version 3.1) - https://www.authorize.net AssureBuy Payment Gateway (version 4.6) - http://www.bluepay.com EBizCharge Payment Gateway (version 2) - http://ebizcharge.com PayFlowPro Payment Gateway (version 4.3.1.0) - https://www.paypal.com  LitleOnline Payment Gateway (version 8.14) - http://www.litle.com FirstData E4 Payment Gateway (version 11) - https://www.firstdata.com 3Delta Payment Gateway (version 1) - http://www.3dsi.com Moneris Payment Gateway (version 2.5) - https://www.moneris.com

	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

Database Software Supported:	Microsoft SQL Server 2012
Other Required Third Party Software:	Microsoft Dynamics GP 2010 or Microsoft Dynamics GP 2013 or QuickBooks Microsoft .Net Framework version 4.5.
Operating System(s) Supported:	The latest supported versions of: Windows 8
Application Functionality Supported	Select one or more from the following list:
Payment Processing Connections:	CardControl, utilizing a payment processor gateway account setup by the user, transmits credit card transaction data using a secure connection to the payment processing gateway. Any response from the payment processor is then presented to the user.
Application Authentication	CardControl user names and passwords are stored in a Microsoft SQL Server 2012 database. Access to the SQL Server database should be secured with industry best practices. Passwords are one-way hashed using industry standard 256 bit SHA2 hashes; a unique input variable is concatenated with each password before the cryptographic algorithm is applied and passwords are unreadable at all times during transmission. CardControlWeb uses unique API Keys generated with information related to the application environment for authentication. Theses keys can be disabled by CardControl administrators or via Application updates. API Keys are two-way hashed using industry standard 256 bit SHA2 hashes.
Description of Versioning Methodology:	CardControl versioning has four levels, Major PA-DSS version, Major, Minor, and Wildcard: X.X.X.X. ‘X’ is a numeric value only. Major PA-DSS Version: Indicates the major version of PA-DSS the application is validated for. Major: Changes including significant changes to the application and would have an impact on PA-DSS requirements.

	Minor: Changes including small changes such as minor enhancements and may or may not have an impact on PA-DSS requirements. Wildcard: Build changes including bug fixes and would have no negative impact on PA-DSS requirements.
List of Resellers/Integrators (If Applicable):	CardControl requires that SalesPad staff install and configure every installation.

Typical Network Implementation

Data Flow Diagram

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 CardControl has been tested, assessed, and validated.

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

Obtaining “PCI Compliance” is the responsibility of the merchant and your 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 CardControl will help you achieve and maintain PCI Compliance with respect to how CardControl 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.

THE 12 REQUIREMENTS OF THE PCI DSS:

Build and Maintain a Secure Network and Systems

1. Install and maintain a firewall configuration to protect cardholder 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 and sensitive information across public networks

Maintain a Vulnerability Management Program

1. Protect all systems against malware and regularly update anti-virus software
2. Develop and maintain secure systems and applications

Implement Strong Access Control Measures

1. Restrict access to data by business need-to-know
2. Identify and authenticate access to system components
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

Considerations for the Implementation of CardControl 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 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 public facing or internet-accessible systems.
• Configure the application to use a DMZ to separate the internet from systems storing cardholder data.
• Use TLS for Secure Data Transmission.
• Delivery of Updates in a PCI Compliant Fashion.

Remove Historical Sensitive Authentication Data (PA-DSS 1.1.4)

No previous versions of CardControl stored sensitive authentication data. Therefore, there is no need for secure removal of this historical data by the application as required by PA-DSS v3.0.

Sensitive Authentication Data Requires Special Handling (PA-DSS 1.1.5)

Sales Pad, LLC does not store Sensitive Authentication Data for any reason, and we strongly recommend that you do not do this either. However, if for any reason you should do so, the following guidelines must be followed when dealing with sensitive authentication data (swipe data, validation values or codes, PIN or PIN block data):

• 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 - If you do not currently have or use a secure delete tool, you can use one of the following for the Windows operating system:
  • Heidi Eraser can be obtained from http://www.heidi.ie/eraser/
  • Microsoft SDelete can be obtained from https://docs.microsoft.com/en-us/sysinternals/downloads/sdelete

Securely Deleting Cardholder Data (PA-DSS 2.1)

The following guidelines must be followed when dealing with cardholder data (PAN alone or with any of the following: expiration date, cardholder name, or service code):

• A customer defined retention period must be defined with a business justification
• Cardholder data exceeding the customer-defined retention period must be securely deleted.
• Any cardholder data that is no longer required for legal, regulatory, or business purposes must be securely deleted.
• The locations of the cardholder data that must be securely deleted are as follows:
  • Credit Card Data – Located in the CustomerCreditCard table under the ‘spcc’ schema in the database
  • Credit Card Processor Log – Located in the CreditCardProcessorLog table under the ‘spcc’ schema in the database
  • Transaction History – Located in the CreditCardTransaction table under the ‘spcc’ schema in the database

To securely delete the cardholder data, you must do the following:

1. In the application, you must use the Data Cleaner utility to securely delete historical data. The Data Cleaner utility contains the functionality to securely delete Credit Card Data, Credit Card Logs, and Transaction History. To delete, a user with permission to use the Data Cleaner must navigate to the Data Cleaner form, specify the parameters regarding the information to be deleted, and click the Clear Data button. Example:
   Figure 1. Data Cleaning Example 1
2. Use the following section of instructions, titled Addressing Inadvertent Capture of PAN, to configure your Windows 8 operating system to prevent inadvertent retention of cardholder data.

Addressing Inadvertent Capture of PAN

DISABLE SYSTEM RESTORE SETTINGS

Disable System Restore

1. Right-click on Computer and select Properties (In Windows 8, this can be done through the start menu and right clicking ‘This PC’)
2. Select System Protection from the top left list. The following screen will appear:
3. Select Configure. The following screen will appear:

1. Select Turn off system protection (In Windows 8, this says ‘Disable system protection’)
2. Click Apply, and click OK to close the System Protection window
3. Click OK again to close the System Properties window
4. Reboot the computer

Encrypt the System PageFile.sys

Encrypting PageFile.sys

In order to perform this operation, the hard disk must be formatted using NTFS.

1. Open Command Prompt - On the Windows task bar, click on the Windows “Orb” and in the search box type in “cmd” – for Windows 8, this can be done through the start menu.
2. Right-click on cmd.exe and select Run as Administrator
3. To Encrypt the PageFile, type the following command: “fsutil behavior set EncryptPagingFile 1”
4. To verify configuration, type the following command: “fsutil behavior query EncryptPagingFile”

1. If encryption is enabled, EncryptPagingFile = 1 should appear
2. In the event you need to disable PageFile encryption, type the following command: “fsutil behavior set EncryptPagingFile 0”

1. To verify configuration, type the following command: “fsutil behavior query EncryptPagingFile”

1. If encryption is disabled, EncryptPagingFile = 0 should appear

Clear the System PageFile.sys upon Shutdown

Windows has the ability to clear the PageFile.sys upon system shutdown. This will delete all temporary data from the PageFile.sys (temporary data may include system and application passwords, cardholder data (PAN/Track), etc.).

Note: Enabling this feature may increase windows shutdown time.

1. Click on the Windows “Orb” and in the search box type in “regedit”
2. Right-click on regedit.exe and select Run as Administrator
3. Navigate to HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management
4. Change the value from 0 to 1
5. Click OK and close Regedit

1. If the value does not exist, add the following:

• Value Name: ClearPageFileAtShutdown
• Value Type: REG_DWORD
• Value: 1

Disable System Management of PageFile.sys

Disabling System Management of PageFile.sys

1. Right-click on Computer and select Properties – on Windows 8, this can be done through right clicking ‘This PC’ from the start menu.
2. Select Advanced System Settings from the top left list. The following screen will appear:

1. Under Performance, select Settings and click on the Advanced tab. The following screen will appear:

1. Select Change under Virtual Memory. The following screen will appear:

1. Uncheck Automatically manage page file size for all drives
2. Select Custom Size
3. Enter the following for the size selections:
   • Initial Size – as a good rule of thumb, the size should be equivalent to the amount of memory in the system.
   • Maximum Size – as a good rule of thumb, the size should be equivalent to 2x the amount of memory in the system.
4. Click OK three times. You will be prompted to reboot your computer

DISABLE WINDOWS ERROR REPORTING

Disabling Windows Error Reporting

1. Open the Control Panel
2. Open the Action Center (In windows 8, this can be selected from the start menu search)
3. Select Change Action Center Settings

1. Select Problem Reporting Settings

1. Select Never Check for Solutions

Mask PAN when displayed (PA-DSS 2.2)

There are only three instances when a full PAN is displayed to the user:

• When a new credit card is created on the Customer Credit Card creation screen. The PAN is displayed to the user as it is entered. Once the card is saved, the PAN is masked.
• The POS screen, “CC Transaction Entry”, displays the PAN to the user as it is entered. Once the transaction is processed, the PAN is masked. Saved credit cards and tokens are always masked on this screen.
• The two previously mentioned situations are the only times when the PAN is viewable by the user by default. The following are instructions to configure CardControl in a way that allows personnel with a legitimate business need to see the full PAN.

1. A user with CardControl Security access must open the CardControl Security menu.
2. Select the authorized security group from the System Groups. Under the security setting Customer Credit Cards, you can enable the security setting Can View Unencrypted Credit Card Numbers. Only personnel with a legitimate business need to view the full PAN should be included in this security group. Whenever this security is enabled, it is logged in the SystemLog table - schema spcc - which user enabled the setting and for what group.

1. Once the security is enabled, the authorized users will need to log out of CardControl to apply the security setting.
2. Upon logging back in, the members of the authorized security group will be able to view full PANs of stored credit cards on the Customer Card. It is also logged in the SystemLog each time a user views a Customer Card to view a full PAN.

In addition to the above-mentioned locations where either a masked, truncated, or full PAN is displayed, there are the following locations where truncated PANs are visible:

• Within the Customer Card form, a “CC Number Masked” column displays the truncated PAN (only the last four digits are available).
• Within the Customer Transaction Log form, a “CC Number Masked” column displays the truncated PAN (only the last four digits are available).
• Within the Transaction Log form, a “CC Number Masked” column displays the truncated PAN (only the last four digits are available).

The above list contains every location where any form of PAN is visible within the application.

Render Stored PAN Unreadable (PA-DSS 2.3)

PAN information is always encrypted and masked before any storage occurs. CardControl truncates or masks all PANs before writing them to transaction history, processor logs, response messages, all screens, and all tables in the database. PAN information is always unreadable when stored unless authorized personnel are given explicit permission to view full PAN information as detailed above.

Protect Secure Data Keys (PA-DSS 2.4)

CardControl does not require storing keys used to secure cardholder data as they are dynamically created. Thus, users are not responsible to

• Restrict access to keys to the fewest number of custodians necessary.
• Store keys securely in the fewest possible locations and forms.

Cardholder Data Encryption Key Management (PA-DSS 2.5)

The following key management functions must be performed per PCI DSS:

• Generation of strong cryptographic keys
• Secure cryptographic key distribution
• Secure cryptographic key storage
• Cryptographic key changes for keys that reached the end of their cryptoperiod (for example, after a defined period of time has passed and/or after a certain amount of ciphertext has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines (for example, NIST Special Publication 800-57)
• Retire keys when the integrity of the key has been weakened
• Replace known or suspected compromised keys
• If retired or replaced cryptographic keys are retained, the application cannot use these keys for encryption operations
• Manual clear-text key-management procedures require split knowledge and dual control of keys
• Prevention of unauthorized substitution of cryptographic keys

CardControl utilizes a dynamic encryption system. This system, which dynamically generates strong encryption keys, alleviates the need for the merchant to:

1. Restrict access to keys to the fewest number of custodians necessary
2. Store keys securely in the fewest possible locations and forms
3. Securely generate, distribute, protect, change, store, and retire/replace encryption keys, where customers or resellers/integrators are involved in these key management activities
4. Have key custodians that acknowledge that they understand and accept their key custodian responsibilities
5. Perform the key management functions defined above

Removal of Cryptographic Material (PA-DSS 2.6)

No previous versions of CardControl used or stored cryptographic key materials or cryptograms for encryption and therefore there is no material to be securely removed as required by PA-DSS v3.0.

Set up Strong Access Controls (3.1 and 3.2)

The PCI DSS requires that access to all systems in the payment processing environment be protected through use of unique users and complex passwords. Unique user accounts indicate that every account used is associated with an individual user and/or process with no use of generic group accounts used by more than one user or process.

During initial installation of the application, a SQL connection string must be provided:

• Do not use the default administrative account for SQL (sa).
• The provided user must have SQL permissions to create, update, and delete objects within SQL.
• SQL secure passwords must be enabled and enforced.
  1. .: You are required to assign a strong password to the default ‘salespad’ account, and then the account should be disabled, deleted, or not used.
     • CardControl enforces a change to the salespad account on initial setup and installation. The user is prompted and required to enter a secure password before being allowed to proceed.

During the initial configuration state, after the product is installed, a default ‘salespad’ user will exist. On first login, the user will be presented with a popup form requiring them to enter a new, strong password for the account. This account has access only to the Security Editor by default. If they exit the form without supplying a new, strong password, the application will terminate.

When setting up new user accounts, one unique account for each user, users will require a new, strong password, which can be configured to reset upon next login.

To modify existing credentials, perform the following steps:

• 
  
  • 
    
    • Log into CardControl Using credentials with security access to the Security Editor.
    • On the left side of the form, within the System Users grid, select the desired user.
    • Check the “Reset Password Next Login” checkbox. This will force the selected user to reset their password when they next successfully log in using their old password.
    • Alternatively, click the Ellipsis button next to the Password field. Then, enter a new, strong password.
    • All passwords must be eight characters or more, and include an uppercase character, a lowercase character, and a number.

See the image included below.

All authentication credentials are provided by the application. For both the completion of the initial installation and for any subsequent changes (for example, any changes that result in user accounts reverting to default settings, any changes to existing account settings, or changes that generate new accounts or that recreate existing accounts), the following 10 points must be followed per PCI 8.1, 8.2, and 8.5.8-15:

1. The application must assign unique IDs for user accounts (8.1.1)
2. The application must provide at least one of the following three methods to authenticate users: (8.2)
   1. Something you know, such as a password or passphrase
   2. Something you have, such as a token device or smart card
   3. Something you are, such as a biometric
3. The application must NOT require or use any group, shared, or generic accounts or passwords (8.5)
4. The application requires passwords to be changed at least every 90 days (8.2.4)
5. The application requires passwords to be at least 7 characters (8.2.3)
6. The application requires passwords to include both numeric and alphabetic characters (8.2.3)
7. The application keeps password history and requires that a new password be different than any of the last four passwords used (8.2.5)
8. The application limits repeated access attempts by locking out the user account after not more than six login attempts (8.1.6)
9. The application sets the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID (8.1.7)
10. The application requires the user to re-authenticate or to re-activate the session if the application session has been idle for more than 15 minutes. (8.1.8)

To be PCI compliant, the account and password criteria from the above 10 requirements must also be applied to any applications or databases included in payment processing. CardControl, as tested in our PA-DSS audit, meets or exceeds these requirements for the following additional required applications or databases:

Microsoft SQL Server 2012

During initial installation, and subsequent ‘database updates’, the application will require the usage of a SQL account with permissions to create the tables, stored procedures, and other SQL objects that are required for the application to run. The user is advised to create a SQL user for the CardControl application that has access to all objects under the [spcc] schema, and access only databases used by Microsoft Dynamics GP, Quickbooks, and other databases only if there is an associated business need.

Any changes made to authentication configurations must be verified as providing authentication methods that are at least as rigorous as PCI DSS requirements.

Note: These password controls are not intended to apply to employees who only have access to one card number at a time to facilitate a single transaction. These controls are applicable for access by employees with administrative capabilities, for access to servers with cardholder data, and for access controlled by the application.

• 
  
  1. : Control access, via unique username and PCI DSS-compliant complex passwords, to any PCs or servers with payment applications and to databases storing cardholder data.

Properly Train and Monitor Admin Personnel

It is your responsibility to institute proper personnel management techniques for allowing admin user access to cardholder data, site data, company databases, etc. You 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, so pay special attention to whom you trust into your admin site and who you allow to view full decrypted and unmasked payment information.

Log Settings Must Be Compliant (PA-DSS 4.1, 4.4)

4.1: CardControl has PA-DSS compliant logging enabled by default. This logging is not configurable and may not be disabled. Disabling or subverting the logging function of CardControl in any way will result in non-compliance with PCI DSS.

CardControl has logging turned on and configured per PCI DSS 10.2 and 10.3 as follows:

Implement automated assessment trails for all system components to reconstruct the following events:

• 
  
  • 
    
    1. All individual user accesses to cardholder data
    2. All actions taken by any individual with root or administrative privileges
    3. Access to application audit trails managed by or within the application
    4. Invalid logical access attempts
• 
  
  1. 5 Use of the application’s identification and authentication mechanisms
     1. Initialization of the application audit logs
     2. Creation and deletion of system-level objects within or by the application

Record at least the following assessment trail entries for all system components for each event from 10.2.x above:

• 
  
  • 
    
    1. User identification
    2. Type of event
    3. Date and time
    4. Success or failure indication
    5. Origination of event
    6. Identity or name of affected data, system component, or resource
• 
  
  1. : CardControl facilitates centralized logging.

Both the Payment Processor Log and the System Log entries can be found in the database as follows:

• 
  
  • 
    
    • Payment Processor Log
      • Table Name: CreditCardProcessorLog
      • Schema: spcc
    • System Log
      • Table Name: SystemLog
      • Schema: spcc

The saved logs are viewable and exportable within the application through the System Log Search form. By using the “Export All” button within the form, the logs can be written to XLS and XLSX (excel) files at a folder location set by the user.

The logs can also be copied and pasted into an Excel file, or written to a CSV file using a SQL script.

Configuring automated centralized logging:

Perform the following steps to configure automated, centralized logging to a user-specified folder location. This process utilizes Microsoft SQL Server Management Studio, which is available for free to any merchant with a SQL server license (required for CardControl). It can be downloaded at the following link (if the link is invalid, please refer to the official Microsoft download center).

Setup Steps:

1. Start Microsoft SQL Management Studio.
2. Connect to the SQL server hosting your company database upon which CardControl is installed.

1. Input the name or IP address of the desired SQL server in the connection form and supply credentials to a SQL user account with permissions to create stored procedures and SQL jobs.
2. Once connected, the server and all databases on the server will be shown in the “Object Explorer” pane, which by default is located on the left side of the application.
   • Left click on the ‘+’ symbol to expand the SQL server dropdown.
   • Expand the dropdown next to ‘Databases’.
   • Right click on the company database upon which CardControl is installed.
   • Left click on the ‘Tasks’ button.
   • Left click on the ‘Export Data…’ button.

1. The SQL Server Import and Export Wizard will be displayed.
   • Click the ‘Next’ button to continue.

1. In the ‘Data source:’ dropdown, select ‘SQL Server Native Client 11.0’.
2. In the ‘Server name:’ dropdown, type the name of the SQL server you connected to previously (this field will default to the current SQL server, so you should not have to modify it if the above steps were followed).
3. In the ‘Authentication’ box, supply the same credentials used to connect to the SQL server previously.
4. In the ‘Database:’ dropdown, type the name of the company database upon which CardControl is installed (this field will default to the selected database, so you should not have to modify it if the above steps were followed).

1. Click ‘Next’ to continue.
2. In the ‘Destination:’ dropdown, select either ‘Flat File Destination’ or ‘Excel File’. For this walk through, ‘Flat File Destination’ will be used.
3. Click ‘Browse’ to open a windows file explorer window. Within this window, select the desired destination for your exported log files. This location should match the location the merchant uses for all centralized logging purposes.
4. Name the file that will result from your export.
5. In the ‘Format:’ dropdown, select ‘Delimited’.
6. Make sure the ‘Column names in the first data row’ checkbox is checked.
7. Click ‘Next’ to continue.
8. Select ‘Copy data from one or more tables or views’ and click ‘Next’

1. IMPORTANT: In the ‘Source table or view:’ dropdown, select “[spcc].[SystemLog]”.
2. In the ‘Row delimiter:’ dropdown, select your desired delimiting character. For this example, ‘Comma {,}’ will be used.

1. Click ‘Preview’. The results should like similar to the following (there may not be data available for display if CardControl has not been logged in to at least once).

1. Close out of the preview, and click ‘Next’ to continue.
2. In the next window,
3. Uncheck the box ‘Run immediately’.
4. Check the box ‘Save SSIS Package’.
5. Select the ‘File System’ radio button.
6. In the ‘Package Protection level’ select ‘Encrypt sensitive data with user key’.
7. Click ‘Next’ to continue.
8. In the ‘Name’ field, name your export process that will be configured to run on a schedule.
9. In the ‘Description’ field, type a short description of how the process is configured to run.
10. Browse to a good location for your export file.

1. Click ‘Finish >>|’ to continue to the final confirmation form.
2. Review and confirm the details of the configured export. Once satisfied, click ‘Finish’ to save the export process to your SQL server.

The process should show success for each executed step.

1. Now that the export script file is saved, it needs to be configured with a SQL Job to run on an automated schedule. SQL Server Agent must be enabled on the server hosting CardControl data. See the following link to configure SQL Server Agent: https://msdn.microsoft.com/en-us/library/ms178142(v=sql.110).aspx
2. Expand SQL Server Agent in the object explorer.
3. Right click on ‘Jobs’.
4. Left click on ‘New Job’.
5. Name the SQL job appropriately.
6. Give the SQL job an appropriate description.
7. Make sure the ‘Enabled’ checkbox is checked.
8. In the ‘Steps’ tab, click the ‘New’ button.

1. Name the new Step.
2. Set the ‘Type’ dropdown to ‘SQL Server Integration Services Package’
3. Set ‘Package source’ to ‘File system’.
4. Browse to the location you saved the previously created export file (.dtsx).

1. In the ‘Schedules’ tab, click ‘New’.
2. Name your schedule appropriately.
3. Set the ‘Schedule type’ to ‘Recurring’.
4. Make sure the ‘Enabled’ checkbox is checked.
5. Set the ‘Frequency’ to the value desired. ‘Daily’ will be used in this example.
6. Set ‘Recurs every’ to the value desired. ‘1’ will be used in this example.
7. Set the ‘Daily Frequency’ values to the desired time table. ‘Occurs once at’ and ’12:00:00 AM’ will be used for this example.

1. The SQL job can have alerts and notifications configured for success, failure, or other results. These results can be emailed to the addresses specified in each tab. Configure these as necessary, but no alerts or notifications are required.
2. Press ‘OK’. The SQL job will now use the export script to perform automated, centralized logging on the schedule configured. You can view and edit the SQL job by expanding the ‘Jobs’ folder under SQL Server Agent in the Object Explorer.

Application Versioning (PA-DSS 5.4.4)

CardControl versioning has four levels: Major, Minor, Build, and Revision: X.X.X.0.

Major changes include significant changes to the application and would have an impact on one or more PA-DSS requirements.

Minor changes include small changes such as minor enhancements or features and may or may not have an impact on PA-DSS requirements.

Build changes include bug fixes and would have no negative impact on PA-DSS requirements. The revision is always a 0.

PCI-Compliant Wireless Settings (PA-DSS 6.1, 6.2, and 6.3)

SalesPad and its product CardControl do not support wireless technologies. However, should the merchant implement wireless access within the cardholder data environment, the following guidelines for secure wireless settings must be followed per PCI Data Security Standard 1.2.3, 2.1.1 and 4.1.1:

1.2.3: Perimeter firewalls must be installed between any wireless networks and systems that store cardholder data, and these firewalls must deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment. The intent of this requirement applies to employee-owned and company-owned computers. Systems that cannot be managed by corporate policy introduce weaknesses to the perimeter and provide opportunities that malicious individuals may exploit. Allowing untrusted systems to connect to an organization’s network could result in access being granted to attackers and other malicious users.

• 
  
  • 
    
    1. : Change wireless vendor defaults per the following 5 points:
       1. Encryption keys must be changed from default at installation, and encryption keys, passwords, and SNMP strings must be changed any time anyone with knowledge of the keys leaves the company or changes positions.
       2. Default SNMP community strings on wireless devices must be changed. Default passwords/phrases on access points are required to be changed upon installation.
       3. Default SNMP community strings are not used. Default passwords/passphrases on access points are not used.
       4. Firmware on wireless devices must be updated to support strong encryption for authentication and transmission over wireless networks
       5. Other security-related wireless vendor defaults, if applicable, must be changed
    2. : Industry best practices (for example, IEEE 802.11.i) must be used to implement strong encryption for authentication and transmission of cardholder data.

Note: The use of WEP as a security control was prohibited as of June 30, 2010.

Services and Protocols (PA-DSS 8.2)

CardControl does not require the use of any insecure services or protocols. CardControl does require the following services and protocols:

• 
  
  • 
    
    • 
      
      • HTTPS
      • TLS

Never Store Cardholder Data on Internet-Accessible Systems (PA-DSS 9.1)

1. Never store cardholder data on Internet-accessible systems (e.g., web server and database server must not be on same server).
2. Systems storing cardholder data must reside on a separate network zone than any public-facing network zones.
3. The CardControl Web API requires a port to be set up during initial configuration of the service – this port can be chosen by the user.
4. CardControl uses port 443 for SSL communication to payment gateways.

CardControl requires the ports for SQL server communication, which defaults