Brink POS PA-DSS Implementation Guidecdn.brinkpos.net/docs/PA-DSS Implementation Guide.pdf• Such removal is absolutely necessary for PCI DSS compliance. PA-DSS 1.1.5 - Delete any

Brink POS PA-DSS Implementation Guide

Partech, Inc.

A description of the policies and procedures related to installation and implementation of the Brink POS

software at the merchant site. This document also includes recommended connection and security

methods as well as details on how PCI requirements affect how Brink POS is installed and implemented.

Partech, Inc.

8383 Seneca Turnpike

New Hartford, NY 13413

http://www.partech.com

Phone: 800.448.6505

Brink POS Customer Implementation Guide

2 | P a g e

Document Change History

Date Version Changed By Change Description

4/30/2019 1.13.1 Christine Fuchs Added Dependencies

4/24/2019 1.13.0 Christine Fuchs Update for v5.0

3/28/2019 1.12.0 Christine Fuchs Adequacy Review v4.1

2/19/2018 1.11.0 Marc Jarvis Adequacy Review v4.1

2/14/2017 1.10.0 Marc Jarvis Update for v4.1

6/24/2016 1.9.0 Brett Clapham Update for v4.0




09/08/2014 1.5.0 Michael Demler Update for v3.3





07/20/2010 1.0.0 Richard Elliott Initial Release


3 | P a g e

Foreword

This document is provided by Partech as a reference guide only and in no way implies that the

recommendations described within will prevent unauthorized access to merchant networks or systems.

Partech accepts no responsibility for the security of merchant networks, systems, or applications.

Additionally, Partech does not provide PCI DSS assessments or audits and cannot provide review of or

approval for merchant network security strategies or policies.


4 | P a g e

Contents

Document Change History ............................................................................................................................ 2

Foreword ....................................................................................................................................................... 3

Overview ....................................................................................................................................................... 6

Intended Audience ........................................................................................................................................ 6

Sensitive Authentication Data (SAD) related requirements ......................................................................... 6

Installation and Configuration ...................................................................................................................... 7

Client installation ...................................................................................................................................... 7

Upgrades ....................................................................................................................................................... 8

Storage & Maintenance ................................................................................................................................ 9

Credit Card Data & Encryption Controls ................................................................................................... 9

Secure Deletion of Cardholder Data ............................................................................................................. 9

Primary Account Number (PAN) Handling .................................................................................................. 10

Cryptography .............................................................................................................................................. 10

Authentication ............................................................................................................................................ 11

Audit Trails .................................................................................................................................................. 13

Versioning Methodology............................................................................................................................. 14

Remote Access ............................................................................................................................................ 14

Wireless Technology ................................................................................................................................... 15

Encryption of Data Sent over Public Networks ........................................................................................... 15

Network Segmentation ........................................................................................................................... 16

Router and Firewall ..................................................................................................................................... 16

Anti-Virus Software ..................................................................................................................................... 17

Merchant Information Security Policy/Program......................................................................................... 17

Visa’s Validation Requirements .................................................................................................................. 19

Troubleshooting & Support ........................................................................................................................ 19

Dependencies.............................................................................................................................................. 20

Links to More Information .......................................................................................................................... 20

Appendix A: Recommended Network Configuration Diagram ................................................................... 21


5 | P a g e


6 | P a g e

Overview

In order to maintain compliance with specific industry requirements such as the Cardholder Information

Security Program (CISP), Industry Data Security Standard (PCI DSS), Security Standard (PA-DSS), Partech

has developed standard recommendations and practices regarding local network and software

installation/configuration of Brink POS at merchant locations.

This document is applicable to version 5.0 of Brink POS and is subject to change by Partech. Please visit

our website for the most up to date version of all documentation.

http://www.brinksoftware.com/documents

Intended Audience

This document is intended for Brink POS Customers/Merchants, Partech Support, Implementation,

Sales, and Resellers, Service Partners, Qualified Security Assessors and any other audience interested in

the implementation policies and procedures used by Partech.

Sensitive Authentication Data (SAD) related requirements

PA-DSS 1.1.4 - Delete sensitive authentication data stored by previous payment application versions.

No version, previous or current, of Brink POS has ever stored sensitive authentication data including

card numbers, track 2 data, CVV data and PIN's. However, if the application had previously stored

sensitive authentication data the following requirements would apply:

• Historical data must be removed (track data, card verification codes, PINs, or PIN blocks stored

by previous versions of the payment application),

• How to remove historical data.

• Such removal is absolutely necessary for PCI DSS compliance.

PA-DSS 1.1.5 - Delete any sensitive authentication data (pre-authorization) gathered as a result of

troubleshooting the payment application.

No version, previous or current, of Brink POS has ever collected sensitive authentication data including

card numbers, track 2 data, CVV data and PIN's. However, if the application had previously collected

sensitive authentication data for troubleshooting the following requirements would apply:

• Sensitive authentication data (pre-authorization) must only be collected when needed to solve a

specific problem.

• Such data must be stored only in specific, known locations with limited access.

• Only collect a limited amount of such data as needed to solve a specific problem.

• Sensitive authentication data must be encrypted while stored.


7 | P a g e

• Such data must be securely deleted immediately after use.

Installation and Configuration

Components of Brink POS which are installed at the merchant’s site is the POS Register client

application. All other components of the Brink POS system reside in a secure data center. Client

applications should run using a restricted windows user account without administrative privileges.

Client installation Brink POS clients synchronize time to ensure that all nodes are working together. In order to operate the

application under Microsoft Windows without administrator privilege the following Local Security Policy

must be to be granted.

Local Policy > User Right Assignments > Change the system time

When first installing the Brink POS Register application two Windows users accounts will be needed, an

account with administrative rights and another un-privileged account (normal account).

Login into the account with administrative rights and temporarily place the normal account user into the

Administrators group. Once the normal account has elevated rights login with this account and execute

the Brink Client installer .msi file. Once installation is complete, remove the normal account user from

the Administrators group.

PA-DSS 8.2 - Use only necessary and secure services, protocols, components, and dependent software

and hardware, including those provided by third parties.

Protocols Dependent Hardware Dependent Software Services

• TLS (TCP Port 443)

• Brink Service (TCP Port 10051)

• Any Hardware capable of running a supported version Microsoft Windows

• Microsoft Windows Operating System (POSReady 2009, POSReady7, Embedded Industry 8.1)

• Microsoft .Net Framework 4.0

• Microsoft SQL Compact Edition 3.5 SP2

• Not applicable


8 | P a g e

Upgrades

PA-DSS 10.2.x - Securely deliver remote payment application updates.

Brink POS updates are delivered as a digitally signed .msi installation file at the secure request of the

client application. The client application automatically installs the .msi only upon successful verification

of the digital signature.

In the event that a patch or update needs to be applied manually via remote access ensure the

following:

• Change default settings in the remote-access software (for example, change default passwords

and use unique passwords for each customer).

• Allow connections only from specific known addresses.

• Use strong authentication and complex passwords for logins (See PA-DSS Requirements 3.1.1

through 3.1.11).

• Enable encrypted data transmission according to PA-DSS Requirement 12.1.

• Enable account lockout after a certain number of failed login attempts. (See PA-DSS

Requirement 3.1.8.)

• Establish a Virtual Private Network (“VPN”) connection via a firewall before access is allowed.

• Enable the logging function.

• Restrict access to customer environments to authorized integrator/reseller personnel.

• Only activate remote-access technologies for payment application updates when needed for

downloads, and turning access off immediately after download completes, per PCI DSS

Requirement 12.3.9.

• If computer is connected via VPN or other high-speed connection, receive remote payment

application updates via a securely configured firewall or personal firewall per PCI DSS

Requirement 1.


9 | P a g e

Storage & Maintenance

Credit Card Data & Encryption Controls Sensitive cardholder data, such as complete track data or primary account number, is never stored by

the Brink POS application. Credit card data is passed directly to the processor by the component

capturing the data and then immediately discarded.

Merchants can opt to allow for tokens to be stored for future transactions. In such cases, tokens, and

only tokens, are stored using a 3rd party PCI-DSS certified tokenization provider. The Brink POS

application does not store the card number, but rather a token to the card number stored by the

tokenization provider, with the actual card number only being retrieved immediately before processing

a transaction on the card.

PA-DSS 9.1 - Store cardholder data only on servers not connected to the Internet.

No version, previous or current, of Brink POS has ever stored cardholder data including card numbers,

track 2 data, CVV data and PIN's. However, if the application had previously stored cardholder data the

following requirements would apply:

• Do not to store cardholder data on public-facing systems (for example, web server and database

server must not be on same server).

• Use a DMZ to separate the Internet from systems storing cardholder data.

• Only allow services/ports that the application needs to use in order to communicate across two

network zones.

Secure Deletion of Cardholder Data

PA-DSS 2.1 - Securely delete cardholder data after customer-defined retention period.



following requirements would apply:

• Instructions that cardholder data exceeding the customer-defined retention period must be

securely deleted.

• A list of all locations where payment application stores cardholder data, so that customer knows

the locations of data that needs to be deleted.

• Instruction that customers need to securely delete cardholder data when no longer required for

legal, regulatory, or business purposes.


10 | P a g e

• How to securely delete cardholder data stored by the payment application, including data

stored on underlying software or systems (such as OS, databases, etc.).

• How to configure the underlying software or systems (such as OS, databases, etc.) to prevent

inadvertent capture or retention of cardholder data.

Primary Account Number (PAN) Handling

PA-DSS 2.2 - Mask PAN when displayed so only personnel with a business need can see the full PAN.

Masked instances of the PAN are displayed as follows:

• Printed Receipts

• Form Fields Following Authorization

• Credit Card Audit Report

• Business Data Audit Report

Brink POS masks the PAN by default on all displays. This behavior is not configurable.

PA-DSS 2.3 - Render PAN unreadable anywhere it is stored (including data on portable digital media,

backup media, and in logs).

No version, previous or current, of Brink POS has ever stored the PAN. However, if the application had

previously stored the PAN the following requirements would apply:

• Details of any configurable options for each method used by the application to render

cardholder data unreadable, and instructions on how to configure each method for all locations

where cardholder data is stored by the payment application (per PA-DSS Requirement 2.1).

• A list of all instances where cardholder data may be output for the customer to store outside of

the payment application, and instructions that the customer is responsible for rendering PAN

unreadable in all such instances.

Cryptography

PA-DSS 2.4 - Protect keys used to secure cardholder data against disclosure and misuse.



following encryption requirements would apply:

• Restrict access to keys to the fewest number of custodians necessary.

• Store keys securely in the fewest possible locations and forms.


11 | P a g e

PA-DSS 2.5.x - Implement key-management processes and procedures for cryptographic keys used for

encryption of cardholder data.




• How to securely generate, distribute, protect, change, store, and retire/replace cryptographic

keys, where customers or integrators/resellers are involved in these key-management activities.

• A sample Key Custodian Form for key custodians to acknowledge that they understand and

accept their key-custodian responsibilities.

• Generation of strong cryptographic keys.

• Secure cryptographic key distribution.

• Secure cryptographic key storage.

• Cryptographic key changes for keys that have reached the end of their cryptoperiod.

• Retirement or replacement of keys as deemed necessary when the integrity of the key has been

weakened or keys are suspected of being compromised.

• Split knowledge and dual control for any manual clear-text cryptographic key management

operations supported by the payment application.

• Prevention of unauthorized substitution of cryptographic keys.

PA-DSS 2.6.x - Provide a mechanism to render irretrievable cryptographic key material or cryptograms

stored by the payment application.




• Procedures detailing how to use the tool or procedure provided with the application to render

cryptographic material irretrievable.

• That cryptographic key material should be rendered irretrievable whenever keys are no longer

used and in accordance with key-management requirements in PCI DSS.

• Instructions on how to re-encrypt historic data with new keys, including procedures for

maintaining security of clear-text data during the decryption /re-encryption process.

Authentication

PA-DSS 3.1 - Use unique user IDs and secure authentication for administrative access and access to

cardholder data.


12 | P a g e

The Brink POS application has never stored cardholder data, however, the Management Portal facilitates

administrative access.

Access to the Brink POS Admin Portal, where credit card processor and employee/user setup functions

exist, is only available with the use of a unique user id and strong password. No usernames or password

should be shared, and no “generic” accounts should be used. Any default users or accounts should be

disabled, renamed, or changed to use a complex password.

To maintain PCI DSS compliance, any changes made to authentication configurations would need to be

verified as providing authentication methods that are at least as rigorous as PCI DSS requirements.

No default accounts are created following installation. However, if the application were to create default

accounts the following applies:

• For any default accounts that won’t be used, assign secure authentication and then disable or

do not use the accounts.

If authentication credentials are generated but not managed by the Brink POS application (e.g. Microsoft

Windows Operating System accounts) then you must comply with PA-DSS Requirements 3.1.1 through

3.1.11, by the completion of installation and for subsequent changes after installation, for all application

level accounts with administrative access or access to cardholder data.

Clocking into the Brink POS Register requires the user to enter a unique PIN, Magnetic Swipe Card, or

Biometric scan. Setup of register users is only available via the Admin Portal where users are required to

provide a unique user id and strong password.

A strong password:

• Consists of between 8 character and 15 characters

• Must include both numeric and alphabetic characters

• Must be changed at least every 90 days

• Must not be the same as the last 4 passwords, or the current password

Brink POS has implements several secure authentication points per PCI requirements. These

enhancements include:

• All users will be required to enter a unique user PIN, Magnetic Swipe, or Biometric scan when

logging into a Brink POS Register.

• All users with Admin Function access (Credit Card Setup or Edit Employees) will be required to

log in with unique user id and strong password before accessing any admin function.

• Any user who attempts to enter a strong password 6 times, incorrectly, will be locked out of

admin functions for 30 minutes, or until another user with admin access unlocks their account.

PA-DSS 3.2 - Use unique user IDs and secure authentication for access to PCs, servers, and databases

with payment applications.


13 | P a g e

All users and integrators must use unique user names and secure authentication to access any PCs,

servers, and databases with payment applications and/or cardholder data per PA-DSS requirements

3.1.1 through 3.1.11.

PA-DSS 3.3.1 - Use strong cryptography to render all payment application passwords unreadable during

transmission.

Brink POS uses strong cryptography, TLS, to render all passwords unreadable at all times during

transmission.

Audit Trails

PA-DSS 4.1 - Implement automated audit trails.

Brink POS produces a number of different security / credit card related audit logs automatically, none of

which can be disabled. All of these logs are stored in backed up databases on Brink’s centralized, hosted

servers. These audit logs are available via the Reports -> Audits menu in the Brink POS Admin Portal.

They are as follows:

1. Business Date Audit – Details all ordering related operations performed in the system,

including user terminal login, adding/removing items from an order, and tendering/closing an

order. For every operation, date/time, employee, terminal and order id, along with operation

specific details are captured. For credit card sale and refund transactions, card type and last

four digits of card number are captured.

2. Credit Card Audit – Details all credit card activities and captures date/time, terminal, and

employee performing transaction, order id and amount, card type and last four digits of card

number, whether or not the card was present, the type of transaction being performed (i.e.

Sale, Void, Adjust), whether or not the transaction succeeded, and processor specific details of

the transaction (i.e. error message or authorization code). 3. Location Security Audit – Details all location specific Brink POS Admin Portal operations,

primary involving settings accesses and changes. Captures, date/time, location name,

terminal, user, operation type, success/failure, and operation specific details.

4. Group Security Audit – Details all restaurant group specific Brink POS Admin Portal operations,

including login attempts/failures, account lockouts, password changes, and group settings

accesses and changes. These are operations that are not specific to a particular location, but

the restaurant group as a whole. Captures, date/time, location name, terminal, user,

operation type, success/failure, and operation specific details, such as the username of an

account that was changed.


14 | P a g e

Brink POS does not package any third party components that result in logging. Though it is not possible

to disable logging and audits in Brink POS disabling any application logs would result in non-compliance

with PCI DSS.

PA-DSS 4.4 - Facilitate centralized logging.

Beyond the automated audit trails listed above, centralized logging may be facilitated by exporting the

‘Brink’ Windows Event log that is present wherever the Brink POS Register application is installed. Any

standard log export tools that support Windows Event logging may be used.

Versioning Methodology

PA-DSS 5.4 - Implement and communicate application versioning methodology.

Brink POS uses a Major, Minor, Build methodology for versioning, for example Brink POS 5.0.46.

In this example the Major number is 5, the Minor number is 0 and the Build number is 46. Changes

made to the application at the Major level may or may not affect PCI compliance. Significant functional

enhancements made to the Brink POS suite may increment the Major or Minor version.

Brink POS PA-DSS certifications will use wildcards for the right most number of the application version

for non-PCI impacting changes, for example Brink POS 5.0.x.

Remote Access

If your organization enables remote access to the network for use by employees, administration, and

vendors, you must implement two-factor authentication for logins. Two-factor authentication requires

the unique login credentials and an additional authentication item such as a token or individual

certificate.

PA-DSS 10.1 - Implement two-factor authentication for all remote access to payment application that

originates from outside the customer environment.

• All remote access originating from outside the customer’s network to the payment application

must use two-factor authentication in order to meet PCI DSS requirements.

PA-DSS 12.x - Encrypt non-console administrative access.

Brink POS does not implement non-console based access. However the underlying operating system can

via RDP protocol. Ensure the following requirements are met:

• Use strong cryptography (such as SSH, VPN, or TLS) for encryption of all non-console

administrative access to payment application or servers in cardholder data environment.


15 | P a g e

Wireless Technology

PA-DSS 6.x - Securely implement wireless technology.

Brink POS does not ship with or require any wireless technologies. However, if Brink POS is

implemented with wireless technology then you must meet these requirements:

• Change any default encryption keys, passwords and SNMP community strings.

• Install a firewall between any wireless networks and systems that store cardholder data.

• Configure firewalls to deny or (if such traffic is necessary for business purposes) permit only

authorized traffic between the wireless environment and the cardholder data environment.

Encryption of Data Sent over Public Networks

PA-DSS 11.1 - Secure transmissions of cardholder data over public networks.

Brink POS clients communicate directly with credit card processors over public networks. All

communications occur over secure TLS sessions using trusted certificates. This behavior is defaulted and

is not configurable. If this were to be configurable the following requirements apply:

• Use of strong cryptography and security protocols if cardholder data is ever transmitted over

public networks.

• Verify that only trusted keys and/or certificates are accepted.

• Use only secure versions and secure implementations of security protocols.

• Configure the payment application to use the proper encryption strength for the encryption

methodology in use.

PCI DSS requires specific methods be used to transmit cardholder data over the internet or other public

networks. Brink POS meets these standards by using strong cryptography and encryption techniques at

the transport layer with TLS, to encrypt credit card data sent to the credit card processor.

PA-DSS 11.2 - Encrypt cardholder data sent over end-user messaging technologies.

No version, previous or current, of Brink POS has ever sent cardholder data including card numbers,

track 2 data, CVV data and PIN's over end-user messaging technologies. However, if the application had

previously sent cardholder data the following requirements would apply:

• Render the PAN unreadable or secure the PAN with strong cryptography.

• PAN must always be rendered unreadable or secured with strong cryptography whenever it is

sent via end-user messaging technologies.


16 | P a g e

Network Segmentation Network segmentation of, or isolating (segmenting), the cardholder data environment from the

remainder of the corporate network is not a PCI DSS requirement. However, it is recommended as a

method that may reduce:

• The scope of the PCI DSS assessment

• The cost of the PCI DSS assessment

• The cost and difficulty of implementing and maintaining PCI DSS controls

• The risk to an organization (reduced by consolidating cardholder data into fewer, more

controlled locations)

Without adequate network segmentation (sometimes called a "flat network") the entire network is in

scope of the PCI DSS assessment. Network segmentation can be achieved through internal network

firewalls, routers with strong access control lists or other technology that restricts access to a particular

segment of a network.

See Appendix A: Recommended Network Configuration Diagram for additional details.

Router and Firewall

All systems should establish firewall and router configuration standards that include the following:

• A formal process for approving and testing all network connections and changes to the firewall

and router configurations

• Current network diagram with all connections to cardholder data, including any wireless

networks

• Requirements for a firewall at each Internet connection and between any demilitarized zone

(DMZ) and the internal network zone

• Description of groups, roles, and responsibilities for logical management of network

components

• Documentation and business justification for use of all services, protocols, and ports allowed,

including documentation of security features implemented for those protocols considered to be

insecure

o Verify that firewall and router configuration standards include a documented list of

services, protocols and ports necessary for business—for example, hypertext transfer

protocol (HTTP) and Secure Sockets Layer (SSL), Secure Shell (SSH), and Virtual Private

Network (VPN) protocols.


17 | P a g e

o Identify insecure services, protocols, and ports allowed; and verify they are necessary

and that security features are documented and implemented by examining firewall and

router configuration standards and settings for each service. An example of an insecure

service, protocol, or port is FTP, which passes user credentials in clear-text.

• Requirement to review firewall and router rule sets at least every six months

You should also build a firewall configuration that restricts connections between untrusted networks

and any system components in the cardholder data environment.

• An “untrusted network” is any network that is external to the networks belonging to the entity

under review, and/or which is out of the entity's ability to control or manage.

• Restrict inbound and outbound traffic to that which is necessary for the cardholder data

environment.

• Secure and synchronize router configuration files.

• Install perimeter firewalls between any wireless networks and the cardholder data environment,

and configure these firewalls to deny or control (if such traffic is necessary for business

purposes) any traffic from the wireless environment into the cardholder data environment.

Anti-Virus Software

Deploy anti-virus software on all systems commonly affected by malicious software (particularly

personal computers and servers).

• Ensure that all anti-virus programs are capable of detecting, removing, and protecting against all

known types of malicious software.

• Ensure that all anti-virus mechanisms are current, actively running, and capable of generating

audit logs.

Merchant Information Security Policy/Program

In addition to the preceding security recommendations, a comprehensive approach to assessing and

maintaining the security compliance of the payment application environment is necessary to protect the

organization and sensitive cardholder data.

The following is a very basic plan every merchant should adopt in developing and implementing a

security policy and program:


18 | P a g e

• Read the PCI DSS in full and perform a security gap analysis. Identify any gaps between existing

practices in your organization and those outlined by the PCI requirements.

• Once the gaps are identified, determine the steps to close the gaps and protect cardholder data.

Changes could mean adding new technologies to shore up firewall and perimeter controls, or

increasing the logging and archiving procedures associated with transaction data.

• Create an action plan for on-going compliance and assessment.

• Implement, monitor and maintain the plan. Compliance is not a one-time event. Regardless of

merchant or service provider level, all entities should complete annual self-assessments using

the PCI Self-Assessment Questionnaire.

• Call in outside experts as needed. Visa has published a Qualified Security Assessor List of

companies that can conduct on-site CISP compliance audits for Level 1 Merchants, and Level 1

and 2 Service Providers. MasterCard has published a Compliant Security Vendor List of SDP-

approved scanning vendors as well.

The following high level 12 Requirements comprise the core of the PCI DSS and should be covered by the

merchant's Information Security Policy/Program:

SECTION GENERAL REQUIREMENT

Build and Maintain a Secure Network

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

Protect Cardholder Data 3. Protect stored cardholder data. 4. Encrypt transmission of cardholder data across open, public networks.

Maintain a Vulnerability Management Program

5. Use and regularly update anti-virus software or programs. 6. Develop and maintain secure systems and applications.

Implement Strong Access Control Measures

7. Restrict access to cardholder data by business need-to know. 8. Assign a unique ID to each person with computer access. 9. Restrict physical access to cardholder data.

Regularly Monitor and Test Networks

10. Track and monitor all access to network resources and cardholder data. 11. Regularly test security systems and processes.

Maintain an Information Security Policy

12. Maintain a policy that addresses information security.


19 | P a g e

Visa’s Validation Requirements

Visa states “CISP (Cardholder Information Security Program) compliance is required of all entities that

store, process or transmit Visa cardholder data.” To be CISP compliant a business must be PCI DSS

Compliant and meet Visa’s validation requirements. The validation requirements vary depending upon

the size of the merchant, as listed here:

• Level 1 Merchants (merchants processing over 6 million transactions per year) must:

o Have an annual audit by a Qualified Security Assessor

o Have Quarterly ASV Scans

• Level 2 Merchants (merchants processing 1 million to 6 million transactions per year)

o Fill out an annual Self-Assessment Questionnaire


o Fill out an Attestation of Compliance form

• Level 3 Merchants (merchants processing over 20,000 e-commerce transactions per year)



o Fill out an Attestation of Compliance form

• Level 4 Merchants (merchants processing less than 1 million transaction per year or less than

20,000 e-commerce transaction per year)



Most Brink POS users will fall into the Level 4 category. Our Links to More Information section provides

a link to the Self Assessment Questionnaire and the Attestation of Compliance form on the PCI SSC

website, as well as a link to Approved PCI Scanning Vendors.

Troubleshooting & Support

Partech Customer Support will never ask a customer to reveal sensitive credit card data for problem

troubleshooting. We may ask for non-sensitive data like type of card or last four digits of card number.

If someone posing as Partech Support asks for sensitive credit card information while troubleshooting a

software issue, please report the technician’s name in a separate phone call to the Partech Support

Manager at 800-403-9027 x2.

Any database sent to Partech Customer Support for backup or troubleshooting purposes will never

contain any sensitive credit card information as this information is never stored by the Brink POS

system.

https://www.pcisecuritystandards.org/saq/instructions_dss.shtmlhttps://www.pcisecuritystandards.org/security_standards/pci_dss_supporting_docs.shtmlhttps://www.pcisecuritystandards.org/pdfs/asv_report.html


20 | P a g e

Dependencies

Point Secure Commerce Application (SCA) MX, 2.19.06

DataCap NETePay with dsiPDCX v2.50.3862, Mercury DSIClient v2.50.3862

Links to More Information

The PCI Security Standards Council

https://www.pcisecuritystandards.org/

Mercury Payment Systems Card Data Security

http://www.mercurypay.com/security-help.htm

Visa’s Cardholder Information Security Program

http://www.visa.com/cisp

PCI SSC Self-Assessment Questionnaire

https://www.pcisecuritystandards.org/saq/instructions_dss.shtml

Attestation of Compliance Form

https://www.pcisecuritystandards.org/security_standards/pci_dss_supporting_docs.shtml

Approved PCI Scanning Vendors

https://www.pcisecuritystandards.org/pdfs/asv_report.html


21 | P a g e

POS Firewall

With SPI

Register N

Kitchen N

Public Internet

Management

PC

Kitchen Printer N

Register 1

Network Switch

Company

Firewall

High Speed Internet

(DSL/Cable Modem)

Sample Merchant Network

Configuration

Appendix A: Recommended Network Configuration Diagram

Documents

Brink POS PA-DSS Implementation Guidecdn.brinkpos.net/docs/PA-DSS Implementation Guide.pdf• Such removal is absolutely necessary for PCI DSS compliance. PA-DSS 1.1.5 - Delete any