Aloha POSv12.3 Data Security Implementation Guide

NCR Aloha Suite Data
Security v12.3
Implementation Guide
Use with CFC and new Aloha Manager
Copyright
Copyright © 2014, NCR Corporation - All rights reserved. The information contained in this publication is confi-
dential 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
NCR Corporation.
NCR Corporation is not responsible for any technical inaccuracies or typographical errors contained in this publi-
cation. Changes are periodically made to the information herein; these changes will be incorporated in new edi-
tions 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.
POS Data Security
Handbook
Implementation Guide
Table of Contents
Introduction
Using This Guide to Meet PCI Requirements..................................................................... 1-1
Build and Maintain a Secure Network.................................................................... 1-12
Protect Cardholder Data ..................................................................................... 1-22
Maintain a Vulnerability Management Program....................................................... 1-27
Implement Strong Access Control Measures .......................................................... 1-28
Regularly Monitor and Test Networks.................................................................... 1-37
Maintain an Information Security Policy ................................................................ 1-41
Upgrading Client Accounts.................................................................................................. 2-1
Working with Backup Files ....................................................................................2-3
Safeguarding Cardholder Data After Upgrading ........................................................2-3
Using the CleanPAN Utility as Part of an Upgrade .....................................................2-4
Frequently Asked Questions ............................................................................................... 3-1
General PCI DSS Information ................................................................................3-3
NCR Aloha Suite and PCI DSS Information ..............................................................3-7
Additional Resources .......................................................................................... 3-10
PCI DSS Configuration Checklists ......................................................................................A-1
Aloha Cryptography .............................................................................................................B-1
EDC Data Flow ......................................................................................................................C-1
Aloha Log Files, Locations, and Contexts .........................................................................D-1
Aloha File Structure..............................................................................................................E-1
Aloha Point-to-Point Encryption ......................................................................................... F-1
POS DSHB v12.3 Implementation Guide iii

iv POS DSHB v12.3 Implementation Guide
Introduction
Acceptance of a given payment application by the PCI Security Standards Council, LLC (PCI SSC) only
applies to the specific version of that payment application that was reviewed by a PA-QSA and subse-
quently accepted by PCI SSC (the “Accepted Version”). If any aspect of a payment application or ver-
sion 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 characteris-
tics important to the achievement of PCI SSC’s goals, but such acceptance does not under any circum-
stances 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 lim-
itation, 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 DSHB v12.3 Implementation Guide Introduction v

The Purpose of This Document
NCR provides this document for the purpose of helping its customers to configure the NCR Aloha Suite
for maximum security, and to help customers at the site level to comply with Payment Card Industry
Data Security Standards (PCI DSS) requirements. Consider this document as the data security imple-
mentation guide for installations using Aloha Quick Service or Aloha Table Service.
Document Publication and Update Frequency

NCR creates a new version of this document as a companion for each new major version of the NCR
Aloha Suite, to reflect any changes occurring in the Aloha system. The Aloha Data Security Implemen-
tation Guide receives an annual review, at minimum, to verify the document actually covers all recent
security-related software changes taking place in Quick Service, Table Service, or Electronic Data Cap-
ture.
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 date on page three, above the Table
of Contents, to indicate the date of the revision. The Feature History table, at the end of the document,
provides information about 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 NCR team. Copies of this document relating to versions of Aloha that are not offi-
cially 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 NCR 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 the NCR Aloha Suite as conforming to these require-
ments, when configured correctly. It is the sincere aim of NCR 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.
Operating System Validation

The NCR Aloha Suite supports many different combinations of operating systems. For the Aloha Suite
12.3 PA-DSS validation XP Pro and W7 (64 bit) were validated on the BOH and XPe was validated on the
FOH. While not every supported operating system was validated, there is essentially no difference from
one supported operating system to another how Aloha Suite functions.
Please see RKS documents 10485 and 10486 for supported operating systems.
vi POS DSHB v12.3 Implementation Guide

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 Stan-
dards 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 pay-
ment software products, in an effort to protect cardholder data. Similarly, payment application manu-
facturers 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 recommenda-
tions put cardholder data at risk, and also risk incurring sizable fines.
Version 2.0 of the PCI DSS requirements, the most recent version, is available in its entirety
for download in PDF format at the following URL:
https://www.pcisecuritystandards.org/
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. NCR Corporation has validated
Aloha version 12.3, 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
5.3.15, have also been validated. NCR Corporation will continue to validate versions of the Aloha soft-
ware as they are developed and released, and recommends customers stay current as new versions
become available.
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 stan-
dards evolve over time. If you have already installed a validated version of Aloha, the security stan-
dards 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.
Several versions of Aloha have been validated against different versions of security standards, as pub-
lished 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:
ATPs://www.pcisecuritystandards.org/sclerodermatitides/pa_dss.shtml
Refer to the table on page 3-8, in the Frequently Asked Questions section of this document,
for more information about validated versions of Aloha, and their respective expiration dates.
POS DSHB v12.3 Implementation Guide vii

When you upgrade Aloha to v6.4 or later, the upgrade process automatically changes specific settings
that relate to credit card masking and expiration dates, to comply with the Fair and Accurate Credit
Transaction Act (FACTA) and PCI DSS. We recommend you verify the success of these changes observa-
tionally. This change was also ‘backed’ into Aloha v6.1.19 and later, and Aloha v6.2.8 and later.
What Is the NCR Aloha Suite Version

Numbering Strategy?
Starting in January, 2012 the NCR Aloha Suite solution began using a common version numbering strat-
egy! This is just one small step Product Development is taking to reduce the complexity of our solution.
Ultimately, our goal is to provide more consistency and standardization across modules.
Going forward, the following Aloha products will use the new version numbering strategy:
• Aloha Update
• Aloha Configuration Center
• Aloha Electronic Draft Capture
• Aloha Order Point
• Aloha Point-of-Sale
Breakdown of New Version Numbers

The breakdown of the new version numbers is: [Year. Release. Point Update. Build] = 12.3.0.123
Year Last two digits of the calendar year

Release Release number of that year for that module.
Point Update Update to the release.
Build Referenced build number (usually internal use only).
Please be aware that an upgrade to the security key is required before upgrading or installing NCR
Aloha Suite v12.3.
viii POS DSHB v12.3 Implementation Guide

1
Using This Guide
to Meet PCI
Requirements
Build and Maintain a Secure Network.................................................................... 1-12

Requirement 1: Install and maintain a firewall configuration to protect cardholder data.1-
12
Requirement 2: Do not use vendor-supplied defaults for security parameters. ......... 1-19
Protect Cardholder Data ..................................................................................... 1-22
Requirement 3: Protect Stored Cardholder Data .................................................. 1-22
Requirement 4: Encrypt transmission of cardholder data across open, public networks. 1-
26
Maintain a Vulnerability Management Program....................................................... 1-27
Requirement 5: Use and regularly update anti-virus software or programs. ............. 1-27
Requirement 6: Develop and maintain secure systems and applications.................. 1-27
Implement Strong Access Control Measures .......................................................... 1-28
Requirement 7: Restrict access to cardholder data by business need to know. ......... 1-28
Requirement 8: Assign a unique ID to each person with computer access. .............. 1-28
Requirement 9: Restrict physical access to cardholder data................................... 1-34
Regularly Monitor and Test Networks.................................................................... 1-36
Requirement 10: Track and monitor all access to network resources and cardholder data.
1-36
Requirement 11: Regularly test security systems and processes. ........................... 1-38
Maintain an Information Security Policy ................................................................ 1-39
Requirement 12: Maintain a policy that addresses information security for all personnel.1-
39
POS DSHB v12.3 Implementation Guide Using This Guide to Meet PCI Requirements 1 - 1
1 - 2 Using This Guide to Meet PCI Requirements POS DSHB v12.3 Implementation Guide
The PCI DSS requirements contain detailed information about practices and considerations you need to
use to establish a secure site. The tables in this section serve as a springboard to the remainder of this
document, to help you comply with PCI DSS requirements, and in many cases to exceed these require-
ments.
We use two images in these tables to help you identify the types of help available in this document:
Identifies links you can use to access places in the document where we discuss topics and con-
figurations that relate to and directly address PCI DSS compliance requirements.
Identifies links you can use to access 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.’
If you are viewing this document in PDF format, you can quickly navigate back to your original
starting point in the tables, or any previous location, by holding down the left Alt key on the
keyboard, and pressing the left arrow key.
Understanding the PCI DSS Requirements Tables

The tables in this section, and the links within them, are not intended as a substitute for reading this
document. We recommend a thorough familiarization with the contents of this Guide, for the proper
implementation of data security using the NCR Aloha Suite.
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 not relate
directly to Aloha software products, or their configuration. Omission of these requirements is not
intended to imply that sites or other entities are not required to comply with these requirements.
Build and Maintain a Secure Network
Requirement Requirement Summary, and Links
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
1.1 Establish firewall and You must establish a formal process for installing and configuring firewalls and
router configuration stan- routers to protect access from external networks, create and maintain a network
dards, as listed in the diagram, and more. Compliance with this requirement does not specifically relate
main PCI DSS require- to the NCR Aloha Suite or associated applications.
ments. Configure the Windows network with firewalls, both software and hard-
ware.
1.2 Build firewall and You must establish firewall and router protection between untrusted networks
router configurations that and the cardholder data environment. Compliance with this requirement does
restrict connections not specifically relate to the NCR Aloha Suite or associated applications.
between untrusted net- Install hardware firewalls between the Aloha network and any outside
works and any system connections.
components in the card-
holder data environment. Install a perimeter firewall between the wireless network and the Aloha
network.
1.4 Install personal fire- You must use a software firewall on any mobile or other employee device, to
wall software on any make its connection to the Aloha network secure.
mobile and/or employee- Analyze all laptops, tablet computers, or other devices employees
owned computers with intend to use for connecting to the network, and verify a software fire-
direct connectivity to the wall is installed, active, and configured correctly to access the network
Internet (for example, in a secure manner.
laptops used by employ-
ees), which are used to
access the organization’s
network.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security
parameters
2.1 Always change ven- You must change all vendor-supplied device names, user names, and passwords
dor-supplied defaults previously configured in file servers, terminals, routers, and other peripherals
before installing a system used in the Aloha network. This requirement includes any default device names,
on the network, including user names, and passwords configured in equipment purchased from NCR Cor-
but not limited to pass- poration, such as file servers and terminals.
words, simple network Change all default device names, user names, and passwords previ-
management protocol ously configured in listed devices, prior to connecting them to the card-
(SNMP) community holder data network.
strings, and elimination
of unnecessary accounts.
Protect Stored Cardholder Data
Requirement 3: Protect Stored Cardholder Data
3.1 Keep cardholder data Establish policies minimizing the storage of cardholder data, and defining the
storage to a minimum by quantity and method of data retention and disposal. Use configuration that
implementing data reten- enhances minimization of sensitive data storage.
tion and disposal policies, Create secure payment card tenders, minimizing storage of sensitive
procedures and pro- cardholder data.
cesses.
Securely delete files previously containing sensitive data.
Securely delete files related to troubleshooting, after they are no lon-

ger needed.
We suggest configuring the NCR Aloha Suite to suppress printing the

cardholder name on payment card vouchers.
3.2 Do not store sensitive Do not store sensitive cardholder data after authorization is complete.
authentication data after By design, the NCR Aloha Suite and associated software satisfies this
authorization (even if requirement by automatically deleting sensitive authentication data
encrypted). 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 dis- Mask the PAN (primary account number) in all locations where it can display, and
played (the first six and in all cases when it prints.
last four digits are the By design, the NCR Aloha Suite and associated software satisfies this
maximum number of dig- requirement by automatically masking the PAN. Only the last four digits
its to be displayed). 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.
Disable Windows print spooling, to prevent inadvertent storage of sen-
sitive cardholder data.
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 unread- Use one-way hash or other cryptographic methods listed in the main PCI DSS
able anywhere it is stored requirements, to render the PAN unreadable, regardless of location or method of
(including on portable storage.
digital media, backup By design, the NCR Aloha Suite and associated software satisfies this
media, and in logs) by requirement by using strong encryption techniques to render the PAN
using any of the unreadable, if stored. All instances of the PAN, when stored, are
approaches listed in the encrypted and unavailable for view.
main PCI DSS require-
ments.
3.5 Protect any keys used Prevent compromise of any manually created keys used to secure the Aloha net-
to secure cardholder data work, or any part of it, including associated networks, such as wireless.
against disclosure and By design, the NCR Aloha Suite and associated software satisfies this
misuse. requirement by automatically managing primary encryption keys with-
out requiring user intervention. The only manually created keys in the
NCR Aloha Suite are associated with the creation, configuration, and
maintenance of wireless networks.
3.6 Fully document and Key management processes and procedures must be formally established and
implement all key-man- completely documented.
agement processes and By design, the NCR Aloha Suite and associated software satisfies this
procedures for cryp- requirement by automatically managing primary encryption keys with-
tographic keys used for out requiring user intervention. The only manually created keys in the
encryption of cardholder NCR Aloha Suite are associated with the creation, configuration, and
data, as listed in the maintenance of wireless networks.
main PCI DSS require-
ments.

Requirement 4: Encrypt transmission of cardholder data across open, public networks
4.1 Use strong cryptogra- Use SSL 3.0 for transmitting sensitive cardholder data to processors.
phy and security proto- By default, the NCR Aloha Suite and associated software uses strong
cols (for example, SSL/ encryption techniques to maximize security when sending data to and
TLS, IPSEC, SSH, etc.) to receiving it from the processors, as outlined in “Aloha Cryptography” on
safeguard sensitive card- page B-1.
holder data during trans-
mission over open, public
networks.
4.2 Never send unpro- Always exercise great care to prevent any kind of transfer of PAN, or other sensi-
tected PANs by end-user tive cardholder data by any means other than standard, encrypted processes, as
messaging technologies initiated by the NCR Aloha Suite.
(for example, e-mail, By default, the NCR Aloha Suite and associated software makes no use
instant messaging, chat, whatsoever of any kind of end-user messaging technologies. All sensi-
etc.). tive cardholder data is encrypted, when read into the system, and
remains in this state until deleted. If stored, the PAN is encrypted.
Maintain a Vulnerability Management Program
Requirement 5: Use and regularly update anti-virus software or programs
5.1 Deploy anti-virus Install industry standard, well respected antivirus software on the Aloha file
software on all systems server, and on all terminals.
commonly affected by Install antivirus, per requirement.
malicious software (par-
ticularly personal com-
puters and servers).
5.2 Ensure that all anti- Establish a policy and a process for downloading antivirus updates, configuring
virus mechanisms are these to occur automatically, if possible, and that periodic scans are also enabled
current, actively run- and configured to run. Ensure that the antivirus is always actively running, and is
ning, and generating generating audit logs.
audit logs. Establish a process for downloading antivirus updates frequently. Daily
is not too often. Require someone in the organization to verify fre-
quently 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 sys- Locate and install all security patches and firmware updates available for every
tem components and device used in the Aloha network. This process must include routers, physical
software are protected firewall devices, wireless access points, computers, and any other type of device
from known vulnerabili- that may impinge upon maintaining the security of the Aloha network, and in
ties by having the latest particular the cardholder data environment.
vendor-supplied security As part of your ongoing efforts to maintain a secure cardholder data
patches installed. Install environment, install all security updates and patches available.
critical security patches
within one month of
release.
6.2 Establish a process to List all devices and system components that may require periodic updates, and
identify and assign a risk establish a process to look for program and security updates on a regular basis.
ranking to newly discov- Create a list of devices requiring periodic updates, and a plan for
ered security vulnerabili- obtaining and installing all updates discovered.
ties.
Requirements 6.3 These requirements are applicable only for custom software applications. If a site
through 6.6 uses exclusively Aloha software products, these requirements are met automati-
cally by the Aloha software PA-DSS validation status.
Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need to know
7.1 Limit access to sys- Document and implement an access control system based on granting the fewest
tem components and privileges possible to user IDs based on role-based access control (RBAC). Spe-
cardholder data to only cifically state the nature of access required for each role. Require written
those individuals whose approval for this documentation.
job requires such access. Create Security Roles beginning with zero permissions, and add only
Access limitations are the permissions required for employees assigned to specific Security
listed in the main PCI Roles to accomplish their jobs.
DSS requirements.
7.2 Establish an access Establish a permissions-based system for controlling access to data and program
control system for sys- configuration elements that begins with denying all access. Add access, based on
tems components with the needs of the user.
multiple users that Use the Security Role feature to control access to data and program
restricts access based on features.
a user’s need to know,
and is set to “deny all”
unless specifically
allowed. This access con-
trol system is detailed in
the main PCI DSS
requirements.
Requirement 8: Assign a unique ID to each person with computer access
8.1 Assign all users a Assign a unique ID to all users, both BOH and FOH, before allowing them to
unique ID before allowing access the system.
them to access system The Aloha system satisfies this requirement by assigning a unique ID to
components or card- each new employee record you create.
holder data.
8.2 In addition to assign- Requires the use of the typical forms of identification methods, in conjunction
ing a unique ID, employ with the unique ID; something you know, something you have, or something you
at least one of the meth- are.
ods listed in the main PCI By default, the Aloha system satisfies this requirement by using pass-
DSS requirements, for words in conjunction with unique IDs for BOH or FOH access. Other
authenticating all users. methods of authentication are also available.
8.3 Incorporate two-fac- Verify two-factor authentication is in use for the Aloha system, and for remote
tor authentication for access to the system, as well.
remote access (network- Command Center and Secure Access provide secure remote application
level access originating access.
from outside the net-
work) to the network by
employees, administra-
tors, 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 technol-
ogies that facilitate two-
factor authentication).
8.4 Render all passwords At no time should the application exposed passwords typed by employees as
unreadable during trans- plain text. When stored, passwords must be secured with strong cryptography.
mission and storage on The Aloha system satisfies this requirement by using strong cryptogra-
all system components phy when storing passwords.
using strong cryptogra-
phy.
8.5 Ensure proper user Require proper management of user identification and authorization credentials
identification and authen- for personnel accessing payment application software.
tication management for Aloha software products automatically manages credentials for pro-
non-consumer users and gram access.
administrators on all sys-
tem components, as Establish rules for access to Aloha software products with regard to
listed in the main PCI employee access parameters, including password requirements, rota-
DSS requirements. tion, 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.
Regularly Monitor and Test Networks
Requirement 10: Track and monitor all access to network resources and cardholder data
Requirements 10.1 Aloha software products satisfy these requirements by default behavior, with lit-
through 10.5, and tle or no possibility of configuration or modification. The areas requiring attention
requirement 10.7 for these requirements are as follows:
The Aloha system satisfies the requirement to log Aloha and EDC pro-
gram 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 The Aloha system makes it easy for you to view log files from within the
system components at configuration management tool. Although you can view the contents of
least daily. Log reviews these files, they are not available for edit.
must include those serv-
ers that perform security
functions like intrusion-
detection system (IDS)
and authentication,
authorization, and
accounting protocol
(AAA) servers (for exam-
ple, RADIUS).
Requirement 11: Regularly test security systems and processes.
Requirements 11.1 Compliance with requirements within PCI DSS Requirement 11 involve activities
through 11.5 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.
Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security for all personnel.
Requirements 12.1 Compliance with requirements within PCI DSS Requirement 12 involve activities
through 12.9. 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 doc-
ument.
Build and Maintain 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.
Requirement 1: Install and maintain a firewall

configuration to protect cardholder data.
To protect sensitive data from external intrusion, you should design and configure your network to be
as secure as possible. This configuration includes installing and maintaining the firewall, but also
involves numerous other changes that will make the network much more secure, after completion. 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
XP, or Windows Server 2003.
• Establish a network firewall that includes a firewall device, such as a router, between the Aloha
network and the Internet. Install firewall software on each computer in the network, or enable
and configure the Windows firewall.
• Install an application firewall in front of any Web-facing applications hosted at the site.
• Establish a routine to search for and install firmware or software updates to your firewall
defenses, as they become available.
• Establish a routine to search for service packs and security patches for the operating systems in
use in your network on a regular basis. Download and install them, as soon as they are avail-
able. If you are using Windows XP or later, configure Automatic Updates, in Control Panel, to
automatically download and install updates as they become available. To avoid slowing network
performance, schedule the updates to occur at a time when business is slow. Remember to
change any vendor-supplied passwords with your own, using practices outlined in this docu-
ment. Search for and change other default security parameters, as well, such as default port
assignments.
• Enable only required services. These include services required by NCR Aloha Suite and other
NCR applications, as well as Windows services. Environments are different based on system
components and configuration. There are basic Windows services required for all environments
not related to any NCR applications. The table below lists application specific services and their
Windows dependences but is not a complete list of required services for Windows to function.
Once you have identified all required services on your system, disable the remaining services.
Windows
Service Products BOH FOH Notes
Service
CtlSvr NCR Aloha Suite x
RfsSvr NCR Aloha Suite x
EdcSvr NCR Aloha Suite x
AeMInStoreService NCR Aloha Suite x
AlohaAlertEngine NCR Aloha Suite x x
AlAdmSvr NCR Aloha Suite x Radiant Auto Loader (RAL)
Radiant Takeout and NCR Aloha Takeout x
Delivery
Radiant Takeout Ser- NCR Aloha Takeout x
vice Monitor
Radiant Online Site NCR Aloha Online x
Agent Service Site Agent
Aloha Kitchen Service NCR Aloha Kitchen x
Radiant Command NCR Command Cen- x x
Center Agent ter, NCR Aloha
Online Site Agent
Radiant Command NCR Command Cen- x x
Center Service ter
Watcher Service
Radiant Support Man- NCR Command Cen- x x
ager ter, NCR Aloha
Online Site Agent
Radiant Heartbeat NCR Command Cen- x
ter, NCR Aloha
Restaurant Guard
Pvnc NCR Command Cen- x x
ter
Aloha Enterprise NCR Aloha Insight x
Redirector Service
Aloha FTP NCR Aloha Insight x
Pollcheck NCR Aloha Restau- x
rant Guard
Stored Value BOH NCR Aloha Stored x
Service Value
Stored Value Update NCR Aloha Stored x
Service Value
Aloha Guest Manager NCR Aloha Guest x
Device Host Manager
Aloha GuestManager NCR Aloha Guest x
File Services Manager
AtgService NCR Aloha Transac- x
tion Gateway
AtgHelper NCR Aloha Transac- x x
tion Gateway
P15xxStats Radiant hardware x
Windows
Service Products BOH FOH Notes
Service
P15xx MSR Keyboard Radiant hardware x Will not be present on any hard-
ware running Gen 3 driver set
(P1230, P1515, P1560) and will
be removed if using a Radiant
Encrypted MSR (EMSR) with a
Gen 2 driver set (P1220, P1510,
P1550, P1520) or if you selected
Radiant as the MSR type.
ICD Service Radiant ICD hard- x
ware
HASP License Man- NCR Aloha Suite x HASP keys
ager
Cryptographic Service NCR Aloha Suite x x x
DCOM Service Pro- NCR Aloha Suite x x x
cess Launcher
Event Log x x x Windows events for audit log-
ging
Remote Procedure NCR Aloha Suite x x x
Call (RPC)
Print Spooler NCR Aloha Suite x x
SQL Server (SQLEX- NCR Aloha Suite x x
PRESS)
Message Queuing NCR Aloha Suite x x Used with OrderPoint
Message Queuing NCR Aloha Suite x x Used with OrderPoint
Triggers
Distributed Transac- NCR Aloha Suite x x Used with OrderPoint
tion Coordinator
FPSSRVR Radiant hardware x Used with Fingerprint scanner
(FPS)
MenuLink Verifone NCR MenuLink x Used with MenuLink when a site
Synchronization is clock in/out via a VeriFone
separately from the POS.
We suggest disabling the following services: FTP Publishing, HTTP SSL, IIS Admin, Indexing
Service, Internet Authentication, Microsoft POP3, Network New Transfer Protocol, Remote
Registry, Simple Mail Transfer Protocol, Simple Network Management Protocol, SSDP Discov-
ery Service (required for Windows 7 and higher), System Restore, Telnet, Universal Plug and
Play Device Host (required for Windows 7 and higher), Wireless Zero Configuration (unless
wireless communication is used)
• Use standard user name and complex password procedures to log in to the Aloha file server. Do
not, under any circumstances, use ‘auto-logon’ to access this computer. Refer to “Managing
Windows Auto-Logon” on page 1-28 for more information about how to disable and remove
auto-logon, if you have used it at any time on your Aloha 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 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 the configuration management tool (New Aloha Manager or Configuration
Center) and EDC.
• Configure the file permissions for the folder shared as BootDrv, on the Aloha file server, to per-
mit access only to specific users, controlling this access primarily by user group membership.
For example, add all Aloha-related accounts to a ‘Power Users’ group, and only grant the ‘Power
Users’ and ‘Administrators’ groups access to the files in the BootDrv folder.
• Configure the file permissions for the EDCProcPath directory to only allow access to the AlohaS-
ervice account and members of the Administrators group. This configuration prevents unautho-
rized 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 appropri-
ate security levels. Disable accounts for staff that are no longer employed, to prevent unautho-
rized 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:
Do not use group, shared, or generic accounts and passwords.
Change passwords at least every 90 days.
Passwords must be a minimum of seven characters in length.
Require passwords to contain alphabetic and numeric characters.
Disallow using the immediate previous four passwords, to prevent repeats.
Lock out a user ID after no more than six unsuccessful attempts to log in.
Set the lockout duration to a minimum of 30 minutes, for locked out IDs, to
prevent ‘hammering’ attacks.
• 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 cus-
tomers 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 use WPA2 as a minimum standard for your security method; WEP
and WPA are now not sufficiently secure for use in the current environment. You must purchase
hardware and configure it to comply with the IEEE 802.11i wireless security standard, 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:
• “How to Clear the Windows Paging File at Shutdown,” Microsoft Knowledge Base article
number 314834.
• “Windows shuts down slowly when it is set to clear the virtual memory pagefile on shut-
down,” Microsoft Knowledge Base article number 320423.
• “You may receive a “Stop 0x0000000A” error message when you shut down or restart a
computer that is running Windows Server 2003,” Microsoft Knowledge Base article number
902069.
• Configure Windows to discard debugging information during an unexpected program or com-
puter shutdown, or ‘crash.’ In the most common operating systems, the option is available in
System Properties > Advanced tab > Startup and Recovery section. Click ‘Settings,’ and select
‘None’ from the ‘Write debugging information’ drop-down list.
• Disable System Restore on the Aloha 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 file server, and on all terminals, to prevent Windows from
giving access to unauthorized external requests for control. In Windows XP, select Start > Set-
tings > Control Panel > System > Remote tab. Clear the check box labeled ‘Allow users to con-
nect remotely to this computer.’ If it is consistent with your support structure, you may also
clear the check box labeled ‘Allow Remote Assistance invitations to be sent from this computer,’
in this same location.
Configuring the Aloha Network

• Do not, at any time, under any circumstances, open a direct, unprotected connection between
the Aloha network and the Internet. Always use up to date antivirus and antispyware programs
in conjunction with a software firewall to keep these communications secure. We also recom-
mend using a hardware router, if possible, between the Aloha network and any Internet con-
nections.
• 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
system. Select Start > Settings > Control Panel > Administrative Tools > Local Security Policy,
and select Security Settings > Local Policies > User Rights Assignment. Locate ‘Deny logon
locally’ in the policy list, and double-click it to add the ‘AlohaService’ user to the list of denied
users.
• Register CtlSvr, EDCSvr, and RFSSvr, if used, under the AlohaService user account.
• 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 > Hard-
ware > 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 com-
municate with the MSR, it ties up the Aloha system itself, preventing access to the information
on the card.
NCR Corporation terminated support for operating systems older than Windows XP, 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 secu-
rity 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 pro-
cessors. At no point does Aloha use ‘end-user’ methods of communication, such as e-mail, instant mes-
saging, chat, or any other non-secure means of transmitting information in any way related to
transactions. Refer to “Aloha Cryptography” on page B-1 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 pro-
cessing 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 sys-
tem. Data not stored within the shared file structure is much less likely to be available to anyone enter-
ing 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 Aloha EDC versions 6.4 and later, EDC adopted a policy of assured backwards
compatibility with NCR Aloha Suite versions 6.1.23 and later, 6.2.16 and later, and 6.4.7 and
later. Generally speaking, you can upgrade to a newer version of EDC to take advantage of
new 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 10265 for more information about features requiring dual upgrades.
Although you must upgrade your HASP key to Aloha v12.3 to run Aloha EDC v12.3, this
change in license status does not require you to upgrade the POS to Aloha v12.3.
To move non-temporary EDC files outside the Iberdir file structure:
1. Settle all pending transaction batches, before continuing with this procedure.
2. Create a new path for EDC outside the \Bootdrv file structure on the EDC server (typically the
Aloha 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 com-
puters 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 loca-
tion. 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 loca-
tion. EDCSvr reads the EDC files in the EDCProcPath location, and monitors the current EDCPath loca-
tion for incoming .req files.
The Aloha system assumes %Iberdir%\EDC as the default location for the environment vari-
able, 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 \Boot-
drv shared folder.
Implementing 128-bit Encryption in Aloha Installations

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 XP, or Windows Server 2003 to include all available ser-
vice packs and security patches, and upgrade Windows Explorer to v6.0, at minimum, this process
upgrades all encryption libraries.
We recommend you use Aloha v12.3, as this version takes advantage of 128-bit encryption, along with
AES 256-bit encryption when cardholder data may be stored on disk. The Aloha system encrypts card-
holder data, and purges non-essential data, such as track data, after completing the authorization pro-
cess.
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 expi-
ration dates, beginning with Aloha v6.4. Upon upgrade, the system disables access to credit card num-
bers 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 role assigned to the most
trusted employees, in Maintenance > Labor > Security Roles. You can find this function by first select-
ing the security role to which you want to give permission for this function, and then selecting POS tab
> File > Reports > Reports > Display Credit/Debit Card Numbers. Select ‘View’ to give access to users
assigned to this security role.
At the next data refresh, employees assigned to this security role 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 - 1 Security Roles, Audit Report Permission Configuration
Also beginning with Aloha v6.4, only employees with pre-existing edit rights in Store Settings can mod-
ify security settings, in the manner described above. Refer to “Accessing The Configuration Manage-
ment Tool” on page 30 for more information about access control to the Aloha system.
Requirement 2: Do not use vendor-supplied defaults

for security parameters.
The topics in this section relate to replacing vendor-supplied defaults for system passwords and other
security parameters.
Protecting Wireless Transmissions

Aloha applications 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, begin by purchasing
commercial grade wireless routers that conform to the IEEE 802.11i security standard, and secure the
network with a new password and encryption key.
Up-to-date wireless routers advertised as conforming to ‘IEEE 802.11 a/b/g/n’ conform to the
‘i’ standard.
After obtaining and installing appropriate wireless hardware, use the following section as a guide to
securing the wireless portion of your network:
• Along with the wireless router, install a perimeter firewall between the wireless portion of your
network and the cardholder data environment. Configure this firewall to deny or appropriately
control any traffic from the wireless environment into the Aloha network.
• Change the default password on the wireless router, to prevent unauthorized reconfiguration of
the router. Change any SNMP string used in the router, as well, as it will come with a well-
known public value (often installed as ‘public’).
• Change the default password on any wireless access points also used in the installation.
• Establish a new encryption key before actually using the wireless network. Change this key if
anyone with knowledge of it changes jobs within or leaves the company.
• Verify router and access point firmware is up to date, to support strong encryption.
• Research wireless router and access point equipment, to identify and change any other defaults
applicable to security.
• Restrict physical access to wireless routers and access points, to prevent tampering or outright
substitution.
• Create and maintain extensive, separate documentation, detailing all restrictions and other
configuration established in your wireless network, including manually created encryption keys,
and your plan for their management.
• Test for unauthorized wireless access points at least quarterly, to include WLAN cards, USB
devices, and other wireless devices connected directly to network ports or devices. Use physical
inspections, in conjunction with network scanning, to detect unauthorized devices.
• If the site uses automated testing for unauthorized wireless devices, verify the testing software
or device is capable of and configured to generate alerts, if unauthorized devices are found.
• Verify the Incident Response Plan includes detailing unauthorized wireless device detection
results, if devices are found.
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 configura-
tion, as it dramatically increases the possibility of unauthorized file access by intruders. If the restau-
rant wishes to provide wireless Internet access to customers, install an isolated wireless access point
(AP), configured outside the Aloha network, thus preventing customers from reaching the Aloha file
server or the FOH terminals. As a best practice, you should also use sensing software 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 illegally ‘joining’ your Aloha network.
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.
You must exercise great care to purchase up-to-date wireless equipment that is
capable of using the WPA2 security standard. Older standards, such as WEP and
WPA are no longer secure in the current wireless environment, and no longer
acceptable for PCI DSS compliance. You must use the WPA2 security standard.
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 default or previous keys 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.
Encryption Requirement
You must also implement strong encryption in all cases where any of the following are broadcast wire-
lessly within the restaurant:
• Cardholder data
• Authentication data
An extensive discussion of wireless network security is beyond the scope of this document. Consider-
able 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. Systems, including the
BOH file server and all terminals, running Windows Server 2003 or Windows XP, with all service packs
and updates installed, and running Microsoft® Internet Explorer (IE), version 6.0 or later are, by defini-
tion, running an appropriate level of encryption.
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 net-
works. Use SSH or SSL/TLS, or other non-console access.
Protect Cardholder Data
This requirement addresses the need to keep cardholder data safe from unauthorized access.
Requirement 3: Protect Stored 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 Payment Card Tenders

As you create payment card tenders, certain options are important for enhancing the security of your
operations. In the configuration management tool, select Maintenance > Payments > Tenders > Type
tab > Options Settings group bar to access this option.
Figure 1 - 2 Tender Maintenance, Type Tab, Options Settings
Enable ‘Use Magnetic Cards ONLY’ to prevent manual credit card entry without manager approval. This
setting helps to prevent unauthorized use of credit card account numbers at the site.
Required Settings:
• On the Type tab, Use Magnetic Card ONLY: Selected

• On the Identification tab, Print on Check: Cleared
Deleting Files Securely

As data retention policies come into play, file deletions must be secure to prevent any possibility of
recovery. Although NCR Corporation provides a utility, CleanPAN, for removing sensitive data from
within Aloha related files, files may exist in any Aloha installation that are beyond the scope or reach of
CleanPAN, and often require deletion. Information in all of these files is encrypted using AES 256 bit
encryption. Each file resides in a Windows share protected by Windows share level security. Files that
may require deletion are as follows:
File Location Contents Secure Deletion

Trans.logs %IBERDIR%\YYYYMMDD Track, PIN Block, Security File is securely deleted as
and %IBERDIR%\DATA Codes (all securely deleted post part of Data Retention
authorization). Policy by customer.
Account Number, Cardholder
Name, Expiration Date.
Mirror.logs %IBERDIR%\TMP and Track, PIN Block, Security File is securely deleted at
%IBERDIR%\DATA Codes (all securely deleted post EOD.
authorization).
Account Number, Cardholder
Name, Expiration Date.
Report.txt %IBERDIR%\TMP The Account number is This file is securely
encrypted only if the Audit deleted when the Audit
Report with the Back Office Report closes.
Security Level to view the full
PAN is displayed. Otherwise,
only the last four digits of the
PAN is visible.
*.req files (Master Terminal) Track, PIN Block, Security File is securely deleted as
%LOCALDIR%\EDC Codes (all securely deleted post part of EDC process.
EDC securely moves it from authorization). Account Num-
the Master Terminal to the ber, Cardholder Name, Expira-
File server tion Date.
(File Server) %IBER-
DIR%\EDC
*.wrk files %IBERDIR%\EDC Account Number, Cardholder File is securely deleted as
Name, Expiration Date. part of EDC process.
*.hld files %IBERDIR%\EDC Account Number, Cardholder File is securely deleted as
*.ans files %IBERDIR%\EDC Account Number, Cardholder File is securely deleted as
*.txn files %EDCProcPath%\Nameof- Account Number, Cardholder File is securely deleted as
CreditCardProcessor Name, Expiration Date. part of settlement pro-
cess.
*.rej files %EDCProcPath%\Nameof- Account Number, Cardholder File is securely deleted as
CreditCardProcessor Name, Expiration Date. part of EDC process.
*.STL files %EDCProcPath%\Nameof- Encrypted Account Number File is wiped by using
CreditCardProcessor (PAN), Expiration Date. CleanPAN according to
File does not contain any Sensi- Merchant’s data retention
tive Account Data. policy.
EDCProcPath, IBERDIR, and LOCALDIR are environmental variables defined at

the time of the POS system implementation
When files require deletion, whether they are on the Aloha file server or on the terminals, you must use
a manual method, as CleanPAN 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. 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 CleanPAN 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 recom-
mend 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 rec-
ommend 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 exer-
cise 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 CleanPAN utility. If
you set aside an exclusion period for CleanPAN, never move any of the excluded files to remov-
able media.
• Document the files removed, and the nature and disposition (location) of the removable media
used for file storage.
• Ensure the removable media are held securely against unauthorized access of any kind, while in
storage.
• Specify, in accordance with pre-determined policies, a time when the removable media must be
destroyed, or otherwise rendered unreadable.
• Ensure that removable media are, in fact, destroyed per established policies.
Secure File Deletion, Other Considerations (SH3)

It is beyond the scope of this document to name applications you can use for secure file deletion, or to
describe in any detail how to actually use these applications. You must select an application capable of
working in a networked environment, and you must establish how to do the following with any applica-
tion you use:
• Select and delete specific files securely, by removing the files and completely clearing the
spaces from which they were removed.
• Securely clear deleted files or file remnants from blank disc space.
• Verify file deletions are complete.
Deleting Sensitive Data Storage Related to Troubleshooting
When it becomes necessary to troubleshoot difficulties customers experience with payment card trans-
actions, the process often involves storing files that can contain sensitive authentication data. If permit-
ted to persist, these files can constitute a considerable data security risk, as this type of data may
include magnetic stripe data, card validation codes or values (security codes), or PIN block data. Spe-
cific guidelines are in effect for support personnel to use for this type of file storage:
• Prevent access to troubleshooting data by anyone other than personnel troubleshooting the
problem.
• Collect this type of information only when you need it to solve a specific problem.
• Exercise great care to collect no more information than is necessary to solve the problem.
• Store these files in an encrypted state, in specific, known, highly secure locations.
• Securely delete these files immediately after they are no longer needed. Refer to “Deleting Files
Securely” on page 22 for more information about deleting files securely.
Suppress Printing the Cardholder Name
Aloha v12.3 automatically suppresses printing the payment card number, except the last four digits,
and is not capable of printing or displaying the expiration date, per Federal law. Although no options are
available to modify this behavior, you can optionally suppress printing the cardholder name. Select
Maintenance > Business > Store > Store Settings tab > Credit Card tab > Voucher print settings group
bar to access this option.
Figure 1 - 3 Store Settings, Credit Card Group, Voucher Print Settings
Suggested Settings:
• Suppress Cardholder Name: Optional, but we recommend selecting this option.
Federal law (Fair and Accurate Credit Transactions Act of 2003, or FACTA) prohibits printing
the expiration date of payment cards. By default, Aloha v12.3 is not capable of printing or dis-
playing expiration dates, once entered. Aloha stores this information in an encrypted format
for the brief time required for authorization. Suppressing the cardholder name on printed
vouchers is not required by Federal law as of the time of publication.
Mask the Primary Account Number (PAN)

Upgrade the NCR Aloha Suite to the latest version available, or at least version 6.4. 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 follow-
ing the authorization. This encryption includes the PAN in all locations in which it is stored. Only under
specific conditions is it possible for specific, trusted employees to view the PAN, based on their security
role assignment. Any such access is logged, regardless of the security role. It is not possible to change
the way the NCR Aloha Suite encrypts and stores the PAN, or other encrypted, sensitive data.
Print Security Considerations and the Audit Report

Users configured with an appropriate security role have access to credit card numbers and expiration
dates, as contained in the Aloha Audit report, if required. These users can export or print this report, as
defined in their security role. If exported, even with credit card information visible, Aloha masks all
credit card data during the process, thus retaining the security of this data.
However, if the user elects to print this report, Aloha will print the report exactly as it appears on-
screen. We strongly suggest never printing the Audit report with card numbers visible, due to multiple
types of security risks. If it becomes necessary to print the report, you must first disable Windows print
spooling, to prevent storing critical cardholder data, including credit card numbers and expiration dates,
on disk.
Requirement 4: Encrypt transmission of cardholder

data across open, public networks.
The Aloha system satisfies this requirement in numerous ways. Refer to “Aloha Cryptography” on page B-
1 for information about how the Aloha system accomplishes data encryption.
Maintain a Vulnerability Management
Program
This section addresses the following PCI DSS requirements:
Requirement 5: Use and regularly update anti-virus

software or programs.
Requirement 6: Develop and maintain secure
systems and applications.
As we understand all too well, numerous types of threats exist in the environment we face today. We
must exercise great care to address these threats, and maximize the safety of cardholder data, and our
business data. To comply with PCI DSS, you must establish and maintain a program that addresses
these threats. In this area, the primary areas of concern involve viruses, spyware, adware, and other
malware.
To address this area of the PCI DSS, you must establish what you intend to do, then execute that plan.
Once complete, establish a process of constant maintenance, to ensure your hard work is not undone
by inaction over time. The best practices in this area are as follows:
• Install and implement known, well-respected antivirus software on all server and terminal com-
puters. Establish a routine to update this software several times each week. Daily is not too
often, as new antivirus updates may become available at any time.
• Similarly, install and implement an antispyware program that detects and prevents or removes
spyware, adware, and other malware. Establish a routine to search for and install updates for
this program on a regular basis. We suggest a weekly interval for this type of software, as
updates tend to become available at irregular intervals, and may be less frequent than for anti-
virus programs.
• Due to the vulnerability implied by a direct Internet connection, you must obtain antivirus and
antispyware program updates from the manufacturers as downloadable components, and
install them on the BOH file server and terminals. Although this process can be admittedly cum-
bersome, it is the best way to safely update these programs.
• Locate and install all available updates and security patches for devices installed on the Aloha
network, such as routers, network switches, hardware firewall devices, wireless access points,
computers, and more.
• Establish a program to routinely look for updates and security patches for all devices installed
on the Aloha network.
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 contains all required components, and use it faith-
fully.
Implement Strong Access Control
Measures
This section addresses PCI DSS requirements relating to access to the NCR Aloha Suite, as follows:
Requirement 7: Restrict access to cardholder data

by business need to know.
Creating Security Roles
In your installation, you probably have one or more security roles available for assigning to employees.
We recommend you examine each security role, and verify that all access is granted on a ‘need-only’
basis. As you create new security roles, we recommend you do not start with an existing record, as this
process can result in accidentally granting access to privileged information, or configuration features.
Start with a new security role with zero access permissions. Grant access only to features and informa-
tion as required for users assigned to a given security role.
The Aloha system automatically prevents granting permissions in excess of your own, thus preventing
the creation of security roles with excessive access by an unauthorized employee.
Requirement 8: Assign a unique ID to each person

with computer access.
Managing Windows Auto-Logon
It is possible to automate the logon process by enabling auto-logon, but this process stores the user
name and password in the Windows registry in clear text. This practice poses a security risk, and vio-
lates the PCI DSS requirement for implementing strong access control measures.
To assist you in managing the Windows auto-logon feature, NCR offers a utility called ‘EncryptAu-
tologon.’ To use it simply create your autologon entries in the registry in clear text in the HKEY_LO-
CAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon section with the following
keys.
"DefaultUserName"=""
"DefaultPassword"=""
"ForceAutoLogon"="1"
"AutoAdminLogon"="1"
Once you create these keys, exit out of regedit, then run the EncryptAutoLogon.exe. The utility will
both encrypt and hide the registry entries. Reboot the computer and it should autologon with the cor-
rect credentials.
Refer to RKSID#11290 to download EncryptAutoLogon.exe and additional informa-

tion.
Use the following guidelines with regard to using the auto-logon feature on an Aloha system:
• NEVER configure the Aloha file server to use an auto-logon feature. If the file server is cur-
rently, or has ever been set to use auto-logon, edit the registry and remove the keys listed
above.
• 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 accom-
plish 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
EncryptAutoLogon.exe on each terminal to move the information to a secure area and store
it in an encrypted format.
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; ensuring
you are using the above ‘best practices’ regarding the auto-logon feature is a must.
For more information on configuring terminals to meet security requirements, refer to the
Managing Separate User Accounts on FOH Terminals Hardware Guide.
Accessing The Configuration Management Tool
Access to the configuration management tool, and all applications configured from within it, is con-
trolled using complex passwords, with rules clearly stated upon notification of the requirement to
change the password. Rules of access, and most other aspects of password configuration, are not avail-
able for corporate or user modification, as they are part of the program itself. New installations require
a password change upon first login. Rules governing the nature of the password itself are hard-coded,
and not available for modification.
Figure 1 - 4 Configuration Management Tool, Password Rules
The configuration management tool also allows users to a configure security question in the event a
user forgets their password. The user must enter the exact answer as they entered when they selected
the security question.
Figure 1 - 5 Password reset
Some aspects of the login process are available for modification in Maintenance > Labor > Security
Roles > Security Role tab > Identification group bar.
Figure 1 - 6 Security Roles, Security Role Tab
Required Settings:
• Screen timeouts in seconds (maximum, zero not allowed): 900 seconds

• User lockout attempts (maximum): 6
• Password expires after this many days (maximum): 90
• Number of historical passwords to retain (minimum): 4
You must change these settings for each Security Role record listed in the header. This capability makes
it possible for you to make some security roles more or less strict than the recommended, depending
on the role of the employees assigned to them.
Configuring FOH Passwords
FOH passwords are numeric, usually set as the employee ID number until the employee changes it, or
until the system requires a change. We recommend configuring the FOH to use mandatory, expiring
passwords, as a ‘best practice,’ although this is not a PCI DSS requirement. To configure FOH pass-
words, select Maintenance > Business > Store > Store Settings tab > Security tab > POS Password
group bar.
Figure 1 - 7 Store Settings, Security Tab, POS Password Configuration
Suggested Settings:
• Min Password Digits: 3

• Max Password Digits: 15
• Password: Required
As with any computer system, we recommend you specifically discourage all employees at all
levels from writing down and leaving their passwords lying around or sharing them with oth-
ers in any way.
Select Maintenance > Business > Additional Features > Employee Maintenance group bar, to
define the Employee Number Length. Suggested length is three or four digits.
Requiring Expiration of FOH Passwords
After establishing the requirement for a password in the FOH, you must also establish a time interval
for the expiration of passwords. Select Maintenance > Labor > Jobcodes > Financial tab > Security
group bar, and set passwords to expire at reasonable intervals, e.g. 30 or 45 days. You must complete
this configuration for every job code.
Figure 1 - 8 Job Codes, Password Configuration
Required Settings:
• Uses Password: Selected

• Password Expires: Selected
• Days until password expires: 45 to 90 Days
You can configure the system to make passwords mandatory, and still use magnetic cards or
fingerprint scanners at the FOH. When you configure passwords to expire after a specific time
interval, magnetic cards, and fingerprint images do not expire after the same time interval.
Using Alternative Security Devices Instead of Passwords
You can increase security considerably for accessing the FOH terminals by requiring employees to use
magnetic stripe cards, or fingerprint scanners. Select Maintenance > Labor > Employees > Employee
tab > POS Security Options group bar, to configure these devices.
Figure 1 - 9 Employee Maintenance, Employee Tab, POS Security Options
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 1 - 9, 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 magnetic cards: Selected (if hardware is installed)

• Must use fingerprint scanner clock in: Selected (if hardware is installed)
• Must use fingerprint scanner for login and manager approval: Selected (if hardware
is installed)
All mention of fingerprint scanners in the previous section is intended to refer to hardware
supplied by NCR Corporation, as part of Radiant terminals, or provided as separate devices.
Non-Radiant hardware does not work with the settings in the Aloha system, or with the under-
lying software environment.
Requirement 9: Restrict physical access to
cardholder data.
To ensure data security, ensure that employees only have physical access to the file server, and other
potentially sensitive equipment appropriate to their work requirements. Prevent access to all other
forms of data storage, if archived external to the file server, to all employees except the most trusted.
This type of storage may include, but is not necessarily limited to, flash drives, CDs, or backup tapes.
Restrict all such access to employees, visitors, contractors, repair technicians, or other personnel who
may be present on site premises. Maintain a log of people entering and leaving areas where this type of
data storage is maintained. Establish full audit trails for on-site storage, off-site transport and storage,
and for destruction of physical data storage media, such as paper, flash drives, or CDs.
Securing Off-Site Data Storage

Printed customer receipts is another area of potential data loss. Although a correctly configured Aloha
system prints no critical information on these receipts, it is still a requirement that you store them in a
secure location, preferably offsite, along with any other critical stored data. It is also a requirement that
you visit offsite storage at least once a year, to verify correct security procedures are in effect. Finally, it
is also a requirement that you establish and monitor data destruction procedures for off-site data stor-
age.
Securing Physical Access On-Site

Restaurants are busy places, and can often be chaotic. In the midst of the constant activity surrounding
this type of business, you must establish access control measures to prevent unauthorized access to
cardholder data through the electronic ports on the Aloha file server. The best method for complying
with this requirement is to install the server in a secure, lockable location. Strong password protection,
discussed in another section, helps complete the security of the file server.
The specific risk, when speaking of the BOH file server, is through use of small, removable data storage
devices. These devices can include, but are not limited to, Personal Digital Assistants (PDAs), laptops,
flash drives, and other removable storage media. It is critical to prevent access to external ports and
removable-media drives on the file server.
Ensuring Secure Remote Application Access

As a best practice, we recommend you use NCR Aloha Command Center for remote site administration.
This application enables you to check system status, copy files to or from a site, and much more, in
accordance with your administrative needs. The capabilities of NCR Aloha Command Center are specifi-
cally tailored to the Aloha environment, and it uses excellent security, requiring two-factor authentica-
tion for access. Contact your NCR representative for more information about Command Center.
Refer to the ‘Command Center Quick Reference Guide’ for information about how to obtain,
install, configure, and use NCR Aloha Command Center.
If remote access to the Aloha network is necessary, and you are not using NCR Aloha Command Center,
you must require a two-factor authentication mechanism, such as RADIUS, TACACS with tokens, or VPN
with individual certificates.
Remote access applications, such as pcAnywhere, are of special concern, in that they inject another
layer of vulnerability into the security equation. If you are using a program like this, you must take
extra precautions to ensure the integrity of the network. In this scenario, there are multiple opportuni-
ties for security breaches, requiring specific actions in each case. The requirements for correct configu-
ration and operation of remote access applications are as follows:
• Change default settings in the remote access software. For example, change default passwords
and use unique passwords for each customer.
• Allow connections only from specific (known) IP/MAC addresses.
• Use strong authentication and complex passwords for logins according to PCI DSS requirements
8.1, 8.3, and 8.5.8 through 8.5.15.
• Enable encrypted data transmission according to PCI DSS requirement 4.1.
• Enable account lockout after a certain number of failed login attempts according to PCI DSS
requirement 8.5.13.
• Configure the system so a remote user must establish a Virtual Private Network (VPN) connec-
tion via a firewall before access is allowed.
• Enable the logging function.
• Restrict access to customer passwords to authorized reseller/integrator personnel.
• Establish customer passwords according to PCI DSS requirements 8.1, 8.2, 8.4, and 8.5.
• Disable all remote access applications when not in use.
Excluding Cardholder Data from Online Servers

Any computer connected to the Internet is, by definition, vulnerable to external attack to some degree.
Firewall devices, firewall software, and antivirus software can provide a high degree of safety, to help
reduce the threat. We also recommend using antispyware/malware software, available at no charge
directly from Microsoft, to add an extra dimension of protection.
None of these security measures, however, is capable of rendering a computer completely safe from
attack. For this reason, you must not store cardholder information on a server connected directly to the
Internet. As a best practice, we recommend upgrading to the latest version of Aloha available validated
against applicable data security standards, and use the CleanPAN utility to clear this type of information
from the Aloha file server. If possible, use a separate computer for obtaining updates for operating sys-
tems, security software, and firmware for hardware devices, to limit the amount of time the Aloha file
server is connected to the Internet for purposes other than authorization and settlement.
Regularly Monitor and Test Networks
Requirement 10: Track and monitor all access to
network resources and cardholder data.
Logging EDC and Configuration Management Tool Program Activity
The secure operation of EDC and the configuration management tool is of vital importance. For this rea-
son, these programs record all program activities, including employee log in, date, time, terminal num-
ber (if applicable), program actions, and log out. It is not possible to modify or disable these logging
functions. Attempts to modify or disable EDC or the configuration management tool logging functions
violate the requirements of the PCI DSS security standards.
EDCSvr captures EDC program activity information and stores it in the EDC debout file. As a related
function, Aloha also logs a message to Debout.txt, detailing employee access to the POS Audit report,
when the employee elects to view credit card account numbers. Select Utilities > POS > View Debug-
ging File to review (but not modify) the contents of these log files.
CFCSvr captures the configuration management tool program activity, and records it in CFCAudit.log.
The contents of this file are available in the same manner as the EDC debout file.
Refer to “Aloha Log Files, Locations, and Contexts” on page D-1 for more information about
log files, their contents, and their locations.
Another component to logging EDC activity relates to troubleshooting EDC when problems occur. When
configured to do so, EDCSvr captures even more detailed information in the EDC Debout file. To prevent
storing this type of information, select Maintenance > System Settings > Debug Event. Troubleshooting
group bar, and clear these settings. As a best practice, under the ‘Debug Event Terminals’ group bar we
recommend that you clear Active or remove the debug event unless you are actively troubleshooting
problems, and that you disable these functions as soon as possible.
Clear
Remove
Figure 1 - 10 Store Settings, System Group, Troubleshooting Tab
Suggested Settings:
• Touch (Active): Cleared

• EDC (Active): Cleared
Viewing Debugging (Debout) Files
You can quickly access debugging files for the purpose of viewing their contents. Select Utilities > POS
> View Debugging File to access the list of files available:
Figure 1 - 11 Utilities, POS, View Debugging Files
Single-click a file you want to view and click View, or double-click the file, to open the file in an appro-
priate viewer. When a user accesses a log file, the configuration management tool Audit report shows
the user who accessed it, and Aloha records the file accessed in Debout.txt.
The Debout.inst file, which records events related to Aloha Update processes, is not viewable
through this utility. This file resides in the same directory as the Aloha Update .msi, and is
directly viewable by using applications such as Windows Notepad. This file contains no sensi-
tive cardholder data, as it only details installation or rollback events.
Requirement 11: Regularly test security systems
and processes.
After configuring your networks and software systems for maximum security, you must establish a pro-
gram to regularly test and verify the configuration is still secure. This section contains some sugges-
tions in this area.
Testing Applications for Vulnerabilities

Rigorous testing during development ensures the integrity of security features in Aloha applications. We
strongly recommend that you upgrade to the latest version of Aloha, as it becomes available, as each
iteration incorporates newer, stronger security features. We also recommend you periodically verify
your configuration is still consistent with the latest security recommendations. Contact your representa-
tive at NCR at least once every year, and inquire about security requirement changes, and changes in
the NCR Aloha Suite to meet these changes. With each annual review, a new version of the NCR Aloha
Suite will be validated, and it will become the recommended version for data security compliance.
Monitoring File Integrity

Logged information is a vital record of activity on the Aloha network, and of activity within the Aloha
program system. If unexpected changes occur to these log files, often an indication of unauthorized
activity, you must have a timely way of knowing about these changes. PCI DSS compliance requires you
to obtain a file-integrity monitoring software product, install it, and configure it to monitor the Aloha log
files. The software must be capable of displaying alerts when unexpected changes occur to these vital
files. As part of compliance, you must use this software to monitor system integrity, and investigate any
alerts it displays.
Maintain an Information Security Policy
Requirement 12: Maintain a policy that addresses
information security for all personnel.
After completing all necessary installation and configuration requirements, your data security efforts
are nearly complete. The next step in the PCI DSS (Section 12), is to formalize your data security pro-
gram into a policy that you publish to your employees. You must state the specific goals of your data
security policy, including all of the steps you expect to take, on an annual basis, to verify that your site
is still secure. Specify the area of responsibility each type of employee has in your data security pro-
gram, and implement a formal security awareness program to emphasize and enforce these responsi-
bilities.
You must also implement an incident response plan, in the event of a system breach. Specify response
procedures, business continuity processes, and data backup strategies and processes. Make specific
lists of people and authorities to contact, both within the company and outside the company, to include
law enforcement and transaction processors. You are required to provide training to employees on the
proper procedures to follow, in the event of a system breach.
To summarize these requirements in a more common-sense way, you must make a list of what you
need to do, on an annual basis, to make sure all of your hard work is still effectively protecting your site
from data security breaches. You must make a list of who to call and what to tell them, in case there is
a security breach. You must be careful about who you hire, performing background checks on new
employees 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.
2
Upgrading Client
Accounts
Working with Backup Files ....................................................................................2-3

Safeguarding Cardholder Data After Upgrading ........................................................2-3
Using the CleanPAN Utility as Part of an Upgrade .....................................................2-4
POS DSHB v12.3 Implementation Guide Upgrading Client Accounts 2 - 1

2 - 2 Upgrading Client Accounts POS DSHB v12.3 Implementation Guide
It is of considerable importance for everyone involved that clients upgrade their Aloha software to the
latest version of Aloha available. Although version 5.3.15 was the first version of Aloha validated as
CISP, and therefore PABP, compliant, the requirements for validation continue to change, and Aloha
software continues to evolve, to meet new security requirements as they emerge. Aloha version 12.3 is
now the latest version validated as complying with the latest applicable data security standards.
As technology advances, NCR Corporation continue to focus and build upon the security aspects of our
products to introduce increasingly more secure features, while retaining previous levels of security. As
the result of this process, we recommend that anyone accepting credit card payments upgrade to Aloha
version 12.3, for the following reasons:
• This version uses AES 256-bit encryption for sensitive data both within the Aloha system and
for data transmission over public networks for authorizations and approvals.
• This version gives you a new method of using EDC that considerably enhances the security of
cardholder data. Beginning with v6.1, EDC supports a new environment variable, EDCProcPath,
which moves all sensitive EDC files outside the shared Bootdrv folder. Refer to “Configuring EDC
for Secure Data Storage” on page 1-17 for more information about safeguarding these files.
• This version provides enhanced security in various areas, as compared to previous versions,
and closes unpublished access methods to the system, under normal, operational conditions.
Upgrading clients to the latest version of Aloha, however, is not sufficient, by itself. You must periodi-
cally verify the configuration of the program is correct, site by site, to maximize the ability of each cus-
tomer 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 the configuration management
tool, 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 pro-
grams, although not directly related to the Aloha system, are configured for maximum security.
Working with Backup Files

It is common practice, when upgrading from one version of Aloha to another, to create backups of the
Aloha directory, often including copies of the dated subdirectories, prior to the actual upgrade. These
backup files can contain cardholder data. The real problem with these files is that they are often outside
the environment of the Aloha system, so the usual mechanisms that function to remove cardholder
data do not work for them. These backup files are thus vulnerable to any unauthorized entry into the
computer containing them. We strongly recommend exercising extreme diligence in removing any
backup files you create, after you no longer need them.
Safeguarding Cardholder Data After

Upgrading
Prior to upgrading to Aloha v12.3, we strongly recommend that you settle all pending EDC batches, and
complete an EOD process. If you experience any difficulties during the EOD process, we recommend,
for simplicity and data integrity, that you resolve these issues prior to the upgrade.
Although you may upgrade to a validated version of Aloha, sensitive authentication data and cardholder
information, including credit card numbers, may still be available in plain text in the dated subdirecto-
ries, or in files retained in directories related to EDC or processors. You must remove this information,
as part of your responsibility for complying with data security requirements. You can use the CleanPAN
utility to clear this information, depending on the version of Aloha used to create existing dated subdi-
rectories. You can obtain this utility from the Aloha Update Web site.
POS DSHB v12.3 Implementation Guide Upgrading Client Accounts

Using the CleanPAN Utility as Part of an
Upgrade
If you have already been using Aloha for some time, sensitive authentication data and cardholder data
may exist in some of the archived files related to the previous version. This risk is especially real if you
are upgrading from a version of Aloha prior to Aloha v6.0. Removal of all cryptographic data that may
have been stored as part of using previous versions of Aloha is of utmost importance, and absolutely
necessary for PCI DSS compliance.
For this reason, you must use the CleanPAN utility, possibly in conjunction with the early version of the
DelTrack utility, as part of your upgrade process. These utilities clear sensitive authentication and card-
holder data from files stored by Aloha on the BOH file server, thus reducing the risk of a data compro-
mise. The process for using CleanPAN and DelTrack, however, is different, depending on whether you
have dated subdirectories created with Aloha v5.2.8 or earlier, or if your dated subdirectories are from
a newer version. The data is stored differently, depending on the version of Aloha used.
The documents describing the early version of DelTrack and CleanPAN provide much more information
about how to use them, when conducting an upgrade, but a summary of this process is as follows:
1. Ensure that all transactions are complete, that all EDC batches are settled, and that EOD has
run successfully.
2. Run DelTrack v1.0.2 to remove all track data from the dated subdirectories created by the older
version of Aloha. (Skip this step, if all of your subdirectories have been created with Aloha
v5.3.1 or later.)
3. Upgrade Aloha to the latest version of Aloha available that has been validated against the data
security standards.
4. Regrind all dated subdirectories, if you are upgrading from Aloha v5.2.8 or earlier. This process
upgrades them to the new version of Aloha.
Refer to the Aloha Manager Utilities Guide for more information about how to configure and
run the Regrind Subdirectories utility.
5. Run CleanPAN against all dated subdirectories that are older than any ‘exclusion’ period you
may establish, e.g. 30 days. You may need to run CleanPAN manually, and configure it to ignore
existing ‘CleanPAN’ marker files.
Refer to the Aloha CleanPAN Feature Focus Guide for more information about this utility, and
how to configure and use it.
After successfully upgrading Aloha, we also recommend, as a ‘best practice,’ that you continually verify
that you continually, and securely delete all dated subdirectories and settlement files created beyond
your data retention policy date.
Although the Payment Card Industry Security Standards Council and NCR Corporation recom-
mend retaining dated subdirectories no longer than 90 days, you must establish a data reten-
tion 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.
2 - 4 Upgrading Client Accounts

3
Frequently Asked
Questions
General PCI DSS Information ................................................................................3-3

NCR Aloha Suite and PCI DSS Information ..............................................................3-7
Additional Resources .......................................................................................... 3-10
POS DSHB v12.3 Implementation Guide Frequently Asked Questions 3 - 1

3 - 2 Frequently Asked Questions POS DSHB v12.3 Implementation Guide
Questions we frequently hear about PCI DSS compliance, and how it relates to the Aloha system tend
to fall into specific categories. This section includes those questions, grouped by category, in an attempt
to help you understand this potentially difficult and confusing topic.
A Note About Links

In this section, you will find numerous blue links, which are active in the PDF version of this document.
Although we have made every effort to verify these links, there is no guarantee that they will work from
every network, or that the companies creating the Web pages will not modify their sites. If you find a
link that does not work for you, please contact us about it. However, you can often copy the link to your
browser, then shorten it to get to a higher-level page. From there, you can search the site to find what
you need. For example:
If this doesn’t work... https://www.pcisecuritystandards.org/security_standards/index.php

Shorten it to this. https://www.pcisecuritystandards.org/
General PCI DSS Information

Q) What is the Payment Card Industry Data Security Standard (PCI DSS)?
A) The Payment Card Industry Data Security Standard (PCI DSS) is the result of collaboration between
the various Credit Card Associations and the federal government to create common industry security
requirements. It consolidates and supersedes the requirements of the previously developed MasterCard
Site Data Protection (SDP) Program and the Visa Cardholder Information Security Program (CISP).
You can obtain a copy of the PCI Data Security Standards document at the following location:
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 cardhold-
ers’ 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. Mer-
chants also benefit from:
• Consumer Confidence — Consumers want security and assurance that their financial informa-
tion and identity is safe.
• Minimized Threat to a Customer’s Reputation and Financial Health — Financial and
resource outlay is minimal compared to the costs associated with the reactive hiring of security
and public relations specialists, or the loss of significant revenue and customer goodwill that
can result from a compromise.
• Potential Fines — In the event of non-compliance, the card associations and the federal gov-
ernment 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 com-
panies’ internal programs that ensure compliance with PCI DSS standards. If you meet PCI DSS stan-
dards, 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 com-
panies 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 Description

1 Any merchant processing over 6,000,000 transactions of Visa or MasterCard per year,
across all channels.
Any merchant that has suffered a hack or an attack that resulted in an account data
compromise.
Any merchant, identified by the Credit Card Issuer (Visa, MasterCard, etc.), that
should meet the Level 1 merchant requirements to minimize risk to the overall sys-
tem.
Any merchant identified by any other payment card brand as Level 1.
2 Any merchant processing 150,000 to 6,000,000 e-commerce transactions* per year.
3 Any merchant processing 20,000 to 150,000 e-commerce transactions* per year.
4 Any merchant processing fewer than 20,000 e-commerce transactions* per year, and
all other merchants processing up to 6,000,000 transactions per year.

Q) What are the PCI DSS Compliance Validation Requirements, based on Merchant Level?
A) 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 Validation Action Validated By Due Date

1 Annual On-site PCI Data Security Qualified Data Security Company 9/3/04
Assessment or Internal Audit if signed by Offi-
and cer of the company
Quarterly Network Scan Qualified Independent Scan Ven-
dor
2 and 3 Annual Self-Assessment Question- Merchant 6/30/05
naire Qualified Independent Scan Ven-
and dor
Quarterly Network Scan
4* Annual Self-Assessment Question- Merchant TBD
naire (Recommended) Qualified Independent Scan Ven-
and dor
Network Scan (Recommended)
* Level 4 merchants must comply with PCI DSS; however, the acquirer determines the nature of com-
pliance 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 detailed listing of the PCI Data Security Standards is available from the Payment Card Industry
Security Standards Council Web site. The section below is a very brief summary.
• Build and Maintain a Secure Network.

1. Install and maintain a firewall configuration to protect cardholder data.
2. Do not use vendor-supplied defaults for system passwords and other security parameters.
• Protect Cardholder Data.
1. Protect stored cardholder data.
2. Encrypt transmission of cardholder data and sensitive information sent across public net-
works.
• Maintain a Vulnerability Management Program.
1. Use and regularly update anti-virus software.
2. Develop and maintain secure systems and applications.
• Implement Strong Access Control Measures.
1. Restrict access to cardholder and business data by ‘business need to know’ basis.
2. Assign unique ID to each person with computer access.
3. Restrict physical access to cardholder data.
• Regularly Monitor and Test Networks.
1. Track and monitor all access to network resources and cardholder data using a user unique
ID.
2. Regularly test security systems and processes.
• Maintain an Information Security Policy.
1. Maintain a policy that addresses information security for all personnel.

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 infor-
mation. Limit traffic from un-trusted networks to web protocols, system administration proto-
cols, 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 the NCR Aloha Suite to the latest version available. NCR 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 all additional installed NCR Aloha Suite modules are at the latest versions available, and
that they are configured for maximum security. Examples may include, but are not limited to,
NCR Aloha Takeout, NCR Aloha Guest Manager, or NCR Aloha Insight.
• Maintain a Vulnerability Management Program.
NCR Corporation 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 user’s activity.
You should delete any default users and passwords provided from Aloha by NCR Corporation.
Restrict access to view or delete the audit logs, including the Debugging-Output-Files (debouts)
created by the Aloha application software.
If you use pcAnywhere for Remote Administration, ensure that the sessions are secured. While
pcAnywhere has its own built-in security features, you should use the Operating System’s secu-
rity measures for the highest level of security. Symantec provides details on how to secure the
system on their Web site in Chapter 7 of the ‘Symantec’s pcAnywhere Administrator’s Guide.’
Please review the guide and implement pcAnywhere security at your sites:
ftp://ftp.symantec.com/public/english_us_canada/products/pcanywhere/pcanywhere32/
ver10.5/manuals/pca_105_admin.pdf
• 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 opera-
tional and network securities. Develop a response plan for security incidents. Communicate to
all system users and maintain signed acknowledgements of the program.
NCR Aloha Suite and PCI DSS Information

Q) Why am I being asked to upgrade to Aloha version 12.3? I thought version 5.3.15 was
CISP compliant.
A) Version 5.3.15 was validated as complying with CISP requirements, as they existed in early 2005.
Since that time, the PCI DSS requirements have evolved, and have been clarified. Aloha version 12.3 is
now the latest version validated to comply with the stated requirements. As always, we recommend
upgrading to the latest version of Aloha validated as complying with the latest published security speci-
fications, as soon as that version becomes available.
Q) What is the responsibility of NCR Corporation?

A) The NCR Aloha Suite is a ‘payment application.’ Best practices and security standards have been
developed to address security and the risks associated with payment applications. The goal of the Pay-
ment Application Best Practices (PABP) and the later Payment Application Data Security Standards (PA-
DSS) is to create secure payment applications. Applications qualify as secure, if they support a mer-
chant’s ability to comply with requirements. NCR Corporation has modified NCR Aloha Suite to achieve
the documented best practices:
1. Do not retain full magnetic stripe data.

2. Protect stored data.
3. Provide secure password features.
4. Log application activity.
5. Develop secure applications.
6. Protect wireless transmissions.
7. Test applications to address vulnerabilities.
8. Facilitate secure network implementation.
9. Cardholder data must never be stored on a server connected to the Internet.
10. Facilitate secure remote software updates.
11. Facilitate secure remote access to application.
12. Encrypt sensitive traffic over public networks.
13. Encrypt all non-console administrative access.
In addition to the above, more specific requirements are applicable to payment card application manu-
facturers, as summarized in the Payment Application Best Practices (PABP), and the Payment Applica-
tion Data Security Standards (PA-DSS), available from the following sources:
PABP http://www.visa.com/pabp
PA-DSS https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml
A list of PABP-validated payment applications is available by clicking ‘PABP-validated Payment Applica-

tions List’ at the very bottom of the page referencing these standards.

Q) Has the NCR Aloha Suite been validated stating it meets these requirements?
A) Yes. Aloha was the first restaurant Point-of-Sale software to receive validation from Visa.
Refer to the following table for detailed information about validated versions of Aloha, and the require-
ments against which they were validated. The following table represents the status of these versions at
the time of this publication table. Please refer to the PCI SSC’s web site for the current status as it may
have changed.
POS version Validated against Deployment notes: Current validation

number: PABP/PA-DSS expires
version: on:
Aloha v5.3.15 Pre-PABP v1.3 Expired - update is required. December 2, 2009
Aloha v6.1 PABP v1.3 Expired - update is required. June 2, 2010
Aloha v6.2 PABP v1.4 Expired - update is required. March 2, 2011
Aloha v6.4 PA-DSS v1.2 Acceptable for new deployments. October 2, 2013
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, NCR Corporation 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 the NCR Aloha Suite has been validated stating it meets the standard
requirements for a Payment Application?
A) Several versions up to and including v12.3 have been validated as complying with the PA-DSS
requirements, and are included in the list of Payment Card Industry Security Standards Council vali-
dated solutions. Although Aloha versions 5.3.15 and later contain many features that address PA-DSS
requirements, Aloha v12.3 is the latest validated version available, meeting the requirements in effect
as of the time of its validation (June, 2012).
Aloha’s compliance certification status is available at:
https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml
Q) What enhancements to the NCR Aloha Suite have been implemented to meet PA-DSS
requirements?
A) NCR Corporation will continue to enhance the NCR Aloha Suite software with each release to con-
tinue 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. Apply Payment
2. Refund
3. Attach Card Info
4. Pre Authorizations
5. Carry Over Payments (24-hour operations)
NCR will continue to review requirements for Payment Applications to meet industry best practices.
Q) What level of encryption is used by Aloha?

A) The NCR Aloha Suite used 64-bit encryption in all versions prior to version 6.0. Beginning with ver-
sion 6.0, the encryption level increased to 128-bit, using industry-standard technology. Aloha v6.4 and
later retains 128-bit encryption for employee passwords, but uses AES 256-bit encryption for payment
card transactions.
Q) What version of SSL does Aloha use?

A) Aloha uses SSL version 3.0 for secure communication across the Internet.
Q) How often will the NCR Aloha Suite be reviewed for compliance?
A) Versions previously validated can remain on the list of validated POS applications, if they remain
unchanged, and if NCR Corporation submits a letter to this effect annually, signed by an Officer. New
versions must be independently validated, prior to being listed as ‘validated.’
Q) How do I upgrade to a version of Aloha that meets PCI DSS?

A) Please contact your NCR representative for assistance in upgrading your current version of the NCR
Aloha Suite.
Q) What about the historical data in the dated subdirectories?

A) In addition to upgrading to a compliant version of the NCR Aloha Suite (v6.1 and later), credit card
track information must be removed from all dated subdirectories created prior to the upgrade. Use the
CleanPAN utility provided by Radiant Systems to remove sensitive cardholder information from both the
EDC settlement files and the Trans.log. This utility removes residual track data, and masks credit card
numbers, expiration dates, and security codes.
Q) Am I compliant if I upgrade Aloha?

A) While upgrading the NCR Aloha Suite 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 secu-
rity related appliances and applications.
Q) What are my next steps?

A) NCR Corporation 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 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 NCR representative.

Additional Resources
For more information regarding PCI DSS requirements, please visit the following links:
• PCI Data Security Standard:
• List of Validated Service Providers:
http://usa.visa.com/merchants/risk_management/cisp_service_providers.html
• List of Validated Payment Applications:
http://usa.visa.com/merchants/risk_management/cisp_payment_applications.html
• pcAnywhere Administrator’s Guide:
ftp://ftp.symantec.com/public/english_us_canada/products/pcanywhere/pcanywhere32/
ver10.5/manuals/pca_105_admin.pdf
• CleanPAN.exe Utility:
Obtain a valid user name and password, then obtain this utility from Aloha Update.
For more information about individual credit card programs:
• Visa CISP
http://www.visa.com/cisp/
• MasterCard SD
http://www.mastercard.com/us/sdp/index.html
• 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

A PCI DSS
Configuration
Checklists
This section includes two checklists designed to help you configure your site for PCI DSS compliance.
The PCI DSS Configuration Checklist provides a relatively detailed list of configuration steps, designed
to help you configure your computers and your networks for basic compliance.
The Site Checklist for PCI DSS and FACTA Compliance is designed as a separately printable ‘leave-
behind’ checklist to help a site administrator perform a quick evaluation as to the compliance status, or
lack thereof, of a specific site.
PCI DSS Configuration Checklist

The steps to PCI DSS compliance are many, and occasionally confusing. Use this checklist as a guide,
and to measure your progress, as you configure your own database for compliance. If you are viewing
this document in PDF format, click any blue link to move immediately to the topic it references for more
information. Each topic also lists its page number, if you are using a printed copy.
System Configuration:
Begin configuring your Aloha installation for PCI DSS compliance at the most basic level, initial installa-
tion.
Install the latest version of Aloha validated against the applicable data security standards. Contact
a member of the NCR team to identify the latest validated version of the NCR Aloha Suite.
Obtain and run the CleanPAN utility, page 1-22, to remove any residual customer data remaining in
your installation, 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 1-34.
Network Security Configuration:

Configure your Windows and Aloha networks for security, to give yourself the best chance of maximiz-
ing data integrity in your installation.
 Verify Windows is configured to purge the paging file each time you restart the BOH file server.
Information about how to do this is available in the Microsoft Knowledge Base, page 1-15.
Verify Windows is configured to discard debugging information, if an unexpected program or com-

puter shutdown occurs, page 1-16.
Disable the ‘Guest’ user in Control Panel. Procedures for doing this vary slightly from one operating
system to another, page 1-14.
POS DSHB v12.3 Implementation Guide PCI DSS Configuration Checklists A - 1

 Reconfigure all Aloha data and program directories relevant to remove the ‘Everyone’ user from
them, page 1-15. Verify their configuration permits access only by the system administrator or other
authorized accounts.
Disable and remove ‘auto-logon’ on the BOH file server, if currently in use. Remove residual config-
uration for auto-logon, if it has ever been used on the BOH file server, page 1-14 and page 1-28.
Enable Windows Automatic Updates, page 1-12.

If you are using a version of Aloha earlier than v6.4, install the two Microsoft Blocker Tool applica-
tions to prevent Automatic Updates from automatically updating Internet Explorer to v7.0 or v8.0,
page 1-21.
Install antivirus software, and obtain updates for it routinely and often, page 1-27. Daily is not too
often.
 Change all default passwords in routers, remote administrative software, or other third-party
hardware or software, as appropriate, page 1-36 and page 1-20.
 Install Aloha(QS) in a secondary directory beneath the root, as in C:\Bootdrv\Aloha(QS), page 1-

14.
Ensure procedures are in place to prevent opening a direct Internet connection from any computer
on the Aloha network, page 1-16.
Create a Windows user account specifically for use in the Aloha network, independent of any other
network requirements, page 1-16.
 Use Local Security Policy to block the Aloha network-specific user from logging on to the system
page 1-16.
 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 1-17.
Delete any default Windows user accounts provided by NCR Corporation or affiliated companies for
use in initial configuration, page 1-19.
Configure Aloha EDC to use an alternate path, outside the BootDrv share, by creating a new envi-
ronment variable, EDCProcPath, and moving the contents of the current EDC folder to the new location,
page 1-17.
 Disable the System Restore feature in Windows. Refer to “Configuring the Windows Network” on
page 1-12 for information about how to disable this feature.
Disable Remote Desktop in Windows. Refer to “Configuring the Windows Network” on page 1-12 for
information about how to disable this feature.
A - 2 PCI DSS Configuration Checklists POS DSHB v12.3 Implementation Guide

NCR Aloha Suite Configuration – Tender Configuration:
Configure your payment card tenders to protect you and your customers. Select Quick Service or Table
Service, in the product panel, to access these options.
 Create secure payment card tenders, by requiring the use of the card itself for transactions, in
Maintenance > Payments > Tenders > Type tab > Options settings group bar, page 1-22.
• On the Type tab, select Use magnetic card only.

• On the Identification tab, clear Print on Check.
NCR Aloha Suite Configuration – Store Settings:

Store Settings provides you with several opportunities to tighten security in your installation. Select
Quick Service or Table Service, in the product panel, to access these options.
Require and configure passwords for use on the Front-of-House (FOH) terminals, in Maintenance >
Business > Store > Store Settings tab > Security tab > POS Password group bar, page 1-29.
Stop excessive EDC event logging, in Maintenance > Business > Store > Store Settings tab > Sys-
tem tab > Troubleshooting group bar, page 1-37.
NCR Aloha Suite Configuration – Labor Settings:

Configuring your labor settings helps you to keep your Aloha network secure. Select Quick Service or
Table Service, in the product panel, to access these options.
 Configure Security Roles that provide no more access than required for each employee type, in
Maintenance > Labor > Security Roles, page 1-28.
Require each employee to use passwords, and set them to expire regularly, in Maintenance > Labor
> Job Codes > Job Code tab, page 1-28.
POS DSHB v12.3 Implementation Guide PCI DSS Configuration Checklists A - 3

Site Checklist for PCI DSS and FACTA Compliance
This section is intended as a simple, high-level checklist for site managers to use as a preliminary
assessment for PCI DSS and FACTA compliance. FACTA is the acronym for Fair and Accurate Credit
Transactions Act. The items in this checklist represent some of the ‘surface’ things you can quickly
check to begin analyzing the data security in your site.
If you are a qualified configuration technician, use the more complete checklist in Appendix A, and the
broader document for help in correcting any flaws discovered when you use this checklist, and to more
thoroughly prepare a site for compliance. This checklist, as well as the rest of this document, is by no
means intended to represent a definitive list of things you can do to guarantee compliance, and is in no
way intended as legal advice. Please contact your legal counsel for more help in these areas.
If you are not a qualified technician, use this checklist as a preliminary evaluation tool, and then contact
your NCR representative for help in configuring your site for security compliance.
Checking Print Output

Begin by processing a credit card or debit card transaction. Carefully examine the guest check and the
voucher for the following:
Only the last four digits of the primary card account number appear in print (mandatory).
The card expiration date does not print (mandatory).
 Name of the cardholder is not present (optional). Although it is currently possible to exclude the
cardholder name, it is not mandatory as of publication date.
 Reprint the transaction both from FOH and BOH, to verify the security configuration remains con-
stant in both locations.
Perform this configuration check for every credit and debit card type you support in your
store, to confirm that all payment cards are configured for security. This requirement does not
apply to gift cards, or other, similar cards.
Checking Your Reports

Check the following, to verify credit card information is masked on your reports:
 Open the Audit report showing the transaction you just processed. Verify the primary account
number is masked.
 Open the EDC Batch report, and find the transaction you just processed. Verify the primary
account number is masked.
A - 4 PCI DSS Configuration Checklists POS DSHB v12.3 Implementation Guide

B Aloha
Cryptography
Versions Prior to 6.0 (starting with 5.3.15)

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

Versions 6.0 and 6.2 of the Aloha Point of Sale system use RSA MD5 128-bit encryption algorithms for
all encryption tasks. Version 6.4 uses AES 256-bit encryption for payment card and cardholder data, to
safeguard transactions, while still using the 128-bit encryption for employee BOH passwords. Version
7.1 uses SHA-256 cryptographic hash for employee BOH passwords.
Order Point version 12.1 introduces SHA-256 encryption of the customer hash when using MyMenu
functionality. This hash is applied to the Card_Number field in the Express Order > dbo.EO_ExpressOr-
der database table.
The following table summarizes the cryptographic methods used in the NCR Aloha suite, beginning with
version 6.0:
Aloha Version Data Encrypted Encryption Method

6.0 and 6.2 Employee passwords RSA MD5 128-bit encryption
6.0 and 6.2 Payment card and cardholder data RSA MD5 128-bit encryption
6.4.7 and later Employee passwords RSA MD5 128-bit encryption
6.4.7 and later Payment card and cardholder data AES 256-bit encryption
6.7.40 and later BOH passwords SHA-256 cryptographic hash
12.1 and later Order Point customer hash SHA-256 cryptographic hash
Key Maintenance
Key management is automatic, taking place in the NCR Aloha Suite, relieving site personnel of any key
management requirements. All versions of the NCR Aloha Suite, 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 cus-
tomer, 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.
Credit Card Data Specifics

Credit card track information persists only during the authorization process. Credit card numbers per-
sist beyond the authorization process, but remain encrypted. Credit card numbers are exported for
reporting purposes in a configurable masked format. Access to credit card numbers is strictly controlled
by configurable permissions, managed only by personnel at the highest level of access. Aloha logs any
POS DSHB v12.3 Implementation Guide Aloha Cryptography B - 1

request, successful or not, for access to credit card numbers, and this access logging cannot be dis-
abled or modified. The CleanPAN utility completely removes credit card numbers, when run against
Aloha or EDC files in which they are stored.
Communication Methods
Aloha communicates securely with processors using SSL 3.0/TLS. When using SSL is automatic, does
not change, and is not within the control of users at any level.
B - 2 Aloha Cryptography POS DSHB v12.3 Implementation Guide

C EDC Data Flow
The accompanying diagrams illustrates the flow of data through, out of, and back into the NCR Aloha
Suite, beginning with the first swipe of a payment card.
Figure C - 1 Aloha POS Network Diagram
POS DSHB v12.3 Implementation Guide EDC Data Flow C - 1

Figure C - 2 EDC Credit Card Data Flow
Cashier swipes credit/debit card; Aloha Processor answers back to Aloha

encrypts data. (encrypted).
Master terminal accepts transactions from all EDC server removes track data, retains
terminals, including itself. other card data, writes answer file back to
the terminal (encrypted). Terminal deletes
track data from Trans.log upon receipt of
answer file.
Aloha sends data to EDC server. EDC settles with processor, creating .stl files
(encrypted).
EDC server sends authorization request to Use secure deletion software to delete .stl
processor (encrypted, using SSL). files manually, in accordance with data
retention policies.
Processor puts funds on hold to cover the

transaction, or declines if funds are insuffi-
cient.
C - 2 EDC Data Flow POS DSHB v12.3 Implementation Guide

Figure C - 3 Data Flow Diagram, Authorization and Refund

Figure C - 4 Data Flow Diagram, Credit Adjustment

‘
Figure C - 5 Data Flow Diagram, Void, Delete Payment

Figure C - 6 Data Flow Diagram, Settlement, End-of-Day

D Aloha Log Files,
Locations, and
Contexts
Aloha has a robust logging system to support security and troubleshooting needs. Log files are available
for inspection, but not for editing, in Aloha Manager by selecting Utilities > POS > View Debugging
Files. The following table lists the most important of these files. In the Location column, ‘BOH’ refers to
the Back-of-House file server, and ‘FOH’ refers to the POS terminals, collectively. The term ‘Iberdir\Tmp’
refers to the Tmp subdirectory, immediately beneath the Aloha or AlohaQS directory.
File Name Location Purpose

Debout.cc BOH, %Iber- Records actions taken by Aloha CleanPAN, when run. Aloha stores no
dir%\Tmp sensitive cardholder data in this file.
Debout.nnn BOH, %Iber- Records debugging information related to Iber.exe or IberQS.exe, for
dir%\Tmp terminals, with ‘nnn’ indicating the terminal number. Aloha versions
5.3.20 and earlier create this file.
Debout.yyyym- BOH, %Iber- Same as for Debout.nnn, except the file name includes the date in
mdd.nn dir%\Tmp yyymmdd format. Aloha versions 5.3.21 and later create this file.
Debout.edc BOH, %Iber- Contains debugging information for EDC.exe and program functions,
dir%\Tmp and records program actions taken by users, beginning with login. Con-
tains no sensitive cardholder data.
Debout.inst Execution direc- Records Aloha Update installation or rollback activities. This file details
tory of the Aloha installation or rollback information, and contains no sensitive cardholder
Update .msi file data.
Debout.rfs BOH, %Iber- Contains debugging information for RFS.exe and RFS.dll and program
dir%\Tmp functions, but contains no sensitive cardholder data.
Debout.svr BOH, %Iber- Contains debugging information for CTLSvr.exe, but contains no sensi-
dir%\Tmp tive cardholder data.
Debout.txt BOH, %Iber- Contains debugging information for the Aloha BOH system, and related
dir%\Tmp .dll files, and other related Aloha BOH functions not stored in other
debout files.
Debout.proces- BOH, %Iber- Files generated by Aloha EDC, one for each processor used. These files
sorname dir%\Tmp record processor events, and other events not related to transactions,
and contain no sensitive cardholder data.
Aloha POS Audit Assembled from Displays only ‘X’ characters for PAN or expiration dates, except when
Report information in users with specific permissions access credit card numbers. When these
database and users access credit card numbers the Aloha POS system records the
log files, then user ID and indication that the specified user accessed credit card num-
discarded upon bers.
close Note: Only users configured with specific permission can view credit
card numbers.
Files specific only to Configuration Center or the new Aloha Manager
Aloha Manager Bootdrv\ Aloha Manager log files record program activity, but contain no sensitive
log files CFC\Log cardholder data.
POS DSHB v12.3 Implementation Guide Aloha Log Files, Locations, and Contexts D - 1
File Name Location Purpose
Aloha Manager Assembled from The Aloha Manager Audit report does not contain sensitive cardholder
Audit Report information in data, but tracks log-in activities and program modifications related to
database and data security.
log files, then
discarded upon
close
Archiving Log Files

The Aloha POS and Aloha Manager record many different types of events in various plain-text log files,
and in the database files. Most of these events relate to operational activities initiated and completed by
the program itself, but also include audit information, such as log-in and log-out events, and informa-
tion about security-related actions taken by users while logged in. Information in these log files is use-
ful for troubleshooting operational problems, but it is also invaluable for detecting improper program
access and modification. If a user logs in, makes changes to the way the Aloha POS functions with
regard to handling of sensitive data, information about these events is stored in the log files, or in the
database itself. This information appears on the audit reports, when a user configured with sufficient
permissions accesses them.
PCI DSS v2.0 requirements now mandate archiving log files to a centralized logging environment. More
information about these requirements is available in PA DSS Requirement 4.4 and PCI DSS Require-
ment 10.5.3. These requirements state that audit trail log files must be promptly backed up to a cen-
tralized log server or to media that is difficult to alter.
The Aloha POS and Aloha Manager facilitate this archiving process by storing the log files listed in the
accompanying table in the specified locations, making them easily accessible for backup purposes, per
the following:
• Log files containing events related to the Aloha POS are stored in the %Iberdir%\tmp directory.
• Log files containing events related to primary program activities, such as log-in and log-out
events, are stored in the %Bootdrv%\CFC\Log directory.
• The Debout.inst file resides separately from the above locations. When you download and run
an Aloha Update .msi file, this log file resides in the same directory in which you placed and
executed the Aloha Update file.
You can satisfy these requirements by performing one or all of the following:
• Purchase a third-party product that makes use of the logs and reports stored for centralized
logging purposes.
• Establish a process whereby the log files are routinely collected and copied to media that is dif-
ficult to alter.
• Create and adhere to a schedule for running and exporting Aloha POS and Aloha Manager Audit
reports. Select the file format (.csv, .xls, or .txt) appropriate for your centralized logging envi-
ronment.
D - 2 Aloha Log Files, Locations, and Contexts POS DSHB v12.3 Implementation Guide
E Aloha File
Structure
This section provides an overview of the Aloha program file structure, and the general functions for
each directory. The location of Each directory is beneath the primary Aloha directory, within the ‘Boot-
Drv’ share. For example, each directory is located within C:\Bootdrv\Aloha or C:\Bootdrv\Alo-
haQS. Any of the directories listed are possible in a given installation, but it is almost impossible that
any installations will contain all directories listed.
The exception to the location of these directories is the EDCProcPath. For security purposes, this direc-
tory is located outside the BootDrv structure, as detailed elsewhere in this document.
Directory Name Contents, or Purpose

\[dated subdirectory] Directory name is in the format, yyyymmdd. Contains .dbf, .cdx and .gnd
files, the Trans.log, and Aloha.ini.
\BackOffice Program and data files for Inventory Control, Delivery/Frequent Buyer,
Advanced Reservations, Accounts Receivable, E-Messenger, or Replication
Manager, if installed.
\Bin Contains program executables for the Aloha POS.
\Bmp Contains logos and other bitmaps.
\CRW Contains pre-defined Crystal Repots.
\DAO Stores Database Access Objects.
\Data This is the working directory, containing the Aloha.ini, House, Trans.log,
and report settings.
\Delivery Contains files related to Delivery MX
\EDC Contains files related to Credit Card Transactions (Electronic Data Capture)
\EDCProcPath Contains .stl files in appropriate processor folders. Sensitive cardholder
data that may still remain is encrypted. Refer to RKS documents numbered
8500, and 8755 for more information.
\History GCLOG.DBF, containing cumulative details of all gift certificates sold or
redeemed. This information is NOT stored in dated subdirectories.
\HTML *.gif and *.htm files
\IC Information for IC Verify (Credit Cards) and Scanners.
\Misc Miscellaneous programs and program files, including drivers.
\NewData Parallel directory to \Data, which includes edited data that hasn't been
refreshed. Prior to editing, it is a mirror of the Data directory except for
.LOG files, security files, HOUSE and report settings.
\PMS Contains files related to the Property Management System.
\Profiles User info for employees with BOH log-in permission.
\Recipe Contains bitmaps and .avi movie files used in the Recipes feature.
\RPTSet Stores user-defined report settings.
\SampData Contains a complete set of database files for demonstration use.
\SQL Contains data files for Aloha Supersite or Relational Database installations.
\SUM Contains the summary files (if needed).
\Tmp Contains debout files, verify text file, mirror files, and other files, temporary
or relatively permanent, not normally accessed by users.
POS DSHB v12.3 Implementation Guide Aloha File Structure E - 1

E - 2 Aloha File Structure POS DSHB v12.3 Implementation Guide
F Aloha Point-to-
Point Encryption
About P2PE
EBT Payment Cards at a Glance

Core Product Aloha EDC, Aloha Quick Service, Aloha Table Service
Complementary Products
Separate License Required? No
Other References Aloha Quick Service Reference Guide, Aloha Quick Service
Reports Guide, Aloha EDC User Guide
Effective with NCR Aloha POS v12.3 and EDC v12.3, or later, Point-to-Point Encryption (P2PE) provides
sites regulated by Payment Card Industry Data Security Standards (PCI DSS) with the potential to
reduce their compliance obligations. Using P2PE removes cardholder data from your environment by
encrypting the data at the moment of capture, without the ability to decrypt. When the data is sent to a
secure on-premises vault or the payment processor, Format-Preserving Encryption (FPE) is enforced. In
the case of First Data, (CES), a token is provided to the Aloha system in place of the cardholder data.
Once you implement P2PE functionality, guests and employees can only process credit, debit, and EBT
payment cards with the PIN pad device. Any attempt to slide one of these cards with an MSR attached
to a POS terminal, or directly in EDC, results in an error that guides you to use the PIN pad device
instead. For other types of payment cards, such as gift cards, you still use a magnetic stripe reader
(MSR).
Should you decide to implement P2PE, it is necessary to work with TSYS or First Data CES to ensure all
requirements are in place and you order and receive the PIN pad devices preloaded with encryption
software specific to your sites. If you currently pass payment information to the Aloha POS from
another Aloha application, such as Aloha Orderman, you cannot implement a P2PE solution at this time.
P2PE functionality is certified with the following processor and hardware combinations within the Aloha
system.
Processor: Encryption Platform: Hardware Device:

TSYS (aka VisaNet) Voltage SecureData™ Ingenico iPP350 PIN pad device
First Data (aka CES) TransArmor VeriFone VX820 PIN pad device
The above PIN pad devices are EMV-capable devices.
POS DSHB v12.3 Implementation Guide Aloha Point-to-Point Encryption F - 1

This document references industry standard verbiage. To help you, you should be aware of the follow-
ing glossary of terms:
Acronym Term
P2PE Point-to-Point Encryption
PCI DSS Payment Card Industry Data Security Standards
FPE Format-Preserving Encryption
PAN Primary Account Number
AES Advanced Encryption Standard
P2PE Support for TSYS (VisaNet)

You can use P2PE functionality with the TSYS (VisaNet) processor with the Ingenico iPP350 PIN pad
device. Cardholder data is captured and encrypted using the Voltage Security encryption and then sent
to TSYS for decryption, using the Voltage SecureData Payments host. TSYS then sends the unencrypted
card data to the payment brands and issuing banks for further processing over a secure connection.
Once TSYS receives a response from the card payment brands and issuing bank, TSYS sends the
response back to the Aloha POS.
While P2PE is in use, guests and employees cannot slide or tap a card, or manually enter any card-
holder data on the POS terminals or within Aloha EDC directly. You must enter all cardholder data on
the iPP350 device. If the guest or employee attempts to swipe a card at the POS terminal, an error
appears, instructing them to use the PIN pad device instead. Cardholder data is never in clear text in
the Aloha environment. Only TSYS can decrypt the cardholder data for further processing.
Keep in mind, this is not a PCI P2PE validated solution; however, the merchant’s PCI QSA or
the acquirer shall determine the PCI scope reduction. Refer to the NCR Aloha POS Data Secu-
rity Implementation Guide for more information regarding this solution. We encourage Aloha
customers to read it prior to implementation.
F - 2 Aloha Point-to-Point Encryption POS DSHB v12.3 Implementation Guide

Figure 1 TSYS and Voltage P2PE Transaction Flow
Voltage Security offers an FPE that keeps credit card numbers protected without the need to modify or
alter their format or structure. FPE is a form of strong encryption that uses the Advanced Encryption
Standard (AES) algorithm to protect cardholder data according to industry standards, while preserving
the original data syntax and thus minimizing the impact on existing systems. Voltage uses AES FFX-
mode encryption to protect data.
Voltage provides a software development kit (SDK) to NCR Aloha that allows the use of two encryption
methods: TEP1 (whole track encryption) and TEP2 (structure preserving encryption). Aloha uses TEP2
to allow card processing through Aloha EDC and for reporting purposes.
Please refer to http://www.voltage.com for more information.
Here are some examples of how Voltage encrypts cardholder data:

• PAN – Primary Account Number - The first six and the last four digits are kept intact, while the
remaining digits are encrypted:
PAN before TEP2 510510 510510 5100 = 5105105105105100
PAN after TEP2 510510 243377 5100 = 5105102433775100
• Track Data - Sensitive Account Data
For encrypting Track 1 data:
Track1 data before %B5105105105100^840PUBLIC/JOHN

TEP2 Q^120422212345?
Track1 data after %B5105103065100^840PUBLIC/JOHN

TEP2 Q^1204222kzKsspG8?
For encrypting Track 2 data:
Track2 data before 5105105105105100=120422212345

TEP2
Track2 data after 5105103065100=1204222kzKsspG8

TEP2
P2PE Support for First Data (CES)

You can use P2PE functionality with the First Data (CES) processor and the Verifone VX820 PIN pad
device. Cardholder data is captured and encrypted using the First Data TransArmor security encryption
and then sent to First Data for decryption at the TransArmor vault. First Data then sends the unen-
crypted cardholder data to the payment brands and issuing banks for further processing over a secure
connection. Once First Data receives a response from the card payment brands and issuing bank, First
Data sends the response back to the Aloha POS with a token that replaces the account number (PAN).
A token ID is listed in the .txn file, for reference.
Keep in mind, this is not a PCI P2PE validated solution; however, the merchant’s PCI QSA or
the acquirer shall determine the PCI scope reduction. Refer to the NCR Aloha POS Data Secu-
rity Implementation Guide for more information regarding this solution. We encourage Aloha
customers to read it prior to implementation.

Figure 2 First Data and TransArmor P2PE Flow
TransArmor and VeriFone offer an FPE that keeps cardholder numbers protected without the need to
modify or alter their format or structure. FPE is a form of strong encryption that uses an Advanced
Encryption Standard (AES) 128-bit algorithm to protect cardholder data according to industry stan-
dards, while preserving the original data syntax and thus minimizing the impact on existing systems.
First Data partners with VeriFone to provide merchants a format-preserving encryption, which secures
cardholder data on a tamper-resistant device before it enters your environment in a format that other
applications interpret as valid cardholder data.
Here are some examples of how TransArmor encrypts cardholder data:
Standard Track Data 435688 760033 1588 = 08119212884426940234
Encrypted Track Data 435688 298101 1588 = 200117632108900331272

The algorithm encrypts data so the output is in the same length and character set as in the input. This
is beneficial for bin routing in Aloha environments. TransArmor then provides a token to replace sensi-
tive data post authorization. A PAN is sent to a centralized First Data server called a “vault” to tokenize
a transaction. After authorization, TransArmor generates a unique and random token number for use in
place of a PAN. In the Aloha system, only the last four digits of the credit card number are stored.
Encrypted Track Data 435688298101 1588
Tokenized Data 85531783655 1588
Please refer to the following link for more information:
http://www.firstdata.com/en_us/products/merchants/security-and-fraud-solutions/encryption-and-
tokenization.html
Hardware Support for P2PE

Effective with Aloha v12.3, you can use the Ingenico iPP350 and VeriFone VX820 PIN pad devices to
process credit, debit, EBT cash, and EBT food cards. These devices support a card slide, card tap, or
manual entry.
The Ingenico iPP350 is used with the Voltage TSYS P2PE solution.
Figure 3 Ingenico iPP350 PIN Pad Device
You can find more information on the device at http://ingenico.us/terminals/iPP350/.

The VeriFone VX820 is used with the TransArmor First Data P2PE solution.
Figure 4 Verifone VX820 PIN Pad Device
You can find more information on the device at http://www.verifone.com/products/hardware/pin-pad/

vx-820.

Configuring Aloha POS for P2PE
Prior to configuring the Aloha POS for Point-to-Point Encryption (P2PE), you must be in contact with
either First Data (CES) or TSYS (VisaNet) for the proper requirements, such as obtaining unique termi-
nal IDs, and the appropriate PIN pad, which is injected specifically for the NCR Aloha software and the
merchant. You must also have Aloha POS and Aloha EDC v12.3 and later, installed at the site.
Prior to implementing P2PE functionality, we highly recommend you remove all

existing sensitive cardholder data from the Aloha environment and settle all credit
card batches. Refer to the NCR Aloha CleanPan guide for instructions on removing
stored cardholder data.
1. Enable P2PE in Store Settings

For the first step, you must access Store Settings, to enable P2PE and define the encryption service you
want to use. Once defined, the system only allows you to select the applicable PIN pad in Terminal
Maintenance.
To enable P2PE in Store Settings:
1. Select Maintenance > Business > Store > Store Settings tab.
2. Select the Credit Card group at the bottom of the screen.
Figure 5 Store - Store Settings Tab - Credit Card Group
3. Under the ‘EDC Setup’ group bar, select either Voltage or TransArmor from the ‘Enable point
to point encryption and disable credit card entry on all POS terminals’ drop-down list.
4. Click Save and exit the Store function.
2. Assign a PIN Pad Device to a Terminal

You must assign a PIN pad device to each terminal that drives a PIN pad device. The system displays
Verifone VX820 if you have TransArmor selected in Store Settings, and displays Ingenico IPP350 if you
have Voltage selected in Store Settings.

As a P2PE requirement, you must also assign a unique terminal ID to each terminal driving a PIN pad.
These IDs are supplied by the processor. If you already have unique terminal IDs assigned, you may
have to obtain new terminal IDs.
To assign a PIN pad device to a terminal:
1. Select Maintenance > Hardware > Terminals.

2. Select a terminal you want to assign a PIN pad device from the drop-down list.
3. Select the Output Devices tab.
Figure 6 Terminals - Output Devices Tab
4. Select either Ingenico IPP350 or Verifone VX820 from the ‘Type’ drop-down list.
5. Select the port to use for the PIN pad device.
6. To assign a unique terminal ID, select the EDC Settings tab.
Figure 7 Terminals - EDC Settings Tab

7. Click Add to start a new processor record for the terminal.
8. Select the processor from the drop-down list.
9. Type the terminal ID number supplied by the processor in ‘Terminal ID.’
10. Click Save.
11. Repeat this procedure for each terminal using a PIN pad device.
12. Exit the Terminals function.
3. Create an ATG Profile

As an internal function, the Aloha system uses the Aloha Transaction Gateway (ATG) functionality to
enable P2PE. You must at least open the ATG function and create an ATG profile for the system to use.
If you already have an ATG profile record defined, you can skip this procedure.
To create an ATG profile:
1. Select Maintenance > System Settings > Aloha Transaction Gateway.

2. Click New.
3. Click Save and exit the Aloha Transaction Gateway function.
4. Create a P2PE Tender

You must create a new P2PE tender to enable the system to divert responses from the MSR to the PIN
pad device. When the cashier touches this tender in the FOH, Aloha sends the amount due to the PIN
pad for initialization. The PIN pad device detects the card type and guides the cardholder or employee
through the rest of the transaction flow.
To create a P2PE tender:
1. Select Maintenance > Payments > Tenders.

2. Click the New drop-down arrow, select Credit Card, and click OK.
3. Type a tender name, such as ‘PIN Pad.’
4. Select Active.
5. Select the Type tab.
Figure 8 Tenders - Type Tab
6. Select Not Applicable from the ‘Credit card provider’ drop-down list.
7. Click Save and exit the Tenders function.

5. Add a P2PE Tender to a Panel for QS
For Quick Service environments, you must also add the P2PE tender button to a panel in use.
To add a P2PE tender to a panel for QS:
1. Select Maintenance > Screen Designer > Quick Service Screen Designer.
2. Select Work with Panels.
3. Select Panel > Open Panel and select a panel containing your tenders.
4. Select Panel > New Button.
5. In the Properties dialog box, select Tender from the ‘Action’ drop-down list.
6. Select the P2PE tender from the ‘Tender’ drop-down list.
7. Configure the remaining options, such as appearance, font and color, as you would for any
other tender.
8. Click Panel > Save Panel.
9. Exit the Screen Designer function.
6. Refresh Data
After all settings are in place, you must select Utilities > Refresh POS & All Products to transfer the
new information to the FOH terminals, or wait for the End-of-Day (EOD) process to accomplish the data
refresh for you. After the data refresh is complete, all new settings become operational across the
Aloha network.

Configuring Aloha EDC for P2PE
After you configure the Aloha POS, you must configure Aloha EDC for P2PE.
1. Configure a CES or TSYS (VisaNet) Processor for P2PE

You must configure either the First Data (CES) or TSYS (VisaNet) processor for P2PE. If you are using
CES, you must also go to the FOH and activate the PIN pad.
To configure the CES or TSYS (VisaNet) processor for P2PE:
1. Select Maintenance > Electronic Draft Capture > Processors.

2. Select either CES or Visa Net from the drop-down list or click the New drop-down arrow,
select the processor, and click OK.
Figure 9 Processors - Processor Tab (CES)
3. Under the ‘Point to point encryption’ group bar, select Enable point to point encryption and
disable credit card entry in EDC.
4. If the processor is CES, perform the following:
a. Type the VSP domain provided by CES.
b. Type the VSP brand provided by CES.
c. Type the Token ID provided by CES.
5. If the processor is TSYS (VisaNet), type the authentication code provided by TSYS.
6. If you are configuring the processor for the first time, complete the remaining options as you
would for any other processor.
7. Click Save and exit the Processor function.

2. Activating P2PE on a VeriFone PIN Pad
If you are implementing a VeriFone PIN pad with TransArmor/First Data (CES), you must ensure activa-
tion between the POS and the TransArmor Vault. This requires a “RegiStart” card (provided by CES) and
it is necessary to perform the following steps on each VeriFone PIN pad.
You must perform a refresh prior to activating P2PE on a VeriFone PIN pad on the FOH.
To perform the RegiStart process:
1. Log in to a FOH terminal with a VeriFone PIN pad device attached.

2. Start a new check.
3. Add an item for $1.00 to the check. This may be an open item.
4. Order the item
5. Navigate to the tender screen/panel.
6. Touch the ‘P2PE tender.’ This initializes the PIN pad with the amount due.
7. Slide the RegiStart card through the MSR on the PIN pad. A declined message appears on the
POS and a “RegiStart Successful” message appears on the PIN pad display.
8. Once successfully registered, delete the declined tender from the check and log out of the
terminal.
9. Repeat this procedure for each POS terminal attached to a VeriFone PIN pad. You can use the
same check for each terminal.

Using P2PE Functionality
Once implemented, you can start using P2PE functionality. When enabled, you cannot use the magnetic
stripe reader to capture cardholder information for a credit, debit, or EBT card. You must use the PIN
pad to complete the transaction.
To use P2PE functionality:
1. Start a check.
2. Add and order items on the check.
3. Access your tender screen.
4. Select the PIN Pad tender configured for P2PE. The tender screen appears with the sales
amount populated in the ‘Amount’ prompt.
5. Confirm the amount by touching OK. The PIN pad takes over and the guest or employee must
complete the transaction using the PIN pad device.
6. Follow the prompts on the PIN pad to manually enter the data, or slide or tap the card across
the PIN pad reader.
7. Enter the tip amount, if necessary.
8. Touch OK to approve the amount of the transaction. The system sends the transaction to the
appropriate vault or issuing bank for further encryption. If you are using First Data (CES), a
token is inserted in the cardholder number.

Aloha POSv12.3 Data Security Implementation Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Aloha POSv12.3 Data Security Implementation Guide

Uploaded by

Copyright:

Available Formats

NCR Aloha Suite Data

POS DSHB v12.3 Implementation Guide iii

POS DSHB v12.3 Implementation Guide Introduction v

Document Publication and Update Frequency

Defining the PCI DSS Requirements

Operating System Validation

vi POS DSHB v12.3 Implementation Guide

What Must I Do to Comply?

How Can I Maintain Compliance?

POS DSHB v12.3 Implementation Guide vii

What Is the NCR Aloha Suite Version

Breakdown of New Version Numbers

Year Last two digits of the calendar year

viii POS DSHB v12.3 Implementation Guide

Build and Maintain a Secure Network.................................................................... 1-12

Understanding the PCI DSS Requirements Tables

Securely delete files related to troubleshooting, after they are no lon-

We suggest configuring the NCR Aloha Suite to suppress printing the

We suggest using Aloha CleanPAN to remove possible residual sensitive

Requirement Requirement Summary, and Links

Implement Strong Access Control Measures

Maintain an Information Security Policy

Requirement 1: Install and maintain a firewall

Configuring the Windows Network

Configuring the Aloha Network

Configuring EDC for Secure Data Storage

To move non-temporary EDC files outside the Iberdir file structure:

Implementing 128-bit Encryption in Aloha Installations

Configuring Aloha for Audit Report Security

Figure 1 - 1 Security Roles, Audit Report Permission Configuration

Requirement 2: Do not use vendor-supplied defaults

Protecting Wireless Transmissions

Wireless Key Management

Change the wireless encryption keys per the following:

Daily Operational Considerations

Facilitating Secure Remote Software Updates

Best practices in this area are as follows:

Encrypting Sensitive Traffic Over Public Networks

Encrypting all Non-Console Administrative Access

Requirement 3: Protect Stored Cardholder Data

Creating Secure Payment Card Tenders

Figure 1 - 2 Tender Maintenance, Type Tab, Options Settings

• On the Type tab, Use Magnetic Card ONLY: Selected

Deleting Files Securely

File Location Contents Secure Deletion

EDCProcPath, IBERDIR, and LOCALDIR are environmental variables defined at

Secure File Deletion, Other Considerations (SH3)

Suppress Printing the Cardholder Name

Figure 1 - 3 Store Settings, Credit Card Group, Voucher Print Settings

• Suppress Cardholder Name: Optional, but we recommend selecting this option.

Mask the Primary Account Number (PAN)

Print Security Considerations and the Audit Report

Requirement 4: Encrypt transmission of cardholder

Requirement 5: Use and regularly update anti-virus

Requirement 7: Restrict access to cardholder data

Requirement 8: Assign a unique ID to each person

Refer to RKSID#11290 to download EncryptAutoLogon.exe and additional informa-

Figure 1 - 4 Configuration Management Tool, Password Rules

Figure 1 - 5 Password reset

Figure 1 - 6 Security Roles, Security Role Tab

• Screen timeouts in seconds (maximum, zero not allowed): 900 seconds

Figure 1 - 7 Store Settings, Security Tab, POS Password Configuration

• Min Password Digits: 3