data security handbook 6.4
TRANSCRIPT
-
8/6/2019 Data Security Handbook 6.4
1/52
Data Security Handbook
Point-of-Sale v6.4
-
8/6/2019 Data Security Handbook 6.4
2/52
Copyright 2010, Radiant Systems, Inc. The information contained in this publication is confidential and proprietary.
No part of this document may be reproduced, disclosed to others, transmitted, stored in a retrieval system, or trans-
lated into any language, in any form, by any means, without written permission of Radiant Systems, Inc.
Radiant Systems, Inc. is not responsible for any technical inaccuracies or typographical errors contained in this pub-
lication. Changes are periodically made to the information herein; these changes will be incorporated in new editions
of this publication. Any reference to gender in this document is not meant to be discriminatory. The software
described in this document is provided under a license agreement. The software may be used or copied only in
accordance with the terms of that agreement.
While the content in this document has been obtained from sources believed to be reliable, no warranty is provided
concerning such content and it does not constitute legal advice. Legal advice concerning specific situations should
be obtained by your legal counsel.
Radiant Systems, Inc., 2010 All Rights Reserved. ALOHA is a U.S. Registered Trademark of Radiant Systems,
Inc. MenuLink is a U.S. Registered Trademark of Radiant Systems, Inc.
http://goback/ -
8/6/2019 Data Security Handbook 6.4
3/52
Page 3
POS v6.4 Data
Security HandbookLast Modified: 1/18/2010
Table of Contents
Defining the PCI DSS Requirements................................................................................... 5What Are the PCI DSS Requirements, and Why Should I Care? ........................................ 5What are Best Practices?................................................................................................... 5
Summarizing the PCI DSS Requirements ........................................................................... 8Complying with the PCI DSS Requirements .................................................................... 12
Building and Maintaining a Secure Network ...................................................................... 12Protecting Cardholder Data ............................................................................................... 19Maintaining a Vulnerability Management Program ............................................................ 21Implementing Strong Access Control Measures................................................................ 22Monitoring and Testing Networks Regularly ..................................................................... 30Maintaining an Information Security Policy ........................................................................ 30
Upgrading Client Accounts................................................................................................ 32Working with Backup Files................................................................................................. 32
Safeguarding Cardholder Data After Upgrading.............................................................. 33Frequently Asked Questions............................................................................................. 35
General PCI DSS Information............................................................................................ 35Aloha POS and PCI DSS Information................................................................................ 39Additional Resources ......................................................................................................... 42
Appendix A: PCI DSS Configuration and Site Compliance CheckLists ....................... 44PCI DSS Configuration Checklist....................................................................................... 44Site Checklist for PCI DSS and FACTA Compliance......................................................... 47
Appendix B: Aloha Cryptography ..................................................................................... 48Appendix C: EDC Data Flow .............................................................................................. 49Feature History ................................................................................................................... 50
-
8/6/2019 Data Security Handbook 6.4
4/52
Page 4 POS v6.4 Data Security Handbook
Acceptance of a given payment application by the PCI Security Standards Council, LLC (PCI SSC) only
applies to the specific version of that payment application that was reviewed by a PA-QSA and subse-
quently accepted by PCI SSC (the Accepted Version). If any aspect of a payment application or version
thereof is different from that which was reviewed by the PA-QSA and accepted by PCI SSC even if the
different payment application or version (the Alternate Version) conforms to the basic product description
of the Accepted Version then the Alternate Version should not be considered accepted by PCI SSC, nor
promoted as accepted by PCI SSC.
No vendor or other third party may refer to a payment application as PCI Approved or PCI SSC
Approved, and no vendor or other third party may otherwise state or imply that PCI SSC has, in whole or
part, accepted or approved any aspect of a vendor or its services or payment applications, except to the
extent and subject to the terms and restrictions expressly set forth in a written agreement with PCI SSC, or
in a PA-DSS letter of acceptance provided by PCI SSC. All other references to PCI SSCs approval or
acceptance of a payment application or version thereof are strictly and actively prohibited by PCI SSC.
When granted, PCI SSC acceptance is provided to ensure certain security and operational characteristics
important to the achievement of PCI SSCs goals, but such acceptance does not under any circumstances
include or imply any endorsement or warranty regarding the payment application vendor or the functional-ity, quality, or performance of the payment application or any other product or service. PCI SSC does not
warrant any products or services provided by third parties. PCI SSC acceptance does not, under any cir-
cumstances, include or imply any product warranties from PCI SSC, including, without limitation, any
implied warranties of merchantability, fitness for purpose or noninfringement, all of which are expressly dis-
claimed by PCI SSC. All rights and remedies regarding products and services that have received accep-
tance from PCI SSC, shall be provided by the party providing such products or services, and not by PCI
SSC or any payment brands.
-
8/6/2019 Data Security Handbook 6.4
5/52
POS v6.4 Data Security Handbook Page 5
Defining the PCI DSS Requirements
Defining the PCI DSS Requirements
The strategy for security in the electronic payment industry is undergoing rapid, dramatic changes in
response to multiple factors, especially criminal activity related to electronic payments. Members of this
industry are working in conjunction with legislatures at all levels to safeguard the environment in whichelectronic payments occur. The Payment Card Industry Data Security Standards (PCI DSS) are the direct
result of these efforts.
Independent security consultants have validated Aloha POS software products as conforming to these
requirements, when configured correctly. It is the sincere aim of Radiant Systems, Inc. to offer this docu-
ment to help resellers and merchants understand the nature of these requirements, and how best to config-
ure and use the Aloha system to comply with these requirements
What Are the PCI DSS Requirements, and Why Should I Care?
The Payment Card Industry Data Security Standards (PCI DSS), as formulated by the Security Standards
Council, are the standards by which payment card companies, such as Visa, American Express, Master-Card, and others, agree to measure the security of individual installations, and electronic payment software
products, in an effort to protect cardholder data. Similarly, payment application manufacturers must adhere
to the Payment Application Data Security Standards (PA DSS), formerly the Payment Application Best
Practices (PABP), also promulgated by the Security Standards Council, as a guideline for making products
that are secure, and protect cardholder data. The overall objective is to define security measures, agreeable
to all, that protect cardholders so that in case you have a security breach, data is not compromised. Mer-
chants and vendors that do not comply with these recommendations put cardholder data at risk, and also
risk incurring sizable fines.
What are Best Practices?
As you compare the contents of this document with the PCI DSS requirements, you will find that Radiant
Systems is recommending more stringent security measures in several areas. In those instances, we feel
that a more strict approach to system security will, in the long run, keep you and your customers safer, and
will help you to avoid costly security breaches. We regard these differences between required minimums
and recommended measures as part of what we call best practices, in that they will contribute even more
to your overall data security without incurring unnecessary costs. We have attempted to make note of areas
in which we differ with the PCI DSS requirements in our recommendations, but all may not be so noted.
What Must I Do to Comply?
The first and best step to data security compliance is to maintain your Aloha installation at the latest avail-
able version validated as meeting the applicable security standards. Radiant Systems, Inc. has validated
Aloha version 6.4, through the use of an independent auditor, as being the latest version of Aloha to com-
Version 1.2 of the PCI DSS requirements, the most recent version, is available in its entirety for
download in PDF or DOC format at the following URL:https://www.pcisecuritystandards.org/security_standards/
pci_dss_download.html_agreement.html
https://www.pcisecuritystandards.org/security_standards/pci_dss_download.htmlhttps://www.pcisecuritystandards.org/security_standards/pci_dss_download.htmlhttps://www.pcisecuritystandards.org/security_standards/pci_dss_download.htmlhttps://www.pcisecuritystandards.org/security_standards/pci_dss_download.html -
8/6/2019 Data Security Handbook 6.4
6/52
Page 6 POS v6.4 Data Security Handbook
ply with the security standards current at the time of validation. This version provides industry-standard
AES 256-bit encryption for data transfer across networks for transaction security, and includes security
enhancements to the Aloha EDC payment application. Earlier versions of Aloha, beginning with 5.3.15,
have also been validated. Radiant Systems will continue to validate versions of the Aloha software as they
are developed and released, and recommends customers stay current as new versions become available.
In addition to upgrading your software, you must ensure that your configuration complies with the sugges-
tions presented in this document. A summary of the primary areas of concern is as follows:
User IDs and passwords Verify that all users who have access to the Aloha network have unique user
names and passwords, including their access to Windows, the Aloha system, both Back-of-House (BOH)
and Front-of-House (FOH), and remote administration software, such as pcAnywhere. Train users to log
out of the Aloha BOH, and log out of Windows, when they are not using the system. Train FOH users to
touch Exit as they finish using the terminals. Disable or clear any default users, passwords, and automatic
logins provided by hardware or software vendors. Configure the system to automatically time out users
due to inactivity, wherever possible.
Dated subdirectories Use the DelTrack utility to remove credit card track information from any datedsubdirectories retained at the time of upgrade. Two versions of this utility are available from the Radiant
FTP site. Refer to Using the DelTrack Utility as Part of an Upgrade on page 33 for more information
about how to use Deltrack, and how to obtain more information about the utility. Refer to Additional
Resources for a link to the Radiant FTP site. Until you complete this task, credit card information may be
available in these directories, and vulnerable to unauthorized access. You can easily configure DelTrack to
run automatically in a post End-of-Day (EOD) batch file. Refer to Safeguarding Cardholder Data After
Upgrading on page 33 for more information about clearing historical data from old dated subdirectories.
Remote administration security Ensure remote administration software and related processes are
secure. Limit the number of people permitted to perform these functions. Do not share remote access cre-
dentials, even within your own company; if someone needs access, give them their own, unique authenti-
cation in the system. Disable remote access software, and shut down all sessions, once required tasks arecomplete. Never leave remote access software listening. Shut down all client-side applications after com-
pleting all remote administration tasks.
Default accounts Change default names and passwords to make randomly guessing account names and
passwords difficult. Network user accounts can create vulnerabilities when they are active across the net-
work, and follow a predictable pattern. User accounts that are very similar to each other and use the same
password, such as Term1 through Term8, all with a password of Aloha, make it easy for someone to
guess their way into the network, especially if this pattern is the same across several sites.
Peripheral equipment, such as routers and wireless access points, may also have default user names and
passwords set in their firmware. Remember to replace these with strings unique to your installation.
Storage of complete, unencrypted mag-stripe data Software configured to permit storage of data
read from the magnetic stripe on a credit card is vulnerable to attack. The risk to cardholders and mer-
chants alike increases dramatically, if the data is not encrypted. The recommendations in this document
will help you to verify your Aloha installations are configured to be as secure as possible.
-
8/6/2019 Data Security Handbook 6.4
7/52
POS v6.4 Data Security Handbook Page 7
Defining the PCI DSS Requirements
Insecure system configuration We recommend disabling the Guest account, which is part of most
Windows installations, and modifying security settings to limit access only to the specific users requiring
it. Open directory shares, anonymous and guest account read-write access to directories, and NETBIOS
network communications are among the vulnerabilities that can provide an open door to unauthorized
network and data access.
Lack of a firewall Failing to use a firewall can also leave a network vulnerable. Antivirus and antispy-
ware software can work together with a firewall to significantly enhance the security of a network. It is
also vital to update these security measures on a routine basis.
How Can I Maintain Compliance?
The first, and best step you must take is to install the latest available version of Aloha that has been vali-
dated against the appropriate data security standards. As stated previously, however, security standards
evolve over time. If you have already installed a validated version of Aloha, the security standards by
which that version was validated will eventually become obsolete. Each security standard version has an
expiration date, which determines the expiration date for software validated against it.
Several versions of Aloha have been validated against different versions of security standards, as published
by the Payment Card Industry Security Standards Council (PCI SSC). For this reason, it is extremely
important to upgrade your Aloha installation to the latest version of Aloha validated against the appropriate
security standards, as it becomes available. A current list of validated versions of Aloha, and the standards
against which they have been validated are available from the following link:
https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml
Refer to the table onpage 40, in the Frequently Asked Questions section of this document, for
more information about validated versions of Aloha, and their respective expiration dates.
https://www.pcisecuritystandards.org/security_standards/pa_dss.shtmlhttps://www.pcisecuritystandards.org/security_standards/pa_dss.shtml -
8/6/2019 Data Security Handbook 6.4
8/52
Page 8 POS v6.4 Data Security Handbook
Summarizing the PCI DSS Requirements
The PCI DSS requirements contain detailed information about considerations necessary to establish a
secure set of practices for protecting cardholder data at the restaurant level. The following table is a very
general, high-level adaptation of the PCI DSS requirements, and is intended as a loose guide to the remain-
der of this document.
PCI Data SecurityRequirement
What this requirement means toyou...
How you can meet thisrequirement...
Build and Maintain a Secure Network
1 Install and maintain a
firewall, and configure it
to protect cardholder
data.
Firewall configuration
review is mandatory atintervals of six months or
less.
Establish configuration standards for fire-
walls and routers, that deny access from
untrusted sources, and prevent access to
cardholder data. Configure firewalls to
prevent connections between public serv-
ers and cardholder data, including wire-
less networks.
Install an application layer firewall in front
of Web-facing applications. Periodic vul-
nerability testing is a requirement.
Install routers with built-in
firewall technology. Verify the
Windows firewall is enabled
and configured correctly. All
hardware and application
firewalls, including routers
are subject to this require-
ment.
Install firewall technology to
protect any Web-based ser-
vices, such as remote order-
ing systems.
Set up a process for review-
ing firewall configuration at
least every six months, to
verify configuration remains
unchanged.2 Do not use vendor-sup-
plied defaults for system
passwords and other
security parameters.
Change vendor-supplied default user
names and passwords before connecting
to the network. Encrypt all non-console
administrative access.
Be careful to change any
user names and passwords
already established as part
of software and hardware
you may install. Remote
administration software,
wireless access points, and
routers are prime examples.
Protect Cardholder Data
3 Protect stored card-
holder data.
Keep data storage to a minimum, and do
not store sensitive data after authoriza-
tion. Never store the validation code orPIN, even if encrypted.
Always upgrade to the latest
version of Aloha validated
against the applicable secu-rity standards.
Configure Aloha per this doc-
ument, to minimize data stor-
age, and to encrypt
cardholder data when stored
short-term.
-
8/6/2019 Data Security Handbook 6.4
9/52
POS v6.4 Data Security Handbook Page 9
Defining the PCI DSS Requirements
4 Encrypt transmission of
cardholder data across
open, public networks.
Use strong cryptography and security
protocols to safeguard sensitive data
transmission over public networks.
Ensure all wireless networks are using
the latest technology, complying with
IEEE 802.11i wherever possible. Never
send unencrypted customer data by e-
mail.
Make sure your operating
system, including Internet
Explorer, is up to date.
Eliminate all use of WEP by
dates specified in the master
specification, replacing hard-
ware and software to support
IEEE 802.11i. Constantly test
your network to verify it is
snooper free.
As a best practice, we rec-
ommend immediate upgrade
to the IEEE 802.11i standard.
Maintain a Vulnerability Management Program
5 Use and regularly update
antivirus and antispy-
ware software.
Install a reputable antivirus program that
is also capable of detecting and removing
spyware and adware. Update it immedi-
ately upon installation, and continue to
update it regularly. Daily is not too often.
Configure the antivirus program to run
continuously, and ensure that it is gener-
ating audit logs.
You can use separate antivirus and anti-
spyware programs, if you wish, as long
as both fulfill the requirements.
Install and configure antivirus
and antispyware software,
per recommended parame-
ters, for maximum security.
Update antivirus program
and virus definitions every
day, as a best practice.
6 Develop and maintain
secure systems andapplications.
Obtain and install all operating system
security patches and updates at leastmonthly.
Establish a schedule to
obtain and install operatingsystem updates for the
server and the terminals.
Implement Strong Access Control Measures
7 Restrict access to card-
holder data by business
need-to-know.
Limit access to computers and applica-
tions that may contain cardholder infor-
mation only to those for whom it is
necessary for their job functions. Use
need to know criteria, and exclude all
others.
Use security policies that
prevent unauthorized
access, and provide physi-
cal access to the BOH file
server only to employees
who require it.
8 Assign a unique ID to
each person with com-puter access. Store user
passwords in an
encrypted format.
Install the latest version of Aloha vali-
dated against the applicable data securitystandards, and implement unique IDs
and strong passwords for anyone having
access to Aloha Manager or Aloha EDC.
Implement two-factor authentication
wherever possible, especially for remote
access.
Ensure authorized users
have their own user nameand expiring, complex pass-
word. Require the user name
and password, plus other
authentication method for
remote access.
PCI Data SecurityRequirement
What this requirement means toyou...
How you can meet thisrequirement...
-
8/6/2019 Data Security Handbook 6.4
10/52
Page 10 POS v6.4 Data Security Handbook
9 Restrict physical access
to cardholder data.
Limit access to computers, printers,
administrative terminals, or other devices
that could hold cardholder data, espe-
cially between employees and visitors.
Prevent unauthorized access to printed
customer data records, such as receipts,
and establish procedures, as laid out in
the standards, for disposal.
Install all parts of the Aloha
network except FOH termi-
nals in areas to which only
authorized personnel have
access. Exclude access to
these parts to non-manage-
ment employees, if possible.
Establish offsite storage for
customer related paper doc-
uments, and establish an
acceptable destruction
schedule and procedure. You
must visit the storage facility
at least annually, to monitor
the security of the site.Regularly Monitor and Test Networks
10 Track and monitor all
access to network
resources and card-
holder data.
Use extensive access and activity log-
ging to monitor access to the system, and
activities on the system, including audit
trails for all critical functions. Ensure at
least three months of log activity are
available.
Activate this type of logging
activity, which is built in to the
Aloha system, in Aloha Man-
ager. It is always active in
EDC.
11 Regularly test security
systems and processes.
Perform regular security tests to expose
vulnerabilities in systems and processes.
Establish a schedule of phys-
ically examining and verify-
ing that all security related
settings are set correctly in
the Aloha system, and in anythird-party programs that
could impact security, includ-
ing programs like PCAny-
where.
You must undergo a PCI
security scan by an
Approved Scanning Vendor
(ASV) on a quarterly basis.
Maintain an Information Security Policy
PCI Data SecurityRequirement
What this requirement means toyou...
How you can meet thisrequirement...
-
8/6/2019 Data Security Handbook 6.4
11/52
POS v6.4 Data Security Handbook Page 11
Defining the PCI DSS Requirements
12 Maintain a policy that
addresses information
security for employees
and contractors.
Maintain a security policy that promul-
gates and explains these requirements,
including approvals, authentication pro-
cedures, and more. This requirement
includes maintaining a policy regarding
remote access technologies, wireless
technologies, removable electronic
media, e-mail and Internet usage, remov-
able electronic media, laptops, or per-
sonal digital assistants (PDAs).
Create and maintain a sys-
tem of explaining the security
policy to all employees. In
this system, discuss all
requirements, authentication
procedures, and more.
Do not permit employee or
customer memory cards, lap-
tops, or PDAs in sensitive
areas, and do not permit any
e-mail or Internet access.
Appendices Additional Requirements
A PCI DSS Applicability for
Hosting Providers
Hosting providers protect cardholder data
environment.
Ask your hosting providers
about the measures they
take to protect cardholder
data.
B Compensating Controls Requirement number three, above, may
be difficult for some sites or some tech-
nologies. This Appendix permits alter-
nate, or compensating, controls that
accomplish the same level of safety by
means other than those outlined in the
requirement itself.
Create, configure, and
request approval for any
compensating, or alternate,
methods you need to imple-
ment, to protect cardholder
data. If you can use standard
configuration to accomplish
this protection, do not estab-
lish alternate methods.
PCI Data SecurityRequirement
What this requirement means toyou...
How you can meet thisrequirement...
-
8/6/2019 Data Security Handbook 6.4
12/52
Page 12 POS v6.4 Data Security Handbook
Complying with the PCI DSS Requirements
Making use of the inherent capabilities of the Aloha applications are the primary focus of compliance with
the PCI DSS data security requirements. Radiant Systems, Inc. has enhanced and maintained these applica-
tions to make them more secure, bringing them into compliance with these security requirements, and con-tinues to explore new ways to enhance data security. Merchant certification, however, involves
configuration at corporate and site levels. The majority of this document discusses how to configure the
Aloha system for compliance at the site level.
This section discusses general topics that will help you understand the PCI Data Security Standards, and
how you can begin the task of configuring your Aloha system for data security and site compliance. Seg-
ment topics roughly correspond to the six main PCI DSS topic areas, to help you organize your compliance
strategy.
Building and Maintaining a Secure Network
The Aloha system installs and runs within the environment defined by Windows. The Aloha network also
depends on the networking settings established in Windows. Although a comprehensive discussion of net-
working is beyond the scope of this document, you can perform specific changes that will increase thesecurity of your network, as discussed in this section.
To protect sensitive data from external intrusion, you should design and configure your network to be as
secure as possible. The characteristics of a secure network include, but are not limited to, the following:
Configuring the Windows Network
Install an up to date operating system on all computers in the Aloha network, such as Windows
2000, Windows XP, or Windows 2003.
Establish a network firewall that includes a firewall device, such as a router, between the Aloha
network and the Internet. Install firewall software on each computer in the network, or enable and
configure the Windows firewall. Install an application firewall in front of any Web-facing applications hosted at the site.
Establish a routine to search for and install firmware or software updates to your firewall defenses,
as they become available.
Establish a routine to search for service packs and security patches for the operating systems in use
in your network on a regular basis. Download and install them, as soon as they are available.
Beginning with Aloha EDC versions 6.4 and later, EDC adopted a policy of assured backwards
compatibility with Aloha POS versions 6.1.23 and later, 6.2.16 and later, and 6.4.7 and later.
Generally speaking, you can upgrade to a newer version of EDC to take advantage of new fea-
tures, and to comply with new processor requirements, without having to upgrade the POS. How-
ever, some new features require an upgrade to both the EDC and POS products. Refer to RKS
document 10265 for more information about features requiring dual upgrades. Although you
must upgrade your HASP key to Aloha v6.7 to run Aloha EDC v6.7, this change in license status
does not require you to upgrade the POS to Aloha v6.7.
-
8/6/2019 Data Security Handbook 6.4
13/52
POS v6.4 Data Security Handbook Page 13
Complying with the PCI DSS Requirements
Remember to change any vendor-supplied passwords with your own, using practices outlined in
this document. Search for and change other default security parameters, as well, such as default
port assignments.
Use standard user name and complex password procedures to log in to the Aloha BOH file server.
Do not, under any circumstances, use auto-logon to access this computer. Refer to Managing
Windows Auto-Logon on page 23 for more information about how to disable and remove auto-logon, if you have used it at any time on your Aloha BOH file server.
Disable the Guest account on all computers in the Aloha network.
Install Aloha on all servers and terminals within a folder beneath the drive root, as in C:\Boot-
Drv\Aloha(QS) or D:\POS\Aloha(QS). This strategy imposes a directory above the Aloha(QS)
program directory to serve as the BootDrv shared directory, thus preventing the sharing of the
entire drive. Shared drives are much more vulnerable to external attack, especially the boot, or C:
drive. The former standard of installing Aloha directly under the root, as in C:\Aloha(QS),
resulted in sharing the entire drive, an unacceptable security risk in the environment we face today.
Remove the Everyone group from the share permissions on all shared folders, particularly the
BootDrv share on the Aloha BOH file server, and all FOH terminals. Instead, configure the share
to only allow access to those users that specifically require access, such as the account being usedby FOH terminals for logon, e.g. the AlohaService account, and any users who log on to the
BOH file server to use Aloha Manager and EDC.
Configure the file permissions for the folder shared as BootDrv, on the Aloha BOH server, to per-
mit access only to specific users, controlling this access primarily by user group membership. For
example, add all Aloha-related accounts to a Power Users group, and only grant the Power
Users and Administrators groups access to the files in the BootDrv folder.
Configure the file permissions for the EDCProcPath directory to only allow access to the Alo-
haService account and members of the Administrators group. This configuration prevents unau-
thorized users access to EDC files on the BOH file server. When you use the EDCProcPath
feature, the EDC files are no longer stored under the BootDrv share, so they are not accessible
from the Aloha network. Change user rights for all Aloha services, e.g. EDCSvr, CTLSvr, RFSSvr, to run under a dedicated
network account with Administrative access. This account requires registry access, but normal
BOH users do not.
Require all administrative personnel to log in to Windows using unique accounts with appropriate
security levels. Disable accounts for staff that are no longer employed, to prevent unauthorized
access.
Never give the passwords to the AlohaService or FOH Aloha login to unauthorized staff. Rotate
passwords periodically (every 90 days at most), and use complex passwords.
Configure the local security policy for password policies, to enforce the following:
Configure the local security policy for account lockout policy to lock out accounts for at least 30
minutes after three or more invalid login attempts, to prevent hammering attacks.
History of three or more passwords, to prevent repeats.
Maximum age of 90 days, minimum age of one day for new passwords.
Minimum length of eight characters (slightly more restrictive than the
PCI DSS requirements).
Complexity requirements to prevent easily guessing passwords.
-
8/6/2019 Data Security Handbook 6.4
14/52
Page 14 POS v6.4 Data Security Handbook
Enable audit logging, in Windows, for all Aloha folders, as well as log on and log off attempts, to
provide information about who is logging in to folders and files, and what user names are tried,
successfully and unsuccessfully, to gain access to computers attached to the Aloha network.
If you are using a wireless network, you must configure the network to exclude access to custom-
ers in the restaurant, or in adjacent businesses. If you provide wireless Internet access to customers
in your restaurant, you must configure customer access as entirely separate from the Aloha net-work. You must eliminate all use of WEP as a method of securing your wireless network. You
must purchase hardware and configure it to comply with the new wireless security standard, IEEE
801.11i, to secure your wireless network.
Configure Windows to purge the paging file at shutdown. Although this change may slow the shut-
down procedure slightly, it causes Windows to purge any residual data remaining in the Windows
paging file at the time of shutdown, effectively removing credit card numbers or other customer
data on the rare occasion when Windows writes this type of data to the paging file. Refer to the fol-
lowing Microsoft Knowledge Base documents for more help with this change:
Windows 2000, XP, and 2003 Server, accessing security policy, and slow shutdown resulting
from enabling, Microsoft Knowledge Base article number 320423.
Windows 2003 Server, disabling Stop message at shutdown, Microsoft Knowledge Base arti-cle number 902069.
Windows XP, how to clear the paging file at shutdown, Microsoft Knowledge Base article
number 314834.
Windows 2000, how to clear the paging file at shutdown, Microsoft Knowledge Base article
number 182086.
Disable System Restore on the Aloha BOH file server, and on all terminals, to prevent Windows
from saving sensitive information as part of the routine system-restoration process. In Windows
XP, select Start > Settings > Control Panel > System > System Restore tab. Select the Turn off
System Restore check box to disable this feature.
Disable Remote Desktop on the Aloha BOH file server, and on all terminals, to prevent Windows
from giving access to unauthorized external requests for control. In Windows XP, select Start >
Settings > Control Panel > System > Remote tab. Clear the check box labeled Allow users to con-
nect remotely to this computer. If it is consistent with your support structure, you may also clear
the check box labeled Allow Remote Assistance invitations to be sent from this computer, in this
same location.
Configuring the Aloha Network
Do not, at any time, under any circumstances, open a direct, unprotectedconnection between the
Aloha network and the Internet. Always use up to date antivirus and antispyware programs in con-
junction with a software firewall to keep these communications secure. We also recommend using
a hardware router, if possible.
Create a network user account, such as AlohaService, add this user to the Administrators user
group, and give the user a site-specific complex password.
Use local security policy settings to restrict the ability of the AlohaService user to log on to the
network. Select Start > Settings > Control Panel > Administrative Tools > Local Security Policy,
and select Security Settings > Local Policies > User Rights Assignment. Locate Deny logon
locally in the policy list, and double-click it to add the AlohaService user to the list of denied
users.
-
8/6/2019 Data Security Handbook 6.4
15/52
POS v6.4 Data Security Handbook Page 15
Complying with the PCI DSS Requirements
Register CtlSvr, EDCSvr, RFSSvr, and any other Aloha related services or devices to use a net-
work user account created specifically for this purpose.
Configure the EDCProcPath folder for access only by the AlohaService account or members of the
Administrator group. Exclude all other users from the permissions list on this folder.
Create and maintain an information security policy, and make that policy public in your client res-
taurants.
Configure supported Radiant terminals to use the 'Radiant' selection, in Maintenance > Hardware
> Terminals > Readers tab > Magnetic Stripe Reader section, to prevent Aloha using the Keyboard
Wedge driver for communication with magnetic stripe readers (MSRs). Some malware can make
use of the Keyboard Wedge driver to access track data, as read by the MSR. By selecting 'Radiant,'
the Aloha system terminates use of the Keyboard Wedge Windows service, if it is running, and
communicates directly with the MSR. If a malware program attempts to communicate with the
MSR, it ties up the Aloha system itself, preventing access to the information on the card.
Radiant Systems terminated support for operating systems older than Windows 2000 at the end of Decem-
ber, 2007, because there are no security patches available for them that will make them compliant with the
new requirements. Although it is possible to upgrade the encryption level in these operating systems, theirinherent security features render them unsafe in the current operating environment. For this reason, we
strongly suggest that you upgrade any computer in your network still using any of these operating systems.
At the store level, one of the main security concerns is to keep the BOH file server locked or logged off
when it is not in use, and protect it with a Windows user name and a complex password. If the site also
includes one or more computers separate from the BOH file server for use by managerial staff, ensure that
these computers are also left locked, logged off, or powered off when not in use.
Configuring EDC for Secure Data Storage
Aloha EDC, beginning with v6.1, is capable of storing and accessing data files related to credit card pro-
cessing outside the established Iberdir path, by using a new environment variable, EDCProcPath. Thischange affords more data security and customer protection by moving non-temporary files related to trans-
action authorizations and settlements outside the Bootdrv share currently used by the Aloha system. Data
not stored within the shared file structure is much less likely to be available to anyone entering the system
from an external location. You can configure Windows and the Aloha system together to permit only the
system administrator access to these files.
To move non-temporary EDC files outside the Iberdir file structure:
1. Settle all pending transaction batches, prior to continuing with this procedure.
2. Create a new path for EDC outside the \Bootdrv file structure on the EDC server (typically the
Aloha BOH file server). For example, if the current file structure is C:\Bootdrv\Aloha\EDC, you
could use C:\AlohaEDC\EDC.
3. Log in to Aloha EDC and select File > Stop POS Processing.
Beginning with version 6.4, Aloha EDC is version independent of Aloha Quick Service or Table
Service. EDC v6.4 and later require Aloha v6.1 or later. Although you must upgrade your HASP
key to Aloha v6.4 to run Aloha EDC v6.4, this change in license status does not require you to
upgrade the POS to Aloha v6.4.
-
8/6/2019 Data Security Handbook 6.4
16/52
Page 16 POS v6.4 Data Security Handbook
4. Log out, and close Aloha EDC, and close any remote instances of EDC running on other comput-
ers on the network, such as a manager workstation.
5. Stop the EDCSvr Windows service.
6. Create a new environment variable, EDCProcPath, specifying the new location for the EDC
folder created above.
7. Move the contents of the old EDC folder to the new location, leaving the old EDC folder and theEDC.ini in place.
8. Start the EDCSvr Windows service.
9. Open and log in to Aloha EDC.
10. Select File > Start POS Processing.
When you configure the system in this manner, the system (Aloha FOH, BOH, or Aloha EDC) writes all
authorization request files (.req) to the default EDCPath, and the transaction (.txn) and settlement (.stl)
files to the new EDCProcPath location. The system writes answer (.ans) files to the EDCPath location. The
FOH deletes .ans files from EDCPath after processing the response, so the file remains in the shared path
for only a short time. The system writes .stl and .txn files solely to the EDCProcPath location. EDCSvr
reads the EDC files in the EDCProcPath location, and monitors the current EDCPath location for incoming
.req files.
Implementing 128-bit Encryption in Aloha Installations
Beginning with version 6.0, the Aloha system supports industry-standard 128-bit encryption, at minimum,as implemented in all recent, properly maintained Windows operating systems. The Aloha system checks
for the presence of the required system libraries that provide 128-bit encryption routines. If these system
libraries are not present, any Aloha program component attempting to launch shuts down. This behavior
includes the installation process. If you upgrade Windows 2000, XP, or Windows Server 2003 to include
all available service packs and security patches, and upgrade Windows Explorer to v6.0, this process
upgrades all encryption libraries.
We recommend you use Aloha v6.4, as this version takes advantage of 128-bit encryption, along with AES
256-bit encryption for the brief periods of time when cardholder data may be stored on disk. The Aloha
system encrypts cardholder data, and purges non-essential data, such as track data, after completing the
authorization process.
The Aloha system assumes %Iberdir%\EDC as the default location for the environment variable,
EDCPath. It is not necessary to create this variable, as Aloha assumes this location if you do not.
If you want to use a path different from the default for EDCPath, create the new folder, and create
a new environment variable, EDCPath, to match the new location. The EDCPath foldermustbe
within the \Bootdrv location. This path is in contrast with the EDCProcPath environment vari-
able, discussed above, which you will define in a location outside the \Bootdrv shared folder.
Although support for 128-bit encryption begins with Aloha v6.0, we recommend you always use
the latest version of Aloha validated against the applicable data security standards, and configure
it for maximum security, as discussed in this document.
-
8/6/2019 Data Security Handbook 6.4
17/52
POS v6.4 Data Security Handbook Page 17
Complying with the PCI DSS Requirements
Configuring Aloha for Audit Report Security
The Audit report, in Quick Service and Table Service, can display or mask credit card numbers and expira-
tion dates, beginning with Aloha v6.4. Upon upgrade, the system disables access to credit card numbers
and expiration dates in the Audit report for all employees, to prevent unauthorized access to cardholder
data. We recommend re-enabling this access only in the security level assigned to the most trusted employ-ees, in Maintenance > Labor > Back Office Security Levels. You can find this function by selecting
Reprint > Audits > Display Credit/Debit Card Numbers, in the Functions column. Select the security level
ID to which you want to give permission for this function, and then select Run and Save.
At the next data refresh, employees assigned to this security level can view credit or debit card numbers
and expiration dates in the Audit report. When an employee accesses credit card information in the audit
report, Aloha details this activity in a message inserted in Debout.txt. All other employees with access to
the Audit report see these numbers in masked format.
Also beginning with Aloha v6.4, only employees with pre-existing edit rights in Store Settings can modify
security settings, in the manner described above. Refer to Controlling Access to Aloha Manager and
Aloha EDC on page 24 for more information about access control to the Aloha system.
Protecting Wireless Transmissions
Aloha applications, beginning with version 6.0, make use of at least 128-bit encryption for all forms of
wireless data transfer between handheld devices, FOH terminals, and the BOH file server. As technology
advances, wireless devices will proliferate in the restaurant environment, and the opportunities for data
fraud will increase accordingly. If you must include a wireless network as part of the Aloha network, pur-
chase commercial grade Access Points (AP) that use the IEEE 801.11i security standard, and secure the
network with a password and encryption key. Do not purchase wireless equipment that is only capable of
using the WEP security standard, as this standard is no longer secure in the current wireless environment.
Figure 1 Back Office Security Levels, Audit Report Permission Configuration
-
8/6/2019 Data Security Handbook 6.4
18/52
Page 18 POS v6.4 Data Security Handbook
Allowing an unencrypted wireless network is a critical security violation, surpassed only by placing the
Aloha file server directly on the Internet without a firewall. You must avoid an unencrypted configuration,
as it dramatically increases the possibility of unauthorized file access by intruders. If the restaurant wishes
to provide wireless access to customers, install an isolated wireless access point (AP), configured outside
the Aloha network, thus preventing customers from reaching the Aloha BOH server or the FOH terminals.
As a best practice, you should also use sensing software, such as NetStumbler, to detect other wireless net-works active in your immediate area, and select a relatively unused channel for your own network. Sensing
software will also help you to detect other access points brought in to your restaurant for the purpose of
joining your Aloha network. NetStumbler is only one of several excellent sensing products available.
You can download a trial version of NetStumbler from the following Internet address.
An extensive discussion of wireless network security is beyond the scope of this document. Considerable
information is available from numerous public sources about wireless network security.
Daily Operational Considerations
Networks in constant daily use experience risks inherent to the types of activities involved. One area of
risk that we often overlook has to do with our daily habits. This section discusses some of the things we
can concentrate on, on a daily basis, to enhance the security of our networks.
Facilitating Secure Remote Software Updates
When sites find it necessary to download software updates, a different kind of vulnerability comes intoplay, the external connection itself. If you are using a modem, or if you have broadband Internet access that
is on all the time, these can provide unwanted avenues through which unauthorized access can occur. As a
best practice, we recommend turning the power off to modems or Internet connectivity devices (e.g. DSL
or other Ethernet appliances) when they are not in use, to effectively shut the door on potential external
threats. Only leave the power on to devices you are actively using for credit card authorization and settle-
ment.
Encrypting Sensitive Traffic Over Public Networks
The Aloha system requires 128-bit encryption support in the operating system, beginning with version 6.0.
You cannot install Aloha applications at or later than this version level without installing 128-bit encryp-
tion. If the Aloha installation does not proceed on one or more computers in your network, we recommendyou verify the operating system on those computers is completely up to date.
Systems running Windows 2000, XP, or 2003 Server, with all service packs and updates installed, and run-
ning Microsoft Internet Explorer, version 6.0 or later are, by definition, running an appropriate level of
encryption. Install Internet Explorer, v6.0 on any computers still exhibiting installation problems related to
encryption issues.
http://www.netstumbler.com/
Remember to replace any default passwords or user names installed by the manufacturer of the
wireless access point with your own, before you place it in service. Default user names and pass-
words are readily available on the Internet for all peripherals, when applicable.
http://www.netstumbler.com/http://www.netstumbler.com/ -
8/6/2019 Data Security Handbook 6.4
19/52
POS v6.4 Data Security Handbook Page 19
Complying with the PCI DSS Requirements
Encrypting all Non-Console Administrative Access
We strongly recommend that you do not use Telnet or rlogin for remote administration of Aloha net-
works. Use SSH or SSL/TLS, or other non-console access.
Protecting Cardholder Data
The primary target of thieves is the data stored in the magnetic stripe on the back of most credit cards. As
technology advances, the contents of other storage media embedded in payment cards will become targets,
as well. Technicians and database configuration specialists must take steps to prevent storage of data
extracted from payment cards, even if encrypted, after authorization is complete. Configure the Aloha sys-
tem to prevent storage of this information wherever possible. When you configure the Aloha system as rec-
ommended in this section, the system encrypts and stores track information in the Trans.log file while
authorizations are in progress. After completing card authorizations, Aloha removes track and security
code information from the files in an irrecoverable manner.
Creating Secure Card TendersWhen you create credit card tenders, there are specific options you can use to enhance the security of your
operations, one of which is mandated by U.S. Federal law. In Aloha Manager, select Maintenance > Pay-
ments > Tenders > Type tab to access these options.
Enable Use Magnetic Cards ONLY to prevent manual credit card entry without manager approval.
Although not specifically required for PCI DSS compliance, this setting helps to prevent unauthorized use
of credit card account numbers at the site. To comply with FACTA, clear the Print Expiration option to
prevent printing sensitive cardholder information on the guest check.
Suggested Settings:
Figure 2 Tender Maintenance, Type Tab
-
8/6/2019 Data Security Handbook 6.4
20/52
Page 20 POS v6.4 Data Security Handbook
Use Magnetic Card ONLY: Selected
Print Expiration: Cleared
Print on Check, on the Identification tab: Cleared
Configuring Printer Output for Compliance
To be PCI DSS compliant, a site must not print the entire credit card number. Select Maintenance > Store
Settings > Credit Card group > Voucher Printing 2 tab to configure printer output for compliance. Use the
options on this tab to mask all but the last four digits of the card number, and to suppress the expiration
date of the card from printed vouchers. You can also optionally suppress printing the cardholder name.
Suggested Settings:
Credit Card Number Mask: Only show last 4 digits
Although some state or local laws may require the display of the expiration date, United States
Federal law requires the suppression of this information, nationwide. We strongly recommend
you configure Aloha to suppress the expiration date. For more information on the Fair and Accu-
rate Credit Transactions Act, effective December 4, 2003, please reference the following Web
site:
http://www.treasury.gov/offices/domestic-finance/financial-institution/cip/pdf/fact-act.pdf
Refer to Configuring Printer Output for Compliance on page 20 for more information about
complying with United States Federal law by suppressing the expiration date.
Figure 3 Store Settings, Credit Card Group, Voucher Printing 2 Tab, Configuration
http://www.treasury.gov/offices/domestic-finance/financial-institution/cip/pdf/fact-act.pdfhttp://www.treasury.gov/offices/domestic-finance/financial-institution/cip/pdf/fact-act.pdf -
8/6/2019 Data Security Handbook 6.4
21/52
POS v6.4 Data Security Handbook Page 21
Complying with the PCI DSS Requirements
Suppress Expiration dates: Selected
Suppress Cardholder Name: Optional
Using Aloha Delivery/Frequent Buyer Securely
The latest implementation of the Back Office product, Aloha Delivery/Frequent Buyer (D/FB), version
5.27.6, complies with the latest data security standards, in that it does the following:
Stores credit card information in the customer record in an encrypted format.
Communicates credit card information to the Aloha system in an encrypted format, if the ver-
sion of Aloha accepts this type of data.
Reconciling Versions of D/FB and Aloha
To be PCI DSS compliant, you must upgrade Aloha Delivery/Frequent Buyer to version 5.27.6, and
upgrade Aloha to a version that accepts the encrypted information from D/FB. The appropriate versions of
Aloha are as follows:
Maintaining a Vulnerability Management Program
As we understand all too well, numerous types of threats exist in the environment we face today. We must
exercise great care to address these threats, and maximize the safety of cardholder data, and our business
data. To comply with PCI DSS, you must establish and maintain a program that addresses these threats. In
this area, the primary areas of concern involve viruses, spyware, adware, and other malware.
To address this area of the PCI DSS, you must establish what you intend to do, then execute that plan.Once complete, establish a process of constant maintenance, to ensure your hard work is not undone by
inaction over time. The best practices in this area are as follows:
Federal law (Fair and Accurate Credit Transactions Act of 2003, or FACTA) requires the config-
uration recommended in this section, nationwide, with regard to not printing the expiration date.
If your state or local laws require different settings, we recommend you discuss these matterswith the appropriate authorities for clarification. Suppressing the cardholder name on printed
vouchers is notrequired by Federal law as of the time of publication.
Quick Service and Table Service, v6.0 v6.0.17 and later accept encrypted data.
Quick Service and Table Service, v6.1 v6.1.15 and later accept encrypted data.
Quick Service and Table Service, v6.2 v6.2.8 and later accept encrypted data.
Quick Service and Table Service, v6.4 All versions accept encrypted data.Quick Service and Table Service, all other
versions
Accept only unencrypteddata.
-
8/6/2019 Data Security Handbook 6.4
22/52
Page 22 POS v6.4 Data Security Handbook
Install and implement known, well-respected antivirus software on all server and terminal comput-
ers. Establish a routine to update this software several times each week. Daily is not too often, as
new antivirus updates may become available at any time.
Similarly, install and implement an antispyware program that detects and prevents or removes spy-
ware, adware, and other malware. Establish a routine to search for and install updates for this pro-
gram on a regular basis. We suggest a weekly interval for this type of software, as updates tend tobecome available at irregular intervals, and are less frequent than for antivirus programs.
You may find it helpful to create a checklist that you can mark each time you search for a security update
for your programs. Make sure the checklist is complete, and use it faithfully.
Implementing Strong Access Control Measures
To ensure data security, ensure that employees only have access appropriate to their work requirements.
Access to the FOH is by password, magnetic card, magnetic pen, or fingerprint scanner, and access to the
BOH is by password.
Secure access to Aloha Manager, the Aloha BOH application, and Aloha EDC is available through the use
of passwords. We recommend specific configurations for passwords, to maximize security. This section
details best practices for configuring passwords in the Aloha system.
Securing Off-Site Data Storage
Printed customer receipts is another area of potential data loss. Although a correctly configured Aloha sys-
tem prints no critical information on these receipts, it is still a requirement that you store them in a secure
location, preferably offsite, along with any other critical stored data. It is also a requirement that you visit
offsite storage at least once a year, to verify correct security procedures are in effect. Finally, it is also a
requirement that you establish and monitor data destruction procedures for off-site data storage.
Securing Physical Access On-Site
Restaurants are busy places, and can often be chaotic. In the midst of the constant activity surrounding this
type of business, you must establish access control measures to prevent unauthorized access to cardholder
data through the electronic ports on the Aloha BOH file server. The best method for complying with this
requirement is to install the server in a secure, lockable location. Strong password protection, discussed in
another section, helps complete the security of the file server.
The specific risk, when speaking of the BOH file server, is through use of small, removable data storage
devices. These devices can include, but are not limited to, Personal Digital Assistants (PDAs), laptops,
flash drives, and other removable storage media. It is critical to prevent access to external ports and remov-
able-media drives on the file server.
-
8/6/2019 Data Security Handbook 6.4
23/52
POS v6.4 Data Security Handbook Page 23
Complying with the PCI DSS Requirements
Managing Windows Auto-Logon
It is possible to automate the logon process by enabling auto-logon, but this process stores the user name
and password in the Windows registry in clear text. This practice poses a security risk, and violates the PCI
DSS requirement for implementing strong access control measures.
To assist you in managing the Windows auto-logon feature, Microsoft offers freeware called Autologon
for Windows, which is a part of the Sysinternals Suite. This application, provided as AutoLogon.exe,
displays the following dialog box, after you accept the license agreement:
AutoLogon.exe is a multi-purpose tool that allows you to do one of the following:
Disable the auto-logon feature.
Enable the auto-logon feature, but encrypt and move the password information to a secure loca-
tion.
Use the following guidelines with regard to using the Windows auto-logon feature on an Aloha system:
NEVER configure the Aloha BOH file server to use the Windows auto-logon feature. If the file
server is currently, or has ever been set to use auto-logon, run the AutoLogon.exe freeware on the
BOH file server and follow the prompts to disable the feature immediately.
After running AutoLogon.exe, restart the Aloha BOH file server. Windows should prompt you for
a user name and password, indicating the program ran successfully.
Configuring a Front-of-House (FOH) terminal to use auto-logon is an accepted configuration;
however, it is still necessary to remove the clear text user name and password. You can accomplish
this in the following ways:
1. If you are using Radiant hardware with Radiant Auto Loader (RAL), install RAL version
2.3.1.0 or later. RAL will move the information to a secure area and store it in an encrypted
format.
2. If you are using Radiant hardware without RAL or are not using Radiant hardware, run Auto-
Logon.exe on each terminal to move the information to a secure area and store it in an
encrypted format.
Click http://technet.microsoft.com/en-us/sysinternals/bb963905.aspx to access Microsoft TechNet and
download AutoLogon.exe. This freeware is also available in the Utilities folder on the Aloha FTP site.
Figure 4 Autologon Sysinternals Dialog Box
http://technet.microsoft.com/en-us/sysinternals/bb963905.aspxhttp://technet.microsoft.com/en-us/sysinternals/bb963905.aspx -
8/6/2019 Data Security Handbook 6.4
24/52
Page 24 POS v6.4 Data Security Handbook
Remember, PCI DSS security requirements apply to all system components, not just the Aloha software
and its configuration. It is your responsibility to configure your systems in a secure manner, and ensuring
you are using the above best practices regarding the auto-logon feature is a must.
Controlling Access to Aloha Manager and Aloha EDC
As security requirements intensify with regard to protecting payment card data, Radiant Systems, Inc. is
enhancing security for all Aloha products. Beginning with Aloha v6.4, we disabled the Alt+X method of
accessing Aloha Manager for Quick Service and Table Service, and Aloha EDC. You must access these
applications through the use of a unique user name and complex, expiring password. This makes PCI DSS
compliance easier at the site level, as requirements become ever more restrictive.
Our recommendation is to control access to Aloha Manager and Aloha EDC using Back Office Security
Levels.
Create a new Back Office Security Level, with access to functions, reports, and other activities
appropriate at the site level.
Assign this security level to specific, trusted personnel at the site level, and ensure that these
employees have unique user names and complex, expiring passwords. Employees assigned to this
security level can give permission to other employees to use new features that become available in
Aloha, beginning with v6.4.
For PCI DSS compliance, you must also disable the Alt+X method of accessing Aloha Manager for ver-
sions prior to v6.4. RKS ID 6298 discusses the procedure for disabling this method of access to Aloha for
all versions of Aloha prior to v6.4. Please contact your Radiant representative if you cannot access the
Radiant Knowledge System to obtain this document.
Configuring Passwords in the Aloha System
Security configuration begins with properly configured employee profiles, requiring the behavior that
results in a set of secure employee practices. The first line of defense in this pursuit of security is to config-
ure the system to require employees to use passwords as a minimum standard. Although we recommendusing magnetic cards and fingerprint scanners for access to the Aloha FOH, you can elect to rely on pass-
words.
For more information on configuring the Aloha FOH terminals to be PCI Compliant, refer to
Using RAL to Configure FOH Terminals to be PCI Compliant.
Aloha Command Center is an excellent alternative to using Alt+X. Employing multi-factored
credentials along with enhanced logging, you can once again launch Aloha Manager and obtain
the same level of access the Alt+X functionality provided.
-
8/6/2019 Data Security Handbook 6.4
25/52
POS v6.4 Data Security Handbook Page 25
Complying with the PCI DSS Requirements
Configuring FOH Passwords
There are two passwords in the Aloha system, Front-of-House (FOH) and Back-of-House (BOH). Pass-
words used at the FOH are numeric, usually being the employee ID number until the employee changes it,
or until the system requires a change. To configure password usage as mandatory for the FOH, select
Maintenance > Store Settings > Security Group > POS Password Settings tab.
Suggested Settings:
Min Password Digits: 3 Max Password Digits: 15
Number Employee: 3 or 4
Password: Required
Figure 5 Store Settings, Security Group, Password Configuration
As with any computer system, we recommend you specifically discourage all employees at all
levels from writing their passwords, and leaving them laying around or sharing them with others.
-
8/6/2019 Data Security Handbook 6.4
26/52
Page 26 POS v6.4 Data Security Handbook
Requiring Expiration of FOH Passwords
After establishing the requirement for a password in the FOH, you must also establish a time interval for
the expiration of passwords. Select Maintenance > Labor > Job Codes, and set passwords to expire at rea-
sonable intervals, e.g. 30 or 45 days. You must complete this configuration for every job code.
Suggested Settings:
Uses Password: Selected
Password Expires: Selected
Renew after: 30 to 45 Days
Creating Complex Passwords for BOH Access
Security at the BOH file server is governed exclusively by password control. For this reason, to comply
with the requirement to implement strong access control, we strongly recommend that BOH passwordsconform to the concept of a complex password.
Figure 6 Job Codes, Password Configuration
You can configure the system to make passwords mandatory, and still use magnetic cards or fin-
gerprint scanners at the FOH. If you configure passwords to expire after a specific time interval,
magnetic cards, and fingerprint images do not expire after the same time interval.
-
8/6/2019 Data Security Handbook 6.4
27/52
POS v6.4 Data Security Handbook Page 27
Complying with the PCI DSS Requirements
This type of password contains upper and lower case letters, numbers, and special characters, for example
&$*@%#. One example of this type of password could be a string like AgrB4&45%. The complex pass-
word is more resistant to external attack, and is nearly impossible for others to guess, especially if the let-
ters do not spell a dictionary word.
Using Alternative Security Devices Instead of Passwords
You can increase security considerably for accessing the FOH terminals by requiring employees to use
magnetic stripe cards, or fingerprint scanners. Select Maintenance > Labor > Employees > Employee tab,
and make these selections in the lower right portion of the screen.
You can use magnetic stripe cards and fingerprint scanners at the same time, depending upon your business
needs, and installed equipment. These two security devices are not mutually exclusive, but if you configure
the system as shown in Figure 7, employees must clock in and log in to the FOH using the fingerprint scan-
ner.
Refer to the Quick Service or Table Service Reference Guide for more information about config-
uring passwords in the Aloha system.
Figure 7 Employee Maintenance, Employee Tab, Security Configuration
Refer to the Aloha Fingerprint Scanner Feature Focus Guide for more information about how toconfigure employee records for use with fingerprint scanners.
Refer to the Quick Service or Table Service Reference Guides for more information about how to
configure terminals using magnetic card readers or fingerprint scanners.
-
8/6/2019 Data Security Handbook 6.4
28/52
Page 28 POS v6.4 Data Security Handbook
Suggested Settings:
Must Use Mag Cards: Selected (if hardware is installed)
Must use Fingerprint Scanner Clock In: Selected (if hardware is installed)
Must use Fingerprint Scanner Log In/JIT: Selected (if hardware is installed)
Logging EDC Program Activity
The secure operation of EDC is of vital importance. For this reason, EDC records all program activities,
including employee log-in, date, time, terminal number (if applicable), program actions, and log-out. It is
not possible to modify or disable this logging function. EDCSvr captures this information and stores it in
the EDC debout file. As a related function, Aloha also logs a message to Debout.txt, detailing employeeaccess to the Audit report, when the employee elects to view credit card account numbers.
Another component to logging EDC activity relates to troubleshooting EDC when problems occur. When
configured to do so, EDCSvr captures even more detailed information in the EDC Debout file. To prevent
storing this type of information, select Maintenance > Store Settings > System Group > Troubleshooting
tab, and clear these settings.
As a best practice, we recommend that you notenable any debugging functions unless you are actively
troubleshooting problems, and that you disable these functions as soon as possible.
Note: For Aloha versions earlier than v6.4, locate these options on the Aloha Settings tab.
All mention of fingerprint scanners in the previous section is intended to refer to hardware sup-
plied by Radiant Systems, Inc., as part of Radiant terminals, or provided as separate devices.
Hardware not provided by Radiant does not work with the settings in the Aloha system, or with
the underlying software environment.
Figure 8 Store Settings, System Group, Troubleshooting Tab
-
8/6/2019 Data Security Handbook 6.4
29/52
POS v6.4 Data Security Handbook Page 29
Complying with the PCI DSS Requirements
Suggested Settings:
Debug Touch: Cleared
Debug EDC Service: Cleared
Creating Back Office Security Levels in Aloha
In your installation, you probably have one or more back office security levels available for assigning to
employees. We recommend you examine each of the existing security levels, to verify that all access is
granted on a need-only basis. As you create new security levels, we recommend you do not start with an
existing level, as this process can result in accidentally granting access to privileged information, or con-
figuration features. Start with a new security level without access to anything in the program. Grant access
only to features and information as required for that user class.
Ensuring Secure Remote Application Access
As a best practice, we recommend you use Radiant Systems Command Center for remote site administra-
tion. This application enables you to check system status, copy files to or from a site, and much more, in
accordance with your administrative needs. The capabilities of Radiant Systems Command Center are spe-
cifically tailored to the Aloha environment, and it uses excellent security, requiring two-factor authentica-
tion for access. Contact your Radiant Systems representative for more information about Command
Center.
If remote access to the Aloha network is necessary, and you are not using Radiant Systems Command Cen-
ter, you must require a two-factor authentication mechanism, such as RADIUS, TACACS with tokens, orVPN with individual certificates.
Remote access applications, such as pcAnywhere, are of special concern, in that they inject another layer
of vulnerability into the security equation. If you are using a program like this, you must take extra precau-
tions to ensure the integrity of the network. In this scenario, there are two opportunities for security
breaches, requiring specific actions in each case:
You must configure the host program to use a non-standard user name and password for each site,
and you must configure the host program to embed the user name and password, to obscure them
from personnel using the host program.
You must configure the client, or site, programs to permit connections only from the host program.
You must also configure the client program to embed, or obscure, the user name employed in thehost program, for logging in to the client.
You must disable all remote access applications when not in use.
Refer to the Command Center Quick Reference Guide for information about how to obtain,
install, configure, and use Radiant Systems Command Center.
-
8/6/2019 Data Security Handbook 6.4
30/52
Page 30 POS v6.4 Data Security Handbook
Excluding Cardholder Data from Online Servers
Any computer connected to the Internet is, by definition, vulnerable to external attack to some degree.
Firewall devices, firewall software, and antivirus software can provide a high degree of safety, to help
reduce the threat. We also recommend using antispyware/malware software, available at no charge directly
from Microsoft, to add an extra dimension of protection.
None of these security measures, however, is capable of rendering a computer completely safe from attack.
For this reason, you must not store cardholder information on a server connected directly to the Internet.
As a best practice, we recommend upgrading to the latest version of Aloha available validated against
applicable data security standards, and use the DelTrack utility to clear this type of information from the
Aloha BOH file server. If possible, use a separate computer for obtaining updates for operating systems,
security software, and firmware for hardware devices, to limit the amount of time the Aloha BOH file
server is connected to the Internet for purposes other than authorization and settlement.
Monitoring and Testing Networks Regularly
After configuring your networks and software systems for maximum security, you must establish a pro-
gram to regularly test and verify the configuration is still secure. This section contains some suggestions in
this area.
Testing Applications for Vulnerabilities
Rigorous testing during development ensures the integrity of security features in Aloha applications. We
strongly recommend that you upgrade to the latest version of Aloha, as it becomes available, as each itera-
tion incorporates newer, stronger security features. We also recommend you periodically verify your con-
figuration is still consistent with the latest security recommendations. Contact your representative at
Radiant Systems at least once every year, and inquire about security requirement changes, and changes in
the Aloha system to meet these changes. With each annual review, a new version of Aloha POS will be val-idated, and it will become the recommended version for data security compliance.
Maintaining an Information Security Policy
After completing all necessary installation and configuration requirements, your data security efforts are
nearly complete. The next step in the PCI DSS (Section 12), is to formalize your data security program into
a policy that you publish to your employees. You must state the specific goals of your data security policy,
including all of the steps you expect to take, on an annual basis, to verify that your site is still secure. Spec-
ify the area of responsibility each type of employee has in your data security program, and implement a
formal security awareness program to emphasize and enforce these responsibilities.
You must also implement an incident response plan, in the event of a system breach. Specify response pro-
cedures, business continuity processes, and data backup strategies and processes. Make specific lists of
people and authorities to contact, both within the company and outside the company, to include law
enforcement and transaction processors. You are required to provide training to employees on the proper
procedures to follow, in the event of a system breach.
-
8/6/2019 Data Security Handbook 6.4
31/52
POS v6.4 Data Security Handbook Page 31
Complying with the PCI DSS Requirements
To summarize these requirements in a more common-sense way, you must make a list of what you need to
do, on an annual basis, to make sure all of your hard work is still effectively protecting your site from data
security breaches. You must make a list of who to call and what to tell them, in case there is a security
breach. You must be careful about who you hire, performing background checks on new employees when-
ever possible, and you must make sure employees only have access to the parts of the system necessary for
them to perform their job functions. You must publish your security plan to your employees, and providethem with training about what to do to avoid security breaches, and what to do if one occurs, including
areas and degrees of responsibility.
-
8/6/2019 Data Security Handbook 6.4
32/52
Page 32 POS v6.4 Data Security Handbook
Upgrading Client Accounts
It is of considerable importance for everyone involved that clients upgrade their Aloha software to the lat-
est version of Aloha available. Although version 5.3.15 was the first version of Aloha validated as CISP,
and therefore PABP, compliant, the requirements for validation continue to change, and Aloha softwarecontinues to evolve, to meet new requirements as they emerge. Aloha version 6.4 is now the latest version
validated as complying with the latest applicable data security standards.
As technology advances, Radiant Systems continue to focus and build upon the security aspects of our
products to introduce increasingly more secure features, while retaining previous levels of security. As the
result of this process, we recommend that anyone accepting credit card payments upgrade to Aloha version
6.4, for the following reasons:
This version uses AES 256-bit encryption for sensitive data both within the Aloha system and for
data transmission over public networks for authorizations and approvals.
This version gives you a new method of using EDC that considerably enhances the security of
cardholder data. Beginning with v6.1, EDC supports a new environment variable, EDCProcPath,which moves all sensitive EDC files outside the shared Bootdrv folder. Refer to Protecting Stored
Data on page 14 for more information about how to safeguard these files.
This version provides enhanced security in various areas, as compared to previous versions, and
closes unpublished access methods to the system, under normal, operational conditions.
Upgrading clients to the latest version of Aloha, however, is not sufficient, by itself. You must periodically
verify the configuration of the program is correct, site by site, to maximize the ability of each customer to
pass site certification requirements. Local configuration changes can inadvertently circumvent security
requirements. You can minimize or eliminate changes of this sort by careful configuration of your Win-
dows environment, and by using Back Office Security Levels, in Aloha Manager, to limit employee access
to specific features, with specific permission levels for specific functions.
The Aloha system often exists in an environment shared with other programs that can also impact security
at the most basic levels, such as pcAnywhere. You must also verify, site by site, that these programs,
although not directly related to the Aloha system, are configured for maximum security.
Working with Backup Files
It is common practice, when upgrading from one version of Aloha to another, to create backups of the
Aloha directory, often including copies of the dated subdirectories, prior to the actual upgrade. These
backup files can contain cardholder data. The real problem with these files is that they are outside the envi-
ronment of the Aloha system, so the usual mechanisms that function to remove cardholder data do not
work for them. These backup files are thus vulnerable to any unauthorized entry into the computer contain-ing them. We strongly recommend exercising extreme diligence in removing any backup files you create,
after you no longer need them.
-
8/6/2019 Data Security Handbook 6.4
33/52
POS v6.4 Data Security Handbook Page 33
Safeguarding Cardholder Data After Upgrading
Safeguarding Cardholder Data After Upgrading
Prior to upgrading to Aloha v6.0 or beyond, we strongly recommend that you settle all pending EDC
batches, and complete an EOD process. If you experience any difficulties during this process, we recom-
mend, for simplicity and data integrity, that you resolve these issues prior to the upgrade.
Although you may upgrade to a validated version of Aloha, cardholder information, including credit card
numbers, may still be available in plain text in the dated subdirectories, or in files retained in directories
related to EDC or processors. You must remove this information, as part of your responsibility for comply-
ing with data security requirements. You can use the DelTrack utility to clear this information. Two ver-
sions of this utility are available, depending on the version of Aloha used to create dated subdirectories.
You can obtain this utility from the Radiant Systems FTP site, along with the document that details how to
use it.
Using the DelTrack Utility as Part of an Upgrade
If you have already been using Aloha for some time, you must use the DelTrack utility as part of yourupgrade process. This utility clears sensitive cardholder data from your dated subdirectories, thus reducing
the risk of a data compromise. The process, however, is different, depending on whether you have dated
subdirectories created with Aloha 5.2.8 or earlier, or if your dated subdirectories are from a newer version.
The data is stored differently, depending on the version of Aloha used.
The documents describing the two versions of the DelTrack utility provide much more information about
how to use them, when conducting an upgrade, but a summary of this process is as follows:
1. Ensure that all transactions are complete, that all EDC batches are settled, and that EOD has run
successfully.
2. Run DelTrack v1.0.2 to remove all track data from the dated subdirectories created by the older
version of Aloha. (Skip this step, if all of your subdirectories have been created with Aloha v5.3.1or later.)
3. Upgrade Aloha to v5.3.1 or later. As a best practice, we recommend upgrading to the latest version
of Aloha available that has been validated against the data security standards.
4. Regrind all dated subdirectories, if you are upgrading from Aloha v5.2.8 or earlier. This process
upgrades them to the new version of Aloha.
5. Run DelTrack v6.4.1 against all dated subdirectories that are older than any exclusion period you
may establish for the new DelTrack, e.g. 30 days. You may need to force DelTrack to run, ignor-
ing the old DelTrack marker files.
6. Configure WinHook to run DelTrack as a routine part of EOD, to ensure you are continually
removing sensitive data from these files on a regular schedule. You can configure DelTrack to omit
dated subdirectories already cleared, and only clear data that is older than the exclusion period.
Refer to the Aloha Manager Utilities Guide for more information about how to configure and run
the Regrind Subdirectories utility.
-
8/6/2019 Data Security Handbook 6.4
34/52
Page 34 POS v6.4 Data Security Handbook
After successfully upgrading Aloha, the following steps are also regarded as a best practice:
Verify that you continually, and permanently delete all dated subdirectories and settlement files
created beyond your data retention policy date.
Manually open the Trans.log files in the dated subdirectories, and search for card numbers to ver-
ify DelTrack has removed this information. This operation is especially important for subdirecto-
ries created by older versions of Aloha.
Manually open the .stl files and search for credit card account numbers to verify DelTrack has
removed this information.
Although the Payment Card Industry Security Standards Council and Radiant Systems recom-mend retaining dated subdirectories no longer than 90 days, you must establish a data retention
policy consistent with your business needs. Your responsibility for deleting cardholder data
extends to any and all data you may retain, regardless of its nature or location.
-
8/6/2019 Data Security Handbook 6.4
35/52
POS v6.4 Data Security Handbook Page 35
Frequently Asked Questions
Frequently Asked Questions
Questions we frequently