Business White Paper

commercelab.ipcommerce.com

PA-DSS Compliance and

Commerce Toolkit for
Applications
Published July 21, 2009 by IP Commerce
Business White Paper PA-DSS Compliance and Commerce Toolkit for Applications from Commerce Lab

Introduction
In 2004, the payment card brands aligned their individual cardholder data protection programs to create the Payment
Card Industry Data Security Standard (PCI DSS). This alignment in standards provides an industry-wide framework
that forms the basis of each association’s individual security programs. The objective of the individual programs is to
compel merchants and payment service providers to enact measures that protect cardholder information. The goal of
the PCI DSS is to specify the security controls required to protect cardholder data in the transaction-processing
environment from end-to-end.

In addition to the operational controls specified by the PCI DSS, Visa developed a voluntary validation program
called Payment Application Best Practices (PABP). Visa derived the PABP validation requirements from the PCI
DSS. These best practices were designed to help software companies create secure payment applications. While
PABP compliance was initially voluntary, by the end of 2008 the Payment Card Industry Security Standards Council
(an association set up by American Express, Japan Credit Bureau, MasterCard, and VISA International to promote
financial data security standards) sanctioned it as a mandatory standard and changed the name to Payment
Applications Data Security Standard (PA-DSS).

Visa’s Payment Application Security Mandates

In addition to the adoption of a specific standard, Visa has released mandates surrounding the use of secure
Payment Applications by merchants accepting Visa cards.

http://usa.visa.com/merchants/risk_management/cisp_key_dates.html

1/1/08 Newly boarded merchants must not use known vulnerable payment applications, and VisaNet Processors
(VNPs) and agents must not certify new payment applications to their platforms that are known vulnerable payment
applications

7/1/08 VNPs and agents must only certify new payment applications to their platforms that are PA-DSS compliant

10/1/08 Newly boarded Level 3 and 4 merchants must be PCI DSS compliant or use PA-DSS-compliant applications

10/1/09 VNPs and agents must decertify all vulnerable payment applications

7/1/10 – Acquirers must ensure their merchants, VNPs and agents use only PA-DSS compliant applications

Who is Affected by PA-DSS?

PA-DSS applies to software companies and integrators of payment applications that store, process or transmit
cardholder data as part of authorization or settlement when these applications are sold, distributed, or licensed to
third parties. Payment applications, when implemented according to PA-DSS and when implemented in a PCI DSS
compliant environment, should facilitate and support driving merchant level PCI DSS compliance.

http://commercelab.ipcommerce.com Page 2
Business White Paper PA-DSS Compliance and Commerce Toolkit for Applications from Commerce Lab

Why Compliance Matters

Right now, Credit Card Processors are contacting your customers requiring them to update to a PCI compliant
environment or to use a PA-DSS compliant application as the 10/1/09 decertification mandate approaches. This
means that software companies, VARs and SIs who do not develop or deploy PA-DSS compliant solutions, will soon
be left behind their competitors who do, and will rapidly lose their reseller base.

The payments industry is complicated; writing software is complicated; PA-DSS is complicated. Without the proper
tools and guidance, a software company can easily lose its way. Leveraging IP Commerce tools, processes, and
partners; software companies can achieve compliance in record time and at a greatly reduced cost. For more, see
Appendix: Simplify Integration and Compliance with Commerce Toolkit for Applications.

Commerce Toolkit for Applications

Building a secure payment processing
application is intricate enough, before even
beginning to consider achieving PA-DSS
compliance. Using Commerce Toolkit for
Applications (CTA), developers can simplify the
process of creating compliant payment
applications. More information about the Rapid
Compliance Program is provided as an
appendix to this document.

The Transaction API, provided with the Toolkit,

gives an application what it needs to be ready
to process an ever-growing number of
electronic payment types from a wide variety of
providers and processors. The API does all the
heavy lifting associated with building
transactions that can be processed over the IP
Commerce Platform. It contains a layer of .NET
classes that sits on top of the Payments
Transaction Layer Switching (PTLS™)
specification. (PTLS–developed, owned and
provided by IP Commerce–is an XML software
specification for payment transactions and other payments-related messages.) With the Transaction API, developers
can create and populate service messages and then use the Toolkit to securely send the messages to the IP
Commerce Platform, where they are routed to the appropriate service provider.

In addition to easing the load of payment-enabling an application, CTA also provides an essential set of tools for
building payment applications that meet PA-DSS requirements including: functionality for providing secure user
authentication, key management, pre-persistence data processing (encryption, masking, removal of cardholder data),
activity logging, and secure transport protocols.

http://commercelab.ipcommerce.com Page 3
Business White Paper PA-DSS Compliance and Commerce Toolkit for Applications from Commerce Lab

Current PA-DSS Requirements

1. Do not retain full magnetic stripe, card validation
code or value (CAV2, CID, CVC2, CVV2), or PIN
block data
2. Protect stored cardholder data
3. Provide secure authentication features
4. Log payment application activity
5. Develop secure payment applications
6. Protect wireless transmissions
7. Test payment 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 payment
application
12. Encrypt sensitive traffic over public networks
13. Encrypt all non-console administrative access
14. Maintain instructional document and training
programs for customers, resellers, and integration

Commerce Toolkit for Applications (CTA)

and PA-DSS Components
Leveraging CTA to create compliant payment applications addresses PA-DSS requirements with specific attention to
requirements dictating:

ƒ Requirement 1 Do not retain full magnetic stripe, card validation code or value, or PIN block data

ƒ Requirement 2 Protect Stored Cardholder Data

ƒ Requirement 3 Provide Secure Authentication Features

ƒ Requirement 4 Log Payment Application Activity

ƒ Requirement 12 Encrypt Sensitive Traffic Over Public Networks

ƒ Requirement 14 Maintain instructional document and training programs for customers, resellers, and integrators

PA-DSS, when treated in its entirety, dictates not only code-level implementation of the payment application, but also
business process surrounding documentation and updates. CTA, when implemented with all appropriate controls,
addresses the technical complexity of the requirements noted above. This limits the complexity and scope of an
assessment process, allowing the developer to focus on the less tangible elements of the assessment process
thereby reducing cost and duration of the process on an ongoing basis.

Secure Objects
Requirement 1 Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CVC2, CVV2), or
PIN block data

ƒ 1.1 Do not store sensitive authentication data subsequent to authorization (even if encrypted): Sensitive
authentication data includes the data cited in PA-DSS Requirements 1.1.1 through 1.1.3

http://commercelab.ipcommerce.com Page 4
Business White Paper PA-DSS Compliance and Commerce Toolkit for Applications from Commerce Lab

CTA does not persist transaction data. An application is responsible for persisting transaction data and must not
store elements identified by the PA-DSS requirements. CTA’s messaging API provides functionality for protecting
request and response message data. While an application can provide cardholder data to the CTA for the purpose of
building and sending a transaction request message, the messaging API automatically secures all Action objects
after calling the objects Send() method. During this process, data items stored in the components that cannot be
persisted are removed. An application must only de-serialize and persist secure Action objects to ensure compliance
with PA-DSS and PCI DSS guidelines.

Pre-Persistence Data Processing

Commerce Toolkit for Applications provides functionality to help ensure cardholder data is being stored properly by
payment applications. Knowing what cardholder and transaction data to encrypt, mask and actually remove is
facilitated by leveraging this component of CTA during the development of a payment application.

Requirement 2 Protect Stored Cardholder Data

ƒ 2.2 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed)

ƒ 2.3 Render PAN, at a minimum, unreadable anywhere it is stored, (including data on portable digital media, backup
media, and in logs) by using any of the following approaches: 1) One way hashes based on strong cryptography, 2)
Truncation, 3) Index tokens and pads (pads must be securely stored), 4) Strong cryptography with associated key
management processes and procedures. The MINIMUM account information that must be rendered unreadable is
the PAN

Poorly designed point-of-service devices and applications can be a major security risk to cardholder data. Over
recent months, these security issues have been highlighted by the outbreak of fraud associated with credit and PIN
debit transactions. CTA helps developers create payment applications that handle data storage in a way that is highly
secure and meets the requirements set forth in PA-DSS. The Toolkit handles the encryption, masking and removal of
sensitive information prior to data persistence through its store method.

Key Management
Encryption is one of the most important protection mechanisms. If other security controls are defeated and an
intruder gains data-level access, the encryption layer provides an additional, final point of protection. Protecting the
“keys” used to encrypt data is as important as the level and method of cryptography.

Requirement 2 Protect Stored Cardholder Data

ƒ 2.5 Payment application must protect cryptographic keys used for encryption of cardholder data against disclosure
and misuse

ƒ 2.6 Payment application must implement key management processes and procedures for cryptographic keys used
for encryption of cardholder data

http://commercelab.ipcommerce.com Page 5
Business White Paper PA-DSS Compliance and Commerce Toolkit for Applications from Commerce Lab

Commerce Toolkit for Applications uses only open non-proprietary encryption algorithms for symmetric and
asymmetric encryption, and hashing procedures. By removing from developers the onus of coding secure encryption,
the Toolkit makes it easier for them to focus on the business logic of their applications. The Toolkit contains a few
easy-to-implement methods that protect data from a host of attacks and brings the application into compliance with
PA-DSS standards.

User Authentication
Due to the sensitive nature of data stored and transmitted by payment applications, only those users with the proper
permissions should be able to authenticate themselves with applications and have access to such data.
Implementing this type of security can be difficult, especially once any level of complexity is introduced.

Requirement 3 Provide Secure Authentication Features

ƒ 3.1 The “out of the box” installation of the payment application in place at the completion of the installation process,
must facilitate use of unique user IDs and secure authentication (defined at PCI DSS Requirements 8.1., 8.2, and
8.5.8-8.5.15) for all administrative access and for all access to cardholder data

ƒ 3.2 Access to PCs, servers, and databases with payment applications should require a unique user ID and secure
authentication

ƒ 3.3 Render payment application passwords unreadable during transmission and storage, using strong cryptography
based on approved standards

PA-DSS and PCI DSS require implementing a series of standards and procedures for managing passwords and
authentication. CTA implements these into an easy-to-use, reusable framework. This reduces the need for
developers to gain expertise in the PA-DSS and PCI standards. They can be confident that by implementing the few
simple methods provided by CTA, they are providing PA-DSS and PCI compliant user password management and
authentication.

Activity Logging
One of the base tenets of PA-DSS and PCI DSS compliance is that the software should support an incident
response. As such, it is of the utmost importance that payment applications provide audit trails to help determine the
nature and severity of a security breach. Specifically, payment applications must maintain the appropriate level of
activity logs. These logging mechanisms are necessary for proactive monitoring of user activity, event tracking, and
fault analysis in case data is compromised.

Requirement 4 Log Payment Application Activity

ƒ 4.1 At the completion of the installation process, the “out of the box” default installation of the payment application
must log all user access (especially users with administrative privileges), and be able to link all activities to individual
users

ƒ 4.2 Payment application must implement an automated audit trail to track and monitor access

http://commercelab.ipcommerce.com Page 6
Business White Paper PA-DSS Compliance and Commerce Toolkit for Applications from Commerce Lab

CTA implements activity logging in two ways. First, it provides a way to log either Error or Error/Debugging level
events to an I/O file. Secondly, since many application developers will also want to leverage event logging from
within their applications, the Toolkit also provides a method for raising logging events to the consuming application.
These events will always fire whether or not the I/O log file is being written. Application developers can consume
these events and either ignore them or log them in a way that makes sense for their application.

In addition to the normal logging procedures previously described CTA raises logging messages for specific events in
the system pertaining to user authentication and user security. Logging these events is mandated by PA-DSS and
PCI DSS. As long as the application either has the default I/O logging turned on or consumes the events in a
compliant fashion, it will satisfy the PA-DSS and PCI DSS activity logging requirements.

Secure Transport Protocols

In recent years, the emergence of widely available high-speed Internet connectivity has encouraged the transmission
of sensitive data in higher volume. This data, whether or not it is payment specific, is at risk when not properly
protected. Using accepted cryptography standards, as supported in CTA, ensures that customer data is protected
and minimizes developer liability.

Requirement 12 Encrypt Sensitive Traffic Over Public Networks

ƒ 12.1 If the payment applications sends, or facilitates sending, cardholder data over public networks, the payment
application must support use of strong cryptography and security protocols such as SSL/TLS and Internet protocol
security (IPSEC) to safeguard sensitive cardholder data during transmission over open, public networks

ƒ 12.2 The payment application must never send unencrypted PANs by end-user messaging technologies (for
example, e-mail, instant messaging, chat)

CTA provides the underlying framework for secure transport protocols by implementing HTTPS, SSL and SSL Mutual
Authentication, and secure Web services as a means of protecting Internet traffic communication. These are
standard protocols that can be difficult and time consuming to implement. The Toolkit saves development time by
providing methods for implementing these protocols. Developers can also be confident in the fact that these
protocols are implemented using the most current open standards for encryption, certificates, WS-Security and
SSL/TLS.

PA-DSS Implementation Guide

PA-DSS requirements cover not only the methodology by which a software application is built but, also, the process
by which documentation is provided to facilitate customer, reseller and integrator interaction with (and usage of) the
application.

Requirement 14 Maintain instructional documentation and training programs for customers, resellers, and
integrators

ƒ 14.1 Develop, maintain, and dissemination a PA-DSS Implementation Guide(s) for customers, resellers, and
integrators

http://commercelab.ipcommerce.com Page 7
Business White Paper PA-DSS Compliance and Commerce Toolkit for Applications from Commerce Lab

CTA provides a complete PA-DSS Implementation Guide that can be used either holistically as part of the
assessment process or as a template to ensure compliance with Requirement 14 of PA-DSS. The document
provides a list of recommendations for PA-DSS compliant implementation of CTA upon successfully completing the
integration process.

About IP Commerce, Inc.

Based in Denver, Colo., IP Commerce, Inc. is a software company that provides dramatically simplified development,
certification, and deployment of secure commerce solutions. The company's IP Commerce Platform, Commerce Lab,
and Commerce Marketplace unites software companies, service providers and distribution channels in a private-
labeled end-to-end network delivering on-demand access to commerce services, -- far more quickly, easily and
securely than ever before. IP Commerce opens worlds of commerce.

IP Commerce maintains partnerships with some of the world's most respected financial institutions and software
companies. The company is backed by leading investors, including Meritage Funds, Venrock, and Appian Ventures.
For more information, visit ipcommerce.com.

http://commercelab.ipcommerce.com Page 8
Business White Paper PA-DSS Compliance and Commerce Toolkit for Applications from Commerce Lab

Appendix: Simplify Integration and Compliance with

Commerce Toolkit for Applications
The PA-DSS Rapid Compliance Program, offered by IP Commerce, provides a fast and affordable way to achieve
successful PA-DSS assessment with easy-to-use tools and a proven process designed to manage PA-DSS
compliance, integration, and go-to-market activities in one bundled solution.

This program is incorporated directly into the IP Commerce Solution Integration and Certification process. Leveraging
IP Commerce’s suite of integration tools and proven end-to-end lifecycle management workflow, coupled with rapid
certification and compliance tools allows software companies to manage integration and compliance efforts
simultaneously – saving valuable time and money.

Because security and compliance requirements differ for various types of solutions, the Rapid Compliance Program
applies targeted “Fast Track” guidance and pricing to enable the lowest possible assessment cost.

Unique Fast Track programs are tailored for:

ƒ Standalone Desktop Applications

ƒ Point-of-Sale Applications

ƒ Client/Server Applications

ƒ Web-based eCommerce Applications

ƒ Hosted Solutions

When software companies commerce-enable their applications using Commerce Toolkit for Applications, and stay on
the Fast Track, they are all but assured to successfully achieve PA-DSS compliance validation at the least possible
cost.

http://commercelab.ipcommerce.com Page 9