Data Security Handbook. Point-of-Sale v6.5

Transcription

1 Data Security Handbook Point-of-Sale v6.5

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

3 POS v6.5 Data Security Handbook Last Modified 1/18/2010 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 Building and Maintaining a Secure Network Protecting Cardholder Data Maintaining a Vulnerability Management Program Implementing Strong Access Control Measures Monitoring and Testing Networks Regularly Maintaining an Information Security Policy Upgrading Client Accounts Working with Backup Files Safeguarding Cardholder Data After Upgrading Frequently Asked Questions General PCI DSS Information Aloha POS and PCI DSS Information Additional Resources Appendix A: PCI DSS Configuration and Site Compliance CheckLists PCI DSS Configuration Checklist Site Checklist for PCI DSS and FACTA Compliance Appendix B: Aloha Cryptography Appendix C: EDC Data Flow Feature History Page 3

4 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 SSC s approval or acceptance of a payment application or version thereof are strictly and actively prohibited by PCI SSC. When granted, PCI SSC acceptance is provided to ensure certain security and operational characteristics important to the achievement of PCI SSC s goals, but such acceptance does not under any circumstances include or imply any endorsement or warranty regarding the payment application vendor or the 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. POS v6.5 Data Security Handbook Page 4

5 The Purpose of This Document The Purpose of This Document Radiant Systems, Inc. provides this document for the purpose of helping its customers to configure the Aloha POS system for maximum security, and to help customers at the site level to comply with Payment Card 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 Aloha POS system, to reflect any changes occurring in the Aloha POS system. The Aloha POS Data Security Handbook receives an annual review, at minimum, to verify the document actually covers all software changes 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 of Payment Application Data Security Standards (PA DSS) in force at the time of the review. As new or modified 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, at the 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 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. Defining the PCI DSS Requirements The strategy for security in the electronic payment industry is undergoing rapid, dramatic changes in response to multiple factors, especially criminal activity related to electronic payments. Members of this industry are working in conjunction with legislatures at all levels to safeguard the environment in which electronic 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 these requirements, when configured correctly. It is the sincere aim of Radiant Systems, Inc. to offer this document to help resellers and merchants understand the nature of these requirements, and how best to configure and use the Aloha system to comply with these requirements What Are the PCI DSS Requirements, and Why Should I Care? The Payment Card Industry Data Security Standards (PCI DSS), as formulated by the Security Standards Council, are the standards by which payment card companies, such as Visa, American Express, Master- Card, and others, agree to measure the security of individual installations, and electronic payment software products, in an effort to protect cardholder data. Similarly, payment application manufacturers must adhere POS v6.5 Data Security Handbook Page 5

6 Defining the PCI DSS Requirements 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: pci_dss_download.html_agreement.html What are Best Practices? As you compare the contents of this document with the PCI DSS requirements, you will find that Radiant Systems is recommending more stringent security measures in several areas. In those instances, we feel that a more strict approach to system security will, in the long run, keep you and your customers safer, and will help you to avoid costly security breaches. We regard these differences between required minimums and recommended measures as part of what we call best practices, in that they will contribute even more to your overall data security without incurring unnecessary costs. We have attempted to make note of areas in which we differ with the PCI DSS requirements in our recommendations, but all may not be so noted. What Must I Do to Comply? The first and best step to data security compliance is to maintain your Aloha installation at the latest available version validated as meeting the applicable security standards. Radiant Systems, Inc. has validated Aloha version 6.5, through the use of an independent auditor, as being the latest version of Aloha to comply with the security standards current at the time of validation. This version provides industry-standard AES 256-bit encryption for data transfer across networks for transaction security, and includes security enhancements to the Aloha EDC payment application. Earlier versions of Aloha, beginning with , have also been validated. Radiant Systems will continue to validate versions of the Aloha software as they are developed and released, and recommends customers stay current as new versions become available. In addition to upgrading your software, you must ensure that your configuration complies with the suggestions presented in this document. A summary of the primary areas of concern is as follows: User IDs and passwords Verify that all users who have access to the Aloha network have unique user names and passwords, including their access to Windows, the Aloha system, both Back-of-House (BOH) and Front-of-House (FOH), and remote administration software, such as pcanywhere. Train users to log out of the Aloha BOH, and log out of Windows, when they are not using the system. Train FOH users to touch Exit as they finish using the terminals. Disable or clear any default users, passwords, and automatic logins provided by hardware or software vendors. Configure the system to automatically time out users due to inactivity, wherever possible. Dated subdirectories Use the DelTrack utility to remove credit card track information from any dated subdirectories retained at the time of upgrade. Two versions of this utility are available from the Radiant FTP site. Refer to Using the DelTrack Utility as Part of an Upgrade on page 40 for more information about how to use Deltrack, and how to obtain more information about the utility. Refer to Additional POS v6.5 Data Security Handbook Page 6

7 Defining the PCI DSS Requirements 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. 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 validated against the appropriate data security standards. As stated previously, however, security standards evolve over time. If you have already installed a validated version of Aloha, the security standards by which that version was validated will eventually become obsolete. Each security standard version has an expiration date, which determines the expiration date for software validated against it. POS v6.5 Data Security Handbook Page 7

8 Defining the PCI DSS Requirements 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: 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. POS v6.5 Data Security Handbook Page 8

9 Defining the PCI DSS Requirements Summarizing the PCI DSS Requirements The PCI DSS requirements contain detailed information about considerations necessary to establish a secure set of practices for protecting cardholder data at the restaurant level. The following table is a very general, high-level adaptation of the PCI DSS requirements, and is intended as a loose guide to the remainder of this document. PCI Data Security Requirement What this requirement means to you... How you can meet this requirement... Build and Maintain a Secure Network 1 Install and maintain a firewall, and configure it to protect cardholder data. Firewall configuration review is mandatory at intervals of six months or less. 2 Do not use vendor-supplied defaults for system passwords and other security parameters. Establish configuration standards for firewalls and routers, that deny access from untrusted sources, and prevent access to cardholder data. Configure firewalls to prevent connections between public servers and cardholder data, including wireless networks. Install an application layer firewall in front of Web-facing applications. Periodic vulnerability testing is a requirement. Change vendor-supplied default user names and passwords before connecting to the network. Encrypt all non-console administrative access. 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 requirement. Install firewall technology to protect any Web-based services, such as remote ordering systems. 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 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. POS v6.5 Data Security Handbook Page 9

10 Defining the PCI DSS Requirements PCI Data Security Requirement Protect Cardholder Data 3 Protect stored cardholder data. 4 Encrypt transmission of cardholder data across open, public networks. What this requirement means to you... Keep data storage to a minimum, and do not store sensitive data after authorization. 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. 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 i wherever possible. Never send unencrypted customer data by e- mail. How you can meet this requirement... Always upgrade to the latest version of Aloha validated against the applicable security standards. Configure Aloha per this document, to minimize data storage, and to encrypt cardholder data when stored short-term. 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 i. Constantly test your network to verify it is snooper free. Maintain a Vulnerability Management Program 5 Use and regularly update antivirus and antispyware software. Install a reputable antivirus program that is also capable of detecting and removing 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. As a best practice, we recommend immediate upgrade to the IEEE i standard. 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. POS v6.5 Data Security Handbook Page 10

11 Defining the PCI DSS Requirements PCI Data Security Requirement 6 Develop and maintain secure systems and applications. Implement Strong Access Control Measures 7 Restrict access to cardholder data by business need-to-know. 8 Assign a unique ID to each person with computer access. Store user passwords in an encrypted format. 9 Restrict physical access to cardholder data. Regularly Monitor and Test Networks 10 Track and monitor all access to network resources and cardholder data. What this requirement means to you... Obtain and install all operating system security patches and updates at least monthly. 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. Prevent unauthorized access to printed customer data records, such as receipts, and establish procedures, as laid out in the standards, for disposal. 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. How you can meet this requirement... Establish a schedule to obtain and install operating system updates for the server and the terminals. Use security policies that prevent unauthorized access, and provide physical access to the BOH file server only to employees who require it. Ensure authorized users have their own user name and expiring, complex password. Require the user name and password, plus other authentication method for remote access. 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-management employees, if possible. Establish offsite storage for 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. Activate this type of logging activity, which is built in to the Aloha system, in Aloha Manager. It is always active in EDC. POS v6.5 Data Security Handbook Page 11

12 Defining the PCI DSS Requirements PCI Data Security Requirement 11 Regularly test security systems and processes. What this requirement means to you... Perform regular security tests to expose vulnerabilities in systems and processes. How you can meet this requirement... Establish a schedule of physically 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. 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, and Internet usage, removable electronic media, laptops, or personal digital assistants (PDAs). Appendices Additional Requirements A PCI DSS Applicability for Hosting Providers Hosting providers protect cardholder data environment. B 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. You must undergo a PCI security scan by an Approved Scanning Vendor (ASV) on a quarterly basis. 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 or Internet access. Ask your hosting providers about the measures they take to protect cardholder data. 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. POS v6.5 Data Security Handbook Page 12

13 Complying with the PCI DSS Requirements Complying with the PCI DSS Requirements Making use of the inherent capabilities of the Aloha applications are the primary focus of compliance with the PCI DSS data security requirements. Radiant Systems, Inc. has enhanced and maintained these applications to make them more secure, bringing them into compliance with these security requirements, and continues to explore new ways to enhance data security. Merchant certification, however, involves configuration at corporate and site levels. The majority of this document discusses how to configure the Aloha system for compliance at the site level. Beginning with Aloha EDC versions 6.4 and later, EDC adopted a policy of assured backwards compatibility with Aloha POS versions and later, and later, and and later. Generally speaking, you can upgrade to a newer version of EDC to take advantage of new features, and to comply with new processor requirements, without having to upgrade the POS. However, some new features require an upgrade to both the EDC and POS products. Refer to RKS document for more information about features requiring dual upgrades. Although you must upgrade your HASP key to Aloha v6.7 to run Aloha EDC v6.7, this change in license status does not require you to upgrade the POS to Aloha v6.7. This section discusses general topics that will help you understand the PCI Data Security Standards, and how you can begin the task of configuring your Aloha system for data security and site compliance. Segment topics roughly correspond to the six main PCI DSS topic areas, to help you organize your compliance strategy. Building and Maintaining a Secure Network The Aloha system installs and runs within the environment defined by Windows. The Aloha network also depends on the networking settings established in Windows. Although a comprehensive discussion of networking is beyond the scope of this document, you can perform specific changes that will increase the security of your network, as discussed in this section. To protect sensitive data from external intrusion, you should design and configure your network to be as secure as possible. The characteristics of a secure network include, but are not limited to, the following: Configuring the Windows Network Install an up to date operating system on all computers in the Aloha network, such as Windows 2000, Windows XP, or Windows 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. POS v6.5 Data Security Handbook Page 13

14 Complying with the PCI DSS Requirements Remember to change any vendor-supplied passwords with your own, using practices outlined in this document. Search for and change other default security parameters, as well, such as default port assignments. Use standard user name and complex password procedures to log in to the Aloha BOH file server. Do not, under any circumstances, use auto-logon to access this computer. Refer to Managing Windows Auto-Logon on page 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:\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 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. POS v6.5 Data Security Handbook Page 14

15 Complying with the PCI DSS Requirements 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 i, 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 Windows 2003 Server, disabling Stop message at shutdown, Microsoft Knowledge Base article number Windows XP, how to clear the paging file at shutdown, Microsoft Knowledge Base article number Windows 2000, how to clear the paging file at shutdown, Microsoft Knowledge Base article number 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. 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 conjunction 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. POS v6.5 Data Security Handbook Page 15

16 Complying with the PCI DSS Requirements 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. Prohibited Communication Technologies It is important to understand that Aloha uses fully encrypted technology for communication with processors. At no point does Aloha use end-user methods of communication, such as , 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 communication 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 processing outside the established Iberdir path, by using a new environment variable, EDCProcPath. This change affords more data security and customer protection by moving non-temporary files related to transaction authorizations and settlements outside the Bootdrv share currently used by the Aloha system. Data not stored within the shared file structure is much less likely to be available to anyone entering the system from an external location. You can configure Windows and the Aloha system together to permit only the system administrator access to these files. Beginning with version 6.4, Aloha EDC is version independent of Aloha Quick Service or Table Service. EDC v6.4 and later require Aloha v6.1 or later. Although you must upgrade your HASP key to Aloha v6.5 to run Aloha EDC v6.5, this change in license status does not require you to upgrade the POS to Aloha v6.5. POS v6.5 Data Security Handbook Page 16

17 Complying with the PCI DSS Requirements 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. Implementing 128-bit Encryption in Aloha Installations Beginning with version 6.0, the Aloha system supports industry-standard 128-bit encryption, at minimum, as implemented in all recent, properly maintained Windows operating systems. The Aloha system checks for the presence of the required system libraries that provide 128-bit encryption routines. If these system libraries are not present, any Aloha program component attempting to launch shuts down. This behavior includes the installation process. If you upgrade Windows 2000, XP, or Windows Server 2003 to include all available service packs and security patches, and upgrade Windows Explorer to v6.0, this process upgrades all encryption libraries. POS v6.5 Data Security Handbook Page 17

18 Complying with the PCI DSS Requirements 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. Configuring Aloha for Audit Report Security The Audit report, in Quick Service and Table Service, can display or mask credit card numbers and expiration dates, beginning with Aloha v6.4. Upon upgrade, the system disables access to credit card numbers and expiration dates in the Audit report for all employees, to prevent unauthorized access to cardholder data. We recommend re-enabling this access only in the security level assigned to the most trusted employees, in Maintenance > Labor > Back Office Security Levels. You can find this function by selecting Reprint > Audits > Display Credit/Debit Card Numbers, in the Functions column. Select the security level ID to which you want to give permission for this function, and then select Run and Save. At the next data refresh, employees assigned to this security level can view credit or debit card numbers and expiration dates in the Audit report. When an employee accesses credit card information in the audit report, Aloha details this activity in a message inserted in Debout.txt. All other employees with access to the Audit report see these numbers in masked format. Figure 1 Back Office Security Levels, Audit Report Permission Configuration 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. POS v6.5 Data Security Handbook Page 18

19 Complying with the PCI DSS Requirements Protecting Wireless Transmissions Aloha applications, beginning with version 6.0, make use of at least 128-bit encryption for all forms of wireless data transfer between handheld devices, FOH terminals, and the BOH file server. As technology advances, wireless devices will proliferate in the restaurant environment, and the opportunities for data fraud will increase accordingly. If you must include a wireless network as part of the Aloha network, purchase commercial grade Access Points (AP) that use the IEEE i security standard, and secure the network with a password and encryption key. Do not purchase wireless equipment that is only capable of using the WEP security standard, as this standard is no longer secure in the current wireless environment. You must also install a perimeter firewall between any wireless network and the environment in which cardholder data is managed or stored. You must configure the firewall to deny or appropriately control any traffic from the wireless environment into the cardholder data environment. Allowing an unencrypted wireless network is a critical security violation, surpassed only by placing the Aloha file server directly on the Internet without a firewall. You must avoid an unencrypted configuration, as it dramatically increases the possibility of unauthorized file access by intruders. If the restaurant wishes to provide wireless access to customers, install an isolated wireless access point (AP), configured outside the Aloha network, thus preventing customers from reaching the Aloha BOH server or the FOH terminals. As a best practice, you should also use sensing software, such as NetStumbler, to detect other wireless networks active in your immediate area, and select a relatively unused channel for your own network. Sensing software will also help you to detect other access points brought in to your restaurant for the purpose of joining your Aloha network. NetStumbler is only one of several excellent sensing products available. You can download a trial version of NetStumbler from the following Internet address. 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. Wireless Key Management Wireless encryption keys require management for secure network operation. The following guidelines are PCI 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. POS v6.5 Data Security Handbook Page 19

20 Complying with the PCI DSS Requirements 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. Daily Operational Considerations Networks in constant daily use experience risks inherent to the types of activities involved. One area of risk that we often overlook has to do with our daily habits. This section discusses some of the things we can concentrate on, on a daily basis, to enhance the security of our networks. Facilitating Secure Remote Software Updates When sites find it necessary to download software updates, a different kind of vulnerability comes into play, the external connection itself. If you are using a modem, or if you have broadband Internet access that is on all the time, these can provide unwanted avenues through which unauthorized access can occur. As a best practice, we recommend turning the power off to modems or Internet connectivity devices (e.g. DSL or other Ethernet appliances) when they are not in use, to effectively shut the door on potential external threats. Only leave the power on to devices you are actively using for credit card authorization and settlement. 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 encryption. If the Aloha installation does not proceed on one or more computers in your network, we recommend you verify the operating system on those computers is completely up to date. Systems running Windows 2000, XP, or 2003 Server, with all service packs and updates installed, and running Microsoft Internet Explorer, version 6.0 or later are, by definition, running an appropriate level of encryption. Install Internet Explorer, v6.0 on any computers still exhibiting installation problems related to encryption issues. POS v6.5 Data Security Handbook Page 20

21 Complying with the PCI DSS Requirements 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. Encrypting all Non-Console Administrative Access We strongly recommend that you do not use Telnet or rlogin for remote administration of Aloha networks. Use SSH or SSL/TLS, or other non-console access. Protecting Cardholder Data The primary target of thieves is the data stored in the magnetic stripe on the back of most credit cards. As technology advances, the contents of other storage media embedded in payment cards will become targets, as well. Technicians and database configuration specialists must take steps to prevent storage of data extracted from payment cards, even if encrypted, after authorization is complete. Configure the Aloha system to prevent storage of this information wherever possible. When you configure the Aloha system as recommended in this section, the system encrypts and stores track information in the Trans.log file while authorizations are in progress. After completing card authorizations, Aloha removes track and security code information from the files in an irrecoverable manner. Creating Secure Card Tenders When you create credit card tenders, there are specific options you can use to enhance the security of your operations, one of which is mandated by U.S. Federal law. In Aloha Manager, select Maintenance > Payments > Tenders > Type tab to access these options. Figure 2 Tender Maintenance, Type Tab POS v6.5 Data Security Handbook Page 21