W H I T E PA P E R
PRINCETON
PAYMENT
SOLUTIONS
TM
How to Eliminate PCIDSS Exposure in SAP®
Environments:
Goals and Strategies for Using Tokens
October 2009
White Paper: How to Eliminate PCI-DSS Exposure in SAP® Environments
1
Executive Summary
The Payment Card Industry
goes out of its way to
point out that outsourcing
payment processing will
not make a company PCIcompliant, as outlined in
Ten Common Myths of
PCI DSS. This document
also addresses other
common misconceptions
that companies should
understand.
https://www.pcisecuritystandards.org/
pdfs/pciscc_ten_common_myths.pdf
Not all companies are responsible for meeting the PCI-DSS requirements, but most that
accept payments with SAP solutions are. Companies that do not electronically store, process or transmit any kind of card data need only answer a few short questions on the PCI
short form to declare that they have no card data to secure and are thus exempt from
the PCI long form assessment. Unfortunately, the simple short form will not suffice for
most companies who take credit cards. If your company stores card data onsite or even accepts
card data at order entry terminals or within a computer-based system such as an SAP system, you
are obligated to address up to 225 detailed security issues in the PCI long forms.
The goals of a PCI long-form initiative usually include:
nProtect card data by securing the network and encrypting the data.
n
n
n
Install encryption in a way that does not change the order process.
Reduce the scope of PCI by having as few applications, systems and networks
“touch” card data as possible.
Implement a “future-proof” solution – be able to use the same system for PII
data to comply with upcoming laws in these areas. (PII addresses other personally-identifiable information such as driver’s license number, bank account
number, and birth date.)
Since the PCI asks for protection of data in storage, processing and transmission, a solution
that promises technology for one or two of these requirements will not relieve you of
all of your PCI responsibilities.
A solution exists now that can take all or part of your SAP system out of PCI scope
while still providing data security that meets the requirements, allowing transparent
system operation, and accommodating future encryption needs: a token server. The token approach lets you remove all credit card numbers from the SAP database and store
them somewhere else, in an external, centralized, secure data vault. In place of the card
number or encrypted card number, a representative token value – or “surrogate card
number” – is stored in the database. This approach also allows you to keep field sales
devices (such as laptops) outside of the PCI scope by tokenizing data before entering it
into the device.
Before you choose a PCI solution, make sure you fully understand the issues and
ramifications related to PCI compliance. This paper outlines some typical goals of a PCI
project, sheds light on common PCI misconceptions, and defines successful and costeffective strategies – such as tokens – for complying with PCI requirements.
You can read the full PCI-DSS standard at
https://www.pcisecuritystandards.org/
Copyright © 2009 Princeton Payment Solutions
Introduction: PCI and Data Encryption
You’ve certainly heard of identity theft. Possibly you’ve even been a victim of it in one
form or another. According to the Identity Theft Resource Center, more than 127 million personal data records were compromised in 2007 in the U.S. As more and more
data is accepted, stored, and processed electronically, opportunities proliferate for identity theft on a grand scale.
www.prinpay.com
White Paper: How to Eliminate PCI-DSS Exposure in SAP® Environments
“PCI DSS mostly calls for good,
basic security. Even if there
was no requirement for PCI
compliance, the best practices
for security contained in the
standard are steps that every
business would want to take
anyway to protect sensitive
data and continuity of
operations.”
— from Ten Common Myths of
PCI DSS, PCI Security Standards
Council
https://www.pcisecuritystandards.org/
pdfs/pciscc_ten_common_myths.pdf
2
The Payment Card Industry has responded to the fraud increase by creating the Payment Card Industry Data Security Standard, also known as the PCI-DSS, to protect data.
The PCI-DSS is a set of 12 general security requirements mandating common-sense
best practices that are probably already in place at many companies. According to the
Payment Card Industry, “PCI DSS mostly calls for good, basic security. Even if there
was no requirement for PCI compliance, the best practices for security contained in the
standard are steps that every business would want to take anyway to protect sensitive
data and continuity of operations.” If a data breach does occur, it will affect your company significantly, both financially and in terms of reputation.
Some of the requirements call for technology solutions to protect the data from unauthorized eyes, corruption from virus, and theft by hackers. Though the card associations have defined a set of penalties for non-compliance with the PCI or breach of data
security, the focus of the PCI effort seems to be security over penalty. However, the
Payment Card Industry is serious about enforcing the standard, and they are conducting assessments to enforce these rules, with possible fines of hundreds of thousands of
dollars levied if data is compromised.
One of the mandates of the PCI-DSS strongly affects companies who use SAP solutions:
companies must now secure payment data with strong encryption techniques and must
use encryption systems that are separate from the payment applications themselves. While
the SAP system can provide an encryption capability, its structure does not meet the
requirements of the PCI (for example, it is not separate from the payment application).
To comply with the PCI, companies who use SAP solutions for payments must:
nPurchase an encryption solution from a third-party supplier ~or~
n
Move card data off site to a third-party payment provider who can host the
system.
Princeton Payment Solutions has been successfully building payment solutions for SAP
customers for more than eleven years. Our customers have requested – and we have
delivered – a variety of encryption technologies for SAP systems, to help our customers
meet PCI requirements and provide the most secure and flexible protection for their
data.
A Quick Approach to the Audit Process
1. If you are a Level 1 or 2 merchant with one million or more transactions per year, you should interview and hire a Qualified
Security Assessor (QSA) to lead you through the process and give you the required assessment reports needed by the
card brands. Smaller companies may not need a QSA to assist them.
2. Go to the Self Assessment Questionnaire A, or short form. If you can pass all the requirements of no storage, processing or
transmission of card data, then you can bypass the rest of the PCI process.
3. If you cannot pass the short form, and almost all SAP installations cannot, you must go to a long form. This process is
complex and detailed, so you might want to hire an outside consultant to walk you through the process, explain the
questions, and strategize on responses.
Copyright © 2009 Princeton Payment Solutions
www.prinpay.com
White Paper: How to Eliminate PCI-DSS Exposure in SAP® Environments
3
Now let’s talk about the PCI process, what’s needed to meet PCI requirements from
a data protection and encryption perspective, the goals of a PCI implementation, and
proven strategies to accomplish those goals.
What Does the PCI Process Look Like?
If you’re an SAP customer
that takes orders through
your Sales/Distribution or
CRM modules, then you will
not be able to bypass the
requirements in the PCI long
For most companies (those processing fewer than a million transactions per year), PCI
is a self-assessment process: you fill out some forms describing your environment and
the protective measures in place, get them signed by management and send them to
your bank card processor or service provider. If your company processes more than a
million transactions on an annual basis, you are required to have a formal assessment
by a PCI-approved Qualified Security Assessor (QSA). His or her job is to review your
application and examine your systems to confirm what you say is what is actually happening in your environment.
form. Storing your data offsite
won’t help.
Part 2c
Merchan
. Eligib
t certifie
ility to
Com
plete S
s eligib
AQ A
ility to co
mplete
Merchan
this sh
ortened
entirely t does not stor
version
on third
e,
of the Se
party se process, or
lf-Asse
tra
rvice pr
The third
ssmen
ovider(s nsmit any ca
party
t Quest
rdho
is conf
) to hand
ionnaire
irmed to service prov
le thes lder data on
becaus
id
er
be PCI
merchan
e functio
e:
DSS co (s) handling st
Merchan
ns;
t premise
mpliant
orage,
t does
s but re
;
proces
not stor
lies
sing, an
e any ca
If Merch
d/
or
rdholder
ant does
transm
receive
iss
da
st
io
ta
or
n
e ca
in elec
d electro
of card
tronic fo
holder
nically. rdholder data
data
rmat; an
, such
d
data is
only in
Part 3.
paper re
PCI DS
ports or
copies
S Valid
of rece
Based
at
io
ipts an
n
on
d is no
complia the results
t
note
nce stat
us (che d in the SAQ
ck one)
A date
:
d (com
pletion
Compl
da
ia
te), (M
erchan
COMPL nt: All sectio
ns of th
t Compa
IANT ra
e PC
ny Nam
ting, th
ereby (M I SAQ are
e) asse
com
rts the
erchan
Non-Co
following
t Compa plete, and al
m
l questio
resultin pliant: Not
ny Nam
ns answ
g in an
all sect
e) has
io
ov
complia
demon
strated ered “yes,” re
nce with erall NON-CO ns of the PCI
sulting
full com
SAQ ar
MPLIA
the PC
in
pl
e
NT
I
an
ia
co
DS
nc
ov
m
ra
Target
S.
e with
pl
ting, th
the PC erall
Date fo
ereby (M ete, or some
I DSS.
r Compl
qu
erchan
iance:
An entit
t Compa estions are an
y
ny Nam
swered
in Part submitting th
e)
“n
o,
has no
4
is
t demon ”
since no of this docum form with a
strated
stat
ent. Ch
t all pa
full
yment
eck with us of Non-Co
brands
require your acquire mpliant may
r or the
be requ
this se
ct
pa
ire
ion.
Part 3a
yment
d to co
brand(
m
. Confir
pl
et
e
s) befo
mation
re com the Action Pl
Merch
an
pleting
of Com
ant co
Part 4,
nfirms:
pliant
Status
PCI DS
S SelfAs
instruct
sessm
ions th
en
t
Q
erein.
uestionn
aire A,
All info
Version
rm
(versio
assess ation within
n of SA
the abov
ment.
Q), wa
e-refere
s compl
nced SA
eted ac
I have
read th
cording
Q and
e PCI DS
in this
to the
attestat
S and
ion fairl
I recogn
y repres
ize that
Part 3b
en
I must
ts the re
. Merch
maintai
su
lts
of my
n full PC
ant Ack
I DSS
nowle
complia
dgemen
nce at
all times
t
.
Signatur
e of Mer
chant Ex
ecutive
Officer
Merchan
t Execut
ive Offi
Date
cer Na
me
Merchan
t Compa
ny Repr
esente
d
Title
PCI DS
S
Copyrig SAQ A, v1.2
, At
ht 2008
PCI Se testation of
Co
curity St
andard mpliance
s Coun
cil LLC
October
2008
Page 2
Copyright © 2009 Princeton Payment Solutions
www.prinpay.com
White Paper: How to Eliminate PCI-DSS Exposure in SAP® Environments
4
Entirely Outsourced – the Short Form
For most companies, the PCI responsibility involves filling out one of several selfassessment forms. The short form, Self-Assessment Questionnaire A, asks a few questions
to determine whether your company does any electronic storage, processing or transmis-
Why PCI is Necessary
Of course the focus of your business is revenue, not chasing
ever-changing nuances of the PCI compliance standards. So
it’s understandable that many understaffed IT and security
departments look at PCI compliance as a nuisance. PCI isn’t
a federal law, it’s a contractual requirement from the card
brands for merchants to accept payment cards. There are fines
associated with non-compliance but your business most likely
won’t come crashing down if it’s not done today. After all,
the requirements have been in place for four years… if you
haven’t done it by now, why should it be a priority?
The simple answer is: the possibility of a breach or other
compromise of data.
Until the Heartland Payment Systems break-in was discovered
in January 2009, many an overworked CIO regarded the PCI as
another form to be filled out and fudged as an exercise in line
with all pledges to be a good corporate citizen.
The Heartland breach revealed that intruders had hacked
into the computers used to process 100 million payment
card transactions per month for 175,000 merchants (source:
USA Today). Heartland announced their intention to notify
each victim whose data was stolen to comply with data-loss
disclosure laws in more than 30 states; they did not disclose
the number of victims, which must have been many millions.
The cost to Heartland – and to the victims – was certainly
staggering. Companies simply cannot afford to expose
themselves to that kind of risk. The practices outlined in the PCI
standard have become a necessary protection rather than just a
nuisance. In addition, more lawmakers are realizing that data
needs to be protected. Individual states such as Massachusetts
and Nevada are enacting laws that dictate the protection of
personal data such as driver’s license number and birth date.
And so the trend continues to move in the direction of
strengthening data security, both for card data and personal
information. After four years on the books, PCI requirements
for data security are gaining acceptance as must-have
best practices and are considered part of the cost of doing
business. Just like insurance, it is a precaution you hope
to never need, but one that’s critical to business continuity
should something happen.
sion of cardholder data within its environment. If you do not do any of
these things – because all of your card processing is completely handled
by a third party – then completing the short form is all that’s necessary
to comply with the PCI-DSS and you can bypass the longer forms (B, C,
or D). You will not need to make any changes to your environment.
Everyone Else – The PCI Long Forms
Unfortunately, the simple short form will not suffice for most companies who take credit cards. You are obligated to address many or all of
the 225 security issues in the 72-page Requirements and Security Assessment Procedures if your company does any of the following activities:
nElectronically stores card data onsite.
n
Processes card data.
n
Transmits card data, including:
n
n
Accepting card data at order entry terminals.
Accepting card data in computer-based systems, such as
SAP systems, or any place where card data is typed in.
Most SAP customers that have a call center cannot meet the criteria that
allow them to bypass the long form requirements. About the only way
you won’t trigger responsibility for these security obligations is if your
purchase process is completely separate from your ordering process:
your customer enters his or her own card number onto your web page
provided by a third party who processes the payment, and you never
receive or transmit the data.
Storing Your Data Somewhere Else: Can You Bypass PCI?
Some companies have a misconception that if they simply use a third
party solution to store card data offsite, they will be exempt from the
cumbersome requirements of the PCI long form. The problem is that
all three processes that touch the payment card data – the transmission, processing and storage – must happen offsite in order to exempt
your company from the rigors of the long form. The PCI requirements
apply not only to the application that accepts payment (in this case the
SAP system), they also apply to the database and to your company’s
network.
Almost all SAP systems that accept card data for orders will subsequently transmit this
information from the order entry terminal to the service provider or an internal payment card interface. Even if you take the SAP system out of scope of the PCI for data
storage or processing, your detailed PCI responsibility is still triggered by the requirements for data transmission, and thus you must fill out the long form.
Copyright © 2009 Princeton Payment Solutions
www.prinpay.com
White Paper: How to Eliminate PCI-DSS Exposure in SAP® Environments
5
A third-party, offsite data storage solution will exempt you from the PCI requirements
that relate to data storage – just not from the requirements for transmission or processing (so you still have to fill out the long form).
However, even if you store your data offsite so you no longer need to worry about the
PCI data storage requirements, the security of your data is still legally your responsibility. The card processing companies write their agreements to ensure that the merchant
(you) is still responsible for the data, unless it is proven that the data is stolen directly
from the third party (Heartland Payment as an example). The liability you took on for
this data cannot be passed to another facility unless done so in writing, and most thirdparty hosts are unwilling to accept it. If that third party is compromised and your data
is stolen, you still have to face the consequences, answer to your angry customers, and
clean up a big mess.
Rather than storing data offsite, another way you can address your PCI data storage responsibility is by encrypting your data onsite using an encryption solution. This option
is less expensive and keeps your data encrypted and under your control, where you
can be sure it is properly secured.
PCI Goals and Strategies
The PCI mandates protection of electronic storage, processing, and transmission of sensitive
card data. Most companies define the following goals for their PCI initiatives:
nProtect the card data.
n
n
n
Install encryption in a way that does not change the order process.
Reduce the scope of PCI by having your card data “touch” as few systems and
networks as possible.
Implement a “future-proof” solution – be able to use the same system for
PII data to comply with upcoming laws in these areas. (PII addresses other
personally-identifiable data such as driver’s license number, bank account
number, and birth date.)
Each goal has several considerations and strategies you can use to meet it.
Protect the Card Data
You need to make sure all parts of your network are secure and can only be accessed
by authorized individuals. In addition, data encryption is required by the PCI, and the
SAP system’s internal encryption does not meet PCI standards. To adequately protect
your card data:
nConfirm firewalls, virus protection and access control.
n
n
Copyright © 2009 Princeton Payment Solutions
Implement data encryption to conform to the PCI requirement for a
segregated key management system and demonstrable key roll-over.
Use tokens to move encrypted data to a secure and segregated server. Token
values – or “surrogate card numbers” – replace the actual data values within
the SAP system, so that the card data can be stored in an external secure data
vault and the SAP system never touches it.
www.prinpay.com
White Paper: How to Eliminate PCI-DSS Exposure in SAP® Environments
6
Business Process Transparency: Don’t Complicate Existing Processes
The simpler you can make your encryption upgrade, the more smoothly it will go. Try
to avoid affecting existing processes as much as possible.
nYour staff should be able to use the same order entry screens as before.
n
n
Make sure additional key strokes or fields are not necessary in order for your
call center to take an order.
Look for systems that allow for continuity of business process and that
minimize disruptions.
Reduce the Scope of PCI
If a system never touches card data (in other words, does not transmit, process, or store
it), then the PCI requirements don’t apply to it. Use these tips to keep as many systems
out of the PCI scope as you can.
nTake your database outside of PCI scope through the use of tokens.
n
n
n
Take the SAP system out of scope by conducting tokenization at order entry.
Segregate the order entry network from the rest of the systems to keep other
networks “clean” of card data, and thus outside of PCI scope.
Keep field sales devices (such as laptops) and their networks out of scope by
tokenizing data before entry into the system.
By reducing the scope of PCI, you can significantly reduce the cost and effort involved
in complying with the PCI standard, as well as increase your chance of success in a PCI
assessment.
Plan for Future Uses of this Technology
States are enacting new laws to protect personally identifiable information (PII) – such
as driver’s license numbers, birth dates, bank account data, and other sensitive information – using mechanisms similar to the PCI. To both meet future mandates and to
protect your customers’ data, make sure that your data protection / encryption solution
can be used for personal information such as HR data or vendor data.
Using Tokens to Protect Card Data
SAP has certified a number of vendors who have developed solutions to assist with SAP
payments and protection of data. SAP has not identified a certification process specific
to PCI data encryption, however, the payment card interface vendors offer various
solutions and strategies that meet the PCI standards.
There are currently two approaches to addressing the PCI mandates for handling credit
card numbers within the SAP system:
1. Encrypt the data within a proper security infrastructure within the SAP
system itself. (Keep in mind that the SAP system’s internal encryption does
not meet PCI requirements, so a third-party solution is required.)
2. Remove all credit card numbers from the SAP database and store them in
a secure data vault. In place of the card number or encrypted card number,
use a token value.
Copyright © 2009 Princeton Payment Solutions
www.prinpay.com
White Paper: How to eliminate PCI-DSS exposure in SAP® Environments
7
PPS’s traditional encryption within the SAP system solution (option 1 above), with
its separate key management and seamless key roll-over, has consistently met PCI
requirements and passed assessments. However, while satisfying the PCI mandate, the
“encryption within the SAP system” approach kept the SAP environment in scope for
PCI. In order to further simplify the PCI process, PPS has now developed a solution for
option 2 above: the CardSecure token server.
When a Token encryption
solution is combined with a
“token aware” Payment Card
Interface application that can
convert the token to the card
value (such as PayWare) to
process payments, the SAP
system can be deemed out of
scope by the DSS assessment.
The PPS Token Solution
By moving all credit card data to another secure database (data vault) and instead storing a token value in the SAP system to represent the actual card number, companies can
take their SAP systems outside of the PCI scope. The external data vault can be isolated
to its own network segment with access tightly controlled, which considerably shrinks
and simplifies the task of PCI compliance. Card data is encrypted in this external data
vault, and key management and rollover are invisible to the SAP system.
Working together with PPS’s PayWare Payment Card Interface, the CardSecure encryption solution now has the ability to implement a token approach as illustrated in the
following diagram. This architecture can take the SAP system out of PCI scope.
SAP
SAP GUI with
Desktop Tokenizer
Web Site
(WebSphere, IIS, Tomcat)
PCI Servers
CardSecure
PayWare
Payment Card
Processor
Copyright © 2009 Princeton Payment Solutions
www.prinpay.com
White Paper: How to Eliminate PCI-DSS Exposure in SAP® Environments
8
PPS’s token solution includes a built-in key manager that can integrate with an external hardware security module (HSM). The system allows unlimited use of tokens – we
do not charge by the token, and you will not run out of tokens. PPS tokens are also
reusable.
As an added benefit, our CardSecure token server protects other personal information,
such as Driver’s Licenses, generically called PII data. It is designed to adapt to evolving
requirements regarding the display of this information.
SAP Tokens and Masking
A PPS token will show only the first two and last four digits of a card number, so there
is no need for a card masking function to obscure the full card number from users who
don’t need to see it. The token in the external encryption database consists of eight
alphanumeric characters, allowing over 200 trillion values. Wrapping the token with
the first two and last four digits of the full card effectively creates a masked value that
is human-readable by your call center staff for card number confirmation purposes –
without a separate masking function. The wrapped token is not actual cardholder data
and thus can be safely seen by anyone – it need not be masked. The token value for a
test Visa card is shown in the screen from our CardSecure GUI below.
PRINCETON
PAYMENT
SOLUTIONS
CardSecure Server
CardSecure Server Login
Login Name:
Password:
PRINCETON
PAYMENT
SOLUTIONS
CardSecure Server
CardSecure Status
KeyGen
CardSecure Token Search
Service Manager
Key Manager
Token Decrypt
Token Search
Token Rollover
You are logged in as admin1 on system rlaptop
Token Cleanup
1234123412341234
Log View
User Manager
Health Check
Change Password
Logout
You are logged in as admin1 on system rlaptop
Copyright © 2009 Princeton Payment Solutions
www.prinpay.com
White Paper: How to Eliminate PCI-DSS Exposure in SAP® Environments
9
With the token approach, access to full card numbers can be provided to users who
need it through CardSecure, further removing the SAP system from the PCI scope.
SAP Tokens and Data Retention
The PCI standard requires cardholder data to be deleted in a timely fashion, yet records
of financial transactions must generally be kept for seven years. The token approach
facilitates both objectives by allowing the encrypted card data to be securely deleted,
while retaining the token indefinitely. Should the card ever return, the system will assign the same token used previously, ensuring the consistency of all transactions.
Onsite or Offsite Tokens?
You have two options for encrypting your data in a way that will pass the long form: a
solution that encrypts your data onsite within your firewall, or a hosted solution with a
third party service provider that stores encrypted data offsite. Both solutions use similar
methods for securing data and will pass requirements outlined in the long form:
nEncryption is used to protect the data, whether it is stored onsite in a secure
data vault or offsite in someone else’s secure server.
n
Both solution types can use a token strategy to replace card data with a
token value that represents the encrypted card data, which is securely stored
elsewhere. Token strategies reduce the scope of systems that the PCI looks at.
Both solutions are secure: the difference lies in cost (hosting offsite is substantially
more expensive) and business proposition. In addition, the offsite data is out of your
control. That may sound like it’s a good thing. But if there’s a breach, even if your data
is offsite, your company is still ultimately responsible for it.
Copyright © 2009 Princeton Payment Solutions
www.prinpay.com
White Paper: How to eliminate PCI-DSS exposure in SAP® Environments
10
Payment Card Interface Integration
The final step to keep card numbers out of the SAP application – and thus reduce the
SAP system’s PCI exposure – is to enable the external Payment Card Interface module
(such as PayWare) to connect to the token server as a trusted application. This structure eliminates the need for the SAP system to decrypt the card number for authorization and settlement; the detokenized (clear) card number is restricted to the specialized
PCI servers.
PayWare
Payment Card
Processor
SAP
CardSecure
NON-PCI ZONE
PCI ZONE
With CardSecure and PayWare in place, the payment card process now looks like this:
nCard information is captured and saved in the sales order.
n
n
n
n
n
Copyright © 2009 Princeton Payment Solutions
An SAP conversion exit extracts the card number before it reaches the SAP
data table and sends the card data to the CardSecure token server. CardSecure
encrypts the card number and stores it, returning a token to be stored in the
SAP data table (in the CCNUM field).
Individual users can be granted authority to see the full number.
To search within the SAP system for transactions using a specific card, the card
number is converted to its token (as for order entry) and the search uses the
token value. The user sees the correct results but SAP isn’t exposed to the
card number.
Key rollover happens completely within the CardSecure database. There is no
key rollover in the SAP system.
Payment card interfaces that are “CardSecure aware,” such as PayWare ERP,
receive tokens in the authorization and settlement requests and in turn
convert these tokens to clear (actual) card numbers for processing by the
Clearinghouse.
www.prinpay.com
White Paper: How to Eliminate PCI-DSS Exposure in SAP® Environments
11
Common Fallacies
The PCI requirements are complex, and confusion is fairly common. It’s important to
ask the right questions and fully understand the ramifications before you make a decision about the best payment and encryption solutions for your company.
Remember that the Payment Card Industry calls for protection of data in storage, processing and transmission. A solution that promises technology for only one or two of these is
not giving you a complete solution to your PCI needs. This section addresses common
fallacies that you may hear from vendors as you investigate options for securing your
data.
False
How can you expect to meet PCI requirements if you have card data on your
facility? We will take it off your facility and put it on ours – otherwise you won’t
pass.
Where the data vault resides – onsite or offsite – has nothing to do with PCI compliance. As long as your data is properly secured, you can meet PCI requirements regardless of where the data resides. In fact, storing the data onsite is a less expensive option
that can accommodate other types of personal data as well (bank account numbers,
driver’s license numbers, birth dates, etc.).
For sites that only take orders over a web page owned by an outside processor, this
approach may help relieve your PCI obligations. But if your business process includes
a call center or any employee taking card data for an order or for payment on any
outstanding invoice, offsite data storage does not relieve you of the PCI burden. Should
you decide to go offsite with storage, the cost could be many times that of keeping it
onsite, even factoring in cost of the appropriate controls (encryption, limited access to
data, etc.)
Also, although card data is likely the first set of data needing security, many states are
now passing laws to protect other personal data such as social security, drivers license
and bank account numbers. You should plan for this new data and its cost as you make
decisions to secure the data in your systems.
False
If you store the data offsite, you are not responsible for it anymore.
Many a CIO would prefer that another company be responsible for protecting sensitive
data, rather than his or her company. Offsite facilities can be PCI-compliant but they
will not indemnify you should there be a break-in or a breach. The merchant (you) is
still responsible for the data even though it is not on your facility. Check your merchant
agreement – the liability you took on for this data cannot be passed to another facility
unless this indemnification is done so in writing.
And of course, regardless of where data is stored, the damage to your reputation is
staggering in the event of a breach.
Copyright © 2009 Princeton Payment Solutions
www.prinpay.com
White Paper: How to Eliminate PCI-DSS Exposure in SAP® Environments
12
Maybe
Our hosted payment approach uses tokens. This method will limit your PCI
exposure by taking card numbers out of your systems.
Again, taking your company “out of PCI” means no numbers in transmission, processing or storage. If your call center or order entry process takes a card number to initiate
the purchase process – even though it later gets tokenized – your SAP application, the
call center and the network are still within PCI scope. Offering tokens alone as a PCI
solution is like offering a three-legged stool with just one leg on it.
Summary
The PCI mandates protection of electronic storage, processing, and transmission of sensitive
card data. Most companies define the following goals for their PCI initiatives:
nProtect the card data.
n
n
n
Install encryption in a way that does not change the order process.
Reduce the scope of PCI by having your card data “touch” as few applications,
systems, and networks as possible.
Implement a “future-proof” solution – be able to use the same system for
PII data to comply with upcoming laws in these areas. (PII addresses other
personally-identifiable data such as driver’s license number, bank account
number, and birth date.)
PPS’s CardSecure token server meets all of these goals and provides many additional
benefits:
nSecurely encrypts and stores data on an external, centralized data vault to
keep it out of the applications in your environment. Tokens can take the SAP
system out of the scope of your next PCI assessment, which considerably
shrinks and simplifies the assessment process.
n
n
n
n
n
n
Copyright © 2009 Princeton Payment Solutions
Allows the encrypted card number to be securely deleted, while retaining the
token indefinitely.
Negates the need for an additional card masking capability, while still
obscuring card details from users who don’t need to see the full number.
In the near future, the CardSecure token server will be able to tokenize card
data before it is entered into field order entry systems such as laptops, thus
keeping those computers and networks out of the PCI scope.
PPS does not charge on a per-token basis. Tokens are re-usable, and you won’t
run out of them.
Key management and rollover are securely conducted and invisible to the SAP
system.
CardSecure’s security structure can protect personal data (bank ACH numbers,
social security numbers, salary details, etc.) that is difficult to protect with the
encryption-only approach.
www.prinpay.com
White Paper: How to Eliminate PCI-DSS Exposure in SAP® Environments
13
PPS can also help you evaluate your needs. We have more than eleven years of experience building payment and encryption solutions for the SAP system. Our PayWare ERP
solution became the first implementation available and has since been a leader in complex SAP payment environments. Long-time users of PayWare ERP include The New
York Times Company, General Electric, Brother International, Reliant Energy, Johnson
& Johnson and SAP itself.
In 2004, PPS was the first company to encrypt data within the SAP system and pass
a PCI audit with our CardSecure solution. Subsequently, we were the first to create a
token infrastructure to take the SAP system completely out of PCI scope in 2008. Companies such as Adobe, Brother, General Electric and Reliant Energy rely on CardSecure
to encrypt and protect their credit card information.
Please contact us to discuss your environment and to help you determine what type of solution is
best for your company.
Contact: Alex Chapman
Email: [email protected]
Phone: +1 (203) 952-5715
www.prinpay.com
Copyright © 2009 Princeton Payment Solutions
www.prinpay.com