Professional Documents
Culture Documents
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.
POS v6.4 Data
Security Handbook
Last Modified: 1/18/2010
Table of Contents
Defining the PCI DSS Requirements................................................................................... 5
What Are the PCI DSS Requirements, and Why Should I Care? ........................................ 5
What are ‘Best Practices?’................................................................................................... 5
Summarizing the PCI DSS Requirements ........................................................................... 8
Complying with the PCI DSS Requirements .................................................................... 12
Building and Maintaining a Secure Network ...................................................................... 12
Protecting Cardholder Data ............................................................................................... 19
Maintaining a Vulnerability Management Program ............................................................ 21
Implementing Strong Access Control Measures................................................................ 22
Monitoring and Testing Networks Regularly ..................................................................... 30
Maintaining an Information Security Policy ........................................................................ 30
Upgrading Client Accounts................................................................................................ 32
Working with Backup Files................................................................................................. 32
Safeguarding Cardholder Data After Upgrading.............................................................. 33
Frequently Asked Questions ............................................................................................. 35
General PCI DSS Information............................................................................................ 35
Aloha POS and PCI DSS Information................................................................................ 39
Additional Resources ......................................................................................................... 42
Appendix A: PCI DSS Configuration and Site Compliance CheckLists ....................... 44
PCI DSS Configuration Checklist....................................................................................... 44
Site Checklist for PCI DSS and FACTA Compliance......................................................... 47
Appendix B: Aloha Cryptography ..................................................................................... 48
Appendix C: EDC Data Flow .............................................................................................. 49
Feature History ................................................................................................................... 50
Page 3
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 SSC’s 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 SSC’s 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.
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.
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
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 dated
subdirectories 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 are
complete. 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.
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.
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 on page 40, in the Frequently Asked Questions section of this document, for
more information about validated versions of Aloha, and their respective expiration dates.
PCI Data Security What this requirement means to How you can meet this
Requirement you... requirement...
Build and Maintain a Secure Network
1 Install and maintain a Establish configuration standards for fire- Install routers with built-in
firewall, and configure it walls and routers, that deny access from firewall technology. Verify the
to protect cardholder untrusted sources, and prevent access to Windows firewall is enabled
data. cardholder data. Configure firewalls to and configured correctly. All
prevent connections between public serv- hardware and application
ers and cardholder data, including wire- firewalls, including routers
Firewall configuration
less networks. are subject to this require-
review is mandatory at
ment.
intervals of six months or
less.
Install firewall technology to
protect any Web-based ser-
Install an application layer firewall in front
vices, such as remote order-
of Web-facing applications. Periodic vul-
ing systems.
nerability testing is a requirement.
PCI Data Security What this requirement means to How you can meet this
Requirement you... requirement...
4 Encrypt transmission of Use strong cryptography and security Make sure your operating
cardholder data across protocols to safeguard sensitive data system, including Internet
open, public networks. transmission over public networks. Explorer, is up to date.
Eliminate all use of WEP by
Ensure all wireless networks are using dates specified in the master
the latest technology, complying with specification, replacing hard-
IEEE 802.11i wherever possible. Never ware and software to support
send unencrypted customer data by e- IEEE 802.11i. Constantly test
mail. your network to verify it is
‘snooper’ free.
PCI Data Security What this requirement means to How you can meet this
Requirement you... requirement...
12 Maintain a policy that Maintain a security policy that promul- Create and maintain a sys-
addresses information gates and explains these requirements, tem of explaining the security
security for employees including approvals, authentication pro- policy to all employees. In
and contractors. cedures, and more. This requirement this system, discuss all
includes maintaining a policy regarding requirements, authentication
remote access technologies, wireless procedures, and more.
technologies, removable electronic
media, e-mail and Internet usage, remov- Do not permit employee or
able electronic media, laptops, or per- customer memory cards, lap-
sonal digital assistants (PDAs). 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 protect cardholder data Ask your hosting providers
Hosting Providers environment. about the measures they
take to protect cardholder
data.
B Compensating Controls Requirement number three, above, may Create, configure, and
be difficult for some sites or some tech- request approval for any
nologies. This Appendix permits alter- compensating, or alternate,
nate, or compensating, controls that methods you need to imple-
accomplish the same level of safety by ment, to protect cardholder
means other than those outlined in the data. If you can use standard
requirement itself. configuration to accomplish
this protection, do not estab-
lish alternate methods.
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.
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.
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:
• 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 used
by 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:
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.
• 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.
• 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, their
inherent 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.
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.
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.
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.
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 folder must be
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.
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.
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.
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.
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.
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.
When sites find it necessary to download software updates, a different kind of vulnerability comes into
play, 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.
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 recommend
you 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.
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.
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:
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
Suggested Settings:
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 matters
with the appropriate authorities for clarification. Suppressing the cardholder name on printed
vouchers is not required 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 Accept only unencrypted data.
versions
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:
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.
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.
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.
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:
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.
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.”
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.
Suggested Settings:
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.
Suggested Settings:
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.
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.
Refer to the Quick Service or Table Service Reference Guide for more information about config-
uring passwords in the Aloha system.
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 Aloha Fingerprint Scanner Feature Focus Guide for more information about how to
configure 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.
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.
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 not enable 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.
Suggested Settings:
Refer to the ‘Command Center Quick Reference Guide’ for information about how to obtain,
install, configure, and use Radiant Systems 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, or
VPN 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 the
host program, for logging in to the client.
• You must disable all remote access applications when not in use.
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.
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.
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 provide
them with training about what to do to avoid security breaches, and what to do if one occurs, including
areas and degrees of responsibility.
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.
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.
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.1
or 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.
Refer to the Aloha Manager Utilities Guide for more information about how to configure and run
the Regrind Subdirectories utility.
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.
• Verify that you continually, and permanently delete all dated subdirectories and settlement files
created beyond your data retention policy date.
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.
• 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.
A. The Payment Card Industry Data Security Standard (PCI DSS) is the result of collaboration between the
various Credit Card Associations and the federal government to create common industry security require-
ments. It consolidates and supersedes the requirements of the previously developed MasterCard Site Data
Protection (SDP) Program and the Visa Cardholder Information Security Program (CISP).
You can obtain a copy of the PCI Data Security Standards document at the following location:
https://www.pcisecuritystandards.org/security_standards/pci_dss_download_agreement.html
As such, the new standard contains IT security requirements and guidelines for all major credit card issu-
ers, including Visa, MasterCard, American Express, JCB, and Discover. These card issuers joined forces to
develop the new requirements as part of an industry-wide standard for protection of cardholders’ credit
card account and transaction information, and to make the use of credit or debit cards a safer process for
cardholders and merchants alike.
Each credit card issuer will continue to maintain their own program identity name for internal purposes
within their operating rules and regulations, such as VISA CISP, MasterCard SDP, etc. However, you can
now refer to all of these programs by referring to ‘the Payment Card Industry Data Security Standards,’ or
simply ‘PCI DSS.’
A. The PCI DSS Standards help merchants and service providers protect their information assets. Mer-
chants also benefit from:
• Consumer Confidence — Consumers want security and assurance that their financial information
and identity is safe.
Q. What about Visa CISP, MasterCard SDP, American Express DSOP and Discover DISC?
A. All major credit card issuers have agreed upon the PCI Data Security Standard to protect cardholder
information and transactions. CISP, SDP, DSOP, and DISC are simply the names of the credit card compa-
nies’ internal programs that ensure compliance with PCI DSS standards. If you meet PCI DSS standards,
you will meet the standards of the individual credit card issuers, except as they adopt more stringent
requirements. This document focuses on the PCI DSS requirements, as the card issuing companies are
deferring to these standards.
A. This program is required of all entities storing, processing or transmitting any credit or debit card holder
data. It ensures that all merchants and service providers are required to safeguard sensitive data.
• Merchants — Retailers, or other entities (pursuant to a Merchant Agreement), that agree to accept
credit cards, debit cards, or both, when properly presented.
• Service Providers — Organizations that process, store, or transmit cardholder data on behalf of
acquirers, members, merchants, or other service providers. Examples are RBS Lynk, Shift Four,
and PayPal.
If you accept payment cards, credit or debit, in your establishment, PCI DSS applies to you.
A. Use the following table to determine the level applicable to your business:
Q. What are the PCI DSS Compliance Validation Requirements, based on Merchant Level?
A. Review the validation requirements in the table below, and check with your acquiring bank for addi-
tional requirements beyond those of the various credit card brands:
* Level 4 merchants must comply with PCI DSS; however, the acquirer determines the nature of compli-
ance validation for merchants in this category. The acquirer is the bankcard association member that ini-
tiates and maintains relationships with merchants that accept Visa or MasterCard cards.
A. A complete summary of the 12 basic PCI Data Security Standards is available in “Summarizing the PCI
DSS Requirements” on page 8. You can obtain a full copy of the requirements from the Payment Card
Industry Security Standards Council Web site, as noted on page 5.
Install and maintain a firewall, to prevent external computers from accessing cardholder informa-
tion. Limit traffic from un-trusted networks to web protocols, system administration protocols, and
other protocols required for business. You should disable all other traffic in your router configura-
tion.
Also implement Internet Protocol (IP) masquerading in order to prevent internal addresses from
being translated and revealed on the internet.
Mask the credit card information printed on customer receipts and credit card vouchers.
Upgrade Aloha POS to the latest version available. In versions 6.0 and later, Aloha encrypts the
credit card track information, from the time the system reads the credit card to the time the system
receives authorization from the credit card processor. The system deletes the track information fol-
lowing the authorization.
Verify that all additional installed Aloha modules are at the latest versions available, and that they
are configured for maximum security. Examples may include, but are not limited to, Aloha Deliv-
ery/Frequent Buyer, Aloha Accounts Receivable, and eFrequency.
Radiant Systems recommends that you install an antivirus application on all computers on the POS
network. Update virus definitions on a frequent, and regular basis. Update security patches for all
installed software within one month of release.
All logins to the computer should be unique to the individual user. This includes the Windows log-
ins, Aloha logins and pcAnywhere logins. Train users to log out of Windows and Aloha when not
using the computer. In addition, configure the Windows screen-saver to automatically lock the
computer after a period of inactivity, in case the user fails to log out. Disable any default users,
passwords, and automatic logins provided by hardware and software vendors.
Assign a unique BOH login for each Aloha user. This enables you to track each user’s activity. You
should delete any default users and passwords provided from Aloha by Radiant Systems. Restrict
access to view or delete the audit logs, including the Debugging-Output-Files (debouts) created by
the Aloha application software.
If you use pcAnywhere for Remote Administration, ensure that the sessions are secured. While
pcAnywhere has its own built-in security features, you should use the Operating System’s security
measures for the highest level of security. Symantec provides details on how to secure the system
on their Web site in Chapter 7 of the ‘Symantec’s pcAnywhere Administrator’s Guide.’ Please
review the guide and implement pcAnywhere security at your sites:
ftp://ftp.symantec.com/public/english_us_canada/products/pcanywhere/pcanywhere32/ver10.5/
manuals/pca_105_admin.pdf
Use the Windows Local Security Policy and various Windows audit logs to enhance auditing capa-
bility on the system. In addition, implement hardware, such as routers, to increase your ability to
track usage.
Document security polices for access control, application and systems development, and opera-
tional and network securities. Develop a response plan for security incidents. Communicate to all
system users and maintain signed acknowledgements of the program.
A. Version 5.3.15 was validated as complying with CISP requirements, as they existed in early 2005. Since
that time, the PCI DSS requirements have evolved, and have been clarified. Aloha version 6.4 is now the
latest version validated to comply with the stated requirements. As always, we recommend upgrading to
the latest version of Aloha validated as complying with the latest published security specifications, as soon
as that version becomes available.
A. Aloha POS by Radiant Systems is a ‘payment application.’ Best practices and security standards have
been developed to address security and the risks associated with payment applications. The goal of the
Payment Application Best Practices (PABP) and the later Payment Application Data Security Standards
(PA DSS) is to create secure payment applications. Applications qualify as secure, if they support a mer-
chant’s ability to comply with requirements. Radiant Systems has modified Aloha POS to achieve the doc-
umented best practices:
In addition to the above, more specific requirements are applicable to payment card application manufac-
turers, as summarized in the Payment Application Best Practices (PABP), and the Payment Application
Data Security Standards (PA DSS), available from the following sources:
PABP http://www.visa.com/pabp
PA DSS https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml
A. Yes. Aloha was the first restaurant Point-of-Sale software to receive validation from Visa.
Refer to the following table for detailed information about validated versions of Aloha, and the require-
ments against which they were validated. The table also provides information about the current status of
each validated version.
Refer to the PCI PA-DSS FAQ on the following Web site for answers to frequently asked questions regard-
ing the plans for grandfathering PABP-validated payment applications:
https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml
As PCI Security Standards continue to evolve, Radiant Systems is committed to continuously increasing
security to protect cardholders and merchants. We strongly encourage clients to adopt the most recent mar-
ket ready Aloha release to stay current with security-related enhancements.
Q. What version of Aloha POS has been validated stating it meets the standard requirements for a
Payment Application?
A. Version 6.4 has been validated as complying with the PCI DSS requirements, and is pending for inclu-
sion on the list of Payment Card Industry Security Standards Council validated solutions. Although Aloha
versions 5.3.15 and later contain many features that address PA DSS requirements, version 6.4 meets the
set of requirements in effect as of the time of its validation (January, 2009).
https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml
Q. What enhancements to Aloha POS have been implemented to meet PA DSS requirements?
A. Radiant Systems will continue to enhance the Aloha software with each release to continue to
strengthen security. The following list includes a few of the security enhancements recently added to Aloha
Quick Service and Table Service:
Radiant Systems will continue to review requirements for Payment Applications to meet industry best
practices.
A. Aloha POS used 64-bit encryption in all versions prior to version 6.0. Beginning with version 6.0, the
encryption level increased to 128-bit, using industry-standard technology. Aloha v6.4 retains 128-bit
encryption for employee passwords, but uses AES 256-bit encryption for payment card transactions.
A. Versions previously validated can remain on the list of validated POS applications, if they remain
unchanged, and if Radiant Systems submits a letter to this effect annually, signed by an Officer. New ver-
sions must be independently validated, prior to being listed as ‘validated.’
A. Please contact your Radiant Systems representative for assistance in upgrading your current version of
Aloha.
A. In addition to upgrading to a compliant version of Aloha POS (v6.1 and later), credit card track infor-
mation must be removed from all dated subdirectories created prior to the upgrade. Use the DelTrack.exe
utility provided by Radiant Systems to remove all track information, or other cardholder information from
both the EDC settlement files and the Trans.log. This utility removes track data, and masks credit card
numbers, expiration dates, and security codes.
A. While upgrading Aloha assists you with some of the security standards directly related to the payment
application, it is the responsibility of the individual merchant to ensure that all PCI DSS standards are met.
Remember, PCI DSS security requirements apply to all ‘system components,’ defined as every network
component, server, or application included in the cardholder data environment. This can include, but is not
limited to, firewalls, switches, routers, wireless access points, network appliances, and other security
related appliances and applications.
A. Radiant Systems recommends that all merchants complete a self-assessment and take action on any
items marked with ‘No.’ When a merchant resolves all identified risks, they should qualify as compliant.
https://www.pcisecuritystandards.org/pdfs/saq/index.shtml
As always, if you need more assistance with any of these items or more information, please contact your
Radiant representative.
Additional Resources
For more information regarding PCI DSS requirements, please visit the following links:
https://www.pcisecuritystandards.org/security_standards/pci_dss_download_agreement.html
https://www.pcisecuritystandards.org/security_standards/pci_dss_download_agreement.html
http://usa.visa.com/merchants/risk_management/cisp_service_providers.html
http://usa.visa.com/merchants/risk_management/cisp_payment_applications.html
ftp://ftp.symantec.com/public/english_us_canada/products/pcanywhere/pcanywhere32/ver10.5/
manuals/pca_105_admin.pdf
• DelTrack.exe Utility:
ftp://ftp.radiantsystems.com/downloads/utilities
You must have a valid user name and password to access the Radiant Systems FTP site.
• Visa CISP
http://www.visa.com/cisp/
• MasterCard SDP
https://sdp.mastercardintl.com/
https://www209.americanexpress.com/merchant/singlevoice/dsw/FrontServ-
let?request_type=dsw&pg_nm=home&ln=en&frm=US
• Discover DISC
http://www.discovernetwork.com/resources/data/data_security.html
The Site Checklist for PCI DSS and FACTA Compliance is designed as a separately printable ‘leave-
behind’ checklist to help a site administrator perform a quick evaluation as to the compliance status, or
lack thereof, of a specific site.
System Configuration:
Begin configuring your Aloha installation for PCI DSS compliance at the most basic level, initial installa-
tion.
Install the latest version of Aloha validated against the applicable data security standards. Contact a
member of the Radiant team to identify the latest validated version of Aloha.
Obtain and run the DelTrack utility, to remove any residual customer data remaining in your installa-
tion, page 33, after upgrading to a PCI DSS validated version of Aloha.
Configure alternate security devices for use on the FOH terminals, such as fingerprint scanners, when
installed. Activate fingerprint scanners in Maintenance > Hardware > Terminals > Readers tab, page 27.
Configure your Windows and Aloha networks for security, to give yourself the best chance of maximizing
data integrity in your installation.
Verify Windows is configured to purge the paging file each time you restart the BOH file server.
Information about how to do this is available in the Microsoft Knowledge Base, page 14.
Disable the ‘Guest’ user in Control Panel. Procedures for doing this vary slightly from one operating
system to another, page 13.
Reconfigure all Aloha relevant data and program directories to remove the ‘Everyone’ user from
them, page 13. Verify their configuration permits access only by the system administrator or other autho-
rized accounts.
Disable and remove ‘auto-logon’ on the BOH file server, if currently in use. Remove residual config-
uration for auto-logon, if it has ever been used on the BOH file server, page 13 and page 23.
Install antivirus software, and obtain updates for it routinely and often, page 22. Daily is not too often.
Change all default passwords in routers, remote administrative software, or other third-party hardware
or software, as appropriate, page 6.
Install Aloha(QS) in a secondary directory beneath the root, as in C:\Bootdrv\Aloha(QS), page 13.
Ensure procedures are in place to prevent opening a direct Internet connection from any computer on
the Aloha network, page 14.
Create a Windows user account specifically for use in the Aloha network, independent of any other
network requirements, page 14.
Use Local Security Policy to block the Aloha network-specific user from logging on to the network
page 14.
Configure CtlSvr, EDCSvr, RFSSvr, and any other Aloha related service, devices, and BOH user
accounts to use the network user account created specifically for this purpose, page 15.
Delete any default Windows user accounts provided by Radiant Systems or affiliated companies for
use in initial configuration, page 38.
Configure Aloha EDC to use an alternate path, outside the BootDrv share, by creating a new environ-
ment variable, EDCProcPath, and moving the contents of the current EDC folder to the new location,
page 15.
Disable the System Restore feature in Windows. Refer to “Configuring the Windows Network” on
page 12 for information about how to disable this feature.
Disable Remote Desktop in Windows. Refer to “Configuring the Windows Network” on page 12 for
information about how to disable this feature.
Configure your payment card tenders to protect you and your customers.
Create secure payment card tenders, by suppressing expiration date printing, and by requiring the use
of the card itself for transactions, in Maintenance > Payments > Tenders > Type tab, page 19.
Note: Not required for PCI DSS compliance, but recommended as a best practice.
Store Settings provides you with several opportunities to tighten security in your installation.
Configure printer output to mask the card number and to omit the expiration date, in Maintenance >
Store Settings > Credit Card group > Voucher Printing 2 tab, page 20.
• Select Only show last 4 digits on all vouchers from the ‘Credit Card Number Mask’ drop-down
list.
• Select Suppress Expiration dates.
Require and configure passwords for use on the Front-of-House (FOH) terminals, in Maintenance >
Store Settings > Security group > POS Password Settings tab, page 24.
Stop EDC event logging, in Maintenance > Store Settings > System group > Aloha Settings tab,
page 28.
Configuring your labor settings helps you to keep your Aloha network secure.
Configure back office security levels that provide no more access than required for each employee
type, in Maintenance > Labor > Back Office Security Levels, page 29.
Require each employee to use FOH passwords, and set them to expire regularly, in Maintenance >
Labor > Job Codes > Job Code tab, page 26.
If you are a qualified configuration technician, use the more complete checklist in Appendix A, and the
broader document for help in correcting any flaws discovered when you use this checklist, and to more
thoroughly prepare a site for compliance. This checklist, as well as the rest of this document, is by no
means intended to represent a definitive list of things you can do to guarantee compliance, and is in no way
intended as legal advice. Please contact your legal counsel for more help in these areas.
If you are not a qualified technician, use this checklist as a preliminary evaluation tool, and then contact
your Aloha/Radiant Systems representative for help in configuring your site for security compliance.
Begin by processing a credit card or debit card transaction. Carefully examine the guest check and the
voucher for the following:
Only the last four digits of the primary card account number appear in print (mandatory).
Name of the cardholder is not present (optional). Although it is currently possible to exclude the card-
holder name, it is not mandatory as of publication date.
Reprint the transaction both from FOH and BOH, to verify the security configuration remains con-
stant there, as well.
Perform this configuration check for every credit and debit card type you support in your store, to
confirm that all payment cards are configured for security. This requirement does not apply to
gift cards, or other, similar cards.
Check the following, to verify credit card information is masked on your reports:
Open the Audit report showing the transaction you just processed. Verify the primary account number
is masked.
Open the EDC Batch report, and find the transaction you just processed. Verify the primary account
number is masked.
Key management is automatic, taking place in the Aloha POS application, and in Aloha EDC, relieving
site personnel of any key management requirements.