POS Data Security 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 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. Understanding the PCI DSS Requirements Tables The PCI DSS requirements contain detailed information about practices and considerations you need to use to establish a secure site. The tables in this guide serve as a springboard to help you comply with PCI DSS requirements, and in many cases to exceed these requirements. All sites and other applicable entities must comply with all PCI DSS requirements, whether they are listed in the tables in this section or not. The PCI DSS Requirements tables list only the requirements that relate directly to Aloha software products. Requirements not listed in the tables do Identifies places in the document where we discuss topics and configurations that relate to and directly address PCI DSS compliance requirements. Identifies places in the document where you can get tips on things you can easily do that make your site more secure than the basic PCI DSS requirements. These items are generally regarded as best practices. Requirement 1: Install and maintain a firewall configuration to protect cardholder data 1.1 Establish firewall and router configuration standards, as listed in the main PCI DSS requirements. You must establish a formal process for installing and configuring firewalls and routers to protect access from external networks, create and maintain a network diagram, and more. Compliance with this requirement does not specifically relate to the Aloha POS or associated applications. Configure the Windows network with firewalls, both software and hardware. 1.2 Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment. You must establish firewall and router protection between untrusted networks and the cardholder data environment. Compliance with this requirement does not specifically relate to the Aloha POS or associated applications. Install hardware firewalls between the Aloha network and any outside connections. Install a perimeter firewall between the wireless network and the Aloha network. 1.4 Install personal firewall software on any mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), which are used to access the organization s network. You must use a software firewall on any mobile or other employee device, to make its connection to the Aloha network secure. Analyze all laptops, tablet computers, or other devices employees intend to use for connecting to the network, and verify a software firewall is installed, active, and configured correctly to access the network in a secure manner. Quick Reference Guide v7.x
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters 2.1 Always change vendor-supplied defaults before installing a system on the network, including but not limited to passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts. You must change all vendor-supplied device names, user names, and passwords previously configured in file servers, terminals, routers, and other peripherals used in the Aloha network. This requirement includes any default device names, user names, and passwords configured in equipment purchased from Radiant Systems, such as file servers and terminals. Change all default device names, user names, and passwords previously configured in listed devices, prior to connecting them to the cardholder data network. Requirement 3: Protect Stored Cardholder Data 3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes. Establish policies minimizing the storage of cardholder data, and defining the quantity and method of data retention and disposal. Use configuration that enhances minimization of sensitive data storage. Create secure payment card tenders, minimizing storage of sensitive cardholder data. Securely delete files previously containing sensitive data. Securely delete files related to troubleshooting, after they are no longer needed. We suggest configuring the Aloha POS to suppress printing the cardholder name on payment card vouchers. 3.2 Do not store sensitive authentication data after authorization (even if encrypted) Do not store sensitive cardholder data after authorization is complete. By design, the Aloha POS and associated software satisfies this requirement by automatically deleting sensitive authentication data after authorization processes are complete. No manual configuration is necessary or possible. We suggest using Aloha CleanPAN to remove possible residual sensitive cardholder data. This is especially critical for older systems, using Aloha 5.3.15 or earlier. 3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed). Mask the PAN (primary account number) in all locations where it can display, and in all cases when it prints. By design, the Aloha POS and associated software satisfies this requirement by automatically masking the PAN. Only the last four digits are ever revealed in plane text. No manual configuration is necessary or possible. Use Security Roles to control access to PAN in the Audit report. Aloha automatically logs access to PAN any time it occurs. Create security roles based on need for access. data. Disable Windows print spooling, to prevent inadvertent storage of sensitive cardholder We suggest using Aloha CleanPAN to remove possible residual sensitive cardholder data. This is especially critical for older systems, using Aloha 5.3.15 or earlier.
3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the approaches listed in the main PCI DSS requirements. Use one-way hash or other cryptographic methods listed in the main PCI DSS requirements, to render the PAN unreadable, regardless of location or method of storage. By design, the Aloha POS and associated software satisfies this requirement by using strong encryption techniques to render the PAN unreadable, if stored. All instances of the PAN, when stored, are encrypted and unavailable for view. 3.5 Protect any keys used to secure cardholder data against disclosure and misuse. Prevent compromise of any manually created keys used to secure the Aloha network, or any part of it, including associated networks, such as wireless. By design, the Aloha POS and associated software satisfies this requirement by automatically managing primary encryption keys without requiring user intervention. The only manually created keys in the Aloha POS system are associated with the creation, configuration, and maintenance of wireless networks. 3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data, as listed in the main PCI DSS requirements. Key management processes and procedures must be formally established and completely documented. By design, the Aloha POS and associated software satisfies this requirement by automatically managing primary encryption keys without requiring user intervention. The only manually created keys in the Aloha POS system are associated with the creation, configuration, and maintenance of wireless networks. Requirement 4: Encrypt transmission of cardholder data across open, public networks 4.1 Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks. 4.2 Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.). Use SSL 3.0 for transmitting sensitive cardholder data to processors. By default, the Aloha POS and associated software uses strong encryption techniques to maximize security when sending data to and receiving it from the processors, as outlined in Appendix B: Aloha Cryptography on page 62. Always exercise great care to prevent any kind of transfer of PAN, or other sensitive cardholder data by any means other than standard, encrypted processes, as initiated by the Aloha POS. By default, the Aloha POS and associated software makes no use whatsoever of any kind of end-user messaging technologies. All sensitive cardholder data is encrypted, when read into the system, and remains in this state until deleted. If stored, the PAN is encrypted. Requirement 5: Use and regularly update anti-virus software or programs 5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers). Install industry standard, well respected antivirus software on the Aloha file server, and on all terminals. Install antivirus, per requirement. 5.2 Ensure that all anti-virus mechanisms are current, actively running, and generating audit logs. Establish a policy and a process for downloading antivirus updates, configuring these to occur automatically, if possible, and that periodic scans are also enabled and configured to run. Ensure that the antivirus is always actively running, and is generating audit logs. Establish a process for downloading antivirus updates frequently. Daily is not too often. Require someone in the organization to verify frequently that the antivirus is actually running and generating logs. Examine the antivirus audit logs on a frequent, regular basis to verify the program is adding new information constantly, and to identify threats dealt with.
Requirement 6: Develop and maintain secure systems and applications 6.1 Ensure that all system components and software are protected from known vulnerabilities by having the latest vendor-supplied security patches installed. Install critical security patches within one month of release. Locate and install all security patches and firmware updates available for every device used in the Aloha network. This process must include routers, physical firewall devices, wireless access points, computers, and any other type of device that may impinge upon maintaining the security of the Aloha network, and in particular the cardholder data environment. As part of your ongoing efforts to maintain a secure cardholder data environment, install all security updates and patches available. 6.2 Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities. List all devices and system components that may require periodic updates, and establish a process to look for program and security updates on a regular basis. Create a list of devices requiring periodic updates, and a plan for obtaining and installing all updates discovered. Requirements 6.3 through 6.6 These requirements are applicable only for custom software applications. If a site uses exclusively Aloha software products, these requirements are met automatically by the Aloha software PA-DSS validation status. Requirement 7: Restrict access to cardholder data by business need to know 7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access. Access limitations are listed in the main PCI DSS requirements. Document and implement an access control system based on granting the fewest privileges possible to user IDs based on role-based access control (RBAC). Specifically state the nature of access required for each role. Require written approval for this documentation. Create Security Roles beginning with zero permissions, and add only the permissions required for employees assigned to specific Security Roles to accomplish their jobs. 7.2 Establish an access control system for systems components with multiple users that restricts access based on a user s need to know, and is set to deny all unless specifically allowed. This access control system is detailed in the main PCI DSS requirements. Document and implement an access control system based on granting the fewest privileges possible to user IDs based on role-based access control (RBAC). Specifically state the nature of access required for each role. Require written approval for this documentation. Create Security Roles beginning with zero permissions, and add only the permissions required for employees assigned to specific Security Roles to accomplish their jobs. Requirement 8: Assign a unique ID to each person with computer access 8.1 Assign all users a unique ID before allowing them to access system components or cardholder data. Assign a unique ID to all users, both BOH and FOH, before allowing them to access the system. The Aloha system satisfies this requirement by assigning a unique ID to each new employee record you create. 8.2 In addition to assigning a unique ID, employ at least one of the methods listed in the main PCI DSS requirements, for authenticating all users. Requires the use of the typical forms of identification methods, in conjunction with the unique ID; something you know, something you have, or something you are. By default, the Aloha system satisfies this requirement by using passwords in conjunction with unique IDs for BOH or FOH access. Other methods of authentication are also available.
8.3 Incorporate two-factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties. (For example, remote authentication and dial-in service (RADIUS) with tokens; terminal access controller access control system (TACACS) with tokens; or other technologies that facilitate two-factor authentication). Verify two-factor authentication is in use for the Aloha system, and for remote access to the system, as well. Command Center and Secure Access provide secure remote application access. 8.4 Render all passwords unreadable during transmission and storage on all system components using strong cryptography. At no time should the application exposed passwords typed by employees as plain text. When stored, passwords must be secured with strong cryptography. The Aloha system satisfies this requirement by using strong cryptography when storing passwords. 8.5 Ensure proper user identification and authentication management for non-consumer users and administrators on all system components, as listed in the main PCI DSS requirements. Require proper management of user identification and authorization credentials for personnel accessing payment application software. Aloha software products automatically manages credentials for program access. Establish rules for access to Aloha software products with regard to employee access parameters, including password requirements, rotation, and expiration. Requirement 9: Restrict physical access to cardholder data 9.1 Through 9.10 Compliance with requirements within PCI DSS Requirement 9 involve activities and processes not related to Aloha software products. This document includes a very brief description of how to begin meeting these requirements. Refer to the main PCI DSS version 2.0 document, available from the PCI Security Standards Council. Requirement 10: Track and monitor all access to network resources and cardholder data Requirements 10.1 through 10.5, and requirement 10.7 Aloha software products satisfy these requirements by default behavior, with little or no possibility of configuration or modification. The areas requiring attention for these requirements are as follows: The Aloha system satisfies the requirement to log Aloha and EDC program activity automatically, without the ability to disable logging. Enable Windows audit logging, and configure it to record log-in and log-out events, and access events to directories related to Aloha software products. Some debugging information is configurable, but we recommend restricting the amount of information captured, except when actively troubleshooting site difficulties. 10.6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion-detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS). The Aloha system makes it easy for you to view log files from within the configuration management tool. Although you can view the contents of these files, they are not available for edit.
Requirement 11: Regularly test security systems and processes. Requirements 11.1 through 11.5 Compliance with requirements within PCI DSS Requirement 11 involve activities and processes not related to Aloha software products. This document provides a very brief description of how to begin meeting these requirements. Refer to the main PCI DSS version 2.0 document, available from the PCI Security Standards Council. Requirement 12: Maintain a policy that addresses information security for all personnel. Requirements 12.1 through 12.9. Compliance with requirements within PCI DSS Requirement 12 involve activities and processes not related to Aloha software products. Refer to the main PCI DSS version 2.0 document, available from the PCI Security Standards Council. A very brief description of how to begin meeting requirement 11 is included in this document.