rb control systems payment application version 2.0 pa-dss ... · standards of pci dss v3.2 and...

v

RB Control Systems Payment Application Version 2.0

PA-DSS 3.2 Implementation Guide

Document Version 2.0

12/27/2016

Author: Tyler Brandt

Document Owner Tyler Brandt

Director of Product Development

Confidential Information

The information contained in this document is RB

Control Systems confidential. Distribution of this

document outside of RB Control Systems is strictly

prohibited. Do not copy or distribute without the

permission of the Chief Technology Officer.

Copyright 2016, RB Control Systems.

Proprietary and Confidential Information 2

Contents 1 NOTICE ........................................................................................................................................................... 4

2 ABOUT THIS DOCUMENT ................................................................................................................................ 5

3 REVISION INFORMATION ............................................................................................................................... 5

4 EXECUTIVE SUMMARY ................................................................................................................................... 8

4.1 PCI Security Standards Council Reference Documents ................................................................................ 8

4.2 Application Summary ................................................................................................................................... 9

4.3 Typical Network Implementation .............................................................................................................. 12

4.4 Dataflow Diagram ...................................................................................................................................... 14

4.4.1 Using Unencrypted Peripherals .............................................................................................................. 14

4.4.2 Using an Encrypted Device ..................................................................................................................... 15

4.5 Difference between PCI Compliance and PA-DSS Validation ..................................................................... 15

4.6 The 12 Requirements of the PCI DSS: ........................................................................................................ 16

5 CONSIDERATIONS FOR THE IMPLEMENTATION OF THE RB CONTROL SYSTEMS PAYMENT APPLICATION IN A

PCI-COMPLIANT ENVIRONMENT .......................................................................................................................... 18

5.1 Remove Historical Sensitive Authentication Data (PA-DSS 1.1.4) .............................................................. 18

5.2 Sensitive Authentication Data requires special handling (PA-DSS 1.1.5) ................................................... 18

5.3 Purging of Cardholder Data (PA-DSS 2.1) ................................................................................................... 19

5.4 All PAN is Masked by Default (PA-DSS 2.2) ................................................................................................ 19

5.5 Cardholder Data Encryption & Key Management (PA-DSS 2.3, 2.4, and 2.5) ............................................ 19

5.6 Removal of Cryptographic material (PA-DSS 2.6) ...................................................................................... 20

5.7 Set up Strong Access Controls (PA-DSS 3.1 and 3.2) .................................................................................. 20

5.8 Properly Train and Monitor Admin Personnel ........................................................................................... 21

5.9 Log settings must be compliant (PA-DSS 4.1.b, 4.4.b) ............................................................................... 21

5.10 PCI-Compliant Wireless settings (PA-DSS 6.1.a and 6.2.b)......................................................................... 22

5.11 PCI-Compliant Delivery of Updates (PA-DSS 7.2.3) .................................................................................... 23

5.12 Services and Protocols (PA-DSS 8.2.c) ........................................................................................................ 24

5.13 Never store cardholder data on internet-accessible systems (PA-DSS 9.1.c) ............................................ 24

5.14 PCI-Compliant Remote Access (10.1) ......................................................................................................... 25

5.15 Vulnerability Identification and Remediation ............................................................................................ 25

5.16 PCI-Compliant Remote Access (10.2.3.a) ................................................................................................... 26

5.17 Data Transport Encryption (PA-DSS 11.1.b) ............................................................................................... 27

5.18 PCI-Compliant Use of End User Messaging Technologies (PA-DSS 11.2.b) ................................................ 28

5.19 Non-console administration (PA-DSS 12.1) ................................................................................................ 28



5.20 Network Segmentation .............................................................................................................................. 28

5.21 Maintain an Information Security Program ............................................................................................... 28

5.22 Application System Configuration .............................................................................................................. 29

5.23 Payment Application Initial Setup & Configuration ................................................................................... 29

6 ADDRESSING INADVERTENT CAPTURE OF PAN ............................................................................................ 30

6.1 Addressing Inadvertent Capture of PAN on Windows 7 ............................................................................ 30

6.1.1 Disabling System Restore ....................................................................................................................... 30

6.1.2 Encrypting PageFile.sys .......................................................................................................................... 31

6.1.3 Clear the System Pagefile.sys on shutdown ........................................................................................... 32

6.1.4 Disabling System Management of PageFile.sys ..................................................................................... 33

6.1.5 Disabling Windows Error Reporting ....................................................................................................... 36

6.2 Addressing Inadvertent Capture of PAN on Windows 8 ............................................................................ 37






6.3 Addressing Inadvertent Capture of PAN on Windows 10 .......................................................................... 46






6.4 Addressing Inadvertent Capture of PAN – Server OS ................................................................................. 56





1 Notice

THE INFORMATION IN THIS DOCUMENT IS FOR INFORMATIONAL PURPOSES ONLY. RB

CONTROL SYSTEMS MAKES NO REPRESENTATION OR WARRANTY AS TO THE ACCURACY OR

THE COMPLETENESS OF THE INFORMATION CONTAINED HEREIN. YOU ACKNOWLEDGE AND

AGREE THAT THIS INFORMATION IS PROVIDED TO YOU ON THE CONDITION THAT NEITHER RB

CONTROL SYSTEMS NOR ANY OF ITS AFFILIATES OR REPRESENTATIVES WILL HAVE ANY

LIABILITY IN RESPECT OF, OR AS A RESULT OF, THE USE OF THIS INFORMATION. IN ADDITION,

YOU ACKNOWLEDGE AND AGREE THAT YOU ARE SOLELY RESPONSIBLE FOR MAKING YOUR

OWN DECISIONS BASED ON THE INFORMATION HEREIN.

Nothing herein shall be construed as limiting or reducing your obligations to comply with any

applicable laws, regulations or industry standards relating to security or otherwise including, but

not limited to, PA-DSS and DSS.

The retailer may undertake activities that may affect compliance. For this reason, RB Control

Systems is required to be specific to only the standard software provided by it.



2 About this Document

This document describes the steps that must be followed in order for your RB Control Systems

Payment Application 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.2 dated April 2016).

RB Control Systems instructs and advises its customers to deploy RB Control Systems

applications in a manner that adheres to the PCI Data Security Standard (v3.2). 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.

You must follow the steps outlined in this Implementation Guide in order for your RB Control

Systems Payment Application installation to support your PCI DSS compliance efforts.

3 Revision Information

Name Title Date of Update Summary of Changes

Tyler Brandt Director of Product

Development

9/30/2014 Document Creation


Development

10/8/2014 Updated the Application Description,

Stored Cardholder Data, Application

Authentication, Application

Encryption, Payment Processing

Connections, and Network Diagram


Development

11/12/2014 Updated the Initial Setup &

Configuration, Network Diagram, and

Data Flow Diagram


Development

9/7/2015 Yearly review of Implementation

Guide




Development

8/23/2016 Updated documentation to meet the

standards of PCI DSS v3.2 and refer to

the new section numbers provided by

the PCI DSS v3.2, updated PAQSA

contact information, added section

All PAN is Masked by Default (PA-DSS

2.2), reworded section 5.4 PCI-

Compliant Deliver of Updates to

better explain processes, and added

additional requirements to prevent

inadvertent capture of PAN


Development

11/15/2016 Updated App version from 1.0 to 2.0,

updated PA-DSS version number,

deprecated SSL, corrected date on

revision information, added masked

credit card number locations,

updated versioning information,

updated section numbering, updated

when community strings, passwords,

and encryption keys need to be

changed, added section for secure

updates (PA-DSS 7.2.3 requirements)


Development

11/17/2016 Updated versioning, updated wireless

setting requirements, added

additional details to the delivery of

updates


Development

11/23/2016 Updated Typical Network

Implementation flowchart and

description, updated logging

information to accurate reflect

capabilities


Development

12/5/2016 Update Network Diagram, updated

wording of flowchart description,

updated audit log information


Development

12/27/2016 Updated Dataflow Diagram to show

the Internet

Note: This PA-DSS Implementation Guide 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. RB Control Systems will distribute the IG to new customers via



electronic copy distributed by email at the time of installation as well as maintaining an up to

date copy on our website.



4 Executive Summary

Payment Application version 2.0 has been PA-DSS (Payment Application Data Security Standard)

certified, with PA-DSS Version 3.2. For the PA-DSS assessment, we worked with the following PCI

SSC approved Payment Application Qualified Security Assessor (PAQSA):

Coalfire Systems, Inc.

11000 Westmoor Circle, Suite 450

Louisville, CO 80021

Coalfire Systems, Inc.

1633 Westlake Ave N #100

Seattle, WA 98109

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 the RB Control

Systems Payment Application as a PA-DSS validated Application operating in a PCI Compliant

environment.

4.1 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):

Payment Applications Data Security Standard (PA-DSS)

https://www.pcisecuritystandards.org/security_standards/index.php

Payment Card Industry Data Security Standard (PCI DSS)

https://www.pcisecuritystandards.org/security_standards/index.php

Open Web Application Security Project (OWASP)

http://www.owasp.org

Center for Internet Security (CIS) Benchmarks (used for OS Hardening) https://benchmarks.cisecurity.org/downloads/multiform/

https://www.pcisecuritystandards.org/security_standards/index.phphttps://www.pcisecuritystandards.org/security_standards/index.phphttp://www.owasp.org/https://benchmarks.cisecurity.org/downloads/multiform/



4.2 Application Summary

Payment Application

Name: RB Control Systems Payment Application

Payment Application

Version: 2.0

Application Description:

The RB Control Systems Payment Application is an application that

handles the collection and passing through of credit and debit card

information to the credit card processor on behalf of another

application. It is designed to be invoked, process the card

information, and then return the result. The RB Control Systems

Payment Application remains lightweight by never storing actual

card data. Payment card data only remains in the memory of the

PC long enough to be passed through to the processor.

The RB Control Systems Payment Application handles the following:

credit card sales

credit card refunds

debit card sales

debit card refunds

credit card tokenization

credit card pre auth

credit card post auth

credit card transaction void

The RB Control Systems Payment Application can handle input from

a credit card swipe, keyboard, and pin pad.

The RB Control Systems Payment Application is distributed

alongside the RB Control Systems software. The use of the RB

Control Systems Payment Application removes the RB Control

Systems software from the scope of PA-DSS.

Typical Role of

Application:

The RB Control Systems Payment Application is lightweight

payment application designed to securely pass credit card

information from the user to the processor and return the response

of the transaction. The information passed by the RB Control

Systems Payment Application can be used by point of sale systems

in order to allow the use of credit card payments while remaining

out of scope.

Application Target

Clientele:

The RB Control Systems Payment Application is designed for use by

point of sale and business management software.

Stored Cardholder Data: The RB Control Systems Payment Application does not store any

cardholder data.

Components of the

Payment Application

RBPaymentApp.exe: Primary application handling taking

payments, adding credit cards on file, and changing application

settings



Rbcs.DeviceManager.exe: Application used in the communication

between the RB Control Systems Payment Application and attached

devices

Required Third Party

Payment Application

Software:

-none-

Database Software

Supported: -none-

Other Required Third

Party Software: -none-

Operating System(s)

Supported:

Microsoft Windows 7 SP 1


Microsoft Windows 10

Microsoft Windows Server 2003 SP 2



Application

Functionality Supported

Select one or more from the following list:

POS Suite POS Admin Shopping Cart

& Store Front

POS Face-

To-Face

X Payment

Middleware

Others

(Please

Specify):

POS Kiosk Payment Back

Office

POS

Specialized

Payment

Gateway/Switch

Payment Processing

Connections:

The RB Control System Payment Application will be invoked by a

separate software in order to process credit and debit card

payments. When invoked, the payment amount will be passed to

the RB Control Systems Payment Application by TCP through a JSON

string. Credit card data is collected by the PC using either a credit

card swipe or manually entered from the keyboard. For debit cards,

the encrypted pin block is collected from the Device Manager via TCP

connection. The Device Manager is simply a service listening for

data from the connected device. Once the PC has collected all card

information, it passes this information as a JSON string to the

processor via the processor's API. The response of the processor

which contains no sensitive credit card data is then passed through

the RB Control Systems Payment Application to the software that

originally invoked the RB Control Systems Payment Application via a

JSON string.

At no point in time does the RB Control Systems Payment

Application store any sensitive credit card data. All payment

information is stored in the memory of the PC only so long as to pass

it through to the processor.



Application

Authentication

For any administrative functionality, users are required to enter a

username and password. This password must be at least 7

characters long, containing both letters and numbers. This

password must be changed every 90 days.

All authentication credentials and merchant parameters are stored

encrypted in the file RbPaymentApp.Data.sjson by the RB Control

Systems Payment Application at the time of saving.

Application Encryption

The RBPaymentApp.Data.sjson file is created in the following

manner. For passwords, PBKDF2-SHA1 is used to create an initial

salted one way hash. That hash is sent to

RNGCryptoServiceProvider with a salt in order to create a final

hash. This hash is then stored Triple-DES encrypted.

Description of

Versioning

Methodology:

The RB Control Systems Payment Application uses a series of 4

numbers to define the current version. The format of these

numbers are xxx.xxx.xxx.xxx. The first set contains the Major

version number followed by the Minor, Build, and Revision versions.

A Major version is updated when the scope of the application has

changed. This includes the addition of any new features or

functionality not included in the original design.

A Minor version is updated when a front end change is made to the

application that updates the usability of the application without

changing the functionality of it. This also includes changes made in

order to maintain the security of the application.

A Build version is updated when a collection of Revisions are sent

as an update to the user. Changes to the Build version will NEVER

be used to indicate security-impacting changes.

A Revision version is updated in house when a bug is fixed within

the application. Changes to the Revision version will NEVER be

used to indicate security-impacting changes. Once a collection of

Revisions are sent as an update, the Build version will change.

Based on the above versioning methodology, the application

version being listed with the PCI SSC is 2.0.x.x. Wildcard version

changes will never be used to represent security-impacting

changes.

List of

Resellers/Integrators

(If Applicable):

-none-



4.3 Typical Network Implementation

*Red lines represent the transfer of unencrypted data and green lines represent the transfer of

encrypted data.

Each machine no matter whether it is a POS, Back Office, or Server has complete functionality of

the RB Control Systems Payment Application. Each machine can also connect to its own

peripherals such as credit card swipes and pin pads individually. The RB Control Systems

Payment Application does not store cardholder data in any way, however, merchant setup

information and user credentials are stored on the server and shared out to POS and Back Office

machines on the network using simple file sharing.

1. When using unencrypted devices to collect sensitive data (keyboards or mag stripe

readers), the payment application will collect the information passed to it and send the

data through an encrypted protocol when communicating with the processor.

2. When using an encrypted device, the RB Control Systems Payment Application will send

the requested payment amount to the encrypted device. All collection of sensitive data

is done by the device itself and the communication to the processor is done by the

encrypted device itself.

3. All computers need to be connected via a wired connection. We do not support a

wireless connection.



4. A secure firewall should be in place to protect the integrity of the local network. Any

device accessible from the internet should be separated behind a firewall from

computers collecting card holder data.

5. Communication will take place through the internet with the Credit Card Processor

through a TLS connection.

6. The Credit Card Processor will respond with the status of inquiries. This status does not

contain any sensitive data.



4.4 Dataflow Diagram

4.4.1 Using Unencrypted Peripherals

*Colored lines represent data flow

-Red lines represent unencrypted sensitive credit card data

-Green lines represent encrypted sensitive credit card data

-Black lines represent data that is not considered sensitive credit card data

1. The credit card is swiped by a mag strip reader or manually entered from a keyboard.

2. The PC displays a masked credit card number, expiration date, cardholder name, CVV,

zip code, and street address. The PC sends the payment information to the Payment

Processor based on their own API settings through a TLS connection over the internet.

Once the cardholder data has been passed to the processor, it is removed from

memory.

3. The Payment Processor returns the authorization response which contains no sensitive

cardholder data.



*The RB Control Systems Payment Application does not handle settling batches or chargebacks. These

will both be done directly through the Credit Card Processor through other means.

4.4.2 Using an Encrypted Device

*Colored lines represent data flow

-Green lines represent encrypted sensitive credit card data

-Black lines represent data that is not considered sensitive credit card data

*There is no clear-text sensitive data in this deployment scenario

1. The PC sends a request to the Device Manager to receive a payment.

2. The Device Manager forwards the request to the appropriate Encrypted Device.

3. The Encrypted Device collects all sensitive credit card data and communicates directly to

the processor in order to receive a response on the status of the payment.

4. The response is sent back through the Device Manager to the PC.

*The RB Control Systems Payment Application does not handle settling batches or chargebacks. These

will both be done directly through the Credit Card Processor through other means.

4.5 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 Payment Application 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 the Payment Application will help you achieve

and maintain PCI Compliance with respect to how Payment Application 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.

4.6 The 12 Requirements of the PCI DSS:

Build and Maintain a Secure Network

1. Install and maintain a firewall configuration to protect data

2. Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data

3. Protect Stored Data

4. Encrypt transmission of cardholder data and sensitive information across public

networks

Maintain a Vulnerability Management Program

5. Use and regularly update anti-virus software

6. Develop and maintain secure systems and applications

Implement Strong Access Control Measures

7. Restrict access to 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



5 Considerations for the Implementation of the RB Control

Systems Payment Application 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 internet-accessible systems

Use TLS for Secure Data Transmission

Delivery of Updates in a PCI Compliant Fashion

5.1 Remove Historical Sensitive Authentication Data (PA-

DSS 1.1.4)

Previous versions of the RB Control Systems Payment Application did not store sensitive

authentication data. Therefore, there is no need for secure removal of this historical data by the

application as required by PA-DSS v3.2.

5.2 Sensitive Authentication Data requires special handling

(PA-DSS 1.1.5)

RB Control Systems 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

5.3 Purging of Cardholder Data (PA-DSS 2.1)

The RB Control Systems Payment Application does not store cardholder data and therefore

there is no data to be purged by the application as required by PA-DSS v3.2.

Any cardholder data you store outside of the application must be documented and you must

define a retention period at which time you will purge (render irretrievable) the stored

cardholder data.

It is your responsibility to maintain your own network and hardware in order to prevent any

capturing of card data without your consent. This includes but is not limited to restricting access

to the operating system using unique user logins, staying up to date with operating system

updates, maintaining a secure firewall, and running secure anti-virus programs on a routine

schedule.

5.4 All PAN is Masked by Default (PA-DSS 2.2)

RB Control Systems Payment Application does not have the ability to display full PAN for any

reason and therefore there is no configuration details to be provided as required for PA-DSS

v3.2.

RB Control Systems will only display masked card information where needed. This can be seen

on customer copy of receipts, merchant copy of receipts, batch reports, itemized payment

reports, and when selecting a credit card on file.

5.5 Cardholder Data Encryption & Key Management (PA-DSS

2.3, 2.4, and 2.5)

RB Control Systems Payment Application does not store cardholder data in any way nor does it

provide any configurability that would allow a merchant to store cardholder data, therefore no

encryption of cardholder data is required for PA-DSS v3.2.



5.6 Removal of Cryptographic material (PA-DSS 2.6)

Previous versions of the RB Control Systems Payment Application never used encryption and

therefore there is no cryptographic data to be securely removed as required by PA-DSS v3.2.

5.7 Set up Strong Access Controls (PA-DSS 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.

All authentication credentials are generated and managed by the RB Control Systems Payment

Application. Secure authentication is enforced automatically by the payment application for all

credentials by 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 recreate existing accounts).

To maintain PCI DSS compliance, the RB Control Systems Payment Application follows these 11

points as per the PCI DSS:

1. The payment application must not use or require the use of default administrative accounts for other necessary or required software (for example, database default administrative accounts) (PCI DSS 2.1 / PA-DSS 3.1.1)

2. The payment application must enforce the changing of all default application passwords for all accounts that are generated or managed by the application, by the completion of installation and for subsequent changes after the installation (this applies to all accounts, including user accounts, application and service accounts, and accounts used by RB Control Systems for support purposes) (PCI DSS 2.1 / PA-DSS 3.1.2)

3. The payment application must assign unique IDs for all user accounts. (PCI DSS 8.1.1 / PA-DSS 3.1.3)

4. The payment application must provide at least one of the following three methods to authenticate users: (PCI DSS 8.2 / PA-DSS 3.1.4)

a. Something you know, such as a password or passphrase b. Something you have, such as a token device or smart card c. Something you are, such as a biometric

5. The payment application must NOT require or use any group, shared, or generic accounts and passwords (PCI DSS 8.5 / PA-DSS 3.1.5)

6. The payment application requires passwords must to be at least 7 characters and includes both numeric and alphabetic characters (PCI DSS 8.2.3 / PA-DSS 3.1.6)

7. The payment application requires passwords to be changed at least every 90 days (PCI DSS 8.2.4 / PA-DSS 3.1.7)

8. The payment application keeps password history and requires that a new password is different than any of the last four passwords used (PCI DSS 8.2.5 / PA-DSS 3.1.8)



9. The payment application limits repeated access attempts by locking out the user account after not more than six logon attempts (PCI DSS 8.1.6 / PA-DSS 3.1.9)

10. The payment application sets the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID. (PCI DSS 8.1.7 / PA-DSS 3.1.10)

11. The payment application requires the user to re-authenticate to re-activate the session if the application session has been idle for more than 15 minutes. (PCI DSS 8.1.8 / PA-DSS 3.1.11)

5.8 Properly Train and Monitor Admin Personnel

It is your responsibility to institute proper personnel management techniques for allowing

admin user access to merchant parameters, logs, etc.

In most systems, a security breach is the result of unethical personnel. So pay special attention

to whom you trust into your admin.

5.9 Log settings must be compliant (PA-DSS 4.1.b, 4.4.b)

4.1.b: The RB Control Systems Payment Application 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 the RB Control Systems Payment Application in any way will result in non-

compliance with PCI DSS.

Because the RB Control Systems Payment Application does not store cardholder data, users will

not be able to access this information. Logs will be created whenever the following actions

occur:

The user has accessed the administrator console in order to set up merchants, modify

users, or view audit logs.

The user has entered an incorrect username and/or password in attempt to access the

administrator console.

The RB Control Systems Payment Application (and subsequently logging for the RB

Control Systems Payment Application) has been started or stopped.

4.4.b: The RB Control Systems Payment Application allows the viewing of all log files. From the

administrator console, users are able to see logs across all machines using the RB Control

Systems Payment Application.

The RB Control Systems Payment Application also supports centralized logging that can monitor

and read pipe (|) delimited files. Centralized log servers should monitor files at least daily

located at v:\RBPaymentApp named pci_access_audit_log_{Computer Name}_{Register Name}

where {Computer Name} is the name of the computer in which the RB Control Systems Payment



Application is installed on, and {Register Name} is the RB Payment Application designated name

for that computer. There will be a separate log file in this location for each computer that uses

the RB Control Systems Payment Application, so the centralized log server should read the

entries from each of these files. These files should be monitored for changes, and the records

within them should be read and written to the centralized log server with the chosen centralized

logging mechanism.

Logs are created containing the following information in a pipe (|) delimited file for use in the

centralized log server:

Date and Time

Thread

Log Level

Log Utility Name

Computer Name where log originated

Register Name where log originated

Action Type

User ID

Payment Application Username

Originating Function of Event

Event Description

Additional Event Information Source

Success Flag

An example of a couple records within the log is…

2016-12-05 16:44:30,508|9|INFO |PCIAccessLogger|JCP-RBCS-

WIN7|_testmelicense|APPLICATION_START|NA|NA|ProgramInitialization|Application is

starting|RB|TRUE

2016-12-05 16:49:07,735|9|INFO |PCIAccessLogger|JCP-RBCS-

WIN7|_testmelicense|USER_ACTION|RBADMINID|rbadmin|ProcessorAdminControl|Saving

processor configuration.||TRUE

The RB Control Systems Payment Application audit logs should be backed up regularly in order

to protect the integrity of the logs. Monitoring of the RB Control Systems Payment Application

audit logs should be done at least daily to note logs where the Success Flag is marked as FALSE

in order to identify potential issues and suspicious activity.

5.10 PCI-Compliant Wireless settings (PA-DSS 6.1.a and 6.2.b)



The RB Control Systems Payment Application does 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:

2.1.1: Change wireless vendor defaults per the following 5 points:

1. Encryption keys must be changed from default at installation, and must be changed

anytime anyone with knowledge of the keys leaves the company or changes positions.

2. Default SNMP community strings on wireless devices must be changed upon installation

or whenever anyone with knowledge of the SNMP community strings leaves the

company or changes positions.

3. Default passwords/passphrases on access points must be changed upon installation or

whenever anyone with knowledge of the passwords/passphrases leaves the company or

changes positions.

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.

The changing of the above vendor defaults is your responsibility and must be maintained by

yourself or a certified IT professional.

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.

4.1.1: 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.

5.11 PCI-Compliant Delivery of Updates (PA-DSS 7.2.3)

The RB Control Systems Payment Application delivers patches and updates in a secure manner:

This section will describe how payment application updates and patches are delivered to the

merchant. The method used must provide a secure chain of trust per requirements in PA-DSS

7.2.a, including:

Timely development and deployment of patches and updates.



Updates are sent on a nightly basis. Each user has a scheduled tasks that checks for any updates

and applies them. The current version information and check-in time are recorded in order to

ensure each user receives the correct information.

Delivery in a secure manner with a known chain-of-trust.

Requests for updates are initiated by the customer through a System Maintenance utility.

Delivery in a manner that maintains the integrity of the deliverable.

All updates are received through a Secure FTP (SFTP) connection.

Integrity testing of patches or updates prior to installation.

At the time of receiving an update, a unique hash key value is create both for the customer and

version of the update. This value is used to verify the integrity of the update before installation.

Communication of notifications of new patches and updates

When an update is set to be delivered, the customer will receive notification through email that

the update will be retrieved that night. As well, the customer will receive an Inner Office

message within the RB Control Systems program whenever an update has been processed.

Update notes are saved on the RB Control Systems website so the customer can review the

change logs at any time.

5.12 Services and Protocols (PA-DSS 8.2.c)

The RB Control Systems Payment Application does not require the use of any insecure services

or protocols. Here are the services and protocols that the RB Control Systems Payment

Application does require:

TLS 1.1

TLS 1.2

5.13 Never store cardholder data on internet-accessible

systems (PA-DSS 9.1.c)

Never store cardholder data on Internet-accessible systems (e.g., web server and database

server must not be on same server).



5.14 PCI-Compliant Remote Access (10.1)

The PCI standard requires that if employees, administrators, or vendors are granted remote

access to the payment processing environment; access should be authenticated using a two-

factor authentication mechanism. The means two of the following three authentication

methods must be used:

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

5.15 Vulnerability Identification and Remediation

RB Control Systems has established a process to identify and assign a risk ranking to newly discovered security vulnerabilities and to test our payment applications for vulnerabilities. Any underlying software or systems that are provided with or required by the payment application are included in this process.

RB Control Systems assigns risk ratings to identified vulnerabilities in the following manner:

o CVSS - http://www.first.org/cvss/cvss-guide.html

Vulnerabilities are labeled "Low" severity if they have a CVSS base score of 0.0-3.9.

Vulnerabilities will be labeled "Medium" severity if they have a base CVSS score of 4.0-6.9.

Vulnerabilities will be labeled "High" severity if they have a CVSS base score of 7.0-10.0.

o NVD - http://nvd.nist.gov/cvss.cfm




o CVSS 2.0 - https://intellishield.cisco.com/security/alertmanager/cvss


http://www.first.org/cvss/cvss-guide.htmlhttp://nvd.nist.gov/cvss.cfmhttps://intellishield.cisco.com/security/alertmanager/cvss





o Windows - http://technet.microsoft.com/en-us/security/gg309152.aspx

Vulnerabilities are labeled according to the Maximum Severity Rating and Vulnerability Impact (Low to Critical).

o SANS Institute - http://www.sans.org/critical-security-controls/

o OWASP - https://www.owasp.org/index.php/Main_Page

The following outside sources are monitored for security vulnerability information:

o Microsoft Advisories

o SANS newsletters

o Development Code forums

Testing of payment applications for new vulnerabilities in the following manner:

o CPPCHECK

o Cenzic Hailstorm

o Rapid 7 NeXpose

Once we identify a relevant vulnerability, we work to develop & test a patch that helps protect

the RB Control Systems Payment Application against the specific, new vulnerability. We attempt

to publish a patch within 7 days of the identification of the vulnerability. This patch will be

installed as part of the automatic nightly update process. We will also monitor to make sure you

received this patch and will contact you if it has not been installed within 7 days of

implementation.

5.16 PCI-Compliant Remote Access (10.2.3.a)

The PCI standard requires that if employees, administrators, or vendors are granted remote

access to the payment processing environment; access should be authenticated using a two-

factor authentication mechanism (username/ password and an additional authentication item

such as a token or certificate).

In the case of vendor remote access accounts, in addition to the standard access controls,

vendor accounts should only be active while access is required to provide service. Access rights

http://technet.microsoft.com/en-us/security/gg309152.aspxhttp://www.sans.org/critical-security-controls/https://www.owasp.org/index.php/Main_Page



should include only the access rights required for the service rendered, and should be robustly

audited.

If users and hosts within the payment application environment may need to use third-party

remote access software such as Remote Desktop (RDP) or Terminal Services to access other

hosts within the payment processing environment, special care must be taken.

In order to be compliant, every such session must be encrypted with at least 128-bit encryption

(in addition to satisfying the requirement for two-factor authentication required for users

connecting from outside the payment processing environment). For Remote Desktop (RDP) and

Terminal Services, this means using the high encryption setting on the server. Additionally, the

PCI user account and password requirements will apply to these access methods as well.

When requesting support from a vendor, reseller, or integrator, customers are advised to take

the following precautions:

Change default settings (such as usernames and passwords) on remote access

software (e.g. VNC)

Allow connections only from specific IP and/or MAC addresses

Use strong authentication and complex passwords for logins according to PA-DSS

3.1.1 – 3.1.10 and PCI DSS 8.1, 8.3, and 8.5.8-8.5.15

Enable encrypted data transmission according to PA-DSS 12.1 and PCI DSS 4.1

Enable account lockouts after a certain number of failed login attempts according to

PA-DSS 3.1.8 and PCI DSS 8.5.13

Require that remote access take place over a VPN via a firewall as opposed to

allowing connections directly from the internet

Enable logging for auditing purposes

Restrict access to customer passwords to authorized reseller/integrator personnel.

Establish customer passwords according to PA-DSS 3.1.1 – 3.1.10 and PCI DSS

Requirements 8.1, 8.2, 8.4, and 8.5.

5.17 Data Transport Encryption (PA-DSS 11.1.b)

The PCI DSS requires the use of strong cryptography and encryption techniques with at least a

128 bit encryption strength (either at the transport layer with TLS or IPSEC; or at the data layer

with algorithms such as RSA or Triple-DES) to safeguard cardholder data during transmission

over public networks (this includes the Internet and Internet accessible DMZ network

segments).

PCI DSS requirement 4.1: Use strong cryptography and security protocols such as transport layer

security (TLS 1.1 and TLS 1.2) and Internet protocol security (IPSEC) to safeguard sensitive

cardholder data during transmission over open, public networks.



Examples of open, public networks that are in scope of the PCI DSS are:

The Internet

Wireless technologies

Global System for Mobile Communications (GSM)

General Packet Radio Service (GPRS)

Refer to the Dataflow diagram for an understanding of the flow of encrypted data associated

with the RB Control Systems Payment Application.

5.18 PCI-Compliant Use of End User Messaging Technologies

(PA-DSS 11.2.b)

The RB Control Systems Payment Application does not allow or facilitate the sending of PANs via

any end user messaging technology (for example, e-mail, instant messaging, and chat).

5.19 Non-console administration (PA-DSS 12.1)

Although the RB Control Systems Payment Application does not support non-console

administration and we do not recommend using non-console administration, should you ever

choose to do this, must use SSH, VPN, or TLS 1.1 or higher for encryption of this non-console

administrative access.

5.20 Network Segmentation

The PCI DSS requires that firewall services be used (with NAT or PAT) to segment network

segments into logical security domains based on the environmental needs for internet access.

Traditionally, this corresponds to the creation of at least a DMZ and a trusted network segment

where only authorized, business-justified traffic from the DMZ is allowed to connect to the

trusted segment. No direct incoming internet traffic to the trusted application environment can

be allowed. Additionally, outbound internet access from the trusted segment must be limited to

required and justified ports and services.

Refer to the standardized Network diagram for an understanding of the flow of

encrypted data associated with the RB Control Systems Payment Application.

5.21 Maintain an Information Security 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/service provider should adopt in developing

and implementing a security policy and program:

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.

5.22 Application System Configuration

Below are the operating systems and dependent application patch levels and configurations

supported and tested for continued PCI DSS compliance.



Microsoft Windows 10




256 MB of RAM minimum, 2GB or higher recommended for Payment Application

200 MB of available hard-disk space

TCP/IP network connectivity

5.23 Payment Application Initial Setup & Configuration

The initial installation of the RB Control Systems Payment Application will be handled by an RB

Control Systems support technician. RB Control Systems can also work with your processor on

your behalf in order to configure the initial merchant setup. During this installation and

configuration, we will also:



Help you set up a user for access to administrative changes within the RB Control

Systems Payment Application

Inactivate any default administration accounts

Conduct a test transaction in order to verify everything is working properly

Set up and test the update process in order to ensure all critical patches will be received

in a timely fashion

6 Addressing Inadvertent Capture of PAN

6.1 Addressing Inadvertent Capture of PAN on Windows 7

6.1.1 Disabling System Restore

Right Click on Computer > Select “Properties”

Select “System Protection” on the top left list, the following screen will appear:

Select Configure, the following screen will appear:



Select “Turn off system protection”

Click apply, and OK to shut the System Protection window

Click OK again to shut the System Properties window

Reboot the computer

6.1.2 Encrypting PageFile.sys

* Please note that in order to perform this operation the hard disk must be formatted using

NTFS.

Click on the Windows “Orb” and in the search box type in “cmd”.

Right click on cmd.exe and select “Run as Administrator”

To Encrypt the Pagefile type the following command: fsutil behavior set

EncryptPagingFile 1

To verify configuration type the following command: fsutil behavior query

EncryptPagingFile

If encryption is enabled EncryptPagingFile = 1 should appear



In the event you need to disable PageFile encryption type the following command: fsutil

behavior set EncryptPagingFile 0


EncryptPagingFile

If encryption is disabled EncryptPagingFile = 0 should appear

6.1.3 Clear the System Pagefile.sys on shutdown

Windows has the ability to clear the Pagefile.sys upon system shutdown. This will purge 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.

Click on the Windows “Orb” and in the search box type in “regedit”.

Right click on regedit.exe and select “Run as Administrator”

Navigate to HKLM\System\CurrentControlSet\Control\Session Manager\Memory

Management

Change the value from 0 to 1

Click OK and close Regedit



If the value does not exist, add the following:

o Value Name: ClearPageFileAtShutdown

o Value Type: REG_DWORD

o Value: 1

6.1.4 Disabling System Management of PageFile.sys

Right Click on Computer > Select “Properties”

Select “Advanced System Settings” on the top left list, the following screen will appear:



Under performance select “Settings” and go to the “Advanced” tab, the following screen

will appear:

Select “Change” under Virtual Memory, the following screen will appear:

Uncheck “Automatically manage page file size for all drives”

Select “Custom Size”

Enter the following for the size selections:



o Initial Size – as a good rule of thumb, the size should be equivalent to the

amount of memory in the system.

o Maximum Size – as a good rule of thumb, the size should be equivalent to 2x the


Click “Ok”, “OK”, and “OK”

You will be prompted to reboot your computer.

6.1.5 Disabling Windows Error Reporting

Open the Control Panel

Open the Action Center

Select “Change Action Center Settings”



Select “Problem Reporting Settings”

Select “Never Check for Solutions”



Right Click on Computer > Select “Properties”:



Select “Advanced System Settings” from the System screen:





Select “Disable system protection”



Reboot the computer



NTFS.



From the desktop hold down the “Windows” key and type “F” to bring up the “Search”

charm, select “Apps” in the “Apps” box type in “cmd”.

Right click on “Command Prompt” icon located on the left side of your screen, a

selection bar will appear at the bottom of the screen, select “Run as Administrator”


EncryptPagingFile”




EncryptPagingFile 1









charm, select “Apps” in the “Apps” box type in “regedit”.





Management

Change the value from 0 to 1 on the “ClearPageFileAtShutdown” DWORD.





o Value: 1






Select the “Advanced” tab:




will appear:














From the desktop hold down the “Windows” key and type “I” to bring up the “Settings”

charm, select “Control Panel”.


Select “Change Action Center Settings”:



Select “Problem Reporting Settings”:



Select “Never Check for Solutions”:

Select “OK” twice and then close Action Center.



Right Click on This PC > Select “Properties”:




Select “Disable system protection”



Reboot the computer



NTFS.

Right click on the Start button or type “CMD” into Cortana/Search bar

If you Right click on the Start button then select COMMAND PROMPT (ADMIN)



If you’re using Cortana/Search bar, right click on “Command Prompt” icon, a selection

bar will appear at the bottom of the screen, select “Run as Administrator”

To verify configuration type the following command: “fsutil behavior query







EncryptPagingFile 1








Right click the Start button and select search or click on Cortana/Search

Type in “regedit”.



Management








o Value: 1






will appear:














Right click the Start button and select search or click on Cortana/Search

Type in “regedit”.


Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error

Reporting.

Find the value named "Disabled" or add a new DWORD value with this name if it doesn't

exist.

Double click it to edit, change the value to 1.




Now instead of a dialogue stating windows is searching online, you will simply get a

dialogue stating that the application has crashed.

To view the error, open Control Panel by right clicking on the start button

Select “Security and Maintenance”

Expand “Maintenance” then click on “View Reliability history” to view all app crashes

Then click “View technical details” to get detailed information on that specific crash



6.4 Addressing Inadvertent Capture of PAN – Server OS



NTFS.


charm, select “Everywhere” in the search box type in “cmd”.

Right click on “Command Prompt” icon located on the left side of your screen, a

selection bar will appear at the bottom of the screen, select “Run as Administrator”






EncryptPagingFile 1











charm, select “Everywhere” in the search box type in “regedit”.



Management






o Value: 1






will appear:














From the desktop hold down the “Windows” key and type “I” to bring up the “Settings”

charm, select “Control Panel”.


Select “Change Action Center Settings”:



Select “Problem Reporting Settings”:



Select “Never Check for Solutions”:

Select “OK” twice and then close Action Center.