Professional Documents
Culture Documents
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 translated 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 publication. Changes are periodically made to the information herein; these changes will be incorporated in new editions of this publication. Any reference to gender in this document is not meant to be discriminatory. The software described in this document is provided under a license agreement. The software may be used or copied only in accordance with the terms of that agreement. While the content in this document has been obtained from sources believed to be reliable, no warranty is provided concerning such content and it does not constitute legal advice. Legal advice concerning specific situations should be obtained by your legal counsel. Radiant Systems, Inc., 2010 All Rights Reserved. ALOHA is a U.S. Registered Trademark of Radiant Systems, Inc. MenuLink is a U.S. Registered Trademark of Radiant Systems, Inc.
Table of Contents
The Purpose of This Document........................................................................................... 5 Defining the PCI DSS Requirements................................................................................... 5 What Are the PCI DSS Requirements, and Why Should I Care? ........................................ 5 What are Best Practices?................................................................................................... 6 Summarizing the PCI DSS Requirements ........................................................................... 9 Complying with the PCI DSS Requirements .................................................................... 13 Building and Maintaining a Secure Network ...................................................................... 13 Protecting Cardholder Data ............................................................................................... 21 Maintaining a Vulnerability Management Program ............................................................ 26 Implementing Strong Access Control Measures................................................................ 27 Monitoring and Testing Networks Regularly ..................................................................... 37 Maintaining an Information Security Policy ........................................................................ 37 Upgrading Client Accounts................................................................................................ 39 Working with Backup Files................................................................................................. 39 Safeguarding Cardholder Data After Upgrading.............................................................. 40 Frequently Asked Questions ............................................................................................. 42 General PCI DSS Information............................................................................................ 42 Aloha POS and PCI DSS Information................................................................................ 46 Additional Resources ......................................................................................................... 49 Appendix A: PCI DSS Configuration and Site Compliance CheckLists ....................... 51 PCI DSS Configuration Checklist....................................................................................... 51 Site Checklist for PCI DSS and FACTA Compliance......................................................... 54 Appendix B: Aloha Cryptography ..................................................................................... 55 Appendix C: EDC Data Flow .............................................................................................. 56 Feature History ................................................................................................................... 57
Page 3
Acceptance of a given payment application by the PCI Security Standards Council, LLC (PCI SSC) only applies to the specific version of that payment application that was reviewed by a PA-QSA and subsequently accepted by PCI SSC (the Accepted Version). If any aspect of a payment application or version thereof is different from that which was reviewed by the PA-QSA and accepted by PCI SSC even if the different payment application or version (the Alternate Version) conforms to the basic product description of the Accepted Version then the Alternate Version should not be considered accepted by PCI SSC, nor promoted as accepted by PCI SSC. No vendor or other third party may refer to a payment application as PCI Approved or PCI SSC Approved, and no vendor or other third party may otherwise state or imply that PCI SSC has, in whole or part, accepted or approved any aspect of a vendor or its services or payment applications, except to the extent and subject to the terms and restrictions expressly set forth in a written agreement with PCI SSC, or in a PA-DSS letter of acceptance provided by PCI SSC. All other references to PCI SSCs approval or acceptance of a payment application or version thereof are strictly and actively prohibited by PCI SSC. When granted, PCI SSC acceptance is provided to ensure certain security and operational characteristics important to the achievement of PCI SSCs goals, but such acceptance does not under any circumstances include or imply any endorsement or warranty regarding the payment application vendor or the functionality, quality, or performance of the payment application or any other product or service. PCI SSC does not warrant any products or services provided by third parties. PCI SSC acceptance does not, under any circumstances, include or imply any product warranties from PCI SSC, including, without limitation, any implied warranties of merchantability, fitness for purpose or noninfringement, all of which are expressly disclaimed by PCI SSC. All rights and remedies regarding products and services that have received acceptance from PCI SSC, shall be provided by the party providing such products or services, and not by PCI SSC or any payment brands.
Page 4
Document Availability
The latest version of this document is available on the Reseller Portal, the Corporate User Portal, and from members of the Radiant team. Copies of this document relating to versions of Aloha that are not officially released are only available from internal sources, in accordance with agreements in force for the use of such versions. If you have any difficulty obtaining an up-to-date copy of this document for your version of Aloha, please contact a member of the Radiant team for assistance.
What Are the PCI DSS Requirements, and Why Should I Care?
The Payment Card Industry Data Security Standards (PCI DSS), as formulated by the Security Standards Council, are the standards by which payment card companies, such as Visa, American Express, MasterCard, and others, agree to measure the security of individual installations, and electronic payment software products, in an effort to protect cardholder data. Similarly, payment application manufacturers must adhere
POS v6.5 Data Security Handbook Page 5
to the Payment Application Data Security Standards (PA DSS), formerly the Payment Application Best Practices (PABP), also promulgated by the Security Standards Council, as a guideline for making products that are secure, and protect cardholder data. The overall objective is to define security measures, agreeable to all, that protect cardholders so that in case you have a security breach, data is not compromised. Merchants and vendors that do not comply with these recommendations put cardholder data at risk, and also risk incurring sizable fines. Version 1.2 of the PCI DSS requirements, the most recent version, is available in its entirety for download in PDF or DOC format at the following URL: https://www.pcisecuritystandards.org/security_standards/ pci_dss_download.html_agreement.html
Resources for a link to the Radiant FTP site. Until you complete this task, credit card information may be available in these directories, and vulnerable to unauthorized access. You can easily configure DelTrack to run automatically in a post End-of-Day (EOD) batch file. Refer to Safeguarding Cardholder Data After Upgrading on page 40 for more information about clearing historical data from old dated subdirectories. Remote administration security Ensure remote administration software and related processes are secure. Limit the number of people permitted to perform these functions. Do not share remote access credentials, even within your own company; if someone needs access, give them their own, unique authentication in the system. Disable remote access software, and shut down all sessions, once required tasks are complete. Never leave remote access software listening. Shut down all client-side applications after completing all remote administration tasks. Default accounts Change default names and passwords to make randomly guessing account names and passwords difficult. Network user accounts can create vulnerabilities when they are active across the network, and follow a predictable pattern. User accounts that are very similar to each other and use the same password, such as Term1 through Term8, all with a password of Aloha, make it easy for someone to guess their way into the network, especially if this pattern is the same across several sites. Peripheral equipment, such as routers and wireless access points, may also have default user names and passwords set in their firmware. Remember to replace these with strings unique to your installation. Storage of complete, unencrypted mag-stripe data Software configured to permit storage of data read from the magnetic stripe on a credit card is vulnerable to attack. The risk to cardholders and merchants alike increases dramatically, if the data is not encrypted. The recommendations in this document will help you to verify your Aloha installations are configured to be as secure as possible. Insecure system configuration We recommend disabling the Guest account, which is part of most Windows installations, and modifying security settings to limit access only to the specific users requiring it. Open directory shares, anonymous and guest account read-write access to directories, and NETBIOS network communications are among the vulnerabilities that can provide an open door to unauthorized network and data access. Lack of a firewall Failing to use a firewall can also leave a network vulnerable. Antivirus and antispyware software can work together with a firewall to significantly enhance the security of a network. It is also vital to update these security measures on a routine basis.
Page 7
Several versions of Aloha have been validated against different versions of security standards, as published by the Payment Card Industry Security Standards Council (PCI SSC). For this reason, it is extremely important to upgrade your Aloha installation to the latest version of Aloha validated against the appropriate security standards, as it becomes available. A current list of validated versions of Aloha, and the standards against which they have been validated are available from the following link: https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml Refer to the table on page 47, in the Frequently Asked Questions section of this document, for more information about validated versions of Aloha, and their respective expiration dates.
Page 8
Build and Maintain a Secure Network Establish configuration standards for fire1 Install and maintain a firewall, and configure it walls and routers, that deny access from untrusted sources, and prevent access to to protect cardholder cardholder data. Configure firewalls to data. prevent connections between public servers and cardholder data, including wireFirewall configuration less networks. review is mandatory at intervals of six months or less.
Install firewall technology to protect any Web-based services, such as remote orderInstall an application layer firewall in front ing systems. of Web-facing applications. Periodic vulnerability testing is a requirement. Set up a process for reviewing firewall configuration at least every six months, to verify configuration remains secure and unchanged. Be careful to change any Do not use vendor-sup- Change vendor-supplied default user plied defaults for system names and passwords before connecting user names and passwords already established as part to the network. Encrypt all non-console passwords and other of software and hardware administrative access. security parameters. you may install. Remote administration software, wireless access points, and routers are prime examples.
Page 9
When file deletion is required, delete the files securely to prevent the possibility of recovery.
Obtain third-party technology, and establish a procedure 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. 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 hardware and software to support IEEE 802.11i. Constantly test your network to verify it is snooper free. As a best practice, we recommend immediate upgrade to the IEEE 802.11i standard.
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 email.
Maintain a Vulnerability Management Program 5 Use and regularly update Install a reputable antivirus program that antivirus and antispyis also capable of detecting and removing ware software. spyware and adware. Update it immediately 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 generating audit logs. You can use separate antivirus and antispyware programs, if you wish, as long as both fulfill the requirements. Install and configure antivirus and antispyware software, per recommended parameters, 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.
Page 10
Implement Strong Access Control Measures 7 Restrict access to cardholder data by business need-to-know. Limit access to computers and applications that may contain cardholder information only to those for whom it is necessary for their job functions. Use need to know criteria, and exclude all others. Install the latest version of Aloha validated 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. Limit access to computers, printers, administrative terminals, or other devices that could hold cardholder data, especially between employees and visitors.
Assign a unique ID to each person with computer access. Store user passwords in an encrypted format.
Install all parts of the Aloha network except FOH terminals in areas to which only authorized personnel have access. Exclude access to these parts to non-managePrevent unauthorized access to printed customer data records, such as receipts, ment employees, if possible. and establish procedures, as laid out in Establish offsite storage for the standards, for disposal. customer related paper documents, and establish an acceptable destruction schedule and procedure. You must visit the storage facility at least annually, to monitor the security of the site. Use extensive access and activity logging 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 Manager. It is always active in EDC.
Regularly Monitor and Test Networks 10 Track and monitor all access to network resources and cardholder data.
Page 11
Regularly test security Perform regular security tests to expose Establish a schedule of physsystems and processes. vulnerabilities in systems and processes. ically examining and verifying that all security related settings are set correctly in the Aloha system, and in any third-party programs that could impact security, including programs like PCAnywhere. You must undergo a PCI security scan by an Approved Scanning Vendor (ASV) on a quarterly basis.
Maintain an Information Security Policy 12 Maintain a policy that addresses information security for employees and contractors. Maintain a security policy that promulgates and explains these requirements, including approvals, authentication procedures, and more. This requirement includes maintaining a policy regarding remote access technologies, wireless technologies, removable electronic media, e-mail and Internet usage, removable electronic media, laptops, or personal digital assistants (PDAs). Create and maintain a system 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, laptops, or PDAs in sensitive areas, and do not permit any e-mail or Internet access.
Appendices Additional Requirements A PCI DSS Applicability for Hosting providers protect cardholder data Ask your hosting providers Hosting Providers environment. about the measures they take to protect cardholder data. Compensating Controls Requirement number three, above, may be difficult for some sites or some technologies. This Appendix permits alternate, 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 implement, to protect cardholder data. If you can use standard configuration to accomplish this protection, do not establish alternate methods.
Page 12
Page 13
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 autologon, 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:\BootDrv\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 permit 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 AlohaService account and members of the Administrators group. This configuration prevents unauthorized users access to EDC files on the BOH file server. When you use the EDCProcPath feature, the EDC files are no longer stored under the BootDrv share, so they are not accessible from the Aloha network. Change user rights for all Aloha services, e.g. EDCSvr, CTLSvr, RFSSvr, to run under a dedicated network account with Administrative access. This account requires registry access, but normal BOH users do not. Require all administrative personnel to log in to Windows using unique accounts with appropriate security levels. Disable accounts for staff that are no longer employed, to prevent unauthorized access. Never give the passwords to the AlohaService or FOH Aloha login to unauthorized staff. Rotate passwords periodically (every 90 days at most), and use complex passwords. Configure the local security policy for password policies, to enforce the following: History of three or more passwords, to prevent repeats. Maximum age of 90 days, minimum age of one day for new passwords. Minimum length of eight characters (slightly more restrictive than the PCI DSS requirements). Complexity requirements to prevent easily guessing passwords.
Configure the local security policy for account lockout policy to lock out accounts for at least 30 minutes after three or more invalid login attempts, to prevent hammering attacks.
Page 14
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 customers 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 network. 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 shutdown 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 following 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 article 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 connect 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.
Page 15
Register CtlSvr, EDCSvr, RFSSvr, and any other Aloha related services or devices to use a network 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 restaurants. 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 December, 2007, because there are no security patches available for them that will make them compliant with the new requirements. Although it is possible to upgrade the encryption level in these operating systems, their inherent security features render them unsafe in the current operating environment. For this reason, we strongly suggest that you upgrade any computer in your network still using any of these operating systems. At the store level, one of the main security concerns is to keep the BOH file server locked or logged off when it is not in use, and protect it with a Windows user name and a complex password. If the site also includes one or more computers separate from the BOH file server for use by managerial staff, ensure that these computers are also left locked, logged off, or powered off when not in use.
Page 16
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 computers 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 all authorization request files (.req) to the default EDCPath, and the transaction (.txn) and settlement (.stl) files to the new EDCProcPath location. The system writes answer (.ans) files to the EDCPath location. The FOH deletes .ans files from EDCPath after processing the response, so the file remains in the shared path for only a short time. The system writes .stl and .txn files solely to the EDCProcPath location. EDCSvr reads the EDC files in the EDCProcPath location, and monitors the current EDCPath location for incoming .req files. The Aloha system assumes %Iberdir%\EDC as the default location for the environment variable, EDCPath. It is not necessary to create this variable, as Aloha assumes this location if you do not. If you want to use a path different from the default for EDCPath, create the new folder, and create a new environment variable, EDCPath, to match the new location. The EDCPath folder must be within the \Bootdrv location. This path is in contrast with the EDCProcPath environment variable, discussed above, which you will define in a location outside the \Bootdrv shared folder.
Page 17
We recommend you use Aloha v6.5, as this version takes advantage of 128-bit encryption, along with AES 256-bit encryption for the brief periods of time when cardholder data may be stored on disk. The Aloha system encrypts cardholder data, and purges non-essential data, such as track data, after completing the authorization process. Although support for 128-bit encryption begins with Aloha v6.0, we recommend you always use the latest version of Aloha validated against the applicable data security standards, and configure it for maximum security, as discussed in this document.
Also beginning with Aloha v6.4, only employees with pre-existing edit rights in Store Settings can modify security settings, in the manner described above. Refer to Controlling Access to Aloha Manager and Aloha EDC on page 29 for more information about access control to the Aloha system.
Page 18
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 passwords are readily available on the Internet for all peripherals, when applicable.
Page 19
Encryption Requirement
You must also implement strong encryption in all cases where any of the following are broadcast wirelessly within the restaurant: Cardholder data Authentication data
An extensive discussion of wireless network security is beyond the scope of this document. Considerable information is available from numerous public sources about wireless network security.
Page 20
In conjunction with establishing encryption support in the operating system, and also by installing the latest version of Aloha available that has been validated as meeting PA DSS requirements, you must also ensure that you use secure encryption transmission technology, such as IPSEC, VPN, or SSL/TLS, for all operations involving communication across public networks for the purpose of handling payment card transactions.
Page 21
Enable Use Magnetic Cards ONLY to prevent manual credit card entry without manager approval. Although not specifically required for PCI DSS compliance, this setting helps to prevent unauthorized use of credit card account numbers at the site. To comply with FACTA, clear the Print Expiration option to prevent printing sensitive cardholder information on the guest check. Suggested Settings: 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 Accurate 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.
Page 22
Figure 3 Store Settings, Credit Card Group, Voucher Printing 2 Tab, Configuration
Suggested Settings: Credit Card Number Mask: Only show last 4 digits Suppress Expiration dates: Selected Suppress Cardholder Name: Optional Federal law (Fair and Accurate Credit Transactions Act of 2003, or FACTA) requires the configuration 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.
When files require deletion, whether they are on the Aloha BOH file server or on the terminals, you must use a manual method, as DelTrack deletes data within the files, not the files themselves. Even if you are removing the files to removable storage media for offsite storage, you must still securely delete the removed 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 left on terminals as the result of redundancy events. Regardless, you must establish a method and a schedule for identifying and securely deleting these files, to obtain and retain PCI DSS certification at the site level.
Page 24
Summarizing from the list above, you must establish a positive method for securely deleting Trans.log files in dated subdirectories, and any other backup log files on terminals, as well as settlement files in both locations. 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 procedures 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 exercise great 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.
Page 25
You may find it helpful to create a checklist that you can mark each time you search for a security update for your programs. Make sure the checklist is complete, and use it faithfully.
Page 26
Page 27
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 location.
Use the following guidelines with regard to using the Windows auto-logon feature on an Aloha system: NEVER configure the Aloha BOH file server to use the Windows auto-logon feature. If the file server is currently, or has ever been set to use auto-logon, run the AutoLogon.exe freeware on the BOH file server and follow the prompts to disable the feature immediately. After running AutoLogon.exe, restart the Aloha BOH file server. Windows should prompt you for a user name and password, indicating the program ran successfully. Configuring a Front-of-House (FOH) terminal to use auto-logon is an accepted configuration; however, it is still necessary to remove the clear text user name and password. You can accomplish this in the following ways: 1. If you are using Radiant hardware with Radiant Auto Loader (RAL), install RAL version 2.3.1.0 or later. RAL will move the information to a secure area and store it in an encrypted format. 2. If you are using Radiant hardware without RAL or are not using Radiant hardware, run AutoLogon.exe on each terminal to move the information to a secure area and store it in an encrypted format.
Click http://technet.microsoft.com/en-us/sysinternals/bb963905.aspx to access Microsoft TechNet and download AutoLogon.exe. This freeware is also available in the Utilities folder on the Aloha FTP site.
POS v6.5 Data Security Handbook Page 28
Remember, PCI DSS security requirements apply to all system components, not just the Aloha software and its configuration. It is your responsibility to configure your systems in a secure manner, and ensuring you are using the above best practices regarding the auto-logon feature is a must. 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.
Page 29
Suggested Settings: Min Password Digits: 3 Max Password Digits: 15 Number Employee: 3 or 4 Password: Required 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.
Page 30
Suggested Settings: Uses Password: Selected Password Expires: Selected Renew after: 30 to 45 Days You can configure the system to make passwords mandatory, and still use magnetic cards or fingerprint 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 corporate office, as part of the upgrade to Aloha v6.5. The site administrator can also define password requirements after 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 their Back Office Security Level settings. After logging in to Aloha Manager, the site administrator can use the following procedure to define the password rules for their site: 1. Launch Aloha Manager per normal practice, using your current password to log in. Aloha immediately 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 minimum, 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 administrator 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. Changing these, or any other settings to values less secure than the requirements established by PCI DSS constitute a violation, and could result in non-compliance with these requirements. 3. Select Maintenance > Store Settings > Security > POS Password Settings tab. The option Use Strong BOH Password Rules is active, by default, upon upgrade.
Figure 7 Excerpt from Store Settings, Security Group, BOH Password Settings POS v6.5 Data Security Handbook Page 32
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 password. Recommended configuration: Not more than 45 days. User May Not Use Previous: __ Passwords Specifies the number of previously used passwords 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. Recommended 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 configuring passwords in the Aloha system.
Page 33
You can use magnetic stripe cards and fingerprint scanners at the same time, depending upon your business needs, and installed equipment. These two security devices are not mutually exclusive, but if you configure the system as shown in Figure 8, employees must clock in and log in to the FOH using the fingerprint scanner. 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. 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) All mention of fingerprint scanners in the previous section is intended to refer to hardware supplied 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.
Page 34
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
Page 35
Page 37
To summarize these requirements in a more common-sense way, you must make a list of what you need to do, on an annual basis, to make sure all of your hard work is still effectively protecting your site from data security breaches. You must make a list of who to call and what to tell them, in case there is a security breach. You must be careful about who you hire, performing background checks on new employees whenever possible, and you must make sure employees only have access to the parts of the system necessary for them to perform their job functions. You must publish your security plan to your employees, and provide them with training about what to do to avoid security breaches, and what to do if one occurs, including areas and degrees of responsibility.
Page 38
Upgrading clients to the latest version of Aloha, however, is not sufficient, by itself. You must periodically verify the configuration of the program is correct, site by site, to maximize the ability of each customer to pass site certification requirements. Local configuration changes can inadvertently circumvent security requirements. You can minimize or eliminate changes of this sort by careful configuration of your Windows environment, and by using Back Office Security Levels, in Aloha Manager, to limit employee access to specific features, with specific permission levels for specific functions. The Aloha system often exists in an environment shared with other programs that can also impact security at the most basic levels, such as pcAnywhere. You must also verify, site by site, that these programs, although not directly related to the Aloha system, are configured for maximum security.
Page 39
Page 40
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. Although the Payment Card Industry Security Standards Council and Radiant Systems recommend retaining dated subdirectories no longer than 90 days, you must establish a data retention policy consistent with your business needs. Your responsibility for deleting cardholder data extends to any and all data you may retain, regardless of its nature or location. Manually open the Trans.log files in the dated subdirectories, and search for card numbers to verify DelTrack has removed this information. This operation is especially important for subdirectories 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.
Page 41
As such, the new standard contains IT security requirements and guidelines for all major credit card issuers, including Visa, MasterCard, American Express, JCB, and Discover. These card issuers joined forces to develop the new requirements as part of an industry-wide standard for protection of cardholders credit card account and transaction information, and to make the use of credit or debit cards a safer process for cardholders and merchants alike. Each credit card issuer will continue to maintain their own program identity name for internal purposes within their operating rules and regulations, such as VISA CISP, MasterCard SDP, etc. However, you can now refer to all of these programs by referring to the Payment Card Industry Data Security Standards, or simply PCI DSS. Q. Why is PCI DSS important? A. The PCI DSS Standards help merchants and service providers protect their information assets. Merchants also benefit from: Consumer Confidence Consumers want security and assurance that their financial information and identity is safe.
Page 42
Minimized Threat to a Customers 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 government 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 cardholder information and transactions. CISP, SDP, DSOP, and DISC are simply the names of the credit card companies internal programs that ensure compliance with PCI DSS standards. If you meet PCI DSS standards, you will meet the standards of the individual credit card issuers, except as they adopt more stringent requirements. This document focuses on the PCI DSS requirements, as the card issuing companies are deferring to these standards. 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 holder data. It ensures that all merchants and service providers are required to safeguard sensitive data. Merchants Retailers, or other entities (pursuant to a Merchant Agreement), that agree to accept credit cards, debit cards, or both, when properly presented. Service Providers Organizations that process, store, or transmit cardholder data on behalf of acquirers, members, merchants, or other service providers. Examples are RBS Lynk, Shift Four, and PayPal.
If you accept payment cards, credit or debit, in your establishment, PCI DSS applies to you. Q. Which Merchant Level applies to me? A. Use the following table to determine the level applicable to your business: Merchant Level
1
Description
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 system.
2 3 4
Any merchant identified by any other payment card brand as Level 1. Any merchant processing 150,000 to 6,000,000 e-commerce transactions* per year. Any merchant processing 20,000 to 150,000 e-commerce transactions* per year. 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.
Page 43
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 additional requirements beyond those of the various credit card brands: Merchant Level
1
Validation Action
Annual On-site PCI Data Security Assessment and Quarterly Network Scan
Validated By
Qualified Data Security Company or Internal Audit if signed by Officer of the company Qualified Independent Scan Vendor Merchant Qualified Independent Scan Vendor Merchant Qualified Independent Scan Vendor
Due Date
9/3/04
2 and 3
Annual Self-Assessment Questionnaire D and Quarterly Network Scan Annual Self-Assessment Questionnaire D (Recommended) and Network Scan (Recommended)
6/30/05
4*
TBD
* Level 4 merchants must comply with PCI DSS; however, the acquirer determines the nature of compliance validation for merchants in this category. The acquirer is the bankcard association member that initiates 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 PCI DSS Requirements on page 9. You can obtain a full copy of the requirements from the Payment Card Industry 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.
Page 44
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 information. Limit traffic from un-trusted networks to web protocols, system administration protocols, and other protocols required for business. You should disable all other traffic in your router configuration. Also implement Internet Protocol (IP) masquerading in order to prevent internal addresses from being 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 the credit card track information, from the time the system reads the credit card to the time the system receives authorization from the credit card processor. The system deletes the track information following the authorization. Verify that all additional installed Aloha modules are at the latest versions available, and that they are configured for maximum security. Examples may include, but are not limited to, Aloha Delivery/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 POS network. Update virus definitions on a frequent, and regular basis. Update security patches for all installed 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 logins, Aloha logins and pcAnywhere logins. Train users to log out of Windows and Aloha when not using the computer. In addition, configure the Windows screen-saver to automatically lock the computer after a period of inactivity, in case the user fails to log out. Disable any default users, passwords, and automatic logins provided by hardware and software vendors. Assign a unique BOH login for each Aloha user. This enables you to track each users activity. You should delete any default users and passwords provided from Aloha by Radiant Systems. Restrict access to view or delete the audit logs, including the Debugging-Output-Files (debouts) created by the Aloha application software.
Page 45
If you use pcAnywhere for Remote Administration, ensure that the sessions are secured. While pcAnywhere has its own built-in security features, you should use the Operating Systems security measures for the highest level of security. Symantec provides details on how to secure the system on their Web site in Chapter 7 of the Symantecs pcAnywhere Administrators Guide. Please review the guide and implement pcAnywhere security at your sites: ftp://ftp.symantec.com/public/english_us_canada/products/pcanywhere/pcanywhere32/ver10.5/ manuals/pca_105_admin.pdf Regularly Monitor and Test Networks. Use the Windows Local Security Policy and various Windows audit logs to enhance auditing capability on the system. In addition, implement hardware, such as routers, to increase your ability to track usage. Maintain an Information Security Policy. Document security polices for access control, application and systems development, and operational and network securities. Develop a response plan for security incidents. Communicate to all system users and maintain signed acknowledgements of the program.
Cardholder data must never be stored on a server connected to the Internet. Facilitate secure remote software updates. Facilitate secure remote access to application. Encrypt sensitive traffic over public networks. Encrypt all non-console administrative access.
In addition to the above, more specific requirements are applicable to payment card application manufacturers, as summarized in the Payment Application Best Practices (PABP), and the Payment Application Data Security Standards (PA DSS), available from the following sources:
PABP PA DSS http://www.visa.com/pabp https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml
A list of PABP-validated payment applications is available by clicking PABP-validated Payment Applications 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 requirements against which they were validated. The table also provides information about the current status of each validated version. POS version number:
Aloha v5.3.15 Aloha v6.1 Aloha v6.2 Aloha v6.4 Aloha v6.5
Refer to the PCI PA-DSS FAQ on the following Web site for answers to frequently asked questions regarding the plans for grandfathering PABP-validated payment applications: https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml As PCI Security Standards continue to evolve, Radiant Systems is committed to continuously increasing security to protect cardholders and merchants. We strongly encourage clients to adopt the most recent market ready Aloha release to stay current with security-related enhancements. Q. What version of Aloha POS has been validated stating it meets the standard requirements for a Payment Application?
Page 47
A. Several versions up to and including v6.5 have been validated as complying with the PA DSS requirements, and are included in the list of Payment Card Industry Security Standards Council validated solutions. Although Aloha versions 5.3.15 and later contain many features that address PA DSS requirements, Aloha v6.5 is the latest validated version available, meeting the requirements in effect as of the time of its validation (June, 2009). Alohas compliance certification status is available at: https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml Q. What enhancements to Aloha POS have been implemented to meet PA DSS requirements? A. Radiant Systems will continue to enhance the Aloha software with each release to continue to strengthen security. The following list includes a few of the security enhancements recently added to Aloha Quick Service and Table Service: 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 authorization and batch settlement. Detailed track information has been securely removed from the Trans.log for the following transaction types: 1. 2. 3. 4. 5. Apply Payment Refund Attach Card Info Pre Authorizations Carry Over Payments (24-hour operations)
Radiant Systems will continue to review requirements for Payment Applications to meet industry best practices. 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, the encryption level increased to 128-bit, using industry-standard technology. Aloha v6.4 and later retains 128bit 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 remain unchanged, and if Radiant Systems submits a letter to this effect annually, signed by an Officer. New versions must be independently validated, prior to being listed as validated.
Page 48
A. Please contact your Radiant Systems representative for assistance in upgrading your current version of Aloha. 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 information must be removed from all dated subdirectories created prior to the upgrade. Use the DelTrack.exe utility provided by Radiant Systems to remove all track information, or other cardholder information from both the EDC settlement files and the Trans.log. This utility removes track data, and masks credit card numbers, expiration dates, and security codes. Q. Am I compliant if I upgrade Aloha? A. While upgrading Aloha assists you with some of the security standards directly related to the payment application, it is the responsibility of the individual merchant to ensure that all PCI DSS standards are met. Remember, PCI DSS security requirements apply to all system components, defined as every network component, server, or application included in the cardholder data environment. This can include, but is not limited to, firewalls, switches, routers, wireless access points, network appliances, and other security related appliances and applications. Q. What are my next steps? A. Radiant Systems recommends that all merchants complete a self-assessment and take action on any items marked with No. When a merchant resolves all identified risks, they should qualify as compliant. 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 your Radiant representative.
Additional Resources
For more information regarding PCI DSS requirements, please visit the following links: PCI Data Security Standard: https://www.pcisecuritystandards.org/security_standards/pci_dss_download_agreement.html https://www.pcisecuritystandards.org/security_standards/pci_dss_download_agreement.html 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
POS v6.5 Data Security Handbook Page 49
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/FrontServlet?request_type=dsw&pg_nm=home&ln=en&frm=US Discover DISC http://www.discovernetwork.com/resources/data/data_security.html
Page 50
System Configuration:
Begin configuring your Aloha installation for PCI DSS compliance at the most basic level, initial installation. Install the latest version of Aloha validated against the applicable data security standards. Contact a member of the Radiant team to identify the latest validated version of Aloha. Obtain and run the DelTrack utility, to remove any residual customer data remaining in your installation, 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, when installed. Activate fingerprint scanners in Maintenance > Hardware > Terminals > Readers tab, page 34.
Page 51
Disable and remove auto-logon on the BOH file server, if currently in use. Remove residual configuration 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 hardware or 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 on the Aloha network, page 15. Create a Windows user account specifically for use in the Aloha network, independent of any other network requirements, page 15. Use Local Security Policy to block the Aloha network-specific user from logging on to the system page 15. Configure CtlSvr, EDCSvr, RFSSvr, and any other Aloha related service, devices, and BOH user accounts to use the network user account created specifically for this purpose, page 16. Delete any default Windows user accounts provided by Radiant Systems or affiliated companies for use in initial configuration, page 45. Configure Aloha EDC to use an alternate path, outside the BootDrv share, by creating a new environment 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 on page 13 for information about how to disable this feature. Disable Remote Desktop in Windows. Refer to Configuring the Windows Network on page 13 for information about how to disable this feature.
Note: Not required for PCI DSS compliance, but recommended as a best practice.
Page 52
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 > POS Password Settings tab, page 31. Stop EDC event logging, in Maintenance > Store Settings > System group > Aloha Settings tab, page 35.
Page 53
Page 54
Data Encrypted
Employee passwords Payment card and cardholder data Employee passwords Payment card and cardholder data
Encryption Method
RSA MD5 128-bit encryption RSA MD5 128-bit encryption RSA MD5 128-bit encryption AES 256-bit encryption
Key Maintenance
Key management is automatic, taking place in the Aloha POS application, and in Aloha EDC, relieving site personnel of any key management requirements. All versions of the Aloha POS system, beginning with v6.0, fully encrypt the credit card track data using the encryption mechanism supported by the version in use. The application maintains all public keys associated with the encryption process; they are not published to the customer, and the customer is not required to manage key rotation. Because of the encryption techniques in place, and the dynamic method of key management performed by the Aloha application itself, there is no need for Aloha customers to manage encryption key rotation and disposal.
Communication Methods
Aloha communicates securely with processors using SSL/TLS. This communication is automatic, does not change, and is not within the control of users at any level.
Page 55
Figure 10 EDC Credit Card Data Flow Cashier swipes credit/debit card; Aloha encrypts data. Processor answers back to AlohaBOH (encrypted).
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. AlohaBOH settles with processor, creating .stl files (encrypted). Use secure deletion software to delete .stl files manually, in accordance with data retention policies.
BOH file server sends authorization request to processor (encrypted, using SSL).
Processor puts funds on hold to cover the transaction, or declines if funds are insufficient.
Page 56
Changes Made
Document released in draft. Document updated to reflect feedback from RAB and PAB members, and from an independent auditor. Document updated to include Appendix B, containing expanded information about cryptography used in the Aloha system. Clarified statements around maintaining installations at the latest version validated as PCI DSS and CISP compliant. Added section about purging the Windows Paging file (hyperlink to relevant section). Updated Figures 1, 3, 8, 10, and 12 to bring them into compliance with Aloha v6.2. Renumbered the document to v6.2. Modified Compliance Checklist to improve the appearance, and make it easier to use. 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 standards and practices. Modified Figure 3 to bring into compliance with v6.4. Added information about disabling Alt+x for earlier versions of Aloha, as contained in RKS 6298, page 29. Added Site Checklist. Renumbered the document to v6.4. Document completely rewritten, to convert from CISP Best Practices to POS Data Security Handbook. Updated document to reflect dual-level encryption built in to Aloha software, Quick Service and Table Service. Updated the document to reflect PCI DSS v1.2 revised standards. Updated the document to reflect correct references to PABP and PA DSS standards. 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 messages 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 prevents using the Keyboard Wedge Windows service, page 15. Added note indicating Aloha v6.4 removes security code, when collected, after authorization, page 21. Renumbered the document to v6.5 throughout, as appropriate. Updating the document to reflect this version.
1/21/2009
2/9/2009
Page 57
Revision Dates
11/20/2009 1/18/2010
Changes Made
Made minor verbiage changes for clarity, re. EDC version-independence. Made minor verbiage changes to sections relating to auto-logon.
Page 58