Transcript Protect Cardholder Data - M

PCI PABP Training Module
The purpose of this training module is to educate
Micro$ale resellers and users on the best methods for
setting up and maintaining an environment for the
Micro$ale POS System that will securely protect the
sensitive cardholder data used during payment
processing based on the standards created by the
Payment Card Industry.
Setting up systems using these standards also helps
prevent and detect unauthorized access to a system and
establishes good forensic evidence that can be used to
determine what happened, how it happened, and who
was involved in the event of a compromise.
This Training Module is also intended to help us all
develop repeatable, documented best practices.
Payment Card Industry Data Security Standard
Systems which process payment transactions necessarily handle
sensitive cardholder account information.
The Payment Card Industry (PCI) has developed security standards for
handling sensitive cardholder information in a published standard
called the PCI Data Security Standard (DSS).
The security requirements defined in the DSS apply to all members,
merchants, and service providers that store, process or transmit
cardholder data. The PCI DSS requirements apply to all system
components within the payment application environment which is
defined as any network device, host, or application included in, or
connected to, a network segment where cardholder data is stored,
processed or transmitted.
PCI DSS Core Requirements
Build and Maintain a Secure Network
1. Install and maintain a firewall configuration to protect data
2. Do not use vendor-supplied defaults for system passwords and other security parameters
Protect Cardholder Data
3. Protect Stored Data
4. Encrypt transmission of cardholder data and sensitive information across public networks
Maintain a Vulnerability Management Program
5. Use and regularly update anti-virus software
6. Develop and maintain secure systems and applications
Implement Strong Access Control Measures
7. Restrict access to data by business need-to-know
8. Assign a unique ID to each person with computer access
9. Restrict physical access to cardholder data
Regularly Monitor and Test Networks
10. Track and monitor all access to network resources and cardholder data
11. Regularly test security systems and processes
Maintain an Information Security Policy
12. Maintain a policy that addresses information security
Access Control
The PCI DSS requires that administrative access and access to cardholder
data in the payment processing environment be protected through the use of
unique user names and complex passwords. Default accounts should not be
used, and application logins should not have administrative privileges.
Unique user accounts (user names) indicate that every account used is
associated with an individual user and/or process. Additionally, any
default accounts provided with operating systems, databases and/or
devices should be removed, disabled, or renamed as possible, or at
least should be given PCI DSS compliant complex passwords and
then not be used. Examples of such default administrator accounts
not to use include the Windows “administrator” and SQL/MSDE “sa”.
Complex Passwords must be at least 7 characters long, they must
include both numeric and alphabetic characters, they must be
changed at least every 90 days, and new passwords can not be
the same as the last 4 passwords that were used.
Furthermore, accounts should be locked out for at least 30 minutes (or require administrator
reset) if an incorrect password is provided 6 times, and sessions idle for more than 15
minutes should require re-entry of username and password to reactivate the session.
Wireless Network Devices
In order to facilitate the safest environment to protect cardholder data, do NOT
process payments across a wireless network. Process all payments from
wired terminals protected by firewall services. Micro$ale does not recommend
and will not support wireless transmission of cardholder data.
The PCI standard requires the encryption of cardholder data transmitted over wireless connections.
The following items identify the PCI standard requirements for wireless connectivity to the payment
environment:
•Firewall/port filtering services should be placed between wireless access points and the payment application environment
with rules restricting access
•Use of appropriate encryption mechanisms such as VPN, SSL/TPS at 128 bit, WEP at 128 bit, and/or WPA
•If WEP is used the following additional requirements must be met:
•-Another encryption methodology must be used to protect cardholder data
•-If automated WEP key rotation is implemented key change should occur every ten to thirty minutes
•-If automated key change is not used, keys should be manually changed at least quarterly and when key personnel leave
•Vendor supplied defaults (administrator username/password, SSID, and SNMP community values) should be changed
•Access point should restrict access to known authorized devices (using MAC Address filtering)
(6.1.c) If customer could implement the payment application into a wireless environment,
instruct customers and resellers/integrators on PCI DSS-compliant wireless settings, per
PCI Data Security Standard 1.3.9, 2.1.1 and 4.1.1.
•If the application can not be installed in a wireless environment, specify that it is not possible and not supported.
Support Guidelines
Storage and Handling of Sensitive Data
There may be times when you must collect credit card data files and log files
to assist with support. Micro$ale encrypts sensitive data while stored, but
support technicians must follow these additional guidelines to insure data
security: only collect sensitive data when necessary for a specific issue, store
that data in a known, secure location with limited access, collect only the
specific data that is necessary for the issue at hand, and securely delete the
sensitive data immediately after use.
Support sessions should also be logged using Trouble Tickets so that there
is an audit trail showing who was involved, what was done, date, and time.
Micro$ale does NOT support the transmission of cardholder data via email,
and customers should be instructed to NEVER send cardholder data via email.
(1.1.6) Sensitive Credit Card data handling and storage considerations:
Resellers/integrators must collect sensitive authentication only when needed to solve a specific problem
•Resellers/integrators must store such data only in specific, known locations with limited access
•Resellers/integrators must collect only the limited amount of data needed to solve a specific problem
•Resellers/integrators must encrypt sensitive authentication data while stored
•Resellers/integrators must securely delete such data immediately after use.
Log Functions
Micro$ale automatically logs all functions involving access to cardholder data
and all functions requiring Administrative access including viewing the logs
themselves. Log settings are NOT configurable by the customer. The main
purposes for logging these events are to prevent or detect unauthorized access
and to provide good forensic evidence to reconstruct what occurred in the
event of a compromise. Logged information is stored in an encrypted database.
(4.2.b) If application log settings are configurable by the customer and customers or resellers/integrators
are responsible for implementing logging, examine PABP Implementation Guide prepared by the
vendor to verify that customers are instructed on how to set PCI DSS-compliant log settings.
Implement automated audit trails to reconstruct the following events, for all system components:
•All individual user accesses to cardholder data
•All actions taken by any individual with root or administrative privileges
•Access to all audit trails
•Invalid logical access attempts
•Use of identification and authentication mechanisms
•Initialization of the audit logs
•Creation and deletion of system-level objects.
Record at least the following audit trail entries for each event, for all system components:
•User identification
•Type of event
•Date and time
•Success or failure indication
•Origination of event
•Identity or name of affected data, system component, or resource.
Baseline System Configuration and
Merchant Account Requirements
Below are the operating systems and dependent application patch levels
and configurations supported and tested for continued PCI DSS compliance:
• Microsoft Windows 2000 Service Pack 4, Windows XP Professional with
Service Pack 2, Windows Server 2003, Windows Embedded for Point of
Service. All latest updates and hot-fixes should be tested and applied.
• 1.0 GHz CPU, 2.0 GHz or faster recommended
• 512 MB of RAM minimum, 1 GB or higher recommended
• 500 MB of available hard-disk space
• TCP/IP network connectivity.
• Current Anti-virus protection
Be sure to install anti-virus software, run regular virus scans on each
system, and update virus definitions regularly for optimal protection.
Merchant Account Setup:
•Credit card batch settlement must be initiated daily by the customer. Host-initiated
and timed batch settlements are not supported by Micro$ale.
•Merchant accounts must also be setup to use Merchant Category Code 5812 for
restaurants with gratuity capabilities.
Network Segmentation
The PCI DSS requires that firewall services be used (with NAT or PAT) to
segment network segments into logical security domains based on the
environmental needs for internet access. A simplified high-level diagram
of an expected network configuration is included here:
Processor
Backoffice Computer
Used for reports and data entry
Never store
cardholder data on
internet-accessible
systems.
POS1
POS workstation
File server that stores shared data
POS2
POS workstation
Internet
Router with Firewall Services
Switch
Ethernet Remote Kitchen Printer
(9.1.b) If customer could store cardholder data on a
server connected to the Internet, instruct customers and
resellers/integrators that they must not store cardholder
data on Internet-accessible systems (e.g., web server and
database server must not be on same server.)
Ethernet Remote Bar Printer
Transport Encryption and
Encryption Key Management
Micro$ale uses SSL for secure transmission of cardholder data across the
Internet. The PCI DSS requires the use of strong cryptography and encryption
techniques with at least a 128 bit encryption strength (either at the transport
layer with SSL or IPSEC; or at the data layer with algorithms such as RSA or
Triple-DES) to safeguard sensitive cardholder data during transmission over
public networks. PCI also requires that cardholder information is never sent via
email without strong encryption of the data.
Encryption keys for sensitive data are generated using an algorithm value
computed from one unique, static value and one random, dynamic value that
changes with each successful batch. This encryption key gets changed every
day after the credit card batch settlement is confirmed during the Daily Close
Out process.
The encryption key can also be changed on demand using the Clear Batch
administrator function in Micro$ale if there is evidence of an encryption key
compromise.
Remote Access and Support Considerations
Remote access is the ability to connect and interact with a remote network or computer
as if you were directly connected to that remote network or computer.
The best policy to ensure the safest and most secure environment for payment
processing is to not allow remote connections to merchant sites.
However, there may be times when you must connect remotely to a client site for support. Ensure that
any such remote connection is initiated by an outbound connection that does not require firewall port
enablement. The customer requesting support must monitor the system environment while the remote
connection is active.
Also, implement the following security features with regard to remote access software:
•Change all default settings when installing remote access or remote control software including
usernames and passwords.
•Use unique passwords for each customer.
•Allow connections from only specific (known) MAC or IP addresses
•Use strong authentication or complex passwords for logins
•Enable encrypted data transmission
•Enable account lockout after a certain number of failed login attempts
•Configure the system so a remote user must establish a Virtual Private Network (VPN)
connection via a firewall before access is allowed.
•Enable logging functions.
•Restrict access to customer passwords to authorized personnel only.
•Implement two-factor authentication for remote access to the network requiring unique
usernames, strong passwords, and an additional item such as a certificate, token, or VPN
with individual certificates.
Router, Firewall, and Authentication Protection
and Secure Modem Use
A network router with firewall services must be used to protect all systems
connected to the Internet. Change the default password for the router when it is
installed, and change it again at regular intervals not longer than 3 months. Use
unique passwords for each client, and restrict access to these passwords to
authorized personnel only. Do not enable any port forwarding for remote
connections or unnecessary services.
The PCI standard requires that if employees, administrators, or vendors are
granted remote access to the payment processing environment; access should
be authenticated using a two-factor authentication mechanism (username/
password and an additional authentication item such as a token or certificate).
In the case of vendor remote access accounts, in addition to the standard
access controls, vendor accounts should only be active while access is required
to provide service. Access rights should include only the access rights required
for the service rendered, and should be robustly audited.
When connecting via dial-up using a modem and phone line, ensure that the
customer only connects or turns on the modem when it is needed and that the
modem is turned off or disconnected immediately after the update is complete.
Non-Console Administration
Micro$ale, as an application, does not require or use third-party remote
access software (non-console administration).
Users and hosts within the payment application environment may need to use
third-party remote access software such as Remote Desktop (RDP)/Terminal
Server, pcAnywhere, etc. to access other hosts within the payment processing
environment.
However, to be compliant, every such session must be encrypted with at least
128-bit encryption (in addition to satisfying the requirement for two-factor
authentication required for users connecting from outside the payment
processing environment). For RDP/Terminal Services this means using the
high encryption setting on the server, and for pcAnywhere it means using
symmetric or public key options for encryption.
Additionally, the PCI user account and password requirements will apply to
these access methods as well.
Definition of Two-Factor Authentication for Access
In identifying and authorizing users for access, you must use of two of the three
authentication methods below to constitute valid two-factor authentication:
•Something you know, such as the User ID/Password combination
•Something you have, such as a Digital Certificate or RSA token
•Something you are, such as a Biometric ID mechanism
Note that two different sets of a single method (e.g., two User ID/Password
combinations) do not create a valid two-factor authentication scenario.
It is also important to note that both methods of authentication must
uniquely identify a specific person or user, not a group of people or users.
Traditional scenarios supported and expected for two-factor remote access
include the use of User ID/Password at the network or computer level in
combination with a Certificate or RSA SecureID used to authorize an
encrypted VPN connection.
Cost-Effective Solutions That Can Meet PABP/ PCI
Requirements Without Enabling “Full” Remote Access
Implementing two-factor authentication can be difficult and costly. There are other
options available by providing connectivity needed to support customers without
creating a “full” remote access solution. Remote access is the ability to connect and
interact with a remote network or computer as if you were directly connected to that
remote network or computer. “Full” remote access implies that this access is
available at will (no action required by the customer), and some level of network
communication is allowed to or through a firewall.
When considering alternative solutions, the following principles must be addressed to
ensure that the solution provides needed controls without enabling “full” remote access:
•Ensure that remote connectivity can be traced to a specific service request (this
would allow identification of the support technicians involved and the customer
requesting support).
•Ensure that the solution does not allow “on demand” or “always on” access.
Remote access must be turned on by the customer requesting support only
when needed, and it must be disabled as soon as the task is completed.
•Ensure the solution uses robust (at least 128 bit) encryption for all communications.
•Ensure that the solution does not allow for the exchange of credentials.
•Mandate that the customer environment must be monitored while access is enabled.
•Ensure that the connection is enabled by an outbound connection that does not
require firewall port enablement.
Remote Access via UltraVNC SC
One example of a Remote Access solution that can be implemented to meet
these requirements is UltraVNC SC (http://www.uvnc.com/). The Remote
Access must be configured to require the customer to initiate the access and
to connect to a specific IP address or range for support connectivity, and all
support personnel involved must be tracked in support logs or trouble tickets.
UltraVNC SC does not require installation and does not require firewall port
enablement at the customer location. The connection can only be initiated by
the customer requesting support. No incoming connections are supported, no
unattended service connections are possible, and the UltraVNC SC module can
only connect to the IP address you have predefined in the module itself.
Micro$ale Software Updates
We strive to correct software bugs as soon as they are discovered and make
patches available as quickly as possible. We are committed to releasing
patches for any known vulnerabilities within 30 days after discovery.
Micro$ale dealers will be notified by phone and/ or email when a necessary
patch is made available, and the patch will be transferred directly to them via
secure remote access, or an upgrade CD will be sent if secure remote access
is not available.
Micro$ale dealers are then responsible for going onsite or connecting via
remote access to update their customers. Micro$ale direct end users will be
notified by phone when a necessary patch is available, and the update will be
transferred directly to the customer site and installed remotely, or an upgrade
CD will be sent if secure remote access is not available.
When implementing Micro$ale updates remotely, technicians must apply the
same security and logging procedures discussed previously.
Upgrade Concerns
Primary goals when upgrading to a new version:
•Smooth transition into the new version
•Ability to reverse the upgrade if there are any problems
•Removal of all legacy cardholder data and cryptographic materials
Before Upgrading:
1. Settle all pending credit card batches.
UNBATCHED CHARGES WILL BE LOST AND IRRECOVERABLE!
2. Run a Daily and Weekly Closeout.
3. Close the Time Records for the current payroll period.
4. Print any desired historic sales reports
5. Make backups of pertinent data
6. Have the new license file and key ready (if applicable).
7. Have the converted employee and menu files ready.
8. Have the Upgrade setup files for the current version available in
case you need to reverse the upgrade.
Upgrades From Versions 1 – 3
These older versions cannot be upgraded, but the employee and menu data can
be saved and converted to be used with the new install of version 7.
Upgrade Procedures from versions 1 – 3:
1. Contact Micro$ale Support if you need assistance converting the employee and
menu files.
2. Copy Install CD or Upgrade files to each hard drive. This will ensure that you have
access to resources for setup and support in case the CD is lost or damaged or to
reverse an upgrade.
3. Install version 7 on the new hardware as a new install.
4. Copy the converted employee and menu files into each Micro$ale directory.
5. Configure the remaining settings as you would a brand new install.
6. When everything is finished, run a Financial Database Reset on each terminal to
remove the sales data generated during setup, testing, and training.
Upgrades From Versions 4 – 7
Upgrade Procedures from versions 4 – 7:
1. Make a backup copy of each Micro$ale directory on a flash drive.
2. Copy Install CD or Upgrade files to each hard drive.
3. Copy a blank Chk-Stat.mdb, CheckNo.mdb, Financial.mdb, and Approvals.mdb to all terminals EXCEPT the
file server(s) to remove extraneous legacy sales data.
4. Run setup.exe from the version 7 Upgrade folder on each terminal.
5. Delete files with the .lic extension in the Micro$ale directory. Copy the new license file to each terminal.
6. If you received a new hardware key, install the new drivers and attach the new key.
7. Start Micro$ale to initiate the automatic database update, but then exit back to Windows immediately.
8. Run the EmployeeUpdate.exe (only for versions earlier than 5.4.x)
9. Run Menu Conversion.exe (only for versions earlier than 5.4.x)
10. Start Micro$ale. Verify and Save the Register Options on each terminal (*see note below).
Save each sales tax, discount, gratuity, and service charge.
11. Run tests to ensure all terminals are communicating: make sure you can ring up and tender orders,
save employees and menu items, close audits, and run sales reports and closeouts without
errors. Run a test credit card charge for each card type, settle the test batch, and verify
deposits with the bank.
12. Run the Legacy Clean function of the DatabaseUtility.exe program to remove all legacy cardholder
data and cryptographic material from previous versions for PCI compliance.
13. After all tests are done, compact the databases on each terminal to make good backup (.bak) copies of
the database files.
NOTE:If you are upgrading from a version earlier than 5.4.x, we recommend that you replace the Register
Options.mdb with a blank one, and reconfigure the settings.
Reversing Upgrades
You must have the backup copy of each Micro$ale directory that you made
and the upgrade setup.exe file for the previous version that you upgraded
from in order to reverse the upgrade.
1. Uninstall all instances of Micro$ale from the Add/ Remove programs
section of the Control Panel.
2. Delete the remaining Micro$ale directory from C:\Program Files\
3. Restore the backup copy of the Micro$ale directory that you made for
that terminal.
4. Run setup.exe from the old version Upgrade folder to re-register
Micro$ale with Windows.
5. Repeat steps 3 and 4 for each terminal in the system.
Implementation of the System Must Not Allow for the
Preservation of Historical Data from Credit Cards
Remove Sensitive Data Stored by Previous Software Versions
An important part of the Micro$ale upgrade process is removing any and all historical
cardholder data that may be leftover from credit card processing using the old version.
Such removal is absolutely necessary for PCI compliance. All Micro$ale files from past
and current versions are stored in the directory C:\Program Files\Micro$ale\. Before
running live charges through the upgraded system, run the Legacy Clean Removal Tool
in the DatabaseUtility.exe program, or manually search for and delete any and all files
with the following names: Approvals.mdb, Approvals.bak
Last Batch.mdb, Last Batch.bak
DTBatch.mdb, DTBatch.bak
Terminalname Batch.mdb, Terminalname Batch.bak
(where Terminalname is the Windows network name of the computer)
Ensure that all backups of these files that were created are also securely deleted.
Micro$ale does not and cannot store card validation values or codes, PINs, or PIN block data.
(1.1.4) Delete any magnetic stripe data, card validation values or codes, and PINs or
PIN block data stored by previous versions of the software.
•historical data must be removed (magnetic stripe data, card validation codes, PINs, or PIN blocks stored
by previous versions of the software) – removal is absolutely necessary for PCI compliance
Current Encryption Required for Sensitive Data
Remove Cryptographic Key Material Stored by Previous Software Versions
Again, it is important during the upgrade process to remove all legacy cryptographic
material from previous versions. Such removal is absolutely necessary for PCI
compliance. All Micro$ale files from past and current versions are stored in the directory
C:\Program Files\Micro$ale\. Before running live charges through the upgraded system,
run the Legacy Clean Removal Tool in the DatabaseUtility.exe program, or manually
search for and delete any and all files with the following names:
CCEncrypter.exe
Approvals.mdb, Approvals.bak
Last Batch.mdb, Last Batch.bak
SitenameAddress.71x (encrypted license file)
(where SitenameAddress is the merchant business name and address)
Ensure that all backups of these files that were created are also securely deleted.
(1.1.5 & 6) Delete any cryptographic key material or cryptogram stored by previous
versions of the software. This could be cryptographic keys used for computation or
verification of cardholder data or sensitive authentication data.
•remove historical cryptographic material - removal is absolutely necessary for PCI compliance
Legacy Data Removal for Upgrades
Run the DatabaseUtility.exe in the Micro$ale directory, click on the Removal
Tools pull-down menu, and select Legacy Clean. This will display all legacy
files containing old cardholder data or cryptographic material.
Click the Select All button to mark all files for removal, and click Remove
Files. All selected files will be deleted from the local Micro$ale directory.
You must run the DatabaseUtility.exe program at each terminal to ensure all
legacy cardholder data and cryptographic materials have been removed from
the system.
Such removal is absolutely necessary for PCI compliance.
Test Accounts
Ensure all test accounts, test card numbers, and test charges are removed
from the system prior to a new installation.
Ensure all test accounts, test card numbers, and test charges are removed
before releasing or implementing software updates or patches.
Furthermore, ensure that “live” credit card account numbers are not used
with a test merchant account, and vice versa.
Information Security Policy/ Program
In addition to the preceding security recommendations, a comprehensive
approach to assessing and maintaining the security compliance of the
payment application environment is necessary to protect the organization
and sensitive cardholder data.
The following is a very basic plan every merchant/service provider should adopt in developing and
implementing a security policy and program:
•Read the PCI DSS in full and perform a security gap analysis. Identify any gaps between existing
practices in your organization and those outlined by the PCI requirements.
•Once the gaps are identified, determine the steps to close the gaps and protect cardholder data.
Changes could mean adding new technologies to shore up firewall and perimeter controls, or
increasing the logging and archiving procedures associated with transaction data.
•Create an action plan for on-going compliance and assessment.
•Implement, monitor and maintain the plan. Compliance is not a one-time event. Regardless of merchant
or service provider level, all entities should complete annual self-assessments using the PCI
Self Assessment Questionnaire.
•Call in outside experts as needed. Visa has published a Qualified Security Assessor List of companies
that can conduct on-site CISP compliance audits for Level 1 Merchants, and Level 1 and 2
Service Providers. MasterCard has published a Compliant Security Vendor List of SDPapproved scanning vendors as well.
Review Summary
This Training Module and accompanying PABP Implementation Guide are to
be reviewed and updated at least annually, when new software versions are
released, and when there are changes in the requirements set forth by the
Payment Card Industry.
PCI-PABP Implementation Guidance
Date last reviewed: 7/11/2008
Reviewed By: Steve Theroux
Date last modified: 7/11/2008
Modified By: Steve Theroux
PABP Training Module
Date last reviewed: 7/11/2008
Reviewed By: Steve Theroux
Date last modified: 7/11/2008
Modified By: Steve Theroux
More Information:
A copy of the Payment Card Industry (PCI) Data Security Standard from VISA’s security website is
available at the following Internet address:
https://www.pcisecuritystandards.org/tech/download_the_pci_dss.htm
Additional information for merchants from VISA is available at the following Internet address:
http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp_merchants.html?it=il|/busin
ess/accepting_visa/ops_risk_management/cisp.html|Merchants