Secure Implementation Guide - SICOM Systems, Inc.

SICOM SL Series

Secure Implementation Guide

SICOM Systems, Inc.

4140 Skyron Drive

Doylestown, Pennsylvania 18901

800-54-SICOM (800-547-4266)

http://www.sicom.com

sales@sicom.com

SICOM SL Series Secure Implementation Guide

by SICOM Systems, Inc.

4140 Skyron Drive

Doylestown, Pennsylvania 18902

800-54-SICOM (800-547-4266)

http://www.sicom.com

sales@sicom.com

Copyright © 2007 SICOM Systems, Inc.

PROPRIETARY RIGHTS NOTICE

All rights reserved. No part of this material may be reproduced or transmitted in any form or by any means,

electronic, mechanical, or otherwise, including photocopying and recording or in connection with any

information storage or retrieval system, without the written permission in writing from SICOM Systems, Inc.

SICOM Systems, Inc. has taken reasonable preventive measures to ensure the accuracy of the information

contained in this manual. However, SICOM Systems, Inc. makes no warranties or representations with respect

to the information contained herein and SICOM shall not be liable for damages resulting from any errors

or omissions herein or from the use of the information contained in this manual.

Document Revision: 1.3, 11/7/2008

Revision History:

1.1 – Addition of Antivirus option

1.2 – Change SL18 to SL series

1.3 - Change Meta Data

LINUX® is a registered trademark of Linus Torvalds.

SICOM and the "S" logo are trademarks of SICOM Systems Incorporated.

Table of Contents

Overview of Standards and Practices ...................................................................1

Visa CISP..........................................................................................................1

PCI Data Security Standard ..............................................................................1

PABP - Payment Applications Best Practices ...................................................2

PCI Standard v1.1.................................................................................................3

Payment Acceptance Environment.......................................................................4

General Guidance .............................................................................................5

General Recommendations ...........................................................................5

Passwords ..............................................................................................5

Network Security ....................................................................................5

Wireless Devices ....................................................................................6

Retention and Protection of Data - .........................................................6

Remote Access ......................................................................................6

External Review......................................................................................6

User Security ..........................................................................................6

Industry Best Practices...........................................................................7

Segregate Web and Payment Systems..................................................7

How do I know if my system is compliant? ........................................................7

1. Checking your Software Version................................................................7

2. If you are using older software...................................................................8

3. Verifying SICOM SL Series Configuration Compliance .............................9

Enhanced User and Login Security.....................................................................11

• All users must use complex passwords.........................................12

• Passwords expire after ..................................................................12

• Passwords may be repeated after.................................................12

• User is locked out..........................................................................12

• Lockout period...............................................................................12

• Minimum password length.............................................................12

• No activity timeout .........................................................................13

• Enable Clam Antivirus ...................................................................13

• Firewall Configuration....................................................................13

Log In Procedure.............................................................................................14

Change Password .......................................................................................15

Error Messages While Logging In................................................................15

Additional Changes Effective with V1.42.........................................................17

SICOM Certificate Authority (CA)........................................................................18

Background on the Browser Padlock...........................................................18

A Chain of Trust...........................................................................................18

Being a Proper “host” (Editing Your “hosts” File) .........................................19

Installing the SICOM Certificate Authority....................................................22

Cookies........................................................................................................25

OpenVPN ........................................................................................................27

Certificate needed before continuing ...........................................................27

OpenVPN Installation ..................................................................................27

Installation of OpenVPN Package................................................................27

Installation of OpenVPN GUI Package ........................................................29

Connecting to the Restaurant..........................................................................31

OpenVPN Configuration Files......................................................................32

Troubleshooting...............................................................................................32

Detailed PCI-DSS Requirements........................................................................35

Glossary..............................................................................................................54

This page intentionally left blank

Introduction to Electronic Payment Processing

SICOM Systems is pleased that you have elected to use our integrated electronic payment

processing software with your SL Series POS (Point of Sale) system. The software provides your

POS system the capability for both Dial-up and Broadband card authorizations, depending upon

your merchant processor, from any Point of Sale terminal.

Security is of paramount importance with any payment acceptance method, whether it is cash,

gift cards/certificates, or debit/credit payments. The widespread acceptance of credit cards in the

quick service industry (QSR) benefits the merchant as well as the cardholder. For the cardholder,

credit cards reduce the cash needed for everyday purchases, resulting in a decreased potential

for loss or theft. For the merchant, cash amounts are also reduced, thereby creating a safer

environment for all employees, while also ensuring that funds are deposited into the bank in a

safe and timely manner.

While accepting electronic payments provide many benefits for both the cardholder and the

merchant, it also comes with responsibilities. Many of these responsibilities, as well as much of

the information provided in this document, come from various industry regulations and guidelines.

The Payment Card Industry standards (PCI), VISA Cardholder Information Security Program

(CISP), Payment Application Best Practices (PABP) and the American Express Card Acceptance

and Processing Network (CAPN) initiative are some of them.

This document is part of our compliance efforts and will also inform you about the steps that

SICOM has taken to assist with your compliance efforts.

Overview of Standards and Practices

"CISP, PCI, PABP,CAPN; What does all of this mean to me?" you may ask. The information

supplied in this document is meant to provide information on some of the responsibilities that you,

as the merchant, have when accepting electronic payments. It is not meant to be authoritative

with respect to merchant processor requirements and guidelines, as much of this information is

taken directly from the Visa® and other industry websites which periodically update their

information.

Visa CISP

When customers offer their bankcard at the POS, over the Internet, on the phone, or through the

mail, they want assurance that their account information is safe. That is why Visa USA instituted

the Cardholder Information Security Program (CISP). Mandated since June 2001, CISP is

intended to protect Visa® cardholder data wherever it resides, ensuring that members,

merchants, and service providers maintain the highest information security standard. CISP is a

set of twelve requirements, also known as the "Digital Dozen", designed to limit merchant liability

and to protect cardholder data.

PCI Data Security Standard

Collaboration between Visa® and MasterCard®, the Payment Card Industry (PCI) Data Security

Standard is a set of common industry security requirements. For simplicity, they use the twelve

requirements of the CISP as the basis for this standard, which are designed to limit merchant

liability and protect cardholder data. Other card companies have incorporated these requirements

into their own programs as well.

As of September 7 th 2006, the standards are maintained by the PCI Security Standards

Council. The executive committee of the organization is comprised of members of

MasterCard®, Visa®, American Express®, Discover®, and JCB®.

PABP - Payment Applications Best Practices

Responsibility for PCI/CISP compliance rests with you, the merchant. However, there are many

aspects of card acceptance and processing that you have no control over. To assist merchants,

Visa has created the Payment Applications Best Practices program. Payment Applications that

have been independently validated, when implemented in a CISP compliant environment, provide

some assurance to the merchant. A PABP compliant application does not guarantee compliance

by the merchant. Since the Payment Application Provider (i.e. SICOM Systems) has no direct

control over the merchant and/or its overall technology infrastructure, the merchant is responsible

for providing the CISP compliant environment.

PABP validation by software vendors is voluntary and is not a requirement by Visa USA at

this time. Please note that some merchant processors require compliance and/or

validation in order to process transactions on their network. It is up to the merchant to

ensure that they comply with the guidelines established by their processor.

2

PCI Standard v1.1

As a merchant accepting payment card transactions, you are required to comply with the PCI

standards and must assess your compliance with the rules and regulations stipulated in PCI’s

agreements. The table below shows the twelve requirements of the PCI Standard as published at

http://www.pcisecuritystandards.org and www.visa.com/cisp. All merchants must comply with

PCI standards. Acquiring banks and Merchant Processors are responsible for ensuring that all of

their merchants comply with the PCI Data Security Standard requirements. Merchant compliance

has been prioritized based on the volume of transactions, the potential risk, and the exposure

introduced into the payment system. While you must check with your Merchant Processor to

determine your level, the QSR market in which SICOM’s SL Series Point of Sale System is used

is generally classified as level 4. Level 4 merchants are currently recommended to perform selfassessments

and quarterly scans of their Payment Acceptance Environment.

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 and 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.

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.

Figure 1 - PCI Standards

3

Payment Acceptance Environment

SICOM’s SL Series Point of Sale System consists of POS terminals connected with an industry

standard Ethernet network communicating via TCP/IP. It is configured as a self-contained

network requiring no additional equipment. Its basic configuration requires telephone lines for

credit authorization and optional SICOM support assistance. The basic configuration limits the

Payment Acceptance Environment to POS equipment only. When configured in this manner,

compliance with your data security obligations should be straightforward and limited to selection

options in the “User Security” menu of your SICOM POS system.

Sample User Security Edit

Figure 2 - User Security Edit

Since the SICOM SL Series POS system uses an industry standard network, it is possible to

integrate the POS network with your existing network or to add additional peripherals like a backoffice

PC, order confirmation signs, and security equipment. Wireless and broadband access

could also be added. It is important to note that the addition of any non-SICOM peripherals or

access methods to the network extends the Payment Acceptance Environment to those devices.

Careful consideration must be used when planning additional connectivity to the POS

network/cardholder environment. Since merchant compliance extends to the entire Payment

Acceptance system, these security obligations extend to the entire network, not just the SICOM

POS system. Devices that do not specifically need to be on the POS network should be

separated via router, firewall or VLan (Virtual LAN). It is suggested that you consult with an IT

professional familiar with Payment Card Industry (PCI) guidelines when contemplating network

modifications. While it may be easy to add the desired functionality to the network, unintended

security risks may be associated with these additions.

Note:

It is important for you to conduct a thorough self-assessment because you may be required to

make representations to your merchant bank and card associations about your entire payment

system. SICOM Systems, Inc. can only furnish information about its own products, not the entire

Payment Acceptance Environment.

4

It is critical for you to remember that your obligation to protect consumer data does not end with

your SICOM POS system, even though it can be configured to comply with PCI requirements.

You have an ongoing responsibility to your merchant bank and to your customers to treat their

data with care. SICOM Systems, Inc. recommends instituting at least the practices listed on the

following pages, regardless of how you use your software.

SICOM Systems, Inc. encourages you to develop additional safeguards. Please be sure to

periodically verify with your cardholder associations, PCI, and your merchant bank that you are

complying with all applicable data security regulations and guidelines.

General Guidance

Some general information SICOM can provide for your compliance effort is that your SICOM SL

Series System with software version MGRNG v1.42 or higher does not store the following

information once an authorization has been given:

• Full track data from a card’s magnetic stripe

• CVV2, CVC2, and CID numbers from the physical card

• PIN block data from PIN-based Debit transactions

In addition, cardholder account numbers and expiration dates should be stored with 3DES

encryption with a 192-bit cipher to protect the data.

Once a batch is successfully closed (a closed batch means that we have received a confirmation

number from the payment processing network), cardholder account information is truncated and

never kept in its entirety.

General Recommendations

Passwords - Secure your SICOM SL Series System with recommended compliance options

using the User Security menu option. Require your computer users to log in using a complex

password (a password with both letters and numbers in it) and configure the operating system to

force users to change their passwords routinely—for example every 30 or 90 days. Do not grant

access to product features that a user does not need. For example, a “Cashier” may only facilitate

sales, and therefore would not need to have access to the Reporting or Void and Refund

functions. In this scenario, you could create two profiles called “Clerk” and “Supervisor” and

ensure that only members of the “Supervisor” profile can perform Generate Reports or Voids and

Refunds.

Network Security - Never install a payment software application on a computer with a direct

link to the Internet unless that link is secured. If you are using the Internet for your transaction

transport, make sure your Internet hardware (cable modem, DSL router, etc.) has built-in firewall

capabilities. Do not leave any administrator-level passwords in their default configuration—

change them to a complex password that only you know, as this password will be much more

difficult for a malicious user to guess. Only enable the minimum access necessary to the

network for maximum security and document why it is necessary. Connectivity to a SICOM POS

system requires port 443 for Secure Web access and port 1194 for OpenVPN. OpenVPN is an

open-source implementation of a Virtual Private Network. A Virtual Private Network adds security

by providing access to the POS network and resources through an SSL (Secure Sockets Layer)

encrypted connection to only those that have provided validated credentials. The SICOM SL

Series System requires both a Digital Certificate and password to grant access to the network.

See the broadband and VPN configuration section of the SICOM SL Series Manager Guide for

5

specific information about ports required for remote POS system access through a firewall. The

Windows version of OpenVPN can be obtained from http://openvpn.net/download . A Graphical

User Interface version can also be obtained from http://openvpn.se .

Wireless Devices - Your SICOM POS system does not require wireless connectivity of any

kind. However, it has been designed to work on any network that supports TCP/IP protocols,

without direct knowledge of the physical devices or communication technologies underlying the

TCP/IP layer. If you use wireless devices of any kind to store or transmit payment transaction

data, those devices must be configured to encrypt transmissions using technologies consistent

with the standards in the Payment Card Industry guidelines. Many wireless devices use WEP

(Wireless Encryption Protcol). It is strongly recommended that you implement additional security

measures on top of WEP, such as IPSec or SSL, because security issues have been found with

WEP. All sensitive Cardholder information originating from SICOM POS equipment is 3DES

encrypted for security.

Retention and Protection of Data - Your SICOM SL Series POS System does not store

sensitive transaction detail after a successful batch close.In addition, non-sensitive batch

transaction information is not stored for more than 30 days.

Remote Access - SICOM Systems support personnel have the ability to provide dial-in

remote-access support to your POS System. Each member of the SICOM support team has their

own individual username. The password they use changes daily. When we are requested to

provide assistance, we will ask for the modem access line to be turned on. If you have provided

a broadband connection to the system, it requires you, the merchant, to provide a VPN, or Virtual

Private Network, for system access.

Since most of SICOM’s customers do not have the requisite technical expertise to configure and

manage a VPN, the SICOM SL Series POS with MGRNG v1.42 and higher provides an optional

VPN using OpenVPN. With OpenVPN, SICOM Support personnel not only have an individual

user name with daily changing password, but also have a digital certificate to authenticate them

when connecting to the network for system-related tasks. If you are providing access to SICOM

personnel via a broadband connection, you will need to ensure that your router/firewall forwards

port 1194 to the SICOM SL Series server at 192.168.1.80 for system-level access. Furthermore,

any remote system-level access will require 2-factor (password and certificate) authentication.

System-level access includes the ability to import sales data poll files as well as exporting Auto

Update and other application data files. User certificates can be provided by SICOM, or the

customer can obtain one from a Certificate Authority such as Verisign or Thawte.

If you are providing remote access into the cardholder environment, it is imperative that you

configure and operate software on any systems in the Payment Card Environment in a manner

consistent with the Payment Card Industry guidelines. Remember that any device connected to

the SICOM SL Series POS network is part of the cardholder environment.

External Review - Depending on the amount of card transactions you process, you may be

obligated to engage an external security assessment company to judge your level of compliance

with the various security compliance programs. If you are required, or choose to follow this path,

consider engaging a CISP-qualified assessor who is versed in the latest requirements from the

card associations. Remember, cardholder security requirements change can change rapidly.

User Security - Your SICOM SL Series software allows you to “lock down” access to only

those users with a legitimate need to use it. It also provides the capability to easily bring your

6

POS system (not necessarily your entire Payment Application Environment) into compliance.

Familiarize yourself with the options in the Enhanced User and Login Security document for

important information on how to set up and configure user account security. Follow the simple

rule of thumb that users should not be granted a particular privilege unless there is a legitimate

need for them to use it.

Industry Best Practices - SICOM Systems, Inc. recommends that you evaluate your

payment processing operations in the context of the comprehensive security guidelines published

by the Open Web Application Security Project. You can download and review their documentation

at http://www.owasp.org.

Segregate Web and Payment Systems – PCI requires that payment software

applications are not installed on the same system as a Web server. It is recommended that a

physical, hardware firewall is in place if the system is connected directly to the Internet. The

SICOM SL Series POS system poses a unique challenge with respect to compliance with

industry guidelines. Your system is a POS terminal, file server, and web server. It requires no

additional equipment. When configured securely, cardholder sensitive information (account

number, expiration dates) is stored on another terminal with no direct access to the Internet. To

check if your system is configured correctly, check the User Security Setting menu of your

system. An alert will be displayed if the remote data storage option is not selected. Remember, a

properly configured system does not mean the entire cardholder environment is in compliance.

How do I know if my system is compliant?

Software Versions 1.42 and higher have been designed to be compliant with PCI requirements.

Version 1.42 is currently pending certification by Visa. All versions prior to MGRNG Version 1.42

will not be certified and are deemed non-compliant

There are two things that you must check to see if your system is compliant. The first is to see if

your system has a certified compliant version of software. The second is to ensure that it is

configured in a compliant manner.

1. Checking your Software Version

From the Main Menu of your POS System, select Maintenance, then Software Release Info.

7

Figure 3 - Software Release Version

should be version 1.42 or higher with SecureLoad

2. If you are using older software

All versions prior to MGRNG Version 1.42 with SecurLoad are not certified compliant. If you are

using a SICOM SL Series POS product to authorize credit transactions that was not tested to be

compliant PCI industry standards, we urge you to upgrade to a more recent version of software.

Here are some additional reasons to upgrade:

• As a result of many changes to credit card processing rules, you may be paying more

than you should to process transactions with you payment processor.

• Your acquiring bank or processing company may require that you upgrade to a PABP

certified software application.

• Versions of software other than those explicitly listed in the Data Storage Statement will

not be tested for PABP compliance.

• You will not be able to take advantage of many other software features now available for

your SICOM POS system.

If you are not sure if your system is in compliance, or you need information about upgrading your

system, please contact SICOM Systems at 800-547-4266.

8

3. Verifying SICOM SL Series Configuration Compliance

Verifying your Compliance Options requires an administrator access level of 98. When logged in

with this level, you have the menu option of System Maintenance Tools. Select User Security

Settings to view or change your current settings

Figure 4 - User Security Setting/PABP Edit

The bottom of the screen will alert you to any settings which are outside of the recommended

standards.

Figure 5 - SICOM Compliance Alerts

9

To easily set all of the options to the recommended settings, and be sure of compliance, we have

also included the Use PABP Recommended Settings button. Seen below, this button will

automatically pre-fill all of the fields to the recommended values when clicked.

10

Enhanced User and Login Security

Beginning with the 1.42 release of the Management software for the SL Series POS, we have

implemented a stronger user security system for PABP and PCI compliance.

These industry standards require all payment environments to be reviewed for compliance. For

the merchant, this includes the POS network when the POS accepts, stores, or transmits

cardholder data and any other device connected to that network. “Any other” devices include a

customer’s PC, wireless devices, Internet Café; Satellite, DSL or Cable networks, or networked

security cameras. Our PABP compliance lists the SICOM Systems, Inc with either SL18 or SL

Series (depending upon your software version) on the VISA website as a compliant system when

configured according to our implementation guidelines. The intent of the Visa PABP compliance

listing is so that when implemented properly in a customers PCI compliant environment, the

system and the environment will be compliant. We must provide the tools and configuration

options for the system to be compliant, but it is up to the merchant to ensure that it is configured

correctly. Part of our compliance dictates that we provide materials to the merchant to educate

them on compliance procedures, which may be out of the scope of the POS system itself.

The enhanced user security settings allow our customers to become compliant with the above

standards and help them to pass the required annual PCI self-assessment questionnaire and

quarterly network scan (or audit, depending upon transaction volume) of their network’s security,

so that they may then be authorized to accept credit cards for payments.

The new security settings can now require users to:

• Ensure that all users use complex passwords.

• Create a new password after a set amount of days, and make sure that users cannot

reuse a password unless that password was used a set number of times ago.

• Make sure that users enter in the correct password, or else be locked out from the

system after a set number of incorrect attempts.

• Ensure that a user’s login password is at least a set number of characters long.

The security settings, when turned on, are enforced in the User Edit (located in the System

Security submenu) and the Change Password feature now included in the new Log In procedure

(see “New Log In Procedure” for more information.)

The following is a snapshot of the User Security Settings Edit, which has been placed on the

System Maintenance Tools menu. This edit is used to configure the restrictions that will aid in

making your payment environment PABP and PCI compliant.

11

Each of the fields is defined as follows:

12

• All users must use complex passwords. This option forces users to create

strong passwords in order to log in to the system. Each users’ password is the key that is

used to access the information stored on the system, and creating a strong password is

essential to preventing unauthorized people from gaining access to that information.

With this option enabled, the software will check the passwords that users enter and

reject those that it considers to be easily guessable, weak, too short, or based on

dictionary words.

• Passwords expire after X days. This option forces the user to change their

password after the amount of days entered. SICOM’s recommended setting is 90 days

to ensure PCI compliance. Users are alerted 14 days prior to expiration to change their

password.

• Passwords may be repeated after X changes. This setting forces the user to

not to repeat using any passwords that they have previously used. This means if a

password is used, then changed, it may not be reused again until the number of following

password changes has passed the value set. The recommended value for compliance is

4 changes.

• User is locked out after X consecutive failed login attempts. If someone

attempts to log in and uses an incorrect password, that username can be prevented from

logging in for a period of time. This option sets the number of times someone can

attempt to log in unsuccessfully before being locked out. The recommended setting for

compliance is no more than 6 failed attempts.

• Lockout period is X minutes. Used in conjunction with the previous option, the

value entered here determines the amount of time, in minutes, that the username is

prevented from logging in (even with the correct password.) The recommended setting

for compliance is 30 minutes.

• Minimum password length is X characters. Shorter passwords make it

easier for a criminal or malicious user to gain access to the system. To help prevent

short passwords, the minimum character length of a password can be restricted. The

value entered here will force the length of a password to be at least (or greater) than what

is input. The recommended value for compliance is 7 characters.

• No activity timeout is X minutes. This setting will automatically “log out” a user

if no activity has been logged by the system for the period of time set. The

recommended value for compliance is 15 minutes.

• Enable Clam Antivirus. When this box is checked and a broadband connection is

present, the SICOM SL Series POS System will periodically scan itself for viruses.

Customer downloaded files will be scanned before being acted on and the system will

perform a complete scan weekly. Virus definitions are updated daily and engine updates

are checked weekly. Contact SICOM Systems if you would like additional information or

changes to the frequency or data being scanned

• Firewall Configuration. The PABP Compliant firewall configuration does not allow

ANY FTP connections, not even via dialup. Options to allow FTP over dialup (Noncompliant);

SSH, VPN, and HTTPS (compliant); and VPN only (compliant) are available.

By default, when the software is installed, the enhanced settings are turned off. They can be

turned on by using the edit located in the System Maintenance Tools menu. Beginning with

Release v1.61, the recommended settings will be the default.

IMPORTANT: The first time the PABP settings are turned on, ALL users

will be required to change their password the next time they log in. This is

to ensure that all users are using the recommended settings. Make sure the

restaurant personnel are aware of this!

When configuring the settings in this edit, an alert will notify the user if any of the settings do not

meet the minimum requirements for compliance:

To easily set all of the options to the recommended settings, and be sure of compliance, we have

also included the Use PABP Recommended Settings button. Seen below, this button will

automatically pre-fill all of the fields to the recommended values when clicked.

13

The Remote User Password edit (located in the System Security submenu) and the

Remote Access User edit (located in the System Maintenance Tools menu) will

always require a complex password be used and a minimum password length of

7 characters, regardless of the settings in the User Security edit.

Log In Procedure

When first attempting to log in, the user will see a text field to input their username. There will not

be a field to input the password.

The user enters his/her username and then presses PROCESS LOGIN to continue. The

software will validate the username to make sure that it is correct, and then present the screen to

input the password.

Once the user enters their password, they can either log in by clicking the PROCESS LOGIN

button, or change their password by clicking the CHANGE PASSWORD button.

14

PLEASE NOTE

All users level 98 or higher will ALWAYS require a complex and minimum 7 character

password be entered regardless of the settings configured!

If the enhanced user security is turned on and the user’s password has expired, the PROCESS

LOGIN button will not appear. The user’s account has been deactivated. Only an administrator

can reset the expired password (to reactivate the account) before they can log in.

Change Password

When changing a password, the current password must be entered, followed by the new

password twice. This ensures that the person making the changes not only knows the current

password (and is not changing the password while the real user is away from the terminal) but

also makes sure that the new password is being correctly entered.

Error Messages While Logging In

Here are the error messages possible when logging in with the system configured for the new

security settings:

The username that was entered does not exist in the database. Be sure that the username was

typed in correctly. The username field is not case-sensitive.

15

They will need to re-enter the username/password combination. This password field is CASE-

SENSITIVE, so that means entries like PASSWORD, PaSsWoRd, and password are not the

same. Check the spelling and Caps Lock keys and have the user try to log in again.

If they incorrectly enter the password, they will see this message appear the next time they

attempt to log in. It will go away if once they successfully enter the correct password and log in.

This message will only appear if the system is configured for PABP compliance.

If they fail to correctly enter the password numerous times in succession, the user account will be

locked, preventing any more log in attempts over a fixed period of time. This message will only

appear if your system is configured for PABP compliance, and will display how long the timeout

is.

If the system is configured for PABP compliance, a user will see this message displayed once

their account’s password is set to expire. By default, the message will be displayed 14 days prior

to the password’s expiration. They have to be sure to choose a new, different password before

the expiration, or else the account will get locked. They will not be able to log in once the account

has been locked.

This message is displayed if the account has been locked due to the password expiring. The

user must contact the system’s administrator (or another user with equal or higher access that

can access the User Edit) to input a new password for the account so that they can log in again.

16

Additional Changes Effective with V1.42

• POS *2.56 – The “*” indicates the POS supports 3DES encryption for transmission of

cardholder data across the network. It is required for sites with software version 1.42

or higher!

• Complete credit card numbers are NO LONGER AVAILABLE in the batch history. Once

a batch is successfully closed, the expiration date and most of the card number is

removed.

• Cardholder data in an open batch has been increased to 3DES encryption.

• Usernames and passwords must be unique. I.E. User: manager, Password: manager is

not valid.

17

SICOM Certificate Authority (CA)

When attempting to connect with a system running MGRNG version 1.42 and higher, you will now

need to use https instead of http. This is because communications between your browser and

the SICOM POS system is encrypted. Many sites on the web will redirect you to the proper

connection, possibly alerting you that you are entering or leaving a secure connection. The SL

Series System cannot because there is no guarantee that the systems are registered with valid

domain names and fixed IP addresses.

Secure connections require 2 things:

• Encrypted Communications

• Trust

Background on the Browser Padlock

When visiting sites on the Internet such as Paypal, eBay, etc., a padlock is often displayed on

your browser. This padlock indicates that the communications session is encrypted. However,

the browser wants to go a step further. To help prevent fraud, the browser wants to check to see

if the site that has been visited can be verified. You could have clicked on a web link and not

really made it to the site that you “thought” you were going to. This is where the trust comes in.

E-commerce sites will register with a Certificate Authority (CA) that they are indeed who they say

that they are. The level of trust often depends upon the information the company provided to the

CA. It could be as simple as an email address, name, and physical address that can be verified

or as complex as submitted incorporation documents for a company. Companies like Verisign,

Thawte, and Commodo provide this research and verification. Furthermore, when visiting a

company’s website, your browser reads a certificate stored on the website and then confirms with

the CA (Verisign, Thawte, etc.). Once confirmed, the information provided by the CA and the

website is used to decrypt the information you requested from the website.

A Chain of Trust

How does the browser know to trust the Certificate Authority? All browsers are preconfigured

with certificates from many CAs. The browser checks the Certificate Authority’s certificate with

one that is in the browser. Since the browser can trust the CA and the CA trusts the website

(eBay, Paypal, etc.), the browser knows it can now trust the website as well. The chain of trust is

complete!

Since each and every SL Series system cannot feasibly be registered with a Certificate Authority,

how can a chain of trust be established? There needs to be another method. SICOM has

created a Self-Signed Certificate and Certificate Authority. As a user of a SICOM product, you

have an inherent trust in us. In addition, you will need to obtain our CA Certificate (or CACERT)

to install in your browser. Unlike major Certificate Authorities, a CA Cert from SICOM will never

be pre-installed in your browser. SICOM’s CACERT can be obtained at

http://www.sicom.com/sicom_ca.crt. It is recommended that you type this address in exactly how

it is written to ensure that the link is not subverted in any way. This is a big part of the chain of

trust, making sure that you receive it from the proper, trusted, source.

18

Being a Proper “host” (Editing Your “hosts” File)

Internet addresses are made up of a series of numbers. Those numbers can change depending

upon where you are connecting from. For example, one address (192.168.1.80) may find the

system in a restaurant while another (146.145.212.68) may find the same system from the

Internet. The certificate installed on the system has to be consistent—no matter how you connect

to it—for it to identify itself properly.

To do this, you will need to modify the “hosts” file you your Windows computer. This file is

located at: \windows\system32\drivers\etc\hosts (in Windows XP). This file lets you reference

an address consistently because you are able to specify the IP address or name to which the

entry refers.

For an in-restaurant system that is addressed at 192.168.1.80, add the following to your hosts

file:

192.168.1.80 manager.penguinpos.com

If you are outside the restaurant, you may wish to create the name or alias of the restaurant with

the fixed IP address. For example, if the restaurant IP address is 146.145.212.68 for Burger

Restaurant #123 in Doylestown, you might want either of the following in your hosts file:

146.145.212.68 bgr123.penguinpos.com

146.145.212.68 doylestown.penguinpos.com

192.168.202.1 vpn.penguinpos.com

192.168.201.1 vpn.penguinpos.com

Notice that all entries have “penguinpos.com”. This is how the SL Series System will identify

itself to you.

Please Note – Do not use an underscore “_” in your name/alias. It will cause our check for

cookies to fail.

The following is an example that should not be used.

146.145.212.68 bgr_123.penguinpos.com

When you attempt to connect to the system at https://192.168.1.80, you will see the following:

19

If you have a domain name associated with the restaurant location, you will not be able to

reference the POS system using that name without an error from your browser. The reason is

that the system is reporting as xxx.penguinpos.com and you may be surfing to it as

bgr123.mycompany.com. Since “mycompany.com” doesn’t match SICOM’s certificate, it will alert

you.

In that case, you would want to reference the system as:

bgr123.mycompany.com bgr123.penguinpos.com

This is especially important if the restaurant location is using a Dynamic DNS (DYNDNS) service

instead of a fixed ip address. The entry in the hosts file will permit mapping from an accepted

name for the certificate to the DYNDNS name that will ultimately find the restaurant.

You will now want to connect to https://manager.penguinpos.com (or whatever entry you created

in your hosts file). However, you will get the following message because there is one more step

that is needed:

You have entered the correct address, but your browser doesn’t trust the security certificate. If

you have Internet Explorer 7, you can continue to the site (although IE actually recommends

closing the browser).

If you do, the address bar on your browser will have a red highlight and indicate a certificate error

as shown below:

20

You can access the system without this warning by installing the SICOM Certificate Authority

(CA)/. SICOM generates the certificates on a secure computer located on our premises and not

connected to any network. You can get the SICOM CA here: http://www.sicom.com/sicom_ca.crt

Save this file to an easily remembered location on your computer’s hard drive. We’ll need it later.

21

Installing the SICOM Certificate Authority

In Internet Explorer, select Tools, then Internet Options, click on the Content tab. The following

window will open:

Select Certificates.

22

Now select Import…and enter the location of the cacert.crt saved earlier.

Let Windows determine which certificate store to place the certificate in by clicking the radio

button marked Automatically select the certificate store based on the type of certificate and click

Next.

23

You will be presented with a security warning:

It is imperative that you receive the SICOM directly from SICOM’s website. This way you can

ensure a chain of trust. Review the thumbprint ID displayed in the security warning, and make

sure it matches what is written here:

97EC3435 D2F3C302 4C116425 BE511FE3 6DE697B9

If the thumbprint ID matches the code above, then select Yes to this security warning.

Otherwise, click No and download another copy of the file from SICOM’s website. If you continue

to encounter difficulty matching the thumbprint ID, contact SICOM Systems Technical Support as

soon as possible.

Once installed, you are able to view the site without any further warnings from Internet Explorer.

You will also have the padlock icon indicating that you have a secure connection.

Warning – Do not remove the “sicom” Certificate Authority (CA) after installing

unless you no longer trust SICOM

If you remove the “sicom” Certificate Authority, you will no longer be able to access your SICOM

SL Series POS system securely. Internet Explorer 7 will no longer alert you to a security

certificate error but will block access to the web pages.

24

Cookies

The SICOM SL Series system uses cookies to confirm your logged in state. This way you do not

need to log in every time you visit a new menu/page. You may wish to ensure that cookies are

enabled from penguinpos.com. Enabling cookies will ensure that you are always allowed to log

in.

In Internet Explorer, select Tools, then Internet Options, click on the Privacy tab.

25

Select the Sites button. Here is where you will specify that penguinpos.com is always allowed to

leave a cookie.

Enter penguinpos.com in the field marked “Address of website”, click Allow and then OK.

26

OpenVPN

When attempting to connect with a system running MGRNG version 1.42 and higher, you might

be required to connect to the restaurant over a VPN (Virtual Private Networking) connection. This

section details the steps necessary to install, configure, and use the OpenVPN software on your

Windows XP computer. OpenVPN cannot be used on a Windows 9x/Me.

OpenVPN is a software package that SICOM Systems, Inc. has chosen to use as the VPN server

on SL Series terminals. It requires the OpenVPN client to connect to the server. You cannot use

the built-in Windows XP VPN client. OpenVPN supports the use of password and “certificate”

authentication, so called “dual-factor authentication”, that is required for our customers to remain

PCI compliant in their sales environments.

The actual restaurant configuration and the type of access to the system desired will determine if

OpenVPN is needed. A very secure installation will require OpenVPN for all connectivity to the

system. Most configurations will allow browser access via SSL – HTTPS, but will also require

OpenVPN for shell and FTP access. Simply put, most IT department personnel retrieving poll

files or downloading auto-updates of other data files will be required to use OpenVPN or some

other VPN solution.

Certificate needed before continuing

Each user granted access to the system through the VPN will need his own security certificate in

addition to being listed in the Remote Access User edit in the system. The Security Certificate is

good for all restaurants owned by the company. Contact SICOM Systems for details and

procedures required to obtain these certificates. Remote users need to be re-added if a hard

drive is replaced in the restaurant.

OpenVPN Installation

First, the OpenVPN software needs to be installed on your Windows computer. It requires

Windows XP and will not work on Windows 9x or Me computers. The latest version of the

software is available at http://openvpn.net/download.html The current release as of this

document’s date is 2.0.9. Select the “Windows Installer” download link, and save the file to your

hard drive. Once the file is downloaded, double-click the saved file to begin the installation.

There is also a Graphical User Interface version (OpenVPN GUI for Windows) available at

http://openvpn.se/download.html

Installation of OpenVPN Package

You will see a security warning displayed by Windows. Click “Run” to continue.

27

Keep pressing “Next” and “Install” until you see another message displayed. Press “Continue

Anyway.”

Once the software is installed, you will see a new icon appear in the system tray on the bottomright

corner of the screen. This indicates that the OpenVPN network adaptor has been

successfully installed.

By default, the adaptor is named “Local Area Connection 2.” To avoid confusion in the future, we

shall rename the connection to something more specific and related to its real use, VPN.

28

Open up your “Network Connections” folder by selecting “Control Panel” from the Start Menu,

then “Network and Internet Connections”, and finally “Network Connections.” You should see the

“Local Area Connection 2” icon in the “LAN or High-Speed Internet” section. Make sure the

bottom line reads “TAP-Win32 Adapter V8.” Right-click on the icon, and select “Rename.”

Use your keyboard to input the new name for the connection, “OpenVPN Connection” and press

enter.

The icon should now be renamed in the window and on the taskbar.

Installation of OpenVPN GUI Package

29

Read the License and click “I Agree” if you accept, click Next. Keep pressing “Next” and “Install”

until you see another message displayed. Press “Continue Anyway.”

Once the software is installed, you will see a new icon appear in the system tray on the bottomright

corner of the screen. This indicates that the OpenVPN network adaptor has been

successfully installed.

30

By default, the adaptor is named “Local Area Connection 2.” To avoid confusion in the future, we

shall rename the connection to something more specific and related to its real use, VPN.

Open up your “Network Connections” folder by selecting “Control Panel” from the Start Menu,

then “Network and Internet Connections”, and finally “Network Connections.” You should see the

“Local Area Connection 2” icon in the “LAN or High-Speed Internet” section. Make sure the

bottom line reads “TAP-Win32 Adapter V8.” Right-click on the icon, and select “Rename.”

Use your keyboard to input the new name for the connection, “OpenVPN Connection” and press

enter.

The icon should now be renamed in the window and on the taskbar.

Connecting to the Restaurant

Now that the software is installed, the next logical step is to try to connect to the restaurant. This

requires several steps to be completed before you can attempt a connection. First, you need

your user certificate provided by SICOM Systems. Each user connecting through OpenVPN must

have an individual user certificate that indicates the user and company. This file (actually a set of

files) is needed to gain access to the system. A corresponding entry is added to the system in

addition to the entry in remote access edit to allow connection to the system. Certificate requests

31

must be made, in writing, by an authorized member or delegate of your company’s executive

staff. You will also need the domain name or IP address of the restaurant you wish to connect

with.

The combination of your username, password, and digital certificate provide the security needed

to positively verify your identity while remotely connecting to a SICOM SL Series system.

Compliance standards state that a remote user needs to possess two forms of identification when

connecting. The first item is “something you know,” a password that is assigned to you and only

you. The second is “something you have,” and this item is in the form of a signed encryption

certificate that is saved on your USB memory stick. Having both of these items proves that you

are who you say you are, and allows the software to grant you access to the remote system.

OpenVPN Configuration Files

If you are using the Windows GUI installation of OpenVPN, Place your digital certificate and

configuration files you received into the OpenVPN config directory. This is usually C:\Program

Files\OpenVPN\config. Right-clicking the OpenVPN icon will let you start OpenVPN for a

specific user configuration file. If more than one user has access to the computer, it is

recommended that the certificate and configuration files be stored on a separate device such as a

USB flash drive. Better yet, the file should be stored on a secure, encrypted portion of the flash

drive.

Right-click OpenVPN

for options

Troubleshooting

Next, we need to set the Windows Firewall settings so that it does not automatically block your

attempts to connect to a restaurant. Right-click the “OpenVPN Connection” icon from the

“Network Connections” window and select “Properties.”

32

Click on the “Advanced” tab shown.

Click the “Settings” button to open the Windows Firewall settings dialog. Click on the “Advanced”

tab of the Windows Firewall dialog box.

33

Under “Network Connection Settings,” find your “OpenVPN Connection” from the list of choices

displayed. Uncheck the box to the left of the connection name to disable Windows Firewall

filtering over the OpenVPN connection.

If you are using Windows XP with Service Pack 2, there are some known third party firewall

software issues. Please refer to this link: http://openvpn.se/xpsp2_problem.html to see if there is

a reported issue with your third party firewall.

34

Detailed PCI-DSS Requirements

The following chart provides the detailed requirements of the PCI Data Security Standard as of

this printing. The column of “Pertinent SICOM SL Series Information” provides 2 types of

information related to your compliance. It either provides information on steps that the SICOM

System has implemented to aid in your compliance efforts or provides alerts to your

responsibilities as the Merchant. Remember, the SICOM SL Series system is designed as a selfcontained,

private network. SICOM has taken steps to assure compliance if the system is

integrated into another network or if the system is connected to a broadband network.

PCI-DSS Topic Pertinent SICOM SL

Information

Build and Maintain a Secure Network

Requirement 1: Install and maintain a firewall configuration to protect data.

Firewalls are computer devices that control computer traffic allowed into a company’s network from

outside, as well as traffic into more sensitive areas within a company’s internal network. All systems

need to be protected from unauthorized access from the Internet, whether for e-commerce, employees

Internet-based access via desktop browsers, or employees’ email access. Often, seemingly insignificant

paths to and from the Internet can provide unprotected pathways into key systems. Firewalls are a key

protection mechanism for any computer network

1.1 Establish firewall configuration standards that

include:

1.1.1 A formal process for approving and testing all

external network connections and changes to

the firewall configuration

1.1.2 A current network diagram with all connections

to cardholder data, including any wireless

networks

1.1.3 Requirements for a firewall at each Internet

connection and between any DMZ and the

Intranet

1.1.4 Description of groups, roles, and responsibilities

for logical management of network components

1.1.5 Documented list of services/ports necessary for

business

Devices that do not need to be

accessed by the SICOM POS

system should be placed onto a

different network segment.

SICOM SL Series has a firewall

in place limiting traffic. A limited

selection of firewall options

exist in the system which the

user can select for their

compliance efforts. The

merchant must provide a

hardware firewall device as a

means of first-line defense if the

POS network is connected to

an external source.

Port 22 (ssh), 443 (https) and

1194(VPN) must be open for

customers desiring external,

remote, connection to an SL

Series System. If using the

OpenVPN service on the

terminal, port 22 does not need

35

36

1.1.6 Justification and documentation for any

available protocols besides HTTP and SSL,

SSH, and VPN

1.1.7 Justification and documentation for any risky

protocols allowed (FTP, etc.), which includes

reason for use of protocol and security features

implemented

to be available. If desired, port

443 may also be closed if you

desire all connectivity to the

SICOM POS system to use the

VPN. This is the safest and

most secure option. Any ports

additional ports open to the

network must be justified by the

merchant.

No insecure protocols are

permitted. Merchant must justify

any protocol access on the

cardholder network for non-

SICOM equipment.

Merchant must justify any

protocol access on the

cardholder network for non-

SICOM equipment.

1.1.8 Periodic review of firewall/router rule sets Refer to the Enhanced User

and Login Security document

on how to check your SICOM

firewall configuration. Merchant

must provide a router

connecting the POS system to

additional devices/resources

and must verify their

router/firewall rules.

1.1.9 Configuration standards for routers

1.2 Build a firewall configuration that denies all

traffic from “un-trusted” networks/hosts, except

for:

1.2.1 Web protocols - HTTP (port 80) and Secure

Sockets Layer (SSL) (typically port 443)

1.2.2 System administration protocols (e.g., Secure

Shell (SSH) or Virtual Private Network (VPN)

1.2.3 Other protocols required by the business (e.g.,

for ISO 8583).

1.3 Build a firewall configuration that restricts

connections between publicly accessible

servers and any system component storing

cardholder data, including any connections from

wireless networks. This firewall configuration

should include:

1.3.1 Restricting inbound Internet traffic to IP

addresses within the DMZ (ingress filters)

Refer to the Enhanced User

and Login Security document

on how to check your SICOM

firewall configuration.

The only external connection to

the POS network shall be to the

SICOM SL Series Manager

Terminal which is addressed as

192.168.1.80. This terminal

does not house sensitive

cardholder data when

configured with a remote

datastore.

1.3.2 Restricting inbound and outbound Internet

traffic to ports 80 and 443

1.3.3 Not allowing internal addresses to pass from

the Internet into the DMZ (egress filters)

1.3.4 Stateful inspection, also known as dynamic

packet filtering (only ”established” connections

are allowed into the network)

1.3.5 Placing the database in an internal network

zone, segregated from the DMZ

1.3.6 Restricting outbound traffic to that which is

necessary for the payment card environment

1.3.7 Securing and synchronizing router configuration

files (e.g., running configuration files – used for

normal running of the routers, and start-up

configuration files - used when machines are rebooted,

should have the same, secure

configuration).

1.3.8 Denying all other inbound and outbound traffic

not specifically allowed

1.3.9 Installation of perimeter firewalls between any

wireless networks and the payment card

environment, and configuration of these

firewalls to deny or control (if such traffic is

necessary for business purposes) any traffic

from the wireless environment

1.3.10 1.3.10 Installation of personal firewall software

on any mobile and/or employee-owned

computers with direct connectivity to the

Internet (e.g., laptops used by employees),

which are used to access the organization’s

network

1.4 Prohibit direct public access between external

networks and any system component that

stores cardholder information (e.g., databases)

1.4.1 Implement a DMZ to filter and screen all traffic,

to prohibit direct routes for inbound and

outbound Internet traffic

1.4.2 Restrict outbound traffic from payment card

applications to IP addresses within the DMZ.

1.5 Implement Internet Protocol (IP) masquerading

to prevent internal addresses from being

translated and revealed on the Internet. Use

technologies that implement RFC 1918 address

space, such as Port Address Translation (PAT)

or Network Address Translation (NAT)

Requirement 2: Do not use vendor-supplied defaults for system passwords and other

security parameters.

37

Hackers (external and internal to a company) often use vendor default passwords and other vendor

default settings to compromise systems. These passwords and settings are well known in hacker

communities and easily determined via public information.

38

2.1 Always change the vendor-supplied defaults

before you install a system on the network (e.g.,

passwords, SNMP community strings, and

elimination of unnecessary accounts).

2.1.1 For wireless environments, change wireless

vendor defaults, including but not limited to,

WEP keys, default SSID, passwords, and

SNMP community strings, and disabling of

SSID broadcasts. Enable Wi-Fi Protected

Access (WPA) technology for encryption and

authentication when WPA-capable.

2.2 Develop configuration standards for all system

components. Make sure these standards

address all known security vulnerabilities and

industry best practices.

2.2.1 Implement only one primary function per server

(e.g., web servers, database servers, and DNS

should be implemented on separate servers)

2.2.2 Disable all unnecessary and insecure services

and protocols (services and protocols not

directly needed to perform the devices’

specified function).

2.2.3 Configure system security parameters to

prevent misuse

2.2.4 Remove all unnecessary functionality, such as

scripts, drivers, features, subsystems, file

systems (e.g., unnecessary web servers).

2.3 Encrypt all non-console administrative access.

Use technologies such as SSH, VPN, or

SSL/TLS for web-based management and other

non-console administrative access.

Non-SICOM devices should be

monitored for enabled services

to ensure that access to the

POS network is not

inadvertently provided.

The SICOM SL Series system

has functionality limited to POS

specific tasks for security

reasons.

Connection to SICOM terminals

is limited to SSH and SSL

connections. Remote access

should be via a VPN with

specific, tracked user accounts.

The SICOM SL can optionally

provide OpenVPN. It should be

configured for broadband

remote access if no other VPN

is used. Certificates can be

obtained and installed by the

merchant or optionally provided

by SICOM Systems, Inc.

Protect Cardholder Data

Requirement 3: Protect Stored Data

Encryption is the ultimate protection mechanism because even if someone breaks through all other

protection mechanisms and gains access to encrypted data, they will not be able to read the data without

further breaking the encryption. This is an illustration of the defense in depth principle.

3.1 Keep cardholder information storage to a

minimum. Develop a data retention and

disposal policy. Limit your storage amount and

retention time to that which is required for

business, legal, and/or regulatory purposes, as

documented in the data retention policy.

3.2 Do not store sensitive authentication data

subsequent to authorization (not even if

encrypted):

3.2.1 Do not store the full contents of any track from

the magnetic stripe (on the back of a card, in a

chip, etc.)

3.2.2 Do not store the card-validation code (Threedigit

or four-digit value printed on the front or

back of a payment card (e.g., CVV2 and CVC2

data))

The SICOM SL Series terminal

does not store any sensitive

cardholder information once a

batch is closed successfully.

Magnetic stripe contents and

PIN blocks are never stored

after authorization.

Not Stored.

3.2.3 Do not store the PIN Verification Value (PVV) Not Stored.

3.3 Mask account numbers when displayed (the

first six and last four digits are the maximum

number of digits to be displayed).

Note that this does not apply to those employees and other

parties with a specific need to see full credit card numbers.

3.4 Render sensitive cardholder data unreadable

anywhere it is stored (including data on portable

media, backup media, in logs, and data

received from or stored by wireless networks)

by using any of the following approaches:

• One-way hashes (hashed indexes),

such as SHA-1

• Truncation

• Index tokens and PADs, with the PADs

being securely stored

• Strong cryptography, such as Triple-

DES 128-bit or AES 256-bit with

associated key management processes

and procedures.

The MINIMUM account information that needs to be rendered

unreadable is the payment card account number.

3.5 Protect encryption keys against both disclosure

and misuse.

Validation code is not requested

or stored.

Only the last 4 digits of account

numbers are displayed.

3DES encryption is used for all

sensitive cardholder data in the

SICOM SL Series POS System.

39

3.5.1 Restrict access to keys to the fewest number of

custodians necessary

3.5.2 Store keys securely in the fewest possible

locations and forms.

3.6 Fully document and implement all key

management processes and procedures,

including:

3.6.1 Generation of strong keys

3.6.2 Secure key distribution

3.6.3 Secure key storage

3.6.4 Periodic key changes

3.6.5 Destruction of old keys

3.6.6 Split knowledge and dual control of keys (so

that it requires 2 or 3 people, each knowing only

their part of the key, to reconstruct the whole

key).

3.6.7 Prevention of unauthorized substitution of keys

3.6.8 Replacement of known or suspected

compromised keys

3.6.9 Revocation of old or invalid keys (mainly for

RSA keys)

3.6.10 Requirement for key custodians to sign a form

specifying that they understand and accept their

key-custodian responsibilities

Contact SICOM Systems

immediately at 800-547-4266 if

it is suspected that these keys

have been compromised.

RSA keys are not used.

Requirement 4: Encrypt transmission of cardholder and sensitive information across

public networks.

Sensitive information must be encrypted during transmission over the Internet, because it is easy and

common for a hacker to intercept and/or divert data while in transit.

40

4.1 Use strong cryptography and encryption

techniques (at least 128 bit) such as Secure

Sockets Layer (SSL), Point-to-Point Tunneling

Protocol (PPTP), Internet Protocol Security

(IPSEC) to safeguard sensitive cardholder data

during transmission over public networks

SICOM encrypts all cardholder

information when transmitted

between terminals.

4.1.1 For wireless networks transmitting cardholder

data, encrypt the transmissions by using Wi-Fi

Protected Access (WPA) technology if WPA

capable, or VPN or SSL at 128-bit. Never rely

exclusively on WEP to protect confidentiality

and access to a wireless LAN. Use one of the

above methodologies in conjunction with WEP

at 128 bit, and rotate shared WEP keys

quarterly and whenever there are personnel

changes.

4.2 Never send cardholder information via

unencrypted e-mail.

The application is designed for

the specific POS hardware and

OS provide by SICOM. It is not

designed for wireless

enablement. Should the

Merchant add wireless

capability to the network, that

Merchant is responsible for

securing it properly.

Full cardholder information is

not normally provided at any

time for merchants. Should

there be an instance where the

merchant obtains cardholder

information, they must ensure

that any transmission of that

data is securely transmitted in

an encrypted format.

Maintain a Vulnerability Management Program

Requirement 5: Use and regularly update anti-virus software or programs.

Many vulnerabilities and malicious viruses enter the network via employees’ email activities. Anti-virus

software must be used on all email systems and desktops to protect systems from malicious software.

5.1 Deploy anti-virus mechanisms on all systems

commonly affected by viruses (e.g. PC’s and

servers).

5.2 Ensure that all anti-virus mechanisms are

current, actively running, and capable of

generating audit logs.

Requirement 6: Develop and maintain secure systems and applications

The SICOM SL Series Manager

Terminal is a closed Linux

system running only POS

related software. Due to the

controlled nature of the host

and application environment,

there are no significant risks.

The customer should either

provide an Antivirus Gateway to

protect the environment or

request (or enable) built-in

ClamAV support. ClamAV is an

opensource AntiVirus package

which the SL Series system

supports.In addition, all non-

SICOM network devices should

have anti-virus and spy-ware

software enabled to ensure no

outside threat to the

environment.

41

Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these

vulnerabilities are fixed via vendor security patches, and all systems should have current software

patches to protect against exploitation by employees, external hackers, and viruses. For in-house

developed applications, numerous vulnerabilities can be avoided by using standard system development

processes and secure coding techniques.

42

6.1 Ensure that all system components and

software have the latest vendor-supplied

security patches.

6.1.1 Install relevant security patches within one

month of release.

6.2 Establish a process to identify newly discovered

security vulnerabilities (e.g., subscribe to alert

services freely available on the Internet).

Update your standards to address new

vulnerability issues.

6.3 Develop software applications based on

industry best practices and include information

security throughout the software development

life cycle. Include the following:

6.3.1 Testing of all security patches and system and

software configuration changes before

deployment

6.3.2 Separate development/test and production

environments

6.3.3 Separation of duties between development/test

and production environments

6.3.4 Production data (real credit card numbers) are

not used for testing or development

6.3.5 Removal of test data and accounts before

production systems become active

6.3.6 Removal of custom application accounts,

usernames, and passwords before applications

become active or are released to customers.

6.3.7 Review of custom code prior to release to

production or customers, to identify any

potential coding vulnerability

6.4 Follow change control procedures for all system

and software configuration changes. The

procedures should include:

6.4.1 Documentation of impact

A SICOM Support contract

provides for software patches

and security updates for the

SICOM POS system. The

Merchant must ensure that all

non-SICOM POS devices on

the network are adequately

maintained to prevent a security

vulnerability to the network.

When necessary, the Merchant

must ensure that all updates

provided by the POS Vendor or

scheduled for installation in a

timely basis.

6.4.2 Management sign-off by appropriate parties

6.4.3 Testing that verifies operational functionality

6.4.4 Back-out procedures.

6.5 Develop web software and applications based

on secure coding guidelines such as the Open

Web Application Security Project guidelines.

Review custom application code to identify

coding vulnerabilities. See www.owasp.org -

“The Ten Most Critical Web Application Security

Vulnerabilities.” Cover prevention of common

coding vulnerabilities in software development

processes, to include:

6.5.1 Unvalidated input

6.5.2 Broken access control (e.g., malicious use of

user IDs)

6.5.3 Broken authentication/session management

(use of account credentials and session

cookies)

6.5.4 Cross-site scripting (XSS) attacks

6.5.5 Buffer overflows

6.5.6 Injection flaws (e.g., SQL injection)

6.5.7 Improper error handling

6.5.8 Insecure storage

6.5.9 Denial of service

6.5.10 Insecure configuration management.

Implement Strong Access Control Measures

Requirement 7: Restrict access to data by business need-to-know.

This ensures critical data can only be accessed in an authorized manner.

7.1 Limit access to computing resources and

cardholder information to only those individuals

whose job requires such access.

7.2 Establish a mechanism for systems with

multiple users that restricts access based on a

user’s need to know, and is set to “deny all”

unless specifically allowed.

The POS system provides

limited access to cardholder

information. Merchant is to

assign security levels to credit

information to only those who

require access. In addition,

merchant is to limit access to

system employee data and

employee creation (via

assigned security levels) as

employees are the entry point

of cardholder data into the

environment.

The POS system prevents

access to all management

functions unless the user has

been assigned a level

43

44

permitting access.

Requirement 8: Assign a unique ID to each person with computer access.

This ensures that actions taken on critical data and systems are performed by, and can be traced to,

known and authorized users.

8.1 Identify all users with a unique username

before allowing them to access system

components or cardholder data.

8.2 Employ at least one of the methods below,

in addition to unique identification, to

authenticate all users:

• Password

• Token devices (e.g., SecureID,

certificates, or public key)

• Biometrics.

8.3 Implement 2-factor authentication for

remote access to the network by

employees, administrators, and third

parties. Use technologies such as RADIUS

or TACACS with tokens, or VPN with

individual certificates.

8.4 Encrypt all passwords during transmission

and storage, on all system components.

8.5 Ensure proper user authentication and

password management for non-consumer

users and administrators, on all system

components:

8.5.1 Control the addition, deletion, and

modification of user IDs, credentials, and

other identifier objects.

8.5.2 Verify user identity before performing

password resets.

8.5.3 Set first-time passwords to a unique value

per user and change immediately after first

use

8.5.4 Immediately revoke accesses of

terminated users.

8.5.5 Remove inactive user accounts at least

every 90 days

8.5.6 Enable accounts used by vendors for

remote maintenance only during the time

needed

User Security Setting edit provides

merchant controls for authentication

requirements and provides on-screen

guidance when items are out of

recommended settings. A single

button option provides in-spec

choices for all items. The Merchant is

required to review these settings for

compliance.

See 8.5 response above.

SICOM Support personnel log in with

unique user names and passwords

which change daily. In addition,

individual certificates linked to the

user are required if the OpenVPN

45

8.5.7 Distribute password procedures and

policies to all users who have access to

cardholder information

8.5.8 Do not use group, shared, or generic

accounts/passwords

8.5.9 Change user passwords at least every 90

days

8.5.10 Require a minimum password length of at

least seven characters

8.5.11 Use passwords containing both numeric

and alphabetic characters

8.5.12 Do not allow an individual to submit a new

password that is the same as any of the

last four passwords he or she has used

8.5.13 Limit repeated access attempts by locking

out the user ID after not more than six

attempts

8.5.14 Set the lockout duration to thirty minutes or

until administrator enables the user ID

8.5.15 If a session has been idle for more than 15

minutes, require the user to re-enter the

password to re-activate the terminal

8.5.16 Authenticate all access to any database

containing cardholder information. This

includes access by applications,

administrators, and all other users.

service has been enabled. Best

practice is to disconnect the modem

when not specifically needed. Since

the modem may be used for the

credit authorization, this may not be

practical in all cases. SICOM

recommends that connectivity via

dial-up be through the OpenVPN

service to discourage attacks on the

application environment.

Merchant must develop policies and

procedures for all users with access

to cardholder data.

Merchant must ensure that each

authorized user has their own

account.








The Application provides this

authentication.

Requirement 9: Restrict physical access to cardholder data

Any physical access to data or systems that house cardholder data allows the opportunity to access

devices or data, and remove systems or hardcopies, and should be appropriately restricted.

46

9.1 Use appropriate facility entry controls to

limit and monitor physical access to

systems that store, process, or transmit

cardholder data.

9.1.1 Use cameras to monitor sensitive areas.

Audit this data and correlate with other

entries. Store for at least three months,

unless otherwise restricted by law.

9.1.2 Restrict physical access to publicly

accessible network jacks.

9.1.3 Restrict physical access to wireless access

points, gateways, and handheld devices.

9.2 Develop procedures to help all personnel

easily distinguish between employees and

visitors, especially in areas where

cardholder information is accessible.

“Employee” refers to full-time and part-time

employees, temporary employees/personnel,

and consultants who are “resident” on the

entity’s site. A “visitor” is defined as a vendor,

guest of an employee, service personnel, or

anyone who needs to enter the facility for a

short duration, usually not more than one day.

9.3 Make sure all visitors are:

9.3.1 Authorized before entering areas where

cardholder data is processed or maintained

9.3.2 Given a physical token (e.g., badge or

access device) that expires, and that

identifies them as non-employees

9.3.3 Asked to surrender the physical token

before leaving the facility or at the date of

expiration.

9.4 Use a visitor log to retain a physical audit

trail of visitor activity. Retain this log for a

minimum of three months, unless

otherwise restricted by law.

9.5 Store media back-ups in a secure off-site

facility, which may be either an alternate

third-party or a commercial storage facility.

9.6 Physically secure all paper and electronic

media (e.g., computers, electronic media,

networking and communications hardware,

telecommunication lines, paper receipts,

paper reports, and faxes) that contain

cardholder information.

9.7 Maintain strict control over the internal or

external distribution of any kind of media

that contains cardholder information

9.7.1 Label the media so it can be identified as

confidential.

9.7.2 Send the media via secured courier or a

delivery mechanism that can be accurately

tracked.

9.8 Ensure management approves all media

that is moved from a secured area

(especially when media is distributed to

47

individuals).

9.9 Maintain strict control over the storage and

accessibility of media that contains

cardholder information:

9.9.1 Properly inventory all media and make

sure it is securely stored.

9.10 Destroy media containing cardholder

information when it is no longer needed for

business or legal reasons:

9.10.1 Cross-cut shred, incinerate, or pulp

hardcopy materials

9.10.2 Purge, degauss, shred, or otherwise

destroy electronic media so that cardholder

data cannot be reconstructed.

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder

data.

Logging mechanisms and the ability to track user activities are critical. The presence of logs in all

environments allows thorough tracking and analysis when something does go wrong. Determining the

cause of a compromise is very difficult without system activity logs.

10.1 Establish a process for linking all access to

system components (especially those done

with administrative privileges such as root)

to an individual user.

48

10.2 Implement automated audit trails to

reconstruct the following events, for all

system components:

10.2.1 All individual user accesses to cardholder

data

10.2.2 All actions taken by any individual with root

or administrative privileges

10.2.3 Access to all audit trails

10.2.4 Invalid logical access attempts

10.2 5 Use of identification and authentication

mechanisms

10.2.6 Initialization of the audit logs

10.2.7 Creation and deletion of system-level

objects.

10.3 Record at least the following audit trail

entries for each event, for all system

components:

10.3.1 User identification

10.3.2 Type of event

10.3.3 Date and time

10.3.4 Success or failure indication

10.3.5 Origination of event

10.3.6 Identity or name of affected data, system

component, or resource.

10.4 Synchronize all critical system clocks and

times.

10.5 Secure audit trails so they cannot be

altered, including the following:

10.5.1 Limit viewing of audit trails to those with a

job-related need

10.5.2 Protect audit trail files from unauthorized

modifications

10.5.3 Promptly back-up audit trail files to a

centralized log server or media that is

difficult to alter

10.5.4 Copy logs for wireless networks onto a log

server on the internal LAN.

10.5.5 Use file integrity monitoring/change

detection software (such a Tripwire) on

logs to ensure that existing log data cannot

be changed without generating alerts

(although new data being added should not

cause an alert).

10.6 Review logs for all system components at

least daily. Log reviews should include

those servers that perform security

functions like IDS and authentication (AAA)

servers (e.g RADIUS).

10.7 Retain your audit trail history for a period

that is consistent with its effective use, as

well as legal regulations.

An audit history usually covers a period of at

least one year, with a minimum of 3 months

available online.

Requirement 11: Regularly test security systems and processes

Vulnerabilities are continually being discovered by hackers/researchers and introduced by new software.

Systems, processes, and custom software should be tested frequently to ensure security is maintained over

time and through changes.

11.1 Test security controls, limitations, network

connections, and restrictions routinely to

make sure they can adequately identify or

stop any unauthorized access attempts.

Where wireless technology is deployed,

use a wireless analyzer periodically to

identify all wireless devices in use.

49

11.2 Run internal and external network

vulnerability scans at least quarterly and

after any significant change in the network

(e.g., new system component installations,

changes in network topology, firewall rule

modifications, product upgrades).

Note that external vulnerability scans must be

performed by a scan vendor qualified by the

payment card industry.

11.3 Perform penetration testing on network

infrastructure and applications at least

once a year and after any significant

infrastructure or application upgrade or

modification (e.g., operating system

upgrade, sub-network added to

environment, web server added to

environment).

11.4 Use network intrusion detection systems,

host-based intrusion detection systems,

and/or intrusion prevention systems to

monitor all network traffic and alert

personnel to suspected compromises.

Keep all intrusion detection and prevention

engines up to date.

11.5 Deploy file integrity monitoring to alert

personnel to unauthorized modification of

critical system or content files, and perform

critical file comparisons at least daily (or

more frequently if the process can be

automated).

Critical files are not necessarily those

containing cardholder data. For file integrity

monitoring purposes, critical files are usually

those that do not regularly change, but the

modification of which could indicate a system

compromise or risk of compromise. File

integrity monitoring products usually come

pre-configured with critical files for the related

operating system. Other critical files, such as

those for custom applications, must be

evaluated and defined by the merchant or

service provider.

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security for employees

and contractors.

A strong security policy sets the security tone for the whole company, and lets employees know what is

expected of them. All employees should be aware of the sensitivity of data and their responsibilities for

protecting it.

50

12.1 Establish, publish, maintain, and

disseminate a security policy that:

12.1.1 Addresses all requirements in this

specification.

12.1.2 Includes an annual process that identifies

threats, and vulnerabilities, and results in a

formal risk assessment

12.1.3 Includes a review at least once a year and

updates when the environment changes.

12.2 Develop daily operational security

procedures that are consistent with

requirements in this specification (e.g.,

user account maintenance procedures, log

review procedures)

12.3 Develop usage policies for critical

employee-facing technologies, such as

modems and wireless, to define proper use

of these technologies for all employees

and contractors. Ensure these usage

policies require:

12.3.1 Explicit management approval

12.3.2 Authentication for use of the technology

12.3.3 A list of all such devices and personnel

with access

12.3.4 Labeling of devices with owner, contact

information, and purpose

12.3.5 Acceptable uses of the technology

12.3.6 Acceptable network locations for these

technologies

12.3.7 A list of company-approved products

12.3.8 Automatic disconnect of modem sessions

after a specific period of inactivity

12.3.9 Activation of modems for vendors only

when needed by vendors, with immediate

deactivation after use.

12.3.10 When accessing cardholder data remotely

via modem, disable storage of cardholder

data onto local hard drives, floppy disks or

other external media. Also disable cut-andpaste,

and print functions during remote

access.

12.4 Ensure the security policy and procedures

clearly define information security

responsibilities for all employees and

contractors.

12.5 Assign to an individual or team the

following information security management

responsibilities:

51

52

12.5.1 Establish, document, and distribute

security policies and procedures

12.5.2 Monitor and analyze security alerts and

information, and distribute to appropriate

personnel

12.5.3 Establish, document, and distribute

security incident response and escalation

procedures to ensure timely and effective

handling of all situations

12.5.4 Administer user accounts, including

additions, deletions, and modifications

12.5.5 Monitor and control all access to data.

12.6 Make all employees aware of the

importance of cardholder information

security

12.6.1 educate employees (e.g., through posters,

letters, memos, meetings, and

promotions).

12.6.2 require employees to acknowledge in

writing they have read and understood the

company’s security policy and procedures.

12.7 Screen potential employees to minimize

the risk of attacks from internal sources.

For those employees who only have

access to one card number at a time to

facilitate a transaction, such as store

cashiers, this requirement is a

recommendation only.

12.8 Contractually require all third parties with

access to cardholder data to adhere to

payment card industry security

requirements. At a minimum, the

agreement should address:

12.8.1 Acknowledgement that the 3rd party is

responsible for security of cardholder data

in their possession.

12.8.2 Ownership by each Payment Card brand,

Acquirer, and Merchants of cardholder

data and acknowledgement that such data

can ONLY be used for assisting these

parties in completing a transaction,

supporting a loyalty program, providing

fraud control services, or for others uses

specifically required by law.

12.8.3 Business continuity in the event of a major

disruption, disaster or failure.

12.8.4 Audit provisions that ensure that Payment

Card Industry representative, or a Payment

Card Industry approved third party, will be

provided with full cooperation and access

to conduct a thorough security review after

a security intrusion. The review will validate

compliance with the Payment Card

Industry Data Security Standard for

protecting cardholder data.

12.8.5 Termination provision that ensures that 3rd

party will continue to treat cardholder data

as confidential.

12.9 Implement an incident response plan. Be

prepared to respond immediately to a

system breach.

12.9.1 Create an incident response plan to be

used in the event of system compromise.

Ensure the plan addresses, at a minimum,

specific incident response procedures,

business recovery and continuity

procedures, data backup processes, roles

and responsibilities, and communication

and contact strategies (e.g., informing

Acquirers and credit card associations.).

12.9.2 Test the plan at least annually.

12.9.3 Designate specific personnel to be

available on a 24/7 basis to respond to

alerts.

12.9.4 Provide appropriate training to staff with

security breach response responsibilities.

12.9.5 Include alerts from intrusion detection,

intrusion prevention, and file integrity

monitoring systems.

12.9.6 Have a process to modify and evolve the

incident response plan according to

lessons learned and to incorporate industry

developments.

Out of scope

53

Glossary

Acquiring Bank A bank that provides credit card merchant

accounts and is responsible for submitting

credit card purchase information to the credit

card associations. Application Service

Provider (ASP)

Bank Card Association The organization is owned by financial

institutions that licenses a bank card program

or performs transaction processing for its

owners. The present day national card

associations, Mastercard International and Visa

International, perform four key functions:

licensing bank cards and service marks to card

issuing banks; authorizing transactions by

cardholders; settling interchange transactions

when the transaction processing bank (called

the Merchant Bank) is different from the card

issuer; and setting the Interchange rate, or the

transaction processing fee paid by association

members.

Firewall A network firewall protects a computer network

from unauthorized access. Network firewalls

may be hardware devices, software programs,

or a combination of the two.

Network firewalls guard an internal computer

network (home, school, business intranet)

against malicious access from the outside.

Network firewalls may also be configured to

limit access to the outside from internal users.

Many network routers include built-in firewall

support. The administrative interface of these

routers include configuration options for the

firewall. Router firewalls can be turned off

(disabled), or they can be set to filter certain

types of network traffic through so-called

firewall rules.

IPSec IPSec, or IP Security is a set of protocols

intended to secure Internet Protocol (IP)

communications. It is done by encrypting

and/or authenticating each IP packet in a data

stream. IPsec also includes protocols for

cryptographic key establishment.

Merchant A business or person providing goods and/or

services to a consumer. The merchant is the

account holder subscribing to a bank for the

purpose of processing credit card transactions.

Merchant Account An agreement between a credit card processor

that allows a business to accept credit cards,

debit cards, gift cards and other forms of

54

electronic payment. This is also widely known

as payment processing or credit card

processing.

Merchants, or business owners who receive

payment for their goods or services, must apply

for a merchant account

Merchant Processor A company that handles or provides

transaction or data processing services to

merchants

A Processor is the company that actually

routes an Authorization Request from a Point

of Sale device (such as a Verifone credit card

terminal) to Visa, MasterCard and American

Express etc. It then arranges for settlement to

the merchant.

Processors need to have a Sponsoring Bank in

order to gain access to the Visa and

MasterCard networks. When a Processor or

other entity has made such an arrangement

with a Sponsoring Bank to resell their services,

they are called an Agent of that bank.

Many banks are also their own processors,

while other banks will use a Third Party

Processor to handle this processing for them.

Network Segmentation A method of distributing network services to

logical devices. Since all network traffic flows

through a network, a segmented network

increases band-width utilization by keeping

network information (packets) in a localized

area. In security applications, it is used to

restrict the flow of data to only those devices

needing access to it. The more devices having

access to data that is not needed, increases

the risk to that data. In the realm of a Payment

Application Environment, the area that

cardholder information traverses and the

devices with access to that environment should

be limited as much as possible.

Payment Application Provider This is the company or dealer that provides the

hardware, software, or services to gather

cardholder information send it along to a

processor. It could be a Verifone Terminal, a

Point of Sale system or a web

application/shopping cart.

Payment Acceptance Environment The area where credit/debit transactions are

processed. This is both a physical as well as a

computer network environment. This is

anywhere a customer provides his card to an

employee, and everywhere the information on

that card is transmitted or stored (anything it

55

touches),

Payment Application Environment Same as Payment Application Environment

Service Provider

Software Vendors

SSL Secure Sockets Layer (SSL) is an industry

standard for secure communications. It was

developed by Netscape for transmitting private

documents quickly became a standard for both

web and data transport. SSL uses a

cryptographic system that uses two keys to

encrypt data − a public key known to everyone

and a private or secret key known only to the

recipient of the message

TCP/IP Transmission Control Protocol/Internet Protocol

IPSec

56

Secure Implementation Guide - SICOM Systems, Inc.

Do you know the secret to free website traffic?

Delete template?

Save as template?