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
3/1/2016 1.8.0 Brett Clapham Update for v3.6
7/30/2015 1.7.0 Brett Clapham Update for v3.5
6/17/2015 1.6.0 Brett Clapham Update for v3.5
09/08/2014 1.5.0 Michael Demler Update for v3.3
01/30/2014 1.4.0 Michael Demler Update for v3.2
09/13/2013 1.3.0 Michael Demler Update for v3.1
02/04/2013 1.2.0 Michael Demler Update for v3.0
11/10/2012 1.1.0 Michael Demler Update for v2.4
07/20/2010 1.0.0 Richard Elliott Initial Release
Brink POS Customer Implementation Guide
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.
Brink POS Customer Implementation Guide
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
Brink POS Customer Implementation Guide
5 | P a g e
Brink POS Customer Implementation Guide
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.
Brink POS Customer Implementation Guide
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
Brink POS Customer Implementation Guide
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.
Brink POS Customer Implementation Guide
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.
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:
• 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.
Brink POS Customer Implementation Guide
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.
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 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.
Brink POS Customer Implementation Guide
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.
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 encryption requirements would apply:
• 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.
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 encryption requirements would apply:
• 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.
Brink POS Customer Implementation Guide
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.
Brink POS Customer Implementation Guide
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.
Brink POS Customer Implementation Guide
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.
Brink POS Customer Implementation Guide
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.
Brink POS Customer Implementation Guide
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.
Brink POS Customer Implementation Guide
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:
Brink POS Customer Implementation Guide
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.
Brink POS Customer Implementation Guide
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 Have Quarterly ASV Scans
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 annual Self-Assessment Questionnaire
o Have Quarterly ASV Scans
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)
o Fill out an annual Self-Assessment Questionnaire
o Have Quarterly ASV Scans
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
Brink POS Customer Implementation Guide
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
Brink POS Customer Implementation Guide
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