A White Paper on the Payment Card Industry “PCI

Transcription

PCI for i
A White Paper on the Payment Card Industry “PCI
DSS” Security Mandates, as it affects users of
the IBM Midrange System i who perform credit
card payment processing…
Copyright 2013
Curbstone “PCI for i” White Paper
888-844-8533
© 2013 Curbstone Corporation
Page 2 of 32
Executive Summary
Acceptance of debit and credit cards is a growing requirement for businesses of all sizes.
Since 2005, the Payment Card Industry Security Standards Council (PCI) has imposed
strict mandates, the Data Security Standards (DSS), to insure the security of the
computer systems that PROCESS, TRANSMIT, and/or STORE sensitive credit card data.
Every business that accepts card data in any way is subject to the requirements of the
PCI DSS, and the compliance requirements vary widely based on transaction volume,
type of business, handling of the card data, and software applications. At the top end, a
company could be required to have a third-party Qualified Security Auditor (QSA) who
has been certified by the PCI, to perform an on-site, extensive analysis of a merchant’s
operations and systems. The cost of these expensive and time consuming audits can be
controlled by partnering with an experienced organization with appropriate expertise.
Meeting these ever-intensifying PCI DSS mandates poses unique challenges to
companies whose main business system is the IBM Midrange AS/400, System i.
Some aspects of compliance are as simple as NEVER storing magnetic stripe data or the
card security code. Others are time consuming, like documenting every piece of
infrastructure hardware, its firmware revision and last update, and monitoring the logs
of all systems on a periodic basis.
888-844-8533
Page 3 of 32
10 Revealing Payment Apps Questions We Dare You Ask
1)
2)
3)
4)
5)
6)
7)
8)
9)
10)
Is it validated to the Payment Application Data Security Standard (PA-DSS)?
Is a specific person assigned responsibility for handling all of the security compliance?
Does it NOT store magnetic stripe data (track data) or PIN blocks? This storage is strictly prohibited!
Does it store primary account numbers (PANs) with strong encryption protection and have ALL access logged
in files that are periodically reviewed and unable to be altered?
Does it use a firewall with Stateful Packet Inspection to specifically protect our systems from unauthorized
access? Are the logs from the firewall monitored periodically?
Does EVERY person have their own unique User ID? Are complex, strong, and unique passwords required to
access our systems? Are those passwords forced to be changed periodically?
Have all system and software default settings and passwords been changed? And are those changes recorded
in a permanent log?
Have all unnecessary and insecure services been removed from these systems? Have those changes been
logged as they are performed?
Have all the systems been patched with all applicable security updates? Is every device in our system being
maintained with the latest firmware updates? Are the updates logged as they are performed?
Have we provided physical security for the systems and other devices that handle card info, including even fax
machines?
If you answered NO to ANY of these, you are likely in violation of the PCI DSS! These 10
questions only address two handfuls of the ~260 questions contained in the PCI SelfAssessment Questionnaire Level “D”. Curbstone’s software and systems are designed
to assist you in having the right answers about your Payment Application!
The Right Payment Partner
Choosing the right partner for your payment processing software and functions would
include their ability to minimize transaction downgrades that result in additional
processing fees. With the proper guidance and procedures, a merchant, like you, can
also more effectively combat chargebacks that result in loss of payment.
Here at Curbstone, we will, as the ideal partner:
 Allow you to maintain EXISTING banking relationships
 Not charge ANY fees for transaction processing
 Provide technology that can remove your systems from PCI DSS scope
 Support ALL major networks so you can solicit competitive processing quotes
 Support switching transparently from one bank/network to another, if needed
 Provide UNLIMITED technical and operational support all day, every day
Just call 888-844-8533 to schedule a no-obligation, Formal Needs Analysis with me!
Ira Chandler
President, Curbstone Corporation
888-844-8533
888-844-8533
Page 4 of 32
Table of Contents
Executive Summary ............................................................................3
10 Revealing Payment Apps Questions We Dare You Ask ............................................... 4
The Right Payment Partner .............................................................................................. 4
DISCLAIMER .......................................................................................6
The Players ........................................................................................7
Merchant .......................................................................................................................... 7
Acquirer ............................................................................................................................ 7
Acquirer Services .............................................................................................................. 8
The Authorization Network .............................................................................................. 8
Processing Diagram – Basic C3 ......................................................................................... 9
PCI Mandates .....................................................................................9
Evolution of Credit Card Security Standards .................................................................... 9
PCI Documents ............................................................................................................... 13
$50,000 in Free Consulting, Downloadable !! ................................................................ 14
PCI Data Security Standard ............................................................................................ 15
PCI PA-DSS vs PCI-DSS ...................................................................... 16
PCI PA-DSS for Application Vendors .............................................................................. 16
The “SAQ” ....................................................................................................................... 19
The Binding “Merchant Agreement” ............................................................................. 20
As VISA Threatens… ........................................................................................................ 21
Re-Issuance Costs ........................................................................................................... 21
The “for i” Section ............................................................................ 21
Network Segmentation .................................................................................................. 22
System Segmentation .................................................................................................... 22
Auditor Unfamiliarity...................................................................................................... 23
Authoritative Security Book ........................................................................................... 23
Curbstone – 20 years on AS/400 “i” .................................................. 25
IBM’s System i Developers’ Roadmap ........................................................................... 25
Curbstone’s Roadmap .................................................................................................... 25
Offload Sensitive Card Data ........................................................................................... 26
Further PCI Scope Minimization..................................................................................... 26
Isolated Payment Terminals (IPT) .................................................................................. 27
Payment Landing Pages (PLP) ........................................................................................ 29
Remote Tokenization ..................................................................................................... 30
Curbstone Unique Features/Benefits ................................................ 31
Reference Materials ......................................................................... 31
The Author....................................................................................... 32
Contact us ....................................................................................................................... 32
888-844-8533
Page 5 of 32
DISCLAIMER
Curbstone is not a Qualified Security Assessor (QSA), and what we present here are our
opinions. The only authorities on your compliance with the Payment Card Industry (PCI)
Security Standards Council Data Security Standards (PCI DSS) are Qualified Security
Assessors. A list of certified companies is available at
https://www.pcisecuritystandards.org/approved_companies_providers/qualified_security_assessors.php .
Curbstone, does, however, have unique insight into payment processing on this
platform. The founder of Curbstone Corporation, Ira Chandler, wrote the first
commercial AS/400 credit card processing software in 1993. He built a company
around that, ROI Corporation, and took it public in 2000. To better service the AS/400
and System i market, he left ROI and founded Curbstone in 2002. ROI was sold to
Verifone and is now their software division.
With 20 years of experience installing payment servers on the IBM
Midrange platform, Mr. Chandler is sharing his expertise in this
white paper. Curbstone’s software, selected by over 300
companies, corporations, universities, nonprofits and government
entities, has been validated as a secure application since the first
security standard, the Visa “Payment Application Best Practices”
(PABP) in 2004. When the PCI developed the Payment Application
Data Security Standards (PCI-DSS) in 2005, Curbstone Card was
one of the first applications to be validated, and has been ever since.
888-844-8533
Page 6 of 32
The Players
Merchant
The term “Merchant” is typically describes the business selling a product or service and
accepting cards as payment. If your company accepts cards in payment, you are the
Merchant!
Acquirer
This is the entity that initiates and maintains relationships with merchants for the
acceptance of payment cards. They are also referred to as “acquiring bank” or
“acquiring financial institution.” An acquirer (or acquiring bank) is a federally-chartered
banking organization that may or may not have brick and mortar branches. Acquirers
range from your local corner bank, to huge organizations that do nothing but acquire,
like TSYS, First Data, or Paymentech. These banks MAY be aligned with a well-known
retail bank, like Paymentech with Chase, or be independent like TSYS.
Major US Acquirers
List of the major acquirers in the US
 First Data Corporation (First Data Merchant Services: FDMS)
o includes CardService International, Wells Fargo, PNC Merchant Services,
SunTrust Merchant Services, and Citi Merchant Services
 Chase Paymentech (Chase Merchant Services, CMS)
 Bank of America Merchant Services (BAMS)
 American Express (through their Centurion Bank)
 Fifth Third Bank
 Heartland Payment Systems
 First national Merchant Solutions (FNMS)
 Elavon/NOVA
 Global Payments
This short list accounts for about 90% of all the card transactions in the US. The rest of
the acquirers are small, very specialized organizations.
Local Bank Acquirers
Many of the small neighborhood banks resell the
acquirer services from these Tier 1 acquirers, though
that may not be made clear to the merchant.
888-844-8533
Page 7 of 32
Independent Sales Organizations (ISOs)
Many companies, who are not officially banking organizations, specialize in vertical
markets, like education or restaurants. They will re-sell a major acquirer’s services to
their verticals. These companies are called Independent Sales Organizations (ISOs). You
may have a Merchant Agreement with a company who is not on the list above. If that is
the case, they are most likely a reseller (ISO) for the services of the Tier 1 Acquirers in
the list above.
Acquirer Services
The acquirer, large or small, is responsible for handling collecting the payments for all
bankcard transactions the merchant processes. Most acquirers perform the transaction
handling once the Merchant “settles” their daily batch through the authorization
network, and insures that the collected money is deposited in the Merchant “deposit
account”.
The fee that the acquirer receives for their services is ALWAYS proportional to the
amount of perceived risk they take in handling the transactions for a particular business.
The Merchant Agreement
The acquirer establishes and maintains merchant relationships by “boarding Merchants”
and resulting in a formal “Merchant Agreement”. The Merchant Agreement is the
authoritative document as to any Merchant processing card payments, and also covers
their responsibility to adhere to the PCI Security Standards to the satisfaction of the
acquirer.
The Authorization Network
The acquirer provides the communications services (either directly or through a
subcontractor) for the merchant to obtain real-time card authorizations and deliver endof-day settlements. Some acquirers, such as Paymentech, also own "authorization
networks," while some use a dedicated independent authorization network, like TSYS
(a.k.a. Vital, a.k.a. VisaNet). The services of the communication network (authorization
network) are paid transparently by the acquirer as part of the Merchant fees.
888-844-8533
Page 8 of 32
Processing Diagram – Basic C3
PCI Mandates
Evolution of Credit Card Security Standards
In 1999, Visa USA realized that the proliferation of businesses that use computers, take
orders, and store card information presented a great risk to cardholders. Visa hired
security consultants to develop a "best practices" document as a guideline for
businesses that store credit card information.
In December 14, 2004, Payment Card Industry (PCI) heavyweights American Express,
Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc.,
together empowered the Payment Card Industry Security Standards Council with the
authority to manage payment industry best practices. The Council maintains, evolves,
and promotes the Payment Card Industry security standards. It also provides critical
tools needed for implementation of the standards such as assessment and scanning
guidelines, a series of Self-Assessment Questionnaires for various categories of
merchants, training and education, and product certification programs.
888-844-8533
Page 9 of 32
The resulting Payment Card Industry Data Security Standard (PCI DSS) is at Revision 2.0;
it is the industry’s definitive source of guidance for merchants fulfilling their mandate
to secure their credit card information.
Security Breach Enforcement
The PCI DSS is not an actual legislative law enforced by government. The enforcement
of the standard is by the major payment brands through fines, sanctions, and more. It
makes non-compliance unacceptable to merchants. Possibly the greatest liability of noncompliance is the consequential damages paid to the banks who issued cards to the
merchant’s customers by non-compliant merchants who suffer a breach. If a security
breach exposes card numbers, the issuing bank must issue new cards to their
customers, at great expense. In the case of TJX (T.J. Maxx Companies), they were found
liable for about $120 MILLION in card re-issuance costs charged to them by the banks
who issued cards to their customers. That did not include the fines and penalties from
the card organizations, which were also substantial.
PCI Standards Enforcement
Finally, the banks who sign up merchants for processing accounts are now requiring
proof that the systems and applications used by those merchants are validated against
the PCI DSS standard. For those merchants with substantial card processing, the
standards must be officially evaluated by certified, independent Qualified Security
Auditors (QSAs), and must be re-validated annually.
To most effectively enforce the new regulations, the standards were first most
rigorously enforced at the merchants who processed the most transactions. In recent
years, those standards have been applied to progressively smaller merchants.
“Store, Process, OR Transmit” Card Data?
Examples of infrastructure that should be considered “In Scope”:
Store: retain cardholder data (in any way) in non-volatile storage
 Write data to disk in physical files
 Write data to disk IFS root file system files
888-844-8533
Page 10 of 32
Process: handle cardholder data (in any way) in volatile storage
 Accept keyed card data into a screen on any workstation
 Accept swiped mag stripe data into a screen on any workstation
 Accept card data in a browser screen generated by your software/server
Transmit: send cardholder data from any system to any other
 Send cardholder data from an e-commerce server to your IBM i
 Send data from any workstation to your IBM i
 Send data to an authorization network for validation
If you do ANY of these, ALL of your infrastructure systems are
“IN PCI SCOPE”
Reducing Scope
Scope can be narrowed with the use of network segmentation, which isolates the
cardholder data environment from the remainder of an entity’s network. Narrowing of
scope can lower the cost of the PCI DSS assessment, lower the cost and difficulty of
implementing and maintaining PCI DSS controls, and reduce risk for the entity. For more
information on scoping, see PCI DSS Appendix D: Segmentation and Sampling of
Business Facilities/System Components. In addition, read on to learn what Curbstone
offers to reduce, perhaps dramatically, your PCI scope.
Why Comply with PCI Security Standards?
Why should you, as a merchant, comply with the PCI Security Standards? At first glance,
especially if you are a smaller organization, it may seem like a lot of effort, and
confusing to boot.
… But not only is compliance becoming increasingly important, it may not be the
headache you expected.
Compliance with data security standards can bring major benefits to businesses of all
sizes.
Compliance with the PCI DSS means that your systems are secure, and customers can
trust you with their sensitive payment card information:
► Trust means your customers have confidence in doing business with you
► Confident customers are more likely to be repeat customers, and to recommend
you to others
Compliance improves your reputation with acquirers and payment brands -- the
partners you need in order to do business
Compliance is an ongoing process, not a one-time event. It helps prevent security
breaches and theft of payment card data, not just today, but in the future:
888-844-8533
Page 11 of 32
► As data compromise becomes ever more sophisticated, it becomes ever more
difficult for an individual merchant to stay ahead of the threats
► The PCI Security Standards Council is constantly working to monitor threats and
improve the industry’s means of dealing with them, through enhancements to
PCI Security Standards and by the training of security professionals
► When you stay compliant, you are part of the solution – a united, global response
to fighting payment card data compromise
Compliance has indirect benefits as well:
 Efforts to comply with PCI Security Standards, will better prepare you to comply
with other regulations as they come along, such as HIPAA, SOX, etc.
 You’ll have a basis for a corporate security strategy
 You will likely identify ways to improve the efficiency of your IT infrastructure
But if you are not compliant, it could be disastrous for your company and for those
entrusted, directly or indirectly, with risk management:
 Compromised data negatively affects consumers, merchants, and financial
institutions
 Just one incident can severely damage your reputation and your ability to
conduct business effectively, far into the future
 Account data breaches can lead to catastrophic loss of sales, relationships and
standing in your community, and depressed share price if yours is a public
company
Possible expensive, negative consequences also include:
 Lawsuits
 Insurance claims
 Reputational damage
 Cancelled accounts
 Payment card issuer fines
 Government fines (?)
Intrusion/Penetration Scans: NOT PCI compliance
Since the acquiring bank with which you have a Merchant Agreement is responsible for
insuring your PCI compliance, they typically are only capable of the most cursory
understanding of the PCI requirements. The limited extent of this understanding is
clearly illustrated by the frequent their elementary requirement for the merchant to
perform periodic Intrusion scans, typically with a vendor with whom the bank receives a
commission on the service. This may be the sole commitment that the bank asks of the
merchant, and if it is, it says far more about their understanding of PCI than the
fulfillment of the requirement says about the merchant. Yes, intrusion scanning is ONE
888-844-8533
Page 12 of 32
SMALL component of PCI compliance, but it only satisfies one section of the PCI DSS:
PCI DSS 11.2
Run internal and external network vulnerability scans at least quarterly and after any significant
change in the network. After passing a scan for initial PCI DSS compliance, an entity must, in subsequent years, pass four
consecutive quarterly scans as a requirement for compliance. Quarterly external scans must be performed by an
Approved Scanning Vendor (ASV). Scans conducted after network changes may be performed by internal staff.
What about the other 260+ sections???
To be candid, if your bank asks you only for an intrusion scan to satisfy their PCI
requirements, they are doing you no favor. Such a demand is a fig leaf that protects
neither the merchant nor the bank in any meaningful way. It should cause serious
consternation on your part. Read on for a summary of what you need to know:
PCI Documents
Fortunately, the PCI has provided free tools to assist in implementing security
enhancements to establish a credit card security baseline. Their superb "best practices"
documents are free to the public and have the official PCI stamp of approval. No need
exists for you to hire an expensive security consultant and pay for the creation of a set
of security guidelines.
https://www.pcisecuritystandards.org/security_standards/documents.php
888-844-8533
Page 13 of 32
$50,000 in Free Consulting, Downloadable !!
If you were to hire a qualified security
auditor to create a comprehensive set
of “Best Practices” security standards
for your organization, how much
would you expect to pay?
“PCI DSS represents
the best available
framework to guide
better protection of
cardholder data. It also
presents an opportunity
to leverage cardholder
data security achieved
through PCI DSS
compliance for better
protection of other
sensitive business
data – and to address
compliance with other
standards and
regulations.”
AberdeenGroup
IT Industry Analyst
Let’s say those standards included a comprehensive IT plan, as well as operational
guidance for all aspects of the business that are related to the handling of credit cards.
Such a service could easily cost f $50,000 or more. The PCI provides all of this, and
888-844-8533
Page 14 of 32
more, for FREE. Download at
https://www.pcisecuritystandards.org/security_standards/documents.php .
PCI Data Security Standard
In a valuable effort to set minimum guidelines for enterprise security, the PCI identified
a dozen areas of concern, grouped into six general headings.
Protecting Card Information – Field by Field
The second set of the standards, policies/procedures, is aimed at protecting the storage
of card information. The gist of these requirements is outlined below:
 Card Account Number -- This is the 14-to-16-digit number on the face of the
card. The first six digits are the BIN representing the bank that issued the card.
The last four digits are all that should be displayed on printed receipts or other
documents, with the leading numbers masked with asterisks. This information
should be strongly encrypted when stored, with Triple Data Encryption Standard
(3DES) or Advanced Encryption Standard (AES) preferred.
 Card Validation Code 2 (CVC2), Card Verification Value 2 Code (CVV2), or
Cardholder Identification (CID) -- These three confusing card verification
acronyms represent the security codes that appear as the last three digits on the
back of a MasterCard (CVC2), Visa (CVV2), or Discover, and the four digits on the
front of an American Express card (CID). This should never be stored for longer
than it takes to process the transaction.
 Expiration Date -- The two digit month and two digit year should not be stored,
although it is allowed; however, if it is stored, it should be encrypted.
 Magnetic Stripe -- The contents of the stripe on the back of the card should
never be stored for longer than the transaction takes to process.
888-844-8533
Page 15 of 32
 Personal Identification Number (PIN) -- This is the four-digit security code
associated with debit cards. The PIN is encrypted immediately after being keyed,
by dedicated hardware like a Hypercom PIN pad. A merchant is unlikely to ever
have possession of it unencrypted; however, it is never allowed to be stored in
any format.
 Access Logging -- One of the most important directives is that any user who gains
access to the unencrypted card data, possibly for accounting or customer service
reasons, must have that access logged in a security file. The file must record the
time, date, user ID, and specific record accessed. Obviously, the identifier of the
record accessed cannot contain the actual card number. Good commercial credit
card processing software will provide this logging--or at least a unique key to the
transaction for access and identification purposes.
Guidelines for Cardholder Data Elements
Once you meet the minimum requirements outlined in the PCI documents, you can be
comfortable that you have created the proper security environment and that your
company will not be held liable for non-compliance, should a security breach occur.
The PCI publishes a series of Self Assessment Questionnaires (below) which provide a
comprehensive analysis tool to document merchant compliance.
PCI PA-DSS vs PCI-DSS
PCI PA-DSS for Application Vendors
Merchants are not the only entities covered by PCI standards. There are extensive
standards imposed on the vendors of “commercial” applications that process credit card
888-844-8533
Page 16 of 32
information, including Curbstone Corporation. These used to be called the Payment
Application Best Practices (PABP), but are now renamed to the Payment Application
Data Security Standards (PA-DSS). These standards are is ONLY achievable with periodic
time-consuming, expensive, third-party security auditor evaluations, and formal
submission to PCI for inclusion in the list of approved applications.
PCI-DSS for Merchants
The Payment Card Industry’s definition of a “merchant” is:
“For the purposes of the PCI Data Security Standards, a merchant is defined as any
entity that accepts payment cards bearing the logos of any of the original five members
of PCI Security Standards Council (American Express, Discover, JCB, MasterCard or Visa)
as payment for goods and/or services...”
It is a multifaceted security standard that includes requirements for security
management, policies, procedures, network architecture, software design and other
critical protective measures. This comprehensive standard is intended to help
organizations proactively protect customer account data.
Merchant PCI Reporting “Levels”
In addition to adhering to the PCI Data Security Standard, compliance validation is
required for Level 1, Level 2, and Level 3 merchants, and may be required for Level 4
merchants.
888-844-8533
Page 17 of 32
Obtained October 17, 2013:
http://uvsa.visa.com/merchants/risk_management/cisp_merchants.html
888-844-8533
Page 18 of 32
Typical PCI DSS Failures
A survey of businesses in the U.S. and Europe reveals activities
that may put cardholder data at risk.
81% store payment card numbers
73% store payment card expiration dates
71% store payment card verification codes
57% store customer data from the payment card magnetic stripe
16% store other personal data
Source: Forrester Consulting: The State of PCI Compliance (commissioned by RSA/EMC)
The “SAQ”
The PCI DSS Self-Assessment Questionnaire (SAQ) is a series of five validation tools
intended to assist merchants and service providers in self-evaluating their compliance
with the Payment Card Industry Data Security Standard (PCI DSS). The multiple versions
of the PCI DSS SAQ vary to meet the needs and characteristics of all merchants,
depending on how they make use of credit cards.
The SAQ includes a series of yes-or-no questions for compliance. If an answer is no, the
organization must state the future remediation date and associated actions. In order to
888-844-8533
Page 19 of 32
align more closely with merchants and their compliance validation process, the SAQs
provide flexibility based on the complexity of particular merchant environments (see
chart below). The PCI DSS Self-Assessment Questionnaire Guidelines and Instructions
document provides more details on each SAQ type (see www.pcisecuritystandards.org).
The most commonly-used SAQ for most merchants who are using the IBM Midrange
platform is the SAQ-D. This is because the merchant is typically accepting cardholder
data into screens on workstations or browsers that are served by the AS/400 i, or the
web server. In addition, that data is typically saved in either volatile or non-volatile
storage, and sent to other systems. This is a match for the three criteria for being “in
scope, to “store, process, or transmit” cardholder data.
The goal of this document is to help you to clarify the scope for which you qualify, and
to suggest ways to decrease that scope. This in turn will assist you in reducing, perhaps
dramatically, the effort and the costs required to establish, maintain and document PCI
compliance. While network segmentation can reduce PCI scope, more flexible and
effective methods must be implemented to reduce efforts and resulting costs to the
absolute minimum..
The Binding “Merchant Agreement”
The key to a merchant's compliance
lies in the "merchant agreement,"
the card processing agreement that
the merchant signs with its
"acquirer." The acquirer is the entity
that buys the card transactions from
the merchant at a "discount." This
could be the Merchant Services
Division of the merchant's bank, or
an independent acquirer.
The merchant agreement stipulates
that the merchant adhere to the
current security standards outlined by the credit card companies. If the merchant loses
888-844-8533
Page 20 of 32
data and is found to not adhere to these standards, the merchant is liable to the card
organizations for possible huge fines.
As VISA Threatens…
Here is an excerpt of the security regulations from Visa: "Members (merchants) receive
protection from fines for merchants or service providers that have been compromised
but found to be Cardholder Information Security Program (CISP)-compliant at the time
of the security breach… Members are subject to fines, up to $500,000 per incident, for
any merchant or service provider that is compromised and not CISP-compliant at the
time of the incident."
That's right; the fine can be up to half a million dollars per incident!
In addition, merchants must immediately notify the acquirer if they lose data. For
instance, if a merchant fails to immediately notify Visa USA Fraud Control of the
suspected or confirmed loss or theft of any Visa transaction information, the member
will be subject to a penalty of $100,000 per incident.
Re-Issuance Costs
Beyond that, a merchant could also be responsible for the card re-issuance costs
incurred by the banks involved. For every compromised card number, a new card must
be issued to the cardholder. The bank that issues the new card can take the merchant to
court to recover those costs; in fact, a suit is pending right now against a large multistore discount retailer for precisely these costs.
The “for i” Section
So far, we have covered the requirements of the PCI Security Standards. Now we can
address some of the issues specific to the IBM System i. If you were to read the entire
library of PCI documents, you would see that it is decidedly PC-centric. Over and over
they refer to the use of individual PC’s (systems) to have individual tasks, like one for
web server, one for database, one for payment application, one more for Order Entry.
And further, they assume that the link between all of these systems is TCP/IP, and that
the liberal use of routers and firewalls with Access Control Lists (ACLs) can provide the
segregation that they require between the various components.
888-844-8533
Page 21 of 32
Network Segmentation
One of the best features of a PC-based architecture is that you can just add another
little server to the system to expand what you are doing. One of the biggest curses of a
PC-based architecture is that you can just add another little server to the system to
expand what you are doing.
Every server added is a huge management responsibility, and if you are using Windows,
heaven forbid, you have that additional issue of Virus protection, constant updates, and
stability.
We all know better. One central machine with ALL of the abilities BUILT IN to the
operating system is superior and much easier to manage.
System Segmentation
888-844-8533
Page 22 of 32
The biggest benefit of the IBM Midrange is that all of the components are fully
integrated to the OS/400 (i) operating system. The biggest challenge of the IBM
Midrange is that all of the components are fully integrated to the OS/400 (i) operating
system.
How do you accommodate the request from PCI for a firewall between each functional
component when all of the components are built in to the operating system? How do
you provide the ACL to control access between components that do not use TCP/IP to
communicate?
Auditor Unfamiliarity
To compound the complications, the vast majority of Qualified Security Assessors (QSAs)
are inundated with work to audit PC-based architecture, so the knowledge of how the
IBM Midrange can accommodate the requirements is not common knowledge.
In fact, the architecture of the AS/400 System i is actually very well suited to the
network segmentation that is so critical to the PCI.
This is where the brilliant design of IBM’s Dr. Frank Soltis comes into
play. He created the AS/400 to handle the segregation that is
required by the PCI. His security design, and that of Carol Woodbury,
his cohort in Security design, is so powerful, the AS/400 is one of the
only (if not THE only) computers that can be configured for NIST Level
C2 security right out of the box!
One significant part of the operating system technology that Curbstone uses in the
handling of segregation is the SUBSYSTEM. This critical component of work
management provides much of the requirements of the PCI for having the different
components running is separate memory spaces. The proposed use of subsystems
allows some payment server software, Curbstone included, to run on the same system
as the order entry software. And, according to the advice of three of our PA-QSAs, that
can be the same system that is connected to the Public Internet.
Authoritative Security Book
For an in-depth dissertation on this subject, we suggest you, or your System i
administrators, study the comprehensive book by Carol Woodbury. Curbstone includes
a copy of the book with every license and it is an official part of the Curbstone “PCI
Implementation Guide.”
888-844-8533
Page 23 of 32
ISBN-13: 9781583477311 -- Publisher: MC Press -- Publication date: 5/1/2012
Obviously, all of the Curbstone software products have been designed to take full
advantage of the design features of the platform. Curbstone software has been
validated in PCI DSS audits consistently over the years.
888-844-8533
Page 24 of 32
Curbstone – 20 years on AS/400 “i”
The founder of Curbstone, Ira Chandler, was the author of the first
commercial credit card processing software for the AS/400 in 1993.
IBM’s System i Developers’ Roadmap
Curbstone Card is the only stand-alone Payment Server selected by IBM for their
Developers’ Roadmap for the System i. Their selection, every year since 2005, is based
on the value of Curbstone’s software to the platform. Curbstone has what we believe to
be the largest installed base of payment server software, and is the only company active
exclusively in the “i” space. One hundred percent of Curbstone customers are AS/400
System i shops!
Curbstone’s Roadmap
The Curbstone CorrectConnect™ (C3) initiative is the future of Curbstone products.
Based on a new technology secure Internet portal, CorrectConnect allows merchants to
eliminate all direct contact with credit card sensitive data for Call Centers, Telephone
Orders, Mail Orders, Retail, and e-commerce.
C3 is the follow-on offering from Curbstone Corporation that builds on the experience
and knowledge gained by working with many hundreds of merchants over the past
twenty years.
C3 is an extension of the award-winning and industry-leading Curbstone Card (C2) with
one very important and far-reaching difference. While C2 ran or operated on the
merchant's AS/400 i server, C3 is a stand-alone Payment Portal. As a “Payment Portal,”
C3 hosts the merchant's cardholder information with all of the proper security
mechanisms -- Curbstone is an approved PCI “Service Provider” -- to ensure that critical
cardholder information is both secure and available to the merchant as needed.
As with C2, C3 will provide a high-speed, secure connection to the authorization
network or bank of your choice as well as to the merchant system(s).
Curbstone's newest technical innovation, the fruit of 20 years of experience, permits
merchants to:
 Dramatically reduce compliance burdens and costs by both IT and
Finance/Accounting
 Answer over 200 fewer questions on your PCI Self-Assessment Questionnaire,
replacing the SAQ-D with the SAQ C-VT
 Improve the security and protection of cardholder data, reducing the risk of fines
and sanctions
888-844-8533
Page 25 of 32
Offload Sensitive Card Data
Implementing the most basic C3 Payment Portal allows merchants to offload the
storage of sensitive cardholder data from their IBM AS/400 i server(s), ERP/MRP
systems, network and web sites, dramatically reducing their "scope" of PCI oversight
and the associated costs. Curbstone assumes the bulk of PCI responsibilities on behalf
of the merchant by being the custodian of all sensitive cardholder data. Although data
will be stored remotely, C3 provides easy and secure real-time processing for all
transactions, including the reuse of card numbers for returning customers or recurring
billing, through the use of advanced remote tokenization technologies. Further, C3hosted data can continue to be seamlessly integrated with your current order fulfillment
and financial applications, just as it is today, but through an encrypted, PCI compliant,
real-time IP connection.
Once you achieve the basic C3 advantage of moving the card data STORAGE off of your
corporate infrastructure, you may want to further minimize your PCI scope to eliminate
“processing” and “transmission” of sensitive card data…
Further PCI Scope Minimization
“How does a Merchant take infrastructure out of PCI scope?”
SIMPLE! Do not store, process, or transmit credit card data.
“But, how do you process payments without touching the card data?”
Curbstone provides THREE simple solutions:
1. Isolated Payment Terminals (IPT)
2. Payment Landing Pages (PLP)
3. Virtual Terminals (VT)
“But what does the merchant sacrifice to accomplish getting OUT of scope?”




They don’t sacrifice fast, real-time processing…
They don’t sacrifice security…
They don’t sacrifice seamless integration…
They don’t sacrifice instant, automated reconciliation…
… They don’t sacrifice ANYTHING!
888-844-8533
Page 26 of 32
Isolated Payment Terminals (IPT)
This section is for companies who accept
credit card data by phone, using
operators who key in the card data into
Order Entry software. Our only
assumption is that you have the source
code to the Order Entry software, and
can make simple nods to it. Imagine
your entire corporate infrastructure on
the left of this diagram.
This can even apply to browser-based
Order Entry that originates on the
AS/400 i. So, let’s stop touching card
data there, and draw a line:
We have taken your systems on the left
OUT of scope and allowed for a simple,
new system to take over card handling.
We are adding an inexpensive wireless
router/firewall, and some number of
inexpensive tablets ($100 or less for 7”
Androids, for example.) Every operator
gets one on their desk. (Inquire about
our VIPT, where the physical tablets are
replaced with a terminal server!)
Once the operator has logged in to the
tablet, and therefore into the Curbstone
C3 Portal, they are linked to their Order
Entry session.
888-844-8533
Page 27 of 32
Once the order is complete, some fields
of NON-sensitive info are sent to the C3
client software on the AS/400 i. This is
sent to the C3 Portal, which generates
the payment request on the tablet.
Note that the tablet has a unique
connection to the Internet through the
dedicated router/firewall. This
completely isolates the sensitive card
data about to be keyed from ALL THE
REST of your infrastructure.
The operator keys the card data and hits
the Authorize button to complete the
authorization. The data is sent to the C3
portal, and then to the Authorization
network of the Merchant’s choice, and
then to the Card-Issuing Bank for
approval. The approval or decline is sent
to BOTH the tablet screen, AND to the
AS/400 i. However, the sensitive card
data is NOT sent back to those devices,
but stored on the C3 Portal.
Now, your Order Entry software gets
what it needs to complete the order, and
the operator is ready to accept more
payments! This accomplishes the
requirements and restrictions of the
SAQ-C/VT, a very simple Self-Assessment
Questionnaire, as opposed to the SAQ-D.
What does that accomplish? A lot!...
888-844-8533
Page 28 of 32
Now, let’s see how we can accomplish the same reduction of scope for e-commerce.
Payment Landing Pages (PLP)
Our assumptions here are that you have a
web server that is accepting payments, and
that you wish to take it totally out of PCI
scope. This is how Curbstone does it.
Imagine that the merchant web server has
completed the order and presented the
page immediately before payment
acceptance. Instead of the payment
888-844-8533
Page 29 of 32
button linking to the payment software ON the web server, the button has been simply
modified to pass the web customer to the Curbstone C3 portal – transparently!
When the web customer’s browser presents
the next page, it is one generated from the
Curbstone C3 Portal. And it is into this page
that the customer will key their credit card
data. Once they have completed the fields,
the web customer clicks the key to proceed
with the payment, and the data is handled
exclusively by the Curbstone C3 Portal, and
approved or declined.
As part of this action, the web customer is sent
BACK to the Merchant Web Server shopping
cart to see the results of their payment.
At the same time, the results are copied to the
AS/400 i of the merchant. Since the card data
is accepted by the page from the C3 Portal, and
the AS/400 i,the web server and the merchant
network never touch it, they are officially out
of scope.
Remote Tokenization
C3 generates a unique token to provide a reference for each transaction for a given
order and the related authorization and subsequent settlement. The merchant can
research any order in their system in the event of a dispute with either the customer or
the bank.
This “token” is used to accommodate returning customer who desire to have their cards
maintained “on-file” for repeated use.
As well, if a credit were to be needed, the “token” would be used to reference the prior
transaction from which the credit would be based. By eliminating the storage of
sensitive PCI data, the merchant systems no longer fall under that aspect of the PCI
scope.
888-844-8533
Page 30 of 32
Curbstone Unique Features/Benefits
In summary, these are some of the unique offerings of Curbstone Corporation.
 Only stand-alone Payment App selected by IBM for their System i Roadmap
 Curbstone services ONLY the IBM Midrange AS/400 System i
 Merchants can retain existing relationships with acquirers/banks
 Curbstone does not charge transaction fees
 Implementation included as part of the fixed setup fee
 All Curbstone products are NATIVE AS/400 System i
 All support is unlimited and available 24x7x365
 Curbstone is network/acquirer agnostic, so merchants select their best providers
 Merchants can switch networks once a year with no reconfiguration fees
 All support and development is doneby real Programmers, based in the Great
State of Georgia, USA
And, did we mention, Curbstone does not charge transaction fees?
Reference Materials
► “PCI Security Standards Council” https://www.pcisecuritystandards.org is the
definitive source for up-to-date information on PCI compliance from the source.
Formed by the major payment brands to develop standards and guidelines, the
Council publishes a wealth of information on the site. This should be considered
the authoritative source on any PCI Compliance issues.
► “PCI DSS”, Wikipedia, http://en.wikipedia.org/wiki/PCI_DSS offers a good high
level introduction to the topic of PCI compliance, with substantial background
material available through related links and cited references.
► “PCI Compliance Guide” http://www.pcicomplianceguide.org is an educational
site provided by a security software company focused on articles and discussion
on PCI Compliance issues. While not as authoritative, information on the site is
easily comprehensible and accessible.
► “Visa Cardholder Information Security Program”
http://usa.visa.com/merchants/risk_management/cisp_overview.html describes
the specific implementation of PCI guidelines mandated by Visa, including current
status of the compliance program, deadlines, penalties, and additional reference
materials.
► “Data Security Webinar – PABP Overview”, Tom Pageler, VISA, January 31, 2007
http://usa.visa.com/download/merchants/webinar013107V2.pdf
► The DSS Standard: https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf
888-844-8533
Page 31 of 32
► Supporting Documents:
https://www.pcisecuritystandards.org/security_standards/documents.php
► Approved Assessors and Scanning Vendors:
https://www.pcisecuritystandards.org/approved_companies_providers/index.php
► Navigating the DSS Standard:
https://www.pcisecuritystandards.org/documents/navigating_dss_v20.pdf
► Self-Assessment Questionnaire:
https://www.pcisecuritystandards.org/merchants/self_assessment_form.php
► Glossary: https://www.pcisecuritystandards.org/security_standards/glossary.php
► Approved QSAs:
https://www.pcisecuritystandards.org/approved_companies_providers/qualified_security
_assessors.php
The Author
Ira Chandler is the founder of Curbstone Corporation and has been programming
communications software for the last 35 years.
Mr. Chandler wrote the first commercial credit card processing software for the IBM
AS/400 in 1993. He has authored and supported AS/400 - iSeries - Power i
communications software currently in use at hundreds of locations.
About 300 companies, universities, and government entities have selected the IBM i
operating system and Curbstone Card, including MIT, Harvard, WW Norton Publishing,
RegalWare, Fisher Scientific, Campbell Hausfeld, Highlights for Children, Sunbelt Rentals,
AdoramaCamera.com, Beneteau Yachts and US Space & Rocket Center.
Contact us
201 Enterprise Court, Ball Ground, Georgia 30107
888-844-8533 toll free
770-737-3045 voice
770-737-3046 fax
[email protected]
888-844-8533
Page 32 of 32

A White Paper on the Payment Card Industry “PCI

Transcription

Similar documents

Desktop Network PCI Card

Preparing for the Evolution: PCI DSS 3.0 and Beyond

where merchant and mobile services merge

Aculab E1/T1 PCI card

Steps for staying PCI DSS compliant

Click here to our current portfolio

E-commerce - PCI DSS E-commerce Guidelines

Remote access to Meditech to View Patient Health

Linux* Power Efficiency Analysis Methods

shipping logistics conditions of carriage

Radiochemistry Webinars Actinide Chemistry Series