PCI/CISP Implementation Guidance

For

PaymentDirector/FraudShield

Version 1.1

EFD – eFunds Corporation PABP/CISP Implementation Guidance

PaymentDirector/FraudShield
1
 Revision History:

Version Date Revision / Description Author

1.0 05/16/2007 Initial Document Creation Brian Grimsley
1.1 08/17/2007 Updated PaymentDirector/FraudShield information Brian Grimsley

EFD – eFunds Corporation PABP/CISP Implementation Guidance

PaymentDirector/FraudShield
2
 Table of Contents

PABP/CISP Implementation Guidance .......................................................................................... 1

Revision History: ............................................................................................................................ 2
Table of Contents............................................................................................................................ 3
Introduction ...................................................................................................................................................4
Visa U.S.A. Reference Documents.........................................................................................................5
Understanding “PABP” vs “PCI Compliance”....................................................................................6
The Payment Card Industry (PCI) Data Security.................................................................................6
1. Do not retain magnetic stripe or CCV2 Data .......................................................................................8
2. Protect Stored Data ..................................................................................................................................9
2.1. Key Management...............................................................................................................................9
2.2. Legacy Cardholder Data ...................................................................................................................9
3. Provide Secure Password Features / Environment Requirements ................................................ 10
3.1. Access Control ................................................................................................................................ 10
3.2. Remote Access ................................................................................................................................ 11
3.3. Non-Console Administration ....................................................................................................... 11
3.4. Wireless Access Control ................................................................................................................ 11
3.5. Transport Encryption .................................................................................................................... 12
3.6. Network Segmentation .................................................................................................................. 13
3.7. Information Security Policy/Program......................................................................................... 14
3.8. Log Application Activity ............................................................................................................... 15
3.9. Internet Security.............................................................................................................................. 16
4. Software Updates / Remote Administration ..................................................................................... 17
5. External Media Security......................................................................................................................... 19
6. 3rd Party Application Integration.......................................................................................................... 19

EFD – eFunds Corporation PABP/CISP Implementation Guidance

PaymentDirector/FraudShield
3
Introduction
To secure cardholder data by requiring that members, merchants, and service providers maintain the
highest information security standards, Visa and MasterCard have introduced PCI (Payment Card
Industry) standards. This new program specifies a number of policies and guidelines needed to
maintain a “secure” environment. In addition, PABP (Payment Applications Best Practices) have
been developed to assist software vendors in creating secure payment applications that help ensure
merchant compliance with the PCI Data Security Standard.

EFD—eFunds Corporation has made a number of application and procedural changes in order to
ensure that your PAYMENTDIRECTOR/FRAUDSHIELD software is compliant with these new
PABP requirements. Your use of a PABP-certified application simplifies some parts of your overall
PCI compliance effort. To however, EFD PAYMENTDIRECTOR/FRAUDSHIELD software
has been PABP (Payment Application Best Practices) certified, with specific EFD software
applications working in conjunction with an independent Visa U.S.A. approved auditing firm.

This document supports the following application(s):

■ PAYMENTDIRECTOR/FRAUDSHIELD version: 5.9

This document also outlines Visa’s Cardholder Information Security Program (CISP),
the Payment Card Industry (PCI) initiative and the Payment Application Best Practices
(PABP) guidelines. The document then provides specific instructions on how to utilize best
practices for using EFD software as a PABP Application operating in a PCI Compliant
environment.

For additional information or questions regarding the above applications, please contact your
eFunds account manager or use the contact information listed below:

EFD | eFunds Corporation

4900 North Scottsdale Road, Suite 1000
Scottsdale, Arizona 85251
Telephone: 1-866-707-9885
Telephone: (480) 629-7700

EFD – eFunds Corporation PABP/CISP Implementation Guidance

PaymentDirector/FraudShield
4
Visa U.S.A. Reference Documents
The following documents detail the Cardholder Information Security Program (CISP) and related
materials (e.g. PABP, PCI, etc):

■ Official VISA documentation may be found at http://www.visa.com/cisp. In the Payment

APP, look for the “PCI Data Security Standard” document, as well as “Payment Applications
Best Practices” (found under the “View All CISP Downloads” link). This site includes
information such as:

o Industry Letter to Merchants

o CISP Overview
o PCI Data Security Standard

■ Additional information for merchants from Visa is available at the following Internet address:
• www.atwcorp.com/pabp/authorizenet/CISP_PABP.pdf
• http://usa.visa.com/download/merchants/cisp_payment_application_best_prac
tices.doc

Please refer to Visa’s “Payment Applications Best Practices” document, as well as the associated
“Payment Card Industry Data Security Standard” document for full details on compliance
regulations.

EFD worked with the following Visa U.S.A. approved certification firm to obtain our PABP
Certification:

Ambiron TrustWave
120 N LaSalle Street
Suite 1250
Chicago, IL 60602
Phone: 312-873-7500
Fax: 312-443-8028
www.atwcorp.com

In summary, PABP is the standard against which EFD – eFunds Corporation has been tested and
certified. You are responsible for compliance with PCI based on your specific implementation of
this software, your software hosting environment, your data security policies, and so on by using

EFD – eFunds Corporation PABP/CISP Implementation Guidance

PaymentDirector/FraudShield
5
various hardware scans, port scans, and configuration evaluation testing methods. This is further
defined in the following section. We go into this definition because many users and merchants are
not clear as to the differences between “PABP” and “PCI Compliance.” While very closely inter-
related, they are different.

Understanding “PABP” vs “PCI Compliance”

As a software vendor, our responsibility is to be “PABP Compliant.” While this is not currently
required by Visa U.S.A, we felt it was important to take a leading position and obtain this
certification.

We have performed an audit and certification compliance review with our independent
auditing firm, to ensure that our platform/software does conform to current PABP standards when
handling, managing and storing payment related information.

Note: We want to reiterate that obtaining “PCI Compliance” falls on you

and your hosting provider, working together, using PCI compliant server architecture
with proper hardware & software configurations and access control procedures.

Additionally, EFD offers PCI ready hosting plans, suitable for installing EFD software, if you need.
Other hosting providers may also offer PCI compliant hosting options.

We have tested and certified to the Visa U.S.A. “Payment Application Best Practices”
(PABP) standard, to ensure that when you load an EFD software product into an environment
equivalent to our recommended PCI ready environment that our application is also following best
practices. This will help you achieve PCI compliance easily with respect to how EFD handles user
accounts, passwords, encryption, and other payment data related information.

After installation and initial certification to PCI standards, you should then follow our
recommended operational guidelines (defined later in this document) to ensure continued
best practices for management of your storefront. Visa U.S.A. specifies different levels of
compliance requirements, driven mostly by the annual transaction volume of your storefront. You
should read the documentation provided by Visa (see above) to determine the level of PCI
Compliance required for your business.

The Payment Card Industry (PCI) Data Security

Since your object as a merchant is to obtain PCI Compliance, we further define the PCI
requirements here to facilitate your compliance process. Remember, EFD has already been “PABP”
certified, so that alleviates the concern that our application could pose security risks that might
prevent you from obtaining PCI compliance. That is why we have obtained the PABP certification.

EFD – eFunds Corporation PABP/CISP Implementation Guidance

PaymentDirector/FraudShield
6
Systems that process payment transactions necessarily handle sensitive cardholder
account information, such as credit card numbers and user passwords.

The Payment Card Industry (PCI) Data Security Standard is a worldwide standard for
payment card and consumer financial data protection. It incorporates the requirements of
the Visa U.S.A. Cardholder Information Security Program (CISP) and the Visa
International Account Information Security (AIS) program, the MasterCard International
Site Data Protection (SDP) program, as well as the security requirements of American
Express DSS, DiscoverCard DISC and the Japan Credit Bureau (JCB).

The Payment Card Industry (PCI) has developed security standards for handling
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.

To be in compliance with this standard, all of your company's Internet connections,

assigned IP addresses, and all Internet connected servers (Web, e-mail, DNS, etc.) must
have no severity level 3, 4, or 5 vulnerabilities in their most recent security audit. Audits must be
conducted at least every 90 days. Various firms can assist with your scans,
including Coalfire Systems, ControlScan, or other firms.

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.

The following twelve high-level requirements comprise the core of the PCI DSS:

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

EFD – eFunds Corporation PABP/CISP Implementation Guidance

PaymentDirector/FraudShield
7
 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

The remainder of this document describes the essential guidance for installing,
configuring, and managing EFD software in a PCI ready environment.

1. Do not retain magnetic stripe or CCV2 Data

Encryption is a critical component of cardholder data protection. If an intruder circumvents other
network security controls and gains access to encrypted data, without the proper cryptographic keys,
the data is unreadable and unusable to that person. Other effective methods of protecting stored
data should be considered as potential risk mitigation opportunities. For example, methods for
minimizing risk include not storing cardholder data unless absolutely necessary, truncating
cardholder data if full PAN is not needed and not sending PAN in unencrypted e-mails.

The PCI standard requires the following:

■ Keep cardholder data storage to a minimum.
■ Do not store sensitive authentication data subsequent to authorization (even if encrypted).
Sensitive authentication data includes the data as cited in the following requirements:
• Do not store the full contents of any track from the magnetic stripe (that is on
the back of a card, in a chip, or elsewhere). This data is alternatively called full
track, track, track 1, track 2, and magnetic stripe data In the normal course of
business, the following data elements from the magnetic stripe may need to be
retained: the accountholder’s name, primary account number (PAN), expiration
date, and service code. To minimize risk, store only those data elements needed
for business. NEVER store the card verification code or value or PIN
verification value data elements. Note: See “Glossary” for additional information.
■ Do not store the card-validation code or value (three-digit or four-digit number printed on the
front or back of a payment card) used to verify card-not-present transactions

EFD – eFunds Corporation PABP/CISP Implementation Guidance

PaymentDirector/FraudShield
8
 • Do not store the personal identification number (PIN) or the encrypted PIN
block.

2. Protect Stored Data

PABP Sections 2.3/ 2.4

2.1. Key Management

The application must implement key management processes and procedures for keys used for
encryption of cardholder data and passwords. You must have a way to change the encryption key
annually. Also, you must perform the follow annually:
■ Securely remove old data encryption keys
■ Securely remove invalid data encryption keys
■ Securely remove encryption keys when compromised

If the data encryption keys are stored in keyfiles, when the data encryption keys are invalid or not
used any longer, they need to be deleted securely.

According to PABP guidelines, using ‘rm’ command in UNIX to simply delete the file is not
considered a secure deletion.
EFD recommends using the following as an example:
■ For Unix use srm (secure delete)

By using srm (secure delete), this removes each specified file by overwriting, renaming and
truncating the file before unlinking. This prevents others from undeleting or recovering any
information about the file from the command line.

2.2. Legacy Cardholder Data

The customer is responsible for ensuring that any unencrypted cardholder data which was present
prior to the installation of PAYMENTDIRECTOR/FRAUDSHIELD, is either encrypted, or
rendered permanently unreadable. This requirement may be met by either over-writing data (such as
a low-level disk format), or by modifying cardholder information to only contain masked values.
EFD recommends first making an encrypted backup of older information, and then low-level
formatting hard disks which contained unencrypted cardholder information.

EFD – eFunds Corporation PABP/CISP Implementation Guidance

PaymentDirector/FraudShield
9
Legacy information in “external” formats (such as printed documents, old receipts, or unencrypted
backups) should also be considered. These items should either be protected as per Data Security
Standard section 9, or destroyed.

3. Provide Secure Password Features / Environment Requirements

PABP Sections 3.1 / 3.2 / 3.3/3.4

3.1. Access Control

The PCI DSS requires that access to all systems in the payment processing environment
be protected through use of unique users and complex passwords. Unique user accounts
indicate that every account used is associated with an individual user and/or process with
no use of generic group accounts used by more than one user or process. Additionally
any default accounts provided with operating systems, databases, and/or devices, should
be removed/disabled/renamed as practicable, or at least should have PCI DSS compliant
complex passwords. Examples of default administrator accounts
include “administrator” (Windows systems), “sa” (SQL/MSDE), and “root” (UNIX/Linux).

The PCI standard requires the following password complexity for compliance (often
referred to as using “strong passwords”):

■ Passwords must be at least 7 characters

■ Passwords must include both numeric and alphabetic characters
■ Passwords must be changed at least every 90 days
■ New passwords can not be the same as the last 4 passwords
■ Application passwords must be encrypted within the files

PCI user-account requirements beyond uniqueness and password complexity are listed
below:

■ If an incorrect password is provided 6 times the account should be locked out

■ Account lock-out duration should be at least 30 minutes (or until an administrator resets it)
■ Sessions idle for more than 15 minutes should require re-entry of user name and password to
reactivate the session
■ In the event of termination, any administrator’s user account should be immediately disabled
or removed immediately

EFD – eFunds Corporation PABP/CISP Implementation Guidance

PaymentDirector/FraudShield
10
To be PCI compliant these same account and password criteria must also be applied to any
applications or databases included in payment processing.

The above guidelines pertain to any accounts that are capable of either administering network
security (such as firewall administration), or accounts capable of directly accessing the data files
through a means other than the software application itself. More details as to administrative access
may be found in PCI Data Security Standard sections 7, 8 and 9, or PABP standards sections 3.1,
3.2, and 3.4.

EFD software, as tested to in our PABP audit, meets, or exceeds these requirements.

3.2. Remote Access

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 (user name/ 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.

3.3. 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,
or similar 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.

3.4. Wireless Access Control

The PCI standard requires the encryption of cardholder data transmitted over wireless
connections. The following items identify the PCI standard requirements for wireless

EFD – eFunds Corporation PABP/CISP Implementation Guidance

PaymentDirector/FraudShield
11
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. EFD recommends placing any
wireless router(s) on an Internet DMZ.
■ 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 the organization
• Vendor supplied defaults (administrator username/password, SSID, and SNMP
community values) should be changed
• Access points should restrict access to known authorized devices (using MAC
Address filtering)
■ Wireless router “SSID broadcasts” must be disabled.
■ Disable any SNMP broadcasts or anonymous query capabilities. If SNMP is desired, ensure
that sensitive SNMP information is not in the “public” domain, and any vendor default
passwords have been changed.
■ EFD recommends always enabling “WPA encryption” on all wireless devices used.
■ EFD recommends placing any wireless routers on a “DMZ” network, thus requiring wireless
traffic to “pass through” a separate firewall device before reaching the software Application
server. This may be accomplished by placing your wireless router between your DSL/Cable
modem router and Firewall devices.

3.5. Transport Encryption

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 (this includes the Internet and
Internet accessible DMZ network segments).

Additionally, PCI requires that cardholder information never be sent via e-mail without

EFD – eFunds Corporation PABP/CISP Implementation Guidance

PaymentDirector/FraudShield
12
strong encryption of the data. EFD software does not transmit card information via e-mail. The use
of a properly installed 128-bit SSL certificate, available from your hosting provider, meets this
requirement. EFD software should then be configured to “go secure” on any page that involves
sensitive data (login pages, account pages, cart pages, payment pages, and so on).

3.6. 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. Traditionally, this corresponds to the creation of at least a DMZ and a
trusted network segment where only authorized, business-justified traffic from the DMZ
is allowed to connect to the trusted segment. No direct incoming Internet traffic to the
trusted application environment can be allowed. Additionally, outbound Internet access
from the trusted segment must be limited to required and justified ports and services.

A simplified high-level diagram of the PCI-ready environment that we performed PABP

certification on is shown below. This environment was created in full at EFD, where specific EFD
software was installed and audited. You can use this or equivalent architecture to achieve PCI
compliance. Check with your preferred hosting provider also to review and analyze if their
supported environments conform to PCI DSS requirements.

EFD – eFunds Corporation PABP/CISP Implementation Guidance

PaymentDirector/FraudShield
13
3.7. 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 both your 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:

EFD – eFunds Corporation PABP/CISP Implementation Guidance

PaymentDirector/FraudShield
14
 ■ 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
SDP-approved scanning vendors as well.

NOTE: We highly recommend contacting Ambiron TrustWare, the PABP auditing firm
which was use for EFD software.

3.8. Log Application Activity

The software must track and monitor all access to network resources and cardholder data. Logging
mechanisms and the ability to track user activities are critical. The presence of logs in all
environments allows thorough tracking and analysis if something does go wrong. Determining the
cause of a compromise is very difficult without system activity logs.
The application must log all user access (especially users with administrative privileges) and be able
to link all activities to individual users.

The following items pertain to Log application activity:

■ Implement automated audit trails for all system components to reconstruct the following
events:
• 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

EFD – eFunds Corporation PABP/CISP Implementation Guidance

PaymentDirector/FraudShield
15
 • 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 all system components for each event:
• 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
■ Synchronize all critical system clocks and times
■ Secure audit trails so they cannot be altered:
• Limit viewing of audit trails to those with a job-related need
• Protect audit trail files from unauthorized modifications
• Promptly back-up audit trail files to a centralized log server or media that is
difficult to alter
• Copy logs for wireless networks onto a log server on the internal LAN
• Use file integrity monitoring and change detection software on logs to ensure
that existing log data cannot be changed without generating alerts (although new
data being added should not cause an alert).

3.9. Internet Security

PABP Sections

The following items pertain to PAYMENTDIRECTOR/FRAUDSHIELD Application server

Internet security.

■ A firewall device must be used to protect the PAYMENTDIRECTOR/FRAUDSHIELD

application host and any computers connected to the
PAYMENTDIRECTOR/FRAUDSHIELD application host.

EFD – eFunds Corporation PABP/CISP Implementation Guidance

PaymentDirector/FraudShield
16
 ■ The firewall device should deny all “inbound” Internet traffic except for ports specifically
needed by the PAYMENTDIRECTOR/FRAUDSHIELD Application server (see general
product documentation).
■ Any vendor default passwords on the firewall device should be assigned a new complex
password.
■ All devices and computers that connect to the PAYMENTDIRECTOR/FRAUDSHIELD
Application server should be placed on a network protected by a firewall device.
■ “Mobile” computers (such as laptops) that connect to the
PAYMENTDIRECTOR/FRAUDSHIELD Application server should additionally have
“personal firewall” software active.
■ Sharing of devices (such as printers) across the Internet should occur via use of a VPN.

4. Software Updates / Remote Administration

PABP Sections 10. / 11

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 (user name/ 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.

In order to retain PABP compliance, certain remote administrative access criteria must be met:
■ EFD recommends remotely accessing the PAYMENTDIRECTOR/FRAUDSHIELD
Application server via a VPN (Virtual Private Network). In the event that a VPN is utilized to
access the PAYMENTDIRECTOR/FRAUDSHIELD application server, a unique, “per
client” encryption cePayment APPficate should be used, coupled with a strong password in
order to access the VPN. Only VPNs using IPSEC, PPTP or 128 bit (or greater) SSL
technologies may be used.
■ Any dial-in modem(s) which provide the capability of remote administrative support must be
turned off, or otherwise disabled, when not in use.
■ The “Payment APPsupport” UNIX user account should be disabled during times when not in
use.
■ “Two factor authentication” is required for any remote administrative access.

EFD – eFunds Corporation PABP/CISP Implementation Guidance

PaymentDirector/FraudShield
17
 • For PAYMENTDIRECTOR/FRAUDSHIELD Application server support,
EFD recommends the use of frequently rotated, password-protected, “secure
shell keypairs” for any external administrative access into the
PAYMENTDIRECTOR/FRAUDSHIELD Application server.
• For remote administration of firewall devices, EFD recommends accessing the
router device through a VPN that has been established with a “per-person”
cePayment APPficate and strong password.
■ Any administrative user account must comply with Visa PCI Standards as dictated in section
8. Some (but not all) of those requirements are as follows:
• Passwords must be at least 7 characters log, utilizing at least numbers and letters.
• All passwords must be changed every 90 days.
• A minimum of five (5) unique passwords must be used for each UNIX user.
• After six (6) failed login attempts, the user account should be disabled for a
minimum of fifteen (15) minutes.
■ In the event that EFD administrative access is needed on the
PAYMENTDIRECTOR/FRAUDSHIELD Application server, EFD will use the “Payment
APPsupport” Unix user account and possibly thereafter, the “root” user account.
■ EFD recommends that the “root” user account never be directly accessible remotely.
Administrators should instead log in as an account with “normal” user privileges, and then
use the “sudo” utility to execute privileged commands.
■ Unencrypted protocols (such as telnet, rsh, or FTP) must never be used to administer a
PAYMENTDIRECTOR/FRAUDSHIELD Application server, or transmit unencrypted
sensitive data. EFD recommends the use of the “ssh” protocol for any remote administration
of the PAYMENTDIRECTOR/FRAUDSHIELD Application server.
■ Unencrypted protocols (such as HTTP or telnet) must never be used to administer the
PAYMENTDIRECTOR/FRAUDSHIELD firewall device. EFD recommends the use of
either “HTTPS” or “ssh” protocols.
■ Automatic security update services (such as ‘yum’ in Linux) should always be enabled. The
system should periodically be checked to ensure that patches are available and being applied.
■ The firewall device “firmware” or “software” should be updated in the event that security
updates are made available by the vendor.

EFD – eFunds Corporation PABP/CISP Implementation Guidance

PaymentDirector/FraudShield
18
5. External Media Security
PABP Section 12.2

The following guidelines pertain to distributing cardholder data via “external” media such as paper
printouts (including reports, receipts and faxes), e-mails, or backup tapes.

■ Never send unencrypted cardholder data in any e-mail.

■ Never send credit card “CVV”, debit “PIN,” or “Swipe” information in an e-mail, even if
encrypted.
■ EFD recommends against printing cardholder information onto “permanent” form (such as
printed documents). If such information is printed, it should be physically protected as per
PCI standards section 9. Some steps to take include:
• Restrict physical access to printed documents containing cardholder information.
• Mark all documents containing cardholder information as “confidential”.
• Cross shred or burn unused documents.
■ No document should ever be printed that contains credit card “CVV”, debit “PIN,” or
“Swipe” values.
■ In the event that data backups are made onto external media (such as tapes, CDs, or Rev
disks), backups should be encrypted using a decryption key which is not present on the
backup media.

6. 3rd Party Application Integration

PABP Sections 1.1.1 / 1.1.2 / 1.1.3

Your PAYMENTDIRECTOR/FRAUDSHIELD Application server has been configured in a way

to best ensure PABP compliance. In order to maintain this level of secure integrity, EFD
recommends against the modification of system configurations, or the installation of additional
software on the PAYMENTDIRECTOR/FRAUDSHIELD application server.

In the event that any third party applications are added, or modifications made to the
PAYMENTDIRECTOR/FRAUDSHIELD application server, the additional application(s) must
not deny the integrity of PABP compliance. In keeping with PABP standards, the following rules
must also apply:

EFD – eFunds Corporation PABP/CISP Implementation Guidance

PaymentDirector/FraudShield
19
 ■ Any 3rd party applications installed must never retain Credit Card “CVV”, CVV2”, Swipe, or
Debit PIN information subsequent to (following) card authorization. (1.1.1/1.1.2/1.1.3)
■ In order to maintain security integrity, EFD does not recommend installation of any
additional applications onto the PAYMENT APP Application server. In the event that third
party applications are added to the PAYMENT APP application server that are capable of
accessing PAYMENT APP application data files, these applications must additionally
conform to the PCI Data Security Standards. (3.x.y)
■ In the event that any 3rd party applications produce log files containing cardholder
information, these log files must be removed immediately upon being used. The customer
should, by default, disable logging of full cardholder information.
■ Any 3rd party applications must encrypt any and all network communications. 128 bit SSL
(or greater) encryption must be used.

Once you have completed any system modifications, or software additions, EFD recommends you
perform a re-evaluation of PABP system compliance, as found in the Visa CISP “Payment
Applications Best Practices” document.

EFD – eFunds Corporation PABP/CISP Implementation Guidance

PaymentDirector/FraudShield
20