AlohaPOSDataSecurityHandbook65

Data Security Handbook

Point-of-Sale v6.5

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 editionsof this publication. Any reference to gender in this document is not meant to be discriminatory. The softwaredescribed in this document is provided under a license agreement. The software may be used or copied only inaccordance with the terms of that agreement.

While the content in this document has been obtained from sources believed to be reliable, no warranty is providedconcerning such content and it does not constitute legal advice. Legal advice concerning specific situations shouldbe 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.5 Data
Security HandbookLast Modified 1/18/2010
Table of ContentsThe Purpose of This Document........................................................................................... 5Defining the PCI DSS Requirements................................................................................... 5

What Are the PCI DSS Requirements, and Why Should I Care? ........................................ 5What are ‘Best Practices?’................................................................................................... 6Summarizing the PCI DSS Requirements ........................................................................... 9

Complying with the PCI DSS Requirements .................................................................... 13Building and Maintaining a Secure Network ...................................................................... 13Protecting Cardholder Data ............................................................................................... 21Maintaining a Vulnerability Management Program ............................................................ 26Implementing Strong Access Control Measures................................................................ 27Monitoring and Testing Networks Regularly ..................................................................... 37Maintaining an Information Security Policy ........................................................................ 37

Upgrading Client Accounts................................................................................................ 39Working with Backup Files................................................................................................. 39

Safeguarding Cardholder Data After Upgrading.............................................................. 40Frequently Asked Questions ............................................................................................. 42

General PCI DSS Information............................................................................................ 42Aloha POS and PCI DSS Information................................................................................ 46Additional Resources ......................................................................................................... 49

Appendix A: PCI DSS Configuration and Site Compliance CheckLists ....................... 51PCI DSS Configuration Checklist....................................................................................... 51Site Checklist for PCI DSS and FACTA Compliance......................................................... 54

Appendix B: Aloha Cryptography ..................................................................................... 55Appendix C: EDC Data Flow .............................................................................................. 56Feature History ................................................................................................................... 57

Page 3

Acceptance of a given payment application by the PCI Security Standards Council, LLC (PCI SSC) onlyapplies 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 versionthereof is different from that which was reviewed by the PA-QSA and accepted by PCI SSC – even if thedifferent payment application or version (the “Alternate Version”) conforms to the basic product descriptionof the Accepted Version – then the Alternate Version should not be considered accepted by PCI SSC, norpromoted as accepted by PCI SSC.

No vendor or other third party may refer to a payment application as “PCI Approved” or “PCI SSCApproved”, and no vendor or other third party may otherwise state or imply that PCI SSC has, in whole orpart, accepted or approved any aspect of a vendor or its services or payment applications, except to theextent and subject to the terms and restrictions expressly set forth in a written agreement with PCI SSC, orin a PA-DSS letter of acceptance provided by PCI SSC. All other references to PCI SSC’s approval oracceptance 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 characteristicsimportant to the achievement of PCI SSC’s goals, but such acceptance does not under any circumstancesinclude 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 notwarrant 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, anyimplied 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 PCISSC or any payment brands.

POS v6.5 Data Security Handbook Page 4

The Purpose of This Document

The Purpose of This DocumentRadiant Systems, Inc. provides this document for the purpose of helping its customers to configure theAloha POS system for maximum security, and to help customers at the site level to comply with PaymentCard Industry Data Security Standards (PCI DSS) certification requirements.

Document Publication and Update Frequency

Radiant Systems creates a new version of this document as a companion for each new version of the AlohaPOS system, to reflect any changes occurring in the Aloha POS system. The Aloha POS Data SecurityHandbook receives an annual review, at minimum, to verify the document actually covers all softwarechanges taking place in Quick Service or Table Service in the past year.

The contents of this document are also reviewed annually for accuracy, in relation to the current version ofPayment Application Data Security Standards (PA DSS) in force at the time of the review. As new or mod-ified standards become available, we modify the document to address these changes.

When interim changes occur in the document, we place a revision number on page two of the document,beneath the Copyright section, to indicate the date of the revision. In all cases, the Feature History table, atthe end of the document, indicates the general nature of modifications made to the document.

Document Availability

The latest version of this document is available on the Reseller Portal, the Corporate User Portal, and frommembers of the Radiant team. Copies of this document relating to versions of Aloha that are not officiallyreleased are only available from internal sources, in accordance with agreements in force for the use ofsuch versions. If you have any difficulty obtaining an up-to-date copy of this document for your version ofAloha, please contact a member of the Radiant team for assistance.

Defining the PCI DSS RequirementsThe strategy for security in the electronic payment industry is undergoing rapid, dramatic changes inresponse to multiple factors, especially criminal activity related to electronic payments. Members of thisindustry are working in conjunction with legislatures at all levels to safeguard the environment in whichelectronic payments occur. The PCI DSS requirements are the direct result of these efforts.

Independent security consultants have validated Aloha® POS software products as conforming to theserequirements, 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 StandardsCouncil, 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 softwareproducts, in an effort to protect cardholder data. Similarly, payment application manufacturers must adhere


Defining the PCI DSS Requirements

to the Payment Application Data Security Standards (PA DSS), formerly the Payment Application BestPractices (PABP), also promulgated by the Security Standards Council, as a guideline for making productsthat are secure, and protect cardholder data. The overall objective is to define security measures, agreeableto 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 alsorisk incurring sizable fines.

What are ‘Best Practices?’

As you compare the contents of this document with the PCI DSS requirements, you will find that RadiantSystems is recommending more stringent security measures in several areas. In those instances, we feelthat a more strict approach to system security will, in the long run, keep you and your customers safer, andwill help you to avoid costly security breaches. We regard these differences between required minimumsand recommended measures as part of what we call ‘best practices,’ in that they will contribute even moreto your overall data security without incurring unnecessary costs. We have attempted to make note of areasin 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 validatedAloha version 6.5, through the use of an independent auditor, as being the latest version of Aloha to com-ply with the security standards current at the time of validation. This version provides industry-standardAES 256-bit encryption for data transfer across networks for transaction security, and includes securityenhancements 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 theyare 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 usernames 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 logout of the Aloha BOH, and log out of Windows, when they are not using the system. Train FOH users totouch Exit as they finish using the terminals. Disable or clear any default users, passwords, and automaticlogins provided by hardware or software vendors. Configure the system to automatically time out usersdue 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 RadiantFTP site. Refer to “Using the DelTrack Utility as Part of an Upgrade” on page 40 for more informationabout how to use Deltrack, and how to obtain more information about the utility. Refer to Additional

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


Resources for a link to the Radiant FTP site. Until you complete this task, credit card information may beavailable in these directories, and vulnerable to unauthorized access. You can easily configure DelTrack torun automatically in a post End-of-Day (EOD) batch file. Refer to “Safeguarding Cardholder Data AfterUpgrading” on page 40 for more information about clearing historical data from old dated subdirectories.

Remote administration security — Ensure remote administration software and related processes aresecure. 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 andpasswords 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 samepassword, 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 andpasswords 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 dataread 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 documentwill 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 mostWindows installations, and modifying security settings to limit access only to the specific users requiringit. Open directory shares, anonymous and guest account read-write access to directories, and NETBIOSnetwork communications are among the vulnerabilities that can provide an ‘open door’ to unauthorizednetwork 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 isalso 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 standardsevolve over time. If you have already installed a validated version of Aloha, the security standards bywhich that version was validated will eventually become obsolete. Each security standard version has anexpiration 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 publishedby the Payment Card Industry Security Standards Council (PCI SSC). For this reason, it is extremelyimportant to upgrade your Aloha installation to the latest version of Aloha validated against the appropriatesecurity standards, as it becomes available. A current list of validated versions of Aloha, and the standardsagainst 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 47, in the Frequently Asked Questions section of this document, for more information about validated versions of Aloha, and their respective expiration dates.




Summarizing the PCI DSS Requirements

The PCI DSS requirements contain detailed information about considerations necessary to establish asecure set of practices for protecting cardholder data at the restaurant level. The following table is a verygeneral, high-level adaptation of the PCI DSS requirements, and is intended as a loose guide to the remain-der of this document.

PCI Data Security Requirement

What this requirement means to you...

How you can meet this requirement...

Build and Maintain a Secure Network1 Install and maintain a

firewall, and configure it to protect cardholder data.

Firewall configuration review is mandatory at intervals 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 secure and 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 Data3 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 or PIN, even if encrypted.

When file deletion is required, delete the files securely to prevent the possibility of recovery.

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.

Obtain third-party technol-ogy, and establish a proce-dure and schedule for using it to securely delete files, when file deletion is required. This requirement applies to any security related files requiring deletion, based on data retention policies.

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 Program5 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,’ including installations on all terminals. Terminals may require manual updates.






6 Develop and maintain secure systems and applications.

Obtain and install all operating system security patches and updates at least monthly.

Establish a schedule to obtain and install operating system updates for the server and the terminals.

Implement Strong Access Control Measures7 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 security standards, 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 name and expiring, complex pass-word. Require the user name and password, plus other authentication method for remote access.

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 Networks10 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 any third-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 Policy12 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 RequirementsA PCI DSS Applicability for

Hosting ProvidersHosting 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.





Complying with the PCI DSS Requirements

Complying with the PCI DSS RequirementsMaking use of the inherent capabilities of the Aloha applications are the primary focus of compliance withthe 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, involvesconfiguration at corporate and site levels. The majority of this document discusses how to configure theAloha system for compliance at the site level.

This section discusses general topics that will help you understand the PCI Data Security Standards, andhow 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 compliancestrategy.

Building and Maintaining a Secure Network

The Aloha system installs and runs within the environment defined by Windows. The Aloha network alsodepends 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 assecure 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 backwardscompatibility 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 RKSdocument 10265 for more information about features requiring dual upgrades. Although youmust upgrade your HASP key to Aloha v6.7 to run Aloha EDC v6.7, this change in license statusdoes not require you to upgrade the POS to Aloha v6.7.



• 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 28 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:

• 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 thePCI DSS requirements).Complexity requirements to prevent easily guessing passwords.



• 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, unprotected connection 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.



• 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 thenew 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, westrongly 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 offwhen it is not in use, and protect it with a Windows user name and a complex password. If the site alsoincludes one or more computers separate from the BOH file server for use by managerial staff, ensure thatthese computers are also left locked, logged off, or powered off when not in use.

Prohibited Communication Technologies

It is important to understand that Aloha uses fully encrypted technology for communication with proces-sors. At no point does Aloha use ‘end-user’ methods of communication, such as e-mail, instant messaging,chat, or any other insecure means of transmitting information in any way related to transactions. Refer to“Appendix B: Aloha Cryptography” on page 55 for more information about the encryption and communi-cation technology, and key management the Aloha system uses to protect cardholder data.

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. Datanot stored within the shared file structure is much less likely to be available to anyone entering the systemfrom an external location. You can configure Windows and the Aloha system together to permit only thesystem administrator access to these files.

Beginning with version 6.4, Aloha EDC is version independent of Aloha Quick Service or TableService. EDC v6.4 and later require Aloha v6.1 or later. Although you must upgrade your HASPkey to Aloha v6.5 to run Aloha EDC v6.5, this change in license status does not require you toupgrade the POS to Aloha v6.5.



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

EDC.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 allauthorization 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. TheFOH deletes .ans files from EDCPath after processing the response, so the file remains in the shared pathfor only a short time. The system writes .stl and .txn files solely to the EDCProcPath location. EDCSvrreads 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 checksfor the presence of the required system libraries that provide 128-bit encryption routines. If these systemlibraries are not present, any Aloha program component attempting to launch shuts down. This behaviorincludes the installation process. If you upgrade Windows 2000, XP, or Windows Server 2003 to includeall available service packs and security patches, and upgrade Windows Explorer to v6.0, this processupgrades all encryption libraries.

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.5, as this version takes advantage of 128-bit encryption, along with AES256-bit encryption for the brief periods of time when cardholder data may be stored on disk. The Alohasystem encrypts cardholder data, and purges non-essential data, such as track data, after completing theauthorization process.

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 numbersand expiration dates in the Audit report for all employees, to prevent unauthorized access to cardholderdata. 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 selectingReprint > Audits > Display Credit/Debit Card Numbers, in the Functions column. Select the security levelID 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 numbersand expiration dates in the Audit report. When an employee accesses credit card information in the auditreport, Aloha details this activity in a message inserted in Debout.txt. All other employees with access tothe 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 modifysecurity settings, in the manner described above. Refer to “Controlling Access to Aloha Manager andAloha EDC” on page 29 for more information about access control to the Aloha system.

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.

Figure 1 Back Office Security Levels, Audit Report Permission Configuration



Protecting Wireless Transmissions

Aloha applications, beginning with version 6.0, make use of at least 128-bit encryption for all forms ofwireless data transfer between handheld devices, FOH terminals, and the BOH file server. As technologyadvances, wireless devices will proliferate in the restaurant environment, and the opportunities for datafraud 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 thenetwork with a password and encryption key. Do not purchase wireless equipment that is only capable ofusing the WEP security standard, as this standard is no longer secure in the current wireless environment.

You must also install a perimeter firewall between any wireless network and the environment in whichcardholder data is managed or stored. You must configure the firewall to deny or appropriately control anytraffic from the wireless environment into the cardholder data environment.

Allowing an unencrypted wireless network is a critical security violation, surpassed only by placing theAloha 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 wishesto provide wireless access to customers, install an isolated wireless access point (AP), configured outsidethe 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. Sensingsoftware 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.

Wireless Key Management

Wireless encryption keys require management for secure network operation. The following guidelines arePCI DSS requirements:

Change the wireless encryption keys per the following:

• Change immediately upon initiation of the wireless network.• Change immediately when an employee with knowledge of the keys leaves the company.• Change immediately when an employee with knowledge of the keys changes positions within the

company.• Change default SNMP community strings on all wireless devices.• Change all other security-related wireless vendor defaults, as applicable.

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/


Encryption Requirement

You must also implement strong encryption in all cases where any of the following are broadcast wire-lessly within the restaurant:

• Cardholder data• Authentication data

An extensive discussion of wireless network security is beyond the scope of this document. Considerableinformation 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 ofrisk that we often overlook has to do with our daily habits. This section discusses some of the things wecan 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 thatis 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. DSLor other Ethernet appliances) when they are not in use, to effectively ‘shut the door’ on potential externalthreats. Only leave the power on to devices you are actively using for credit card authorization and settle-ment.

Best practices in this area are as follows:

• Configure a firewall or personal firewall product for proper data security, if connecting via VPN or other high-speed connection.

• Activate remote-access technologies only when you need them for downloading updates from applicable vendors.

• Deactivate remote-access technologies immediately after all downloads are complete.

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 ofencryption. Install Internet Explorer, v6.0 on any computers still exhibiting installation problems related toencryption issues.



In conjunction with establishing encryption support in the operating system, and also by installing the lat-est version of Aloha available that has been validated as meeting PA DSS requirements, you must alsoensure that you use secure encryption transmission technology, such as IPSEC, VPN, or SSL/TLS, for alloperations involving communication across public networks for the purpose of handling payment cardtransactions.

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. Astechnology 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 dataextracted 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 whileauthorizations are in progress. After completing card authorizations, Aloha removes track and securitycode information from the files in an irrecoverable manner.

Creating Secure Card Tenders

When you create credit card tenders, there are specific options you can use to enhance the security of youroperations, one of which is mandated by U.S. Federal law. In Aloha Manager, select Maintenance > Pay-ments > Tenders > Type tab to access these options.

Figure 2 Tender Maintenance, Type Tab



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 useof credit card account numbers at the site. To comply with FACTA, clear the ‘Print Expiration’ option toprevent printing sensitive cardholder information on the guest check.

Suggested Settings:

• Use Magnetic Card ONLY: Selected• Print Expiration: Cleared• Print on Check, on the Identification tab: Cleared

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 23 for more information about complying with United States Federal law by suppressing the expiration date.


http://www.treasury.gov/offices/domestic-finance/financial-institution/cip/pdf/fact-act.pdf


Configuring Printer Output for Compliance

To be PCI DSS compliant, a site must not print the entire credit card number. Select Maintenance > StoreSettings > Credit Card group > Voucher Printing 2 tab to configure printer output for compliance. Use theoptions on this tab to mask all but the last four digits of the card number, and to suppress the expirationdate 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 • 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), version5.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.

Figure 3 Store Settings, Credit Card Group, Voucher Printing 2 Tab, Configuration

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.



Reconciling Versions of D/FB and Aloha

To be PCI DSS compliant, you must upgrade Aloha Delivery/Frequent Buyer (D/FB) to version 5.27.6,and upgrade Aloha to a version that accepts the encrypted information from D/FB. The appropriate ver-sions of Aloha are as follows:

Deleting Files Securely

As data retention policies come into play, file deletions must be secure to prevent any possibility of recov-ery. Although Radiant Systems provides a utility, DelTrack, for removing sensitive data from within Aloharelated files, files may exist in any Aloha installation that are beyond the scope or reach of DelTrack, andoften require deletion. Files that may require deletion are as follows:

• Settlement files, located in the processor directory on the BOH file server, contain encrypted card-holder data. DelTrack removes cardholder data from these files.

• Trans.log files, located in dated subdirectories on the BOH file server, contain encrypted card-holder data. DelTrack removes cardholder data from these files.

• Trans.log files, in dated subdirectories on terminals made file server, contain encrypted cardholder data. The system does not delete these files, and DelTrack does not work outside the Aloha BOH file server. Site personnel must use a manual process to securely delete these files.

• Backup logs on terminals contain encrypted cardholder data. Site personnel must use a manual process to securely delete these files.

When files require deletion, whether they are on the Aloha BOH file server or on the terminals, you mustuse a manual method, as DelTrack deletes data within the files, not the files themselves. Even if you areremoving the files to removable storage media for offsite storage, you must still securely ‘delete’ theremoved files from the spaces they previously occupied, to prevent possible recovery.

Files may require secure deletion as part of a scheduled data retention policy, or they may be remnants lefton terminals as the result of redundancy events. Regardless, you must establish a method and a schedulefor identifying and securely deleting these files, to obtain and retain PCI DSS certification at the site level.

Quick Service and Table Service, v6.0 v6.0.17 and later accept encrypted data.



Quick Service and Table Service, v6.4 All versions accept encrypted data.

Quick Service and Table Service, v6.5 All versions accept encrypted data.

Quick Service and Table Service, allother versions

Accept only unencrypted data.



Summarizing from the list above, you must establish a positive method for securely deleting Trans.log filesin dated subdirectories, and any other backup log files on terminals, as well as settlement files in both loca-tions. We recommend the following process for addressing the issue of secure file deletion:

1. Select a secure file deletion utility from the many available, some of which are available at no cost. Regardless of the utility you decide to use, we recommend verifying the utility actually deletes files securely, before you use it with your Aloha installation.

2. Define a data retention policy for data on the BOH file server. You must establish a time frame, usually 30 days, for DelTrack to skip over before beginning its work, and you must determine the maximum amount of time you will retain copies of files before deleting them. We recommend the bare minimum of retention time required to support your business. If you determine that you must archive dated subdirectories or other files for extended periods of time, we recommend you arrange for secure off-site storage of this data. If you use off-site storage, you must verify the pro-cedures in use at this facility are also in compliance with industry standard best practices.

3. When the retention time expires on a given set of files, delete the files manually, then execute the secure deletion utility to securely remove the files from the server or terminals.

If your company data retention policy requires saving specific files to removable media, you must exercisegreat care to adhere to the following, to ensure PCI DSS compliance, per requirement number 3.1:

• Never move files to removable media if there is the possibility that they may contain cardholder data. Only move files from which this data has already been removed by the DelTrack utility. If you set aside an exclusion period for recent files in DelTrack, never move any of these files to removable media.

• Document the files removed, and the nature and disposition (location) of the removable media used for file storage.

• Ensure the removable media are held securely against unauthorized access of any kind, while in storage.

• Specify, in accordance with pre-determined policies, a time when the removable media must be destroyed, or otherwise rendered unreadable.

• Ensure that removable media are, in fact, destroyed per established policies.

Secure File Deletion Considerations

It is beyond the scope of this document to name applications you can use for secure file deletion, or todescribe in any detail how to actually use these applications. You must select an application capable ofworking in a networked environment, and you must establish how to do the following with any applicationyou use:

• Select and delete specific files securely, by removing the files and completely clearing the spaces from which they were removed.

• Securely clear deleted files or file remnants from blank disc space.• Verify file deletions are complete.



Deleting Sensitive Data Storage Related to Troubleshooting

When it becomes necessary to troubleshoot difficulties customers experience with payment card transac-tions, the process often involves storing files that can contain sensitive authentication data. If permitted topersist, these files can constitute a considerable data security risk, as this type of data may include mag-netic stripe data, card validation codes or values (security codes), or PIN block data. Specific guidelinesare in effect for support personnel to use for this type of file storage:

• Prevent access to troubleshooting data by anyone other than personnel troubleshooting the prob-lem.

• Collect this type of information only when you need it to solve a specific problem.• Exercise great care to collect no more information than is necessary to solve the problem.• Store these files in an encrypted state, in specific, known, highly secure locations. • Securely delete these files immediately after they are no longer needed. Refer to “Deleting Files

Securely” on page 24 for more information about deleting files securely.

Maintaining a Vulnerability Management Program

As we understand all too well, numerous types of threats exist in the environment we face today. We mustexercise great care to address these threats, and maximize the safety of cardholder data, and our businessdata. To comply with PCI DSS, you must establish and maintain a program that addresses these threats. Inthis 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 byinaction over time. The best practices in this area are as follows:

• 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 to become available at irregular intervals, and may be less frequent than for antivirus programs.

• Due to the vulnerability implied by a direct Internet connection, you must obtain antivirus and antispyware program updates from the manufacturers as downloadable components, and install them on the BOH file server and terminals manually. Although this process can be admittedly cumbersome, it is the only way to safely update these programs.

You may find it helpful to create a checklist that you can mark each time you search for a security updatefor 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, or fingerprint scanner, and access to the BOH is bypassword.

Secure access to Aloha Manager, the Aloha BOH application, and Aloha EDC is available through the useof passwords. We recommend specific configurations for passwords, to maximize security. This sectiondetails 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 securelocation, preferably offsite, along with any other critical stored data. It is also a requirement that you visitoffsite storage at least once a year, to verify correct security procedures are in effect. Finally, it is also arequirement 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 thistype of business, you must establish access control measures to prevent unauthorized access to cardholderdata through the electronic ports on the Aloha BOH file server. The best method for complying with thisrequirement is to install the server in a secure, lockable location. Strong password protection, discussed inanother 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 storagedevices. 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.



Managing Windows Auto-Logon

It is possible to automate the logon process by enabling auto-logon, but this process stores the user nameand password in the Windows registry in clear text. This practice poses a security risk, and violates the PCIDSS requirement for implementing strong access control measures.

To assist you in managing the Windows auto-logon feature, Microsoft offers freeware called ‘Autologonfor 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 fora 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 anddownload 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.aspx


Remember, PCI DSS security requirements apply to all system components, not just the Aloha softwareand its configuration. It is your responsibility to configure your systems in a secure manner, and ensuringyou 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. isenhancing security for all Aloha products. Beginning with Aloha v6.4, we disabled the Alt+X method ofaccessing Aloha Manager for Quick Service and Table Service, and Aloha EDC. You must access theseapplications through the use of a unique user name and complex, expiring password. This makes PCI DSScompliance 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 SecurityLevels.

• 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 forall versions of Aloha prior to v6.4. Please contact your Radiant representative if you cannot access theRadiant Knowledge System to obtain this document.

Configuring Passwords in the Aloha System

Security configuration begins with properly configured employee profiles, requiring the behavior thatresults 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.



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, selectMaintenance > 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.



Requiring Expiration of FOH Passwords

After establishing the requirement for a password in the FOH, you must also establish a time interval forthe 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

Requiring Complex Passwords for BOH Access

Security at the BOH file server is governed exclusively by password control. For this reason, to complywith the requirement to implement strong access control, employees who log in to the BOH must use com-plex, or ‘strong,’ passwords. This type of password contains upper and lower case letters, numbers, andspecial characters, such as &$*@%#. One example of this type of password could be a string likeAgrB4&45e%. The complex password is more resistant to external attack, and is nearly impossible for oth-ers to guess, especially if the letters do not spell a dictionary word.

As part of compliance with Payment Card Industry Data Security Standards (PCI DSS), at the site level,employees must use a complex password to log in to Aloha Manager. Simply using an employee number isno longer acceptable. This requirement is active, by default, when you upgrade to Aloha v6.5.

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.



Site-level password requirements may arrive pre-configured as part of a database provided by a corporateoffice, as part of the upgrade to Aloha v6.5. The site administrator can also define password requirementsafter the upgrade. In both cases, the first time an employee logs in to Aloha Manager after the upgrade,they must change their password using the new strong password rules. After the site administrator logs in,they can redefine the password requirements, assuming they have sufficient permission configured in theirBack Office Security Level settings.

After logging in to Aloha Manager, the site administrator can use the following procedure to define thepassword rules for their site:

1. Launch Aloha Manager per normal practice, using your current password to log in. Aloha imme-diately asks you to provide a new password.

2. Change your password when prompted, per the following rules, as defined in the software:• Must be between 7 and 25 characters in length.• Must not contain the employee name or nickname, or the employee number.• Must contain at least one alpha and at least one numeric character, in any desired order.• Must not be identical to a password used recently, as specified by the system administrator.

In addition to the above requirements imposed by the Aloha POS software, the PCI DSS imposes additional requirements. In most cases, Radiant Systems recommends somewhat more stringent configuration, as follows:

• Do not use group, shared, or generic accounts and passwords. Each user must log in to the Aloha system with a unique user name and password.

• Passwords may not be identical to one used within the past four (4) password changes, at min-imum, for compliance with PCI DSS. We recommend setting this option at six (6) passwords.

• Limit repeated access attempts to not more than six (6) attempts, before locking the user ID. We recommend three (3) attempts.

• Set the lockout time interval for a locked ID to a minimum of 30 minutes, without administra-tor intervention. We concur with the recommendation of 30 minutes.

• Set the time-out interval for EDC sessions to a maximum of 15 minutes. We recommend a time-out interval of no more than five (5) minutes.

3. Select Maintenance > Store Settings > Security > POS Password Settings tab. The option Use Strong BOH Password Rules is active, by default, upon upgrade.

Changing these, or any other settings to values less secure than the require-ments established by PCI DSS constitute a violation, and could result in non-com-pliance with these requirements.

Figure 7 Excerpt from Store Settings, Security Group, BOH Password Settings



4. Configure the BOH Password Settings per the following:

User Lockout Attempts: __ Times — Specifies the number of unsuccessful attempts a user can make before the system locks them out. Type the number of unsuccessful attempts you want to allow a legitimate user before locking them out. Recommended configuration: Three (3) failed attempts result in user ID lockout.

Password Expires After: __ Days — Defines the number of days to elapse before the user must create a new password. Type the number of days, after which an employee must create a new pass-word. Recommended configuration: Not more than 45 days.

User May Not Use Previous: __ Passwords — Specifies the number of previously used pass-words the system will disallow for an employee creating a new password. Type the number of recent passwords you want to prevent employees re-using, when they create a new password. Rec-ommended configuration: Six (6) non-repeating passwords.

5. Click Save to save your changes.6. Close Store Settings. 7. Let the normal End-of-Day process perform a data refresh, making your changes effective on the

Aloha BOH file server, and across the network.

Refer to the Quick Service or Table Service Reference Guide for more information about config-uring passwords in the Aloha system.



Using Alternative Security Devices Instead of Passwords

You can increase security considerably for accessing the FOH terminals by requiring employees to usemagnetic 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 businessneeds, and installed equipment. These two security devices are not mutually exclusive, but if you configurethe system as shown in Figure 8, employees must clock in and log in to the FOH using the fingerprint scan-ner.

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)

Figure 8 Employee Maintenance, Employee Tab, Security Configuration

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.



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 isnot possible to modify or disable this logging function. If modification or disabling of the EDC loggingfunction is attempted, in any way, it would violate the requirements of the PCI DSS security standards.EDCSvr captures this information and stores it in the EDC debout file. As a related function, Aloha alsologs a message to Debout.txt, detailing employee access to the Audit report, when the employee elects toview credit card account numbers.

Another component to logging EDC activity relates to troubleshooting EDC when problems occur. Whenconfigured to do so, EDCSvr captures even more detailed information in the EDC Debout file. To preventstoring this type of information, select Maintenance > Store Settings > System Group > Troubleshootingtab, and clear these settings.

As a best practice, we recommend that you not enable any debugging functions unless you are activelytroubleshooting 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:

• Debug Touch: Cleared• Debug EDC Service: Cleared

Figure 9 Store Settings, System Group, Troubleshooting Tab



Creating Back Office Security Levels in Aloha

In your installation, you probably have one or more back office security levels available for assigning toemployees. We recommend you examine each of the existing security levels, to verify that all access isgranted on a ‘need-only’ basis. As you create new security levels, we recommend you do not start with anexisting 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 accessonly 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, inaccordance 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 CommandCenter.

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 layerof 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 multiple opportunities for securitybreaches, requiring specific actions in each case. The requirements for correct configuration and operationof remote access applications are as follows:

• Change default settings in the remote access software. For example, change default passwords and use unique passwords for each customer.

• Allow connections only from specific (known) IP/MAC addresses.• Use strong authentication and complex passwords for logins according to PCI DSS requirements

8.1, 8.3, and 8.5.8 through 8.5.15.• Enable encrypted data transmission according to PCI DSS requirement 4.1.• Enable account lockout after a certain number of failed login attempts according to PCI DSS

requirement 8.5.13.• Configure the system so a remote user must establish a Virtual Private Network (VPN) connection

via a firewall before access is allowed.• Enable the logging function.• Restrict access to customer passwords to authorized reseller/integrator personnel.• Establish customer passwords according to PCI DSS requirements 8.1, 8.2, 8.4, and 8.5.• 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.



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 helpreduce the threat. We also recommend using antispyware/malware software, available at no charge directlyfrom 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 againstapplicable data security standards, and use the DelTrack utility to clear this type of information from theAloha 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 fileserver 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 inthis area.

Testing Applications for Vulnerabilities

Rigorous testing during development ensures the integrity of security features in Aloha applications. Westrongly 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 atRadiant Systems at least once every year, and inquire about security requirement changes, and changes inthe 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 arenearly complete. The next step in the PCI DSS (Section 12), is to formalize your data security program intoa 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 aformal 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 ofpeople and authorities to contact, both within the company and outside the company, to include lawenforcement and transaction processors. You are required to provide training to employees on the properprocedures 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 todo, on an annual basis, to make sure all of your hard work is still effectively protecting your site from datasecurity breaches. You must make a list of who to call and what to tell them, in case there is a securitybreach. 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 forthem 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, includingareas and degrees of responsibility.


Upgrading Client Accounts

Upgrading Client AccountsIt 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.5 is now the latest versionvalidated as complying with the latest applicable data security standards.

As technology advances, Radiant Systems continue to focus and build upon the security aspects of ourproducts to introduce increasingly more secure features, while retaining previous levels of security. As theresult of this process, we recommend that anyone accepting credit card payments upgrade to Aloha version6.5, 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 periodicallyverify the configuration of the program is correct, site by site, to maximize the ability of each customer topass site certification requirements. Local configuration changes can inadvertently circumvent securityrequirements. 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 accessto 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 securityat 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 theAloha directory, often including copies of the dated subdirectories, prior to the actual upgrade. Thesebackup 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 notwork 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.


Safeguarding Cardholder Data After Upgrading

Safeguarding Cardholder Data After UpgradingPrior to upgrading to Aloha v6.0 or beyond, we strongly recommend that you settle all pending EDCbatches, 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 cardnumbers, may still be available in plain text in the dated subdirectories, or in files retained in directoriesrelated 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 touse it.

Using the DelTrack Utility as Part of an Upgrade

If you have already been using Aloha for some time, cardholder data may exist in some of the archivedfiles related to the previous version. This risk is especially real if you are upgrading from a version ofAloha prior to v6.0. Removal of all cryptographic data that may have been stored as part of using previousversions of Aloha is of utmost importance, and absolutely necessary for PCI DSS compliance.

For this reason, you must use the DelTrack utility as part of your upgrade process. This utility clears sensi-tive cardholder data from files stored by Aloha on the BOH file server, thus reducing the risk of a datacompromise. The process for using DelTrack, however, is different, depending on whether you have datedsubdirectories created with Aloha v5.2.8 or earlier, or if your dated subdirectories are from a newer ver-sion. 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 abouthow 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 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.


Safeguarding Cardholder Data After Upgrading

5. Run DelTrack v6.4.1 or later 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, ignoring 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.

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.


Frequently Asked Questions

Frequently Asked QuestionsQuestions we frequently hear about PCI DSS compliance, and how it relates to the Aloha system tend tofall into specific categories. This section includes those questions, grouped by category, in an attempt tohelp you understand this potentially difficult and confusing topic.

A Note About Links

In this section, you will find numerous blue links, which are active in the PDF version of this document.Although we have made every effort to verify these links, there is no guarantee that they will work fromevery network, or that the companies creating the Web pages will not modify their sites. If you find a linkthat does not work for you, please contact us about it. However, you can often copy the link to yourbrowser, then shorten it to get to a higher-level page. From there, you can search the site to find what youneed.

General PCI DSS Information

Q. What is the Payment Card Industry Data Security Standard (PCI DSS)?

A. The Payment Card Industry Data Security Standard (PCI DSS) is the result of collaboration between thevarious 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 DataProtection (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 todevelop the new requirements as part of an industry-wide standard for protection of cardholders’ creditcard account and transaction information, and to make the use of credit or debit cards a safer process forcardholders and merchants alike.

Each credit card issuer will continue to maintain their own program identity name for internal purposeswithin their operating rules and regulations, such as VISA CISP, MasterCard SDP, etc. However, you cannow refer to all of these programs by referring to ‘the Payment Card Industry Data Security Standards,’ orsimply ‘PCI DSS.’

Q. Why is PCI DSS important?

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.


https://www.pcisecuritystandards.org/tech/download_the_pci_dss.htm


• Minimized Threat to a Customer’s Reputation and Financial Health — Financial and resource outlay is minimal compared to the costs associated with the reactive hiring of security and public relations specialists, or the loss of significant revenue and customer goodwill that can result from a compromise.

• Potential Fines — In the event of non-compliance, the card associations and the federal govern-ment can assess fines, and impose restrictions and other penalties, and can bring other legal actions.

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 cardholderinformation 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 stringentrequirements. This document focuses on the PCI DSS requirements, as the card issuing companies aredeferring to these standards.

Q. Who needs to participate in the PCI DSS Program?

A. This program is required of all entities storing, processing or transmitting any credit or debit card holderdata. 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.

Q. Which Merchant Level applies to me?

A. Use the following table to determine the level applicable to your business:

Merchant Level Description1 Any merchant processing over 6,000,000 transactions of Visa or MasterCard per

year, across all channels.Any merchant that has suffered a hack or an attack that resulted in an account data compromise.Any merchant, identified by the Credit Card Issuer (Visa, MasterCard, etc.), that should meet the Level 1 merchant requirements to minimize risk to the overall sys-tem.Any merchant identified by any other payment card brand as Level 1.

2 Any merchant processing 150,000 to 6,000,000 e-commerce transactions* per year.3 Any merchant processing 20,000 to 150,000 e-commerce transactions* per year.4 Any merchant processing fewer than 20,000 e-commerce transactions* per year,

and all other merchants processing up to 6,000,000 transactions per year.



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.

Q. What are the 12 basic requirements of PCI DSS standards?

A. A complete summary of the 12 basic PCI Data Security Standards is available in “Summarizing the PCIDSS Requirements” on page 9. You can obtain a full copy of the requirements from the Payment CardIndustry Security Standards Council Web site, as noted on page 5.

• Build and Maintain a Secure Network.1. Install and maintain a working firewall to protect data.2. Do not use vendor-supplied defaults for passwords and other security parameters.

• Protect Cardholder Data.3. Protect stored data – at all times! 4. Encrypt transmission of cardholder data and sensitive information sent across public networks.

• Maintain a Vulnerability Management Program.5. Use and regularly update anti-virus software.6. Develop and maintain secure systems and applications.

• Implement Strong Access Control Measures.7. Restrict access to business data on a ‘need to know’ basis.8. Assign unique ID to each person with computer access.9. Restrict physical access to cardholder data.

• Regularly Monitor and Test Networks.10. Track and monitor all access to network resources and cardholder data using a user unique ID.11. Regularly test security systems and processes.

• Maintain an Information Security Policy.

Merchant Level Validation Action Validated By Due Date1 Annual On-site PCI Data Secu-

rity AssessmentandQuarterly Network Scan

Qualified Data Security Company or Internal Audit if signed by Officer of the company Qualified Independent Scan Ven-dor

9/3/04

2 and 3 Annual Self-Assessment Ques-tionnaire D andQuarterly Network Scan

MerchantQualified Independent Scan Ven-dor

6/30/05

4* Annual Self-Assessment Ques-tionnaire D (Recommended) andNetwork Scan (Recommended)

MerchantQualified Independent Scan Ven-dor

TBD



12. Implement and maintain an information security policy.

Q. What can I do to meet PCI DSS requirements?

A. Use the following suggestions to meet PCI DSS requirements:

• Build and Maintain a Secure Network.

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, andother 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 frombeing translated and revealed on the internet.

• Protect Cardholder Data.

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 thecredit card track information, from the time the system reads the credit card to the time the systemreceives 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 theyare configured for maximum security. Examples may include, but are not limited to, Aloha Deliv-ery/Frequent Buyer, Aloha Accounts Receivable, and eFrequency.

• Maintain a Vulnerability Management Program.

Radiant Systems recommends that you install an antivirus application on all computers on the POSnetwork. Update virus definitions on a frequent, and regular basis. Update security patches for allinstalled software within one month of release.

NOTE: Test all patches prior to deploying them.

• Implement Strong Access Control Measures.

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 notusing the computer. In addition, configure the Windows screen-saver to automatically lock thecomputer 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. Youshould delete any default users and passwords provided from Aloha by Radiant Systems. Restrictaccess to view or delete the audit logs, including the Debugging-Output-Files (debouts) created bythe Aloha application software.



If you use pcAnywhere for Remote Administration, ensure that the sessions are secured. WhilepcAnywhere has its own built-in security features, you should use the Operating System’s securitymeasures for the highest level of security. Symantec provides details on how to secure the systemon their Web site in Chapter 7 of the ‘Symantec’s pcAnywhere Administrator’s Guide.’ Pleasereview 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

• Regularly Monitor and Test Networks.

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 totrack usage.

• Maintain an Information Security Policy.

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 allsystem users and maintain signed acknowledgements of the program.

Aloha POS and PCI DSS Information

Q. Why am I being asked to upgrade to Aloha version 6.5? I thought version 5.3.15 was CISP com-pliant.

A. Version 5.3.15 was validated as complying with CISP requirements, as they existed in early 2005. Sincethat time, the PCI DSS requirements have evolved, and have been clarified. Aloha version 6.5 is now thelatest version validated to comply with the stated requirements. As always, we recommend upgrading tothe latest version of Aloha validated as complying with the latest published security specifications, as soonas that version becomes available.

Q. What is the responsibility of Radiant Systems?

A. Aloha POS by Radiant Systems is a ‘payment application.’ Best practices and security standards havebeen developed to address security and the risks associated with payment applications. The goal of thePayment 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:

1. Do not retain full magnetic stripe data.2. Protect stored data.3. Provide secure password features.4. Log application activity.5. Develop secure applications.6. Protect wireless transmissions.7. Test applications to address vulnerabilities.8. Facilitate secure network implementation.




9. Cardholder data must never be stored on a server connected to the Internet.10. Facilitate secure remote software updates.11. Facilitate secure remote access to application.12. Encrypt sensitive traffic over public networks.13. Encrypt all non-console administrative access.

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 ApplicationData Security Standards (PA DSS), available from the following sources:

A list of PABP-validated payment applications is available by clicking ‘PABP-validated Payment Applica-tions List’ at the very bottom of the page referencing these standards.

Q. Has Aloha POS been validated stating it meets these requirements?

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 ofeach 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:


As PCI Security Standards continue to evolve, Radiant Systems is committed to continuously increasingsecurity 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 aPayment Application?

PABP http://www.visa.com/pabpPA DSS https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml

POS version number:

Validated against PABP/PA DSS version:

Deployment notes: Current validation expires on:

Aloha v5.3.15 Pre-PABP v1.3 Not recommended for new deployments. December 2, 2009Aloha v6.1 PABP v1.3 Acceptable for new deployments. June 2, 2010Aloha v6.2 PABP v1.4 Acceptable for new deployments. December 2, 2010Aloha v6.4 PA DSS v1.2 Acceptable for new deployments. October 2, 2013Aloha v6.5 PA DSS v1.2 Acceptable for new deployments. October 2, 2013




http://www.visa.com/pabp


A. Several versions up to and including v6.5 have been validated as complying with the PA DSS require-ments, and are included in the list of Payment Card Industry Security Standards Council validated solu-tions. Although Aloha versions 5.3.15 and later contain many features that address PA DSS requirements,Aloha v6.5 is the latest validated version available, meeting the requirements in effect as of the time of itsvalidation (June, 2009).

Aloha’s compliance certification status is available at:


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 tostrengthen security. The following list includes a few of the security enhancements recently added to AlohaQuick Service and Table Service:

• Credit card numbers are encrypted and masked in historical data files.• Credit card numbers are encrypted and secured in the Electronic Data Capture (EDC) files.• Credit card numbers are encrypted in all files used to communicate and complete both card autho-

rization and batch settlement.• Detailed track information has been securely removed from the Trans.log for the following trans-

action types:

1. Apply Payment2. Refund3. Attach Card Info4. Pre Authorizations5. Carry Over Payments (24-hour operations)

Radiant Systems will continue to review requirements for Payment Applications to meet industry bestpractices.

Q. What level of encryption is used by Aloha?

A. Aloha POS used 64-bit encryption in all versions prior to version 6.0. Beginning with version 6.0, theencryption level increased to 128-bit, using industry-standard technology. Aloha v6.4 and later retains 128-bit encryption for employee passwords, but uses AES 256-bit encryption for payment card transactions.

Q. How often will Aloha be reviewed for compliance?

A. Versions previously validated can remain on the list of validated POS applications, if they remainunchanged, 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.’

Q. How do I upgrade to a version of Aloha that meets PCI DSS?




A. Please contact your Radiant Systems representative for assistance in upgrading your current version ofAloha.

Q. What about the historical data in the dated subdirectories?

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.exeutility provided by Radiant Systems to remove all track information, or other cardholder information fromboth the EDC settlement files and the Trans.log. This utility removes track data, and masks credit cardnumbers, expiration dates, and security codes.

Q. Am I compliant if I upgrade Aloha?

A. While upgrading Aloha assists you with some of the security standards directly related to the paymentapplication, 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 networkcomponent, server, or application included in the cardholder data environment. This can include, but is notlimited to, firewalls, switches, routers, wireless access points, network appliances, and other securityrelated appliances and applications.

Q. What are my next steps?

A. Radiant Systems recommends that all merchants complete a self-assessment and take action on anyitems marked with ‘No.’ When a merchant resolves all identified risks, they should qualify as compliant.

Download the ‘AOC SAQ D - Merchants v1.2’ questionnaire at:

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 yourRadiant representative.

Additional Resources

For more information regarding PCI DSS requirements, please visit the following links:

• PCI Data Security Standard:



• List of Validated Service Providers:

http://usa.visa.com/merchants/risk_management/cisp_service_providers.html

• List of Validated Payment Applications:

http://usa.visa.com/merchants/risk_management/cisp_payment_applications.html


https://www.pcisecuritystandards.org/saq/index.shtml


http://usa.visa.com/merchants/risk_management/cisp_service_providers.html

http://usa.visa.com/merchants/risk_management/cisp_payment_applications.html



• pcAnywhere Administrator’s Guide:


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

For more information about individual credit card programs:

• Visa CISP

http://www.visa.com/cisp/

• MasterCard SDP

https://sdp.mastercardintl.com/

• American Express DSOP

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



ftp://ftp.alohapos.com/downloads/utilities

http://www.visa.com/cisp/

https://sdp.mastercardintl.com/

https://www209.americanexpress.com/merchant/singlevoice/dsw/FrontServlet?request_type=dsw&pg_nm=home&ln=en&frm=US

http://www.discovernetwork.com/resources/data/data_security.html

Appendix A: PCI DSS Configuration and Site Compli-

Appendix A: PCI DSS Configuration and Site Compliance CheckLists This section includes two checklists designed to help you configure your site for PCI DSS compliance. ThePCI DSS Configuration Checklist provides a relatively detailed list of configuration steps, designed to helpyou configure your computers and your networks for basic compliance.

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, orlack thereof, of a specific site.

PCI DSS Configuration Checklist

The steps to PCI DSS compliance are many, and occasionally confusing. Use this checklist as a guide, andto measure your progress, as you configure your own database for compliance. If you are viewing this doc-ument in PDF format, click any blue link to move immediately to the topic it references for more informa-tion. Each topic also lists its page number, if you are using a printed copy.

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 amember 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 40, after upgrading to a PCI DSS validated version of Aloha.

Configure alternate security devices for use on the FOH terminals, such as fingerprint scanners, wheninstalled. Activate fingerprint scanners in Maintenance > Hardware > Terminals > Readers tab, page 34.

Network Security Configuration:

Configure your Windows and Aloha networks for security, to give yourself the best chance of maximizingdata 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 15.

Disable the ‘Guest’ user in Control Panel. Procedures for doing this vary slightly from one operatingsystem to another, page 14.

Reconfigure all Aloha data and program directories relevant to remove the ‘Everyone’ user fromthem, page 14. 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 14 and page 28.

Install antivirus software, and obtain updates for it routinely and often, page 26. Daily is not too often.

Change all default passwords in routers, remote administrative software, or other third-party hardwareor software, as appropriate, page 6.

Install Aloha(QS) in a secondary directory beneath the root, as in C:\Bootdrv\Aloha(QS), page 14.

Ensure procedures are in place to prevent opening a direct Internet connection from any computer onthe Aloha network, page 15.

Create a Windows user account specifically for use in the Aloha network, independent of any othernetwork requirements, page 15.

Use Local Security Policy to block the Aloha network-specific user from logging on to the systempage 15.

Configure CtlSvr, EDCSvr, RFSSvr, and any other Aloha related service, devices, and BOH useraccounts to use the network user account created specifically for this purpose, page 16.

Delete any default Windows user accounts provided by Radiant Systems or affiliated companies foruse in initial configuration, page 45.

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

Disable the System Restore feature in Windows. Refer to “Configuring the Windows Network” onpage 13 for information about how to disable this feature.

Disable Remote Desktop in Windows. Refer to “Configuring the Windows Network” on page 13 forinformation about how to disable this feature.

Aloha POS Configuration – Tender Configuration:

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 useof the card itself for transactions, in Maintenance > Payments > Tenders > Type tab, page 21.

• Select Use Magnetic Card ONLY.• Clear Print Expiration.• On the Identification tab, clear Print on Check.

Note: Not required for PCI DSS compliance, but recommended as a best practice.



Aloha POS Configuration – Store Settings:

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

• 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 29.

Require complex, expiring BOH passwords, in Maintenance > Store Settings > Security group > POSPassword Settings tab, page 31.

Stop EDC event logging, in Maintenance > Store Settings > System group > Aloha Settings tab,page 35.

Aloha POS Configuration – Labor Settings:

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 employeetype, in Maintenance > Labor > Back Office Security Levels, page 36.

Require each employee to use FOH passwords, and set them to expire regularly, in Maintenance >Labor > Job Codes > Job Code tab, page 31.



Site Checklist for PCI DSS and FACTA Compliance

This section is intended as a simple, high-level checklist for site managers to use as a preliminary assess-ment for PCI DSS and FACTA compliance. FACTA is the acronym for Fair and Accurate Credit Transac-tions Act. The items in this checklist represent some of the ‘surface’ things you can quickly check to beginanalyzing the data security in your site.

If you are a qualified configuration technician, use the more complete checklist in Appendix A, and thebroader document for help in correcting any flaws discovered when you use this checklist, and to morethoroughly prepare a site for compliance. This checklist, as well as the rest of this document, is by nomeans intended to represent a definitive list of things you can do to guarantee compliance, and is in no wayintended 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 contactyour Aloha/Radiant Systems representative for help in configuring your site for security compliance.

Checking Print Output

Begin by processing a credit card or debit card transaction. Carefully examine the guest check and thevoucher for the following:

Only the last four digits of the primary card account number appear in print (mandatory).

The card expiration date does not 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.

Checking Your Reports

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 numberis masked.

Open the EDC Batch report, and find the transaction you just processed. Verify the primary accountnumber is masked.

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.


Appendix B: Aloha Cryptography

Appendix B: Aloha CryptographyVersions Prior to 6.0 (starting with 5.3.15)

Versions of the Aloha Point-of-Sale system prior to 6.0 use a proprietary hash algorithm with a 64-bit keyto generate encrypted data. All keys associated with the encryption are maintained within the applicationor are environmentally generated based on type of data and transaction at time of encryption.

Aloha Versions 6.0 and Later

Versions 6.0 and 6.2 of the Aloha Point of Sale system use RSA MD5 128-bit encryption algorithms for allencryption tasks. Version 6.4 uses AES 256-bit encryption for payment card and cardholder data, to safe-guard transactions, while still using the 128-bit encryption for employee BOH passwords. The followingtable summarizes the encryption methods used in the Aloha system, beginning with version 6.0:

Key Maintenance

Key management is automatic, taking place in the Aloha POS application, and in Aloha EDC, relievingsite personnel of any key management requirements. All versions of the Aloha POS system, beginningwith v6.0, fully encrypt the credit card track data using the encryption mechanism supported by the versionin use. The application maintains all public keys associated with the encryption process; they are not pub-lished to the customer, and the customer is not required to manage key rotation. Because of the encryptiontechniques in place, and the dynamic method of key management performed by the Aloha applicationitself, there is no need for Aloha customers to manage encryption key rotation and disposal.

Credit Card Data Specifics

Credit card track information persists only during the authorization process. Credit card numbers persistbeyond the authorization process, but remain encrypted. Credit card numbers are exported for reportingpurposes in a configurable masked format. Access to credit card numbers is strictly controlled by config-urable permissions, managed only by personnel at the highest level of access. Aloha logs any request, suc-cessful or not, for access to credit card numbers, and this access logging cannot be disabled or modified.The DelTrack utility completely removes credit card numbers, when run against Aloha or EDC files inwhich they are stored.

Communication Methods

Aloha communicates securely with processors using SSL/TLS. This communication is automatic, does notchange, and is not within the control of users at any level.

Aloha Version Data Encrypted Encryption Method6.0 and 6.2 Employee passwords RSA MD5 128-bit encryption6.0 and 6.2 Payment card and cardholder data RSA MD5 128-bit encryption6.4.7 and later Employee passwords RSA MD5 128-bit encryption6.4.7 and later Payment card and cardholder data AES 256-bit encryption


Appendix C: EDC Data Flow

Appendix C: EDC Data FlowThe accompanying diagram illustrates the flow of data through, out of, and back into the Aloha POS sys-tem, beginning with the first swipe of a payment card.

Figure 10 EDC Credit Card Data Flow

Cashier swipes credit/debit card; Aloha encrypts data.

Processor answers back to AlohaBOH (encrypted).

Master terminal accepts transactions from all terminals, including itself.

BOH file server removes track data, retains other card data, writes answer file back to the terminal (encrypted). Terminal deletes track data from Trans.log upon receipt of answer file.

Aloha sends data to BOH file server. AlohaBOH settles with processor, creating .stl files (encrypted).

BOH file server sends authorization request to processor (encrypted, using SSL).

Use secure deletion software to delete .stl files manually, in accordance with data retention policies.

Processor puts funds on hold to cover the transaction, or declines if funds are insuffi-cient.


Appendix C: EDC Data Flow

Feature History

Revision Dates Changes Made6/30/2006 Document released in draft.7/21/2006 Document updated to reflect feedback from RAB and PAB members,

and from an independent auditor. 12/1/2006 Document updated to include Appendix B, containing expanded informa-

tion about cryptography used in the Aloha system. 1/22/2007 Clarified statements around maintaining installations at the latest version

validated as PCI DSS and CISP compliant.4/2/2007 Added section about purging the Windows Paging file (hyperlink to rele-

vant section).5/3/2007 Updated Figures 1, 3, 8, 10, and 12 to bring them into compliance with

Aloha v6.2. 5/24/2007 Renumbered the document to v6.2. 6/20/2007 Modified Compliance Checklist to improve the appearance, and make it

easier to use. 6/21/2007 Added coverage for RFCs 43736 - mask card numbers in audit report

page 18, 58097-8 - disable Alt+X access page 29, and 48425 - track all activity in EDC page 35. Also considerably expanded section about wireless networks, to include more detailed information, and some recommendations for security stan-dards and practices.

8/7/2007 Modified Figure 3 to bring into compliance with v6.4.8/30/2007 Added information about disabling Alt+x for earlier versions of Aloha, as

contained in RKS 6298, page 29. 11/1/2007 Added ‘Site Checklist.’ 1/29/2008 Renumbered the document to v6.4. 8/8/2008 Document completely rewritten, to convert from ‘CISP Best Practices’ to

‘POS Data Security Handbook.’ 9/11/2008 Updated document to reflect dual-level encryption built in to Aloha soft-

ware, Quick Service and Table Service.12/18/2008 Updated the document to reflect PCI DSS v1.2 revised standards.

Updated the document to reflect correct references to PABP and PA DSS standards.

1/21/2009 Multiple modifications, as follows:Documented how v6.4 uses Back Office Access Levels to control access to credit card information in the Audit report. Also documented mes-sages logged to Debout.txt when someone accesses debit or credit card numbers in the Audit report (page 18 and page 29).Added bullet point in Aloha Network Configuration about how v6.4 pre-vents using the Keyboard Wedge Windows service, page 15.Added note indicating Aloha v6.4 removes security code, when col-lected, after authorization, page 21.

2/9/2009 Renumbered the document to v6.5 throughout, as appropriate.Updating the document to reflect this version.


11/20/2009 Made minor verbiage changes for clarity, re. EDC version-indepen-dence.

1/18/2010 Made minor verbiage changes to sections relating to auto-logon.

Revision Dates Changes Made

Page 58 POS v6.5 Data Security Handbook

AlohaPOSDataSecurityHandbook65

Documents

personal digital

keyboard wedge

frequently

exercise great

credit card

aloha deliveryfrequent

pci dss requirements

data retention